ASCII Adjust After Multiplication 1

[rickbarclay]

My newest project:
Develop a program that will allow a user to input
two numbers of any length.. and derive the product of the two numbers.

Strategy:
User enters numbers of any size into a string. Convert ascii to integer. Math is performed one digit at a time.

This a good opportunity to use AAM (ascii adjust after
multiplication); however, I have a couple questions on how to use this
operation.

From what I understand, one would load the AL (for 8bit 'char'
operations) and perform a normal MUL operation.. thus leaving the
product in the AX register. The AX now contains a value that is
(ascii*ascii). At this point, use AAM to convert to an unpacked
decimal representation.

Next, to turn this value back into an ascii character.. The closest
example on how to do this in Kip Irvine's book on page 252 (in the AAA program example) which indicates that one can OR the (ascii*ascii) product
with its unpacked decimal to obtain the comperable ascii value. Is
this a valid operation? If so, will this work in all cases? This
would seem to be a very cool property.. and I am suprised we were
never taught this technique in class..

Summary:
I think AAM is comperable to c++'s atoi( ) function.. whereas 'OR'ing
the product of two ascii with it's unpacked decimal resembles the
itoa( ) function.

So is my logic correct? If not, please point out any fallacies. Here is a simple explaination of ASCII Adjust Operators.. doesn't go into much detail at all:

http://docs.sun.com/app/docs/doc/80...jct9o0ao?a=view

Another problem to tackle:
With this type of program, it would be nice to create new memory at runtime depending on the size of the numeric strings entered. Is it possible to declare new memory at runtime? IF so how? IF not, should I just declare bunch of space at assembly and hope that is good enough?

 

[lionelhill]

memory allocation is down to the operating system, so it depends on the platform where you're using your assembly. Usual old-fashioned strategy of languages such as C and Pascal is to prepare the exe file (assuming a DOS type environment) to request as large a space as possible and then have their own heap allocation system to control memory.

To be honest, I'm not a great fan of the ascii adjust instructions. They're a bit of a hang-on from former times. Of course they do give you a way to handle numbers of arbitary length, but assuming you actually want to multiply some genuinely very long numbers for a genuinely useful reason, you may want a quicker way to do it. If you work in individual decimal places, it's going to be really slow. Wouldn't it be better to convert to genuine binary numbers of arbitary length and multiply them (still a much harder task than addition)?

The or-ing to get ascii thing: I assume they mean that ascii codes of the digits "0" to "9" are simply the values 0 to 9 plus a bit, so you can either get the ascii code by adding the ascii value of "0", or by or-ing with the ascii value of "0"; it makes no diference. It wouldn't work unless the number you're starting with is 0-9.