translate a dword number in a base from 2 to 16

[dedndave]

i think i have found what could be described as a bug in crt__itoa
while it uses a faster routine for base 10 values, it is a signed routine   :lol

Code Select Expand

        BaseN   crt__itoa
Base 2  2498    2325    11111111111111111111111111111111
Base 3  1743    1556    102002022201221111210
Base 4  1311    1201    3333333333333333
Base 5  1175    1087    32244002423140
Base 6  1105    998     1550104015503
Base 7  1067    934     211301422353
Base 8  967     862     37777777777
Base 9  969     864     12068657453
Base 10 902     107     -1
Base 11 900     798     1904440553
Base 12 834     657     9ba461593
Base 13 828     645     535a79888
Base 14 834     737     2ca5b7463
Base 15 832     656     1a20dcd80
Base 16 764     634     ffffffff

[MichaelW]

It's not a bug, that is the documented behavior:

http://msdn.microsoft.com/en-us/library/yakksftt(v=VS.71).aspx

[dedndave]

yah - ok
"we found a bug - let's change the documentation and call it a feature"

[dedndave]

well - "-1" is a short string and, thus, a faster conversion
so, in order to get a valid comparison, i changed the value to 7FFFFFFF...

Code Select Expand

        BaseN   crt__itoa
Base 2  2439    2257    1111111111111111111111111111111
Base 3  1700    1520    12112122212110202101
Base 4  1321    1213    1333333333333333
Base 5  1180    1074    13344223434042
Base 6  1041    941     553032005531
Base 7  1038    935     104134211161
Base 8  971     864     17777777777
Base 9  902     801     5478773671
Base 10 909     788     2147483647
Base 11 864     781     a02220281
Base 12 836     682     4bb2308a7
Base 13 836     689     282ba4aaa
Base 14 835     659     1652ca931
Base 15 768     645     c87e66b7
Base 16 768     591     7fffffff

personally, i say they should all either be signed or unsigned
not changing underwear because the radix has changed   :lol

[ToutEnMasm]

the proc i've just posted is just as fast as dw2hex_ex and would be faster if i got rid of the prologue and epilogue code and used esp and also it could be faster if i used trashable regs (maybe use edx instead of edi to save a push and pop)

I agree with that

For those who are interested i join the brother of your dwtohex,dwtobin
The masm32 have a very bigger table

.data
   ;---------------0------1------2------3------4------5-------6-----7---
   bintable BYTE "0000","0001","0010","0011","0100","0101","0110","0111"
   ;------8----9------10----11----12-------13----14-----15---
   DB "1000","1001","1010","1011","1100","1101","1110","1111",0
   ;-------------------------------------------------------------
.code
dwtobin PROC USES esi edi,value:DWORD, buff:DWORD
   mov ecx, 8
   mov esi, value
   mov edi, buff
   
@@:
   rol esi, 4      ;4 bits de poids fort
   mov eax, esi
   and eax,0000000Fh
   mov eax, dword ptr bintable[eax*4]
   mov [edi], eax
   add edi, 4
   sub ecx, 1
   jnz @B
   mov BYTE PTR [edi], 0
   ;suprimer zeros inutiles
   mov esi,buff
   mov edi,buff
   @@:
   .if byte ptr [esi] == "0"
      inc esi
      jmp @B
   .endif
   .if byte ptr [esi] == 0
      dec esi
      mov byte ptr [esi],"0"
   .endif
   mov eax,0
   @@:
   .if byte ptr [esi] != 0
      movsb
      inc eax ;count the number of char
      jmp @B
   .endif
   mov BYTE PTR [edi], 0   ;and return the number of char
   ret
dwtobin ENDP   

[MichaelW]

"we found a bug - let's change the documentation and call it a feature"

Efficiency in action :bg

Actually, that behavior has existed since the DOS days.