A cute hex-dumping trick

[Larry Hammick]

Code Select Expand

al2hexax:
    db   0D4h,10h   ;This is AAM with base sixteen instead of base ten -- splits AL into two nibbles.
    call @F
    xchg al,ah
@@: and  al,0Fh
    cmp  al,0Ah
    sbb  al,69h    ;0-9 comes out "0"-"9", and 10-15 comes out "A"-"F".
    das
    ret


[Larry Hammick]

I forgot to leave out the unnecessary "and al,0Fh". Should be

Code Select Expand

al2hexax:
    db   0D4h,10h   ;This is AAM with base sixteen instead of base ten -- splits AL into two nibbles.
    call @F
    xchg al,ah
@@: cmp  al,0Ah
    sbb  al,69h    ;0-9 comes out "0"-"9", and 10-15 comes out "A"-"F".
    das
    ret

[dedndave]

hi Larry - i remember the trick of using AAM that way
but, i thought i had read somewhere that it would cause an invalid instruction exception
in any event, AAM is a pretty slow instruction - 18 clocks i think - on an 8088, it was ~80 clocks
and'ing/shifting/or multiplying to split the byte is faster - just not as small

your code is really 2 tricks - the other being the conversion to ASCII hex
that seems like a goodie, replacing my old 4 liner that finds the ASCII hex for a single nybble...
(i say "my" - i stole it from IBM XT BIOS - lol)

        add     al,90h
        daa
        adc     al,40h
        daa

but, it doesn't look right - have you tested it ?
the difference between SBB with CF and SBB without CF is only 1
the switch needs to be a delta of 7

EDIT - oh - i think i get it - the DAS takes care of the other 6

if ( (al and 0Fh) > 9 or (AuxC = 1)) then
        al := al -6
endif
if (al > 9Fh or Carry = 1) then
        al := al - 60h
endif

[Larry Hammick]

Yes D&D the AMM is really a mini division-with-remainder operation, intrinsically slow. It's invalid altogether in 64-bit code, and so are the other binary-coded-decimal instructions. But it is documented by Intel, and not "deprecated" at all.
I figure, in any little ascii formatting routine, whose only purpose it to produce visually meaningful output (hex dumping or line trimming or the like), any microseconds lost to slow opcodes will be negligible alongside the hopelessly slow human brain. :D But for sending big chunks of data in base64 or the like, speed would count. Just my philosophy.

[dedndave]

well - i tend to agree, actually
anything that cranks out display values is not usually speed-crtical
there aren't many cases when you want to see 5,000,000,000 values all at once
on the flip-side, making code a little smaller is not really important at all nowdays
make it fast as you can, so long as the size is reasonable
i just enjoy the little code "trix"

[dedndave]

one thing i really like about your trick is that AH doesn't get trashed - with my old code, DAA destroys AH

[geppy]

and x64 destroys DAA  :wink
so you'll have to rewrite you code eventually

[dedndave]

what makes you think we want to write 64-bit - lol
"I do not support x64 architecture"
hopefully, i can use xp until i die, too
i think the 64-bit processors do support it in 32-bit mode - we are good to go