Any assembly programmers here?

[Ashkael]

Hello Lurkers,

Here’s wondering if there are any fellow electrical/computer engineers here that could give me a little hand with an assignment.

See, as a final project in one of my classes my team has to code a calculator program. My part of the work consists of getting numbers from an external keypad device and sending them over to the arithmetic module of the program for calculation. The user is supposed to enter his numbers for calculations in decimal (base 10). I get those numbers encoded in ASCII from the keypad, convert them to HEX, and store them side by side in some buffer in RAM. So, what I have now in my buffer is a string of HEX-Encoded Decimal numbers.

Suppose the user enters: 1 2 3 4 5

This means that in my buffer I now have:

Buffer: $01 $02 $03 $04 $05 (1 byte long each)


My problem is this: how can I convert these HED’s to proper HEX to send them over to the arithmetic module (which, by the way, is expecting an 8-byte long HEX number as any of the two operands for the calculation)?

An easy way of doing this conversion is to simply multiply each individual HED by decimal 10^0, 10^1, 10^2, … 10^n, from less significant to most significant and adding all of these results. Problem? The biggest accumulator I have available can only hold 2 bytes, therefore the built-in multiplication instruction can only multiply 1-byte long numbers.

Can anybody give me any help with this? :(

[LavCat]

Hello Lurkers,

Here’s wondering if there are any fellow electrical/computer engineers here that could give me a little hand with an assignment.

See, as a final project in one of my classes my team has to code a calculator program. My part of the work consists of getting numbers from an external keypad device and sending them over to the arithmetic module of the program for calculation. The user is supposed to enter his numbers for calculations in decimal (base 10). I get those numbers encoded in ASCII from the keypad, convert them to HEX, and store them side by side in some buffer in RAM. So, what I have now in my buffer is a string of HEX-Encoded Decimal numbers.

Suppose the user enters: 1 2 3 4 5

This means that in my buffer I now have:

Buffer:  $01 $02 $03 $04 $05 (1 byte long each)
My problem is this: how can I convert these HED’s to proper HEX to send them over to the arithmetic module (which, by the way, is expecting an 8-byte long HEX number as any of the two operands for the calculation)?

An easy way of doing this conversion is to simply multiply each individual HED by decimal 10^0, 10^1, 10^2, … 10^n, from less significant to most significant and adding all of these results. Problem? The biggest accumulator I have available can only hold 2 bytes, therefore the built-in multiplication instruction can only multiply 1-byte long numbers.

Can anybody give me any help with this?  :(
[right][snapback]61388[/snapback][/right]

You don't say what architecture. I suggest doing a table lookup on each digit and adding.

[Ashkael]

You don't say what architecture.  I suggest doing a table lookup on each digit and adding.
[right][snapback]61394[/snapback][/right]

I forgot about that. We are using the Motorola M68HC11E9 development board. Regarding the lookup table, man that's a great idea, I didn't thought of that earlier. It eliminates the need for multiplication. Gonna try that right away. :)

[LavCat]

I forgot about that. We are using the Motorola M68HC11E9 development board. Regarding the lookup table, man that's a great idea, I didn't thought of that earlier. It eliminates the need for multiplication. Gonna try that right away. :)
[right][snapback]61429[/snapback][/right]

You are welcome, I hope the calculator works! I remember one commercial calculator that I used in college in which multiplication was not commutative. More recently Intel had a small problem with the floating point lookup tables in the first Pentium.

[whyBish]

Check out the Reference manual section under

http://www.freescale.com/webapp/sps/site/p...=01624684498635

My bet is that if you store the decimal as two digits per byte (rather than the one per byte you are currently using) there will be some sort of hex to decimal conversion in the instructionset itself.

Worth a shot, but unfortunately the download is taking far too long for me on dialup. :(

[whyBish]

Nope, looks like it doesn't.

There is the DAA op to deal with BCDs but that is only good if you are performing additions, so you will need the hex internal representation.

Anyway, good luck. Assembler programming is fun : trying to figure out what an assembler program is supposed to be doing on the other hand ...

[kandrathe]

Demonstration program for 68HC11E9 -- 24 bit multiplication with 48 bit result and 24 bit division of a 48 bit dividend.

or

The source code for this General Math package for the MC68HC11.

[Ashkael]

Anyway, good luck.  Assembler programming is fun : trying to figure out what an assembler program is supposed to be doing on the other hand ...
[right][snapback]61477[/snapback][/right]

Thanks. Gotta agree with you there, it sure is fun. However, reading someone else's code is as bad as trying to read someone else's handwritting or math. Also, isn't it funny that, when you look back at your code 2 or 3 later, you can't tell what the heck you did?

[Ashkael]

Thanks for the links. I had already checked those programs, though, but didn't bother to try them because the people that are in charge of the math module already coded better arithmetic routines. I ended up using them.

[Ashkael]

You are welcome, I hope the calculator works!  I remember one commercial calculator that I used in college in which multiplication was not commutative.  More recently Intel had a small problem with the floating point lookup tables in the first Pentium.
[right][snapback]61467[/snapback][/right]

Hmm? How can multiplication not be commutative? :blink: The way I have the calculator coded so far all operations with the exception of division are commutative. The overall design of the operation-handling routines must have been real crap in that calculator of yours! :P

Edit: Talking about crappy routines, I was running some tests on my calculator and found out that subtraction wasn't working correctly all the time. It turns out that the genius that coded the subtraction routine is expecting the first operand to be positive and the second one to be negative 100% of the time. Now I have to handle this mess and add extra code to get the subtraction working right. That's what happens when you outsource jobs to idiots. :angry:

[whyBish]

Hmm? How can multiplication not be commutative?

Edit: Talking about crappy routines

I'm guessing that it would be something to do with the low order bits.
As an example, on a machine with an 8 bit accumulator, of you want to perform 16*16*(1/16) (doing shift for division) you will get an overflow if you do the two multiplications first, since 256 doesn't fit in an 8 bit accumulator, but if you do 16*(1/16)*16 you get the correct answer. Unfortunately, if you do 15*16*(1/16) in the way that worked in the above example (15*(1/16)*16) you will get the 'wrong' answer due to loss of precision, but would have been fine if you multiplied the two numbers first before the division.

[whyBish]

Also, isn't it funny that, when you look back at your code 2 or 3 later, you can't tell what the heck you did?
[right][snapback]61713[/snapback][/right]

That's probably (IMO) the most important lesson you can learn. Knowing that it will not just be others that will have problems looking at your code but also yourself. Good skills at commenting code is unfortunately rather rare where I've been working so far, but the best I've seen was from an ex-mainframe programmer who has a ratio of about 6 lines of comments per line of code in Java. (He implements a lot of the critical stuff so performance tweaks etc. can make the code obscure, and not wanting someone to inadvertantly remove an important ++ or similar is crucial)