Keep DAA! (was Re: 8086 bugs)

Jim Battle frustum at pacbell.net
Sat Dec 10 01:51:28 CST 2005


J.C. Wren wrote:

> Noooooo........!  DAA has a very useful function.
> 
>    AND AL,00fh
>    ADD AL,090h
>    DAA
>    ADC AL,040h
>    DAA
>    RET
> 
> Now, what's it do?
>      --jc

Chuck Guzis already posted that one yesterday towards the start of this (sub)thread:
> It's still there--and is one of the reasons this little tibit still works
> to convert a 4-bit binary value to ASCII hex:
>        
>         and   al,15
>         add   al,90h
>         daa
>         adc   al,40h
>         daa

Miraculously I've been able to avoid learning the x86 instruction set, but that 
is probably 8 bytes (the same sequence would be on an 8080 or z80).

But you can do z80 code like:

	add  a,'0'
	cpi  '9' + 1
	jr   n,foo
	add  a,'a'-'0'
foo:

which is also 8 bytes.  yeah, there is a branch in it, and it doesn't have the 
coolness associated with the tricky way, but it is clearer, probably runs at 
about the same speed.

So you can't really justify DAA using this example.  DAA was for doing BCD math; 
and that is the start and end of the justification.

I know that the TI CC-40 and TI-74 calculators (and I'm sure there are others) 
used base 100 arithmetic -- two digits per byte like bcd, but in some ways more 
straightforward.  When they normalized their mantissa there was two digit 
granularity.

One thing a bit puzzling is rather than using the msb of one of the mantissa 
bytes to indicate the sign (since a byte holds on only 0-99, the msb is free), 
instead they indicate such by 1's complementing the first mantissa byte.  I'm 
sure there is a reason why for their given instruction set this is superior 
(test msb and clear it before preforming mantissa operation would seem simpler 
than test msb and conditionally complement, but whatever).





More information about the cctech mailing list