# Help With Assembly Programming

Discussion in 'Mac Programming' started by MacMuttonchops, May 11, 2010.

1. ### MacMuttonchops macrumors member

Joined:
Jun 5, 2008
Location:
New York, NY
#1
Hey all,

Hopefully some of you know assembly. I'm using Boot Camp to do this, so there's my Mac tie-in. I trust this forum better.

I'm attempting to write an assembly program that performs Euclid's algorithm on two two-digit integers and then displays the highest common factor. We have to do the algorithm a certain way.

Here's the diagram of how it has to work: http://cl.ly/13FR
And here's my code: http://cl.ly/12iN

It's compiling beautifully with no errors (on the first try, no less!), so I'm guessing there's a problem with my logical flow here. It only works if A>B and if B is already the highest common factor. For example, 20 and 10, 40 and 20, 60 and 30...you get the idea. However it will only half work if you put in something like 66 and 33, or anything that will return an answer that doesn't end in zero. 66 and 33 produce an answer of 3N...which leads me to the second problem.

When we do the division, I'm dividing the answer by ten to get the first digit plus a remainder. I'm then multiplying the remainder by ten to get the second digit and then printing the two digits. According to my logic: say the HCF is 33 (as with 66=A and 33=B above), I would divide 33 by 10 to get 3 with a remainder of 3/10. I take the 3, convert it to ASCII and then save it. Then I take the 3/10, multiply it times ten, convert that answer to ASCII, and then store that. Then I print both digits. I'm guessing that I'm incorrect in thinking this way because I'm getting an "N" instead of a number as an output. That would mean me using the remainder from the division and converting that to ASCII is not actually what I want, since I'm getting a character, right?

Otherwise, if A<B or B is not already the highest common factor, the command prompt will freeze. It won't throw any errors, I just get Windows telling me to close the program because it's no longer responding.

I've commented this thing to death, so if anyone could read through it and see where my logic is flawed, I'd really appreciate it.

Thanks!

2. ### mrbash macrumors 6502

Joined:
Aug 10, 2008
#2
Your logic seems to be sound, but one of your routines is not doing what what you think it is. I would recommend you create tests for each of your routines to ensure that you aren't making any assumptions.

The difficulty with assembly is that you are prone to altering the entire stack in a subroutine.

3. ### chown33 macrumors 604

Joined:
Aug 9, 2009
Location:
Sailing beyond the sunset
#3
Your logic is flawed: the remainder would be 3, not 3/10. Work it out by hand using traditional long division.

And as mrbash wrote, you have a bug in your looping algorithm where the code you wrote doesn't match the flowchart or your description. I recommend that you walk through your current code using pencil and paper and the two input values that cause the failure. Write down the registers and values at every step, and manually perform every arithmetic and conditonal-branch operation. You're essentially emulating the CPU. It shouldn't take more than twice around the loop to spot the problem, if that.

To summarize: you have at least two distinct bugs. One is in the looping algorithm. The other is in your output-producing code. Those are the two I saw. There may be more. I didn't look that hard.

4. ### MacMuttonchops thread starter macrumors member

Joined:
Jun 5, 2008
Location:
New York, NY
#4
Thanks. I got it to work! I would have never guessed the remainder. I noticed that I had cmp ax, bx when I was checking to see if B>A. I flipped those around and...voila! The compare is the bug you found in the algorithm, right? And in the output-producing code, you were referring to my remainder snafu, correct?

Thanks for the help!

5. ### chown33 macrumors 604

Joined:
Aug 9, 2009
Location:
Sailing beyond the sunset
#5
Yes. Yes.

You're welcome!