Fast hexstring to binary conversion

[TimoVJL]

An old AMD is still in use and i got it from my niece, when i bought her a HP Intel i5 laptop.
I let AMD Ryzen just rest with it's 32 GB memory in upstairs, as your AMD Athlon Gold 3150U have same kind of CPU, so don't help tests.

[HSE]

Congrats, you beat MasmBasic

Apparently it's no so hard , but  not always 

Code Select Expand

Intel(R) Core(TM) i3-10100 CPU @ 3.60GHz (SSE4)

20432   cycles for 100 * MasmBasic Val
3208    cycles for 100 * Masm32 SDK hex2bin
20506   cycles for 100 * strtoull
2656    cycles for 100 * HexVal

20648   cycles for 100 * MasmBasic Val
3658    cycles for 100 * Masm32 SDK hex2bin
20626   cycles for 100 * strtoull
2764    cycles for 100 * HexVal

20714   cycles for 100 * MasmBasic Val
3649    cycles for 100 * Masm32 SDK hex2bin
20098   cycles for 100 * strtoull
2762    cycles for 100 * HexVal

20720   cycles for 100 * MasmBasic Val
3628    cycles for 100 * Masm32 SDK hex2bin
20784   cycles for 100 * strtoull
2771    cycles for 100 * HexVal

20596   cycles for 100 * MasmBasic Val
3613    cycles for 100 * Masm32 SDK hex2bin
20639   cycles for 100 * strtoull
2734    cycles for 100 * HexVal


[jj2007]

Apparently it's no so hard , but  not always 

One should not compare apples and oranges: you can throw 0x123, $123, 123h, 1234 (ordinary decimal number) or 101010101010b at MasmBasic Val(), and always get a correct answer - plus, for fast parsing, the number of used characters in edx *).

The proper comparison is between strtoull and the new HexVal macro, which both handle hexadecimal Ascii strings; and there I see a factor 7.x ;-)

Besides, while the strtoull docs says "long long" (IBM: "strtoull() returns the converted unsigned long long value, represented in the string"), it doesn't say that you have to grab the long long from eax and edx:

Code Select Expand

include \masm32\MasmBasic\MasmBasic.inc
  Init
  Cls 3
  MbHexQ=1        ; limit Hex$ to 16 bytes
  Dll "ucrtbase"
  Declare strtoull, C:3
  Let esi="1234567890AbCdEfh"
  PrintLine "strtoull returns ", Hex$(strtoull(esi, 0, 16))
  PrintLine "HexVal returns  ", Hex$(HexVal(esi, 64))
  MbHexQ=0        ; no limit
  Inkey "HexVal returns  ", Hex$(HexVal("1234567890AbCdEf1234567890AbCdEfh", 128))
EndOfCode

Code Select Expand

strtoull returns 90ABCDEF
HexVal returns  12345678 90ABCDEF
HexVal returns  12345678 90ABCDEF 12345678 90ABCDEF
*) RichMasm uses Val(): Paste 0x123, $123, 123h, 1234, 101010101010y, then select each number and hit Ctrl N.

[HSE]

Hi JJ,

One should not compare apples and oranges

If MasmBasic Val() is not comparable, just don't compare 

Apparently strtoull is less friendly than MasmBasic Val(), but can process more numeric bases. I don't even know about that function. Good investigation 

[jj2007]

can process more numeric bases

If I need to convert octal numbers, I'll use strtoull then, thanks.

[HSE]

Just to note that strtoull return edx:eax

Code Select Expand

strtoull returns in edx 12345678
strtoull returns in eax 90ABCDEF

[jj2007]

while the strtoull docs says "long long" ..., it doesn't say that you have to grab the long long from eax and edx

HexVal(pStr, 64) returns a QWORD in xmm0, which is easier to handle than two volatile registers.

[daydreamer]

Best print performance to put code in Workerthread you have a whole separate set of registers and main thread prints results
But I have no knowledge of ARM SIMT works???
So easiest to port to ARM assembler is stick to use scalar gp registers? Both 32 and 64 bit?

[jj2007]

Hi Daydreamer, you are obviously in the wrong thread...

[TimoVJL]

It really depends on the calling convention used, but typically EAX is used for 32-bit and smaller integral data types, floating point values tend to use FPU or MMX registers, and 64-bit integral types tend to use a combination of EAX and EDX instead. Then there is the issue of complex class/struct types, in which case the compiler may decide to optimize away the return value and use an extra output parameter on the call stack to pass the returned object by reference to the caller.

Does the return value always go into eax register after a method call?

[jj2007]

64-bit integral types tend to use a combination of EAX and EDX

HexVal(pStr, 64) returns a QWORD in xmm0, which is easier to handle than two volatile registers.

HexVal("1234ABCDh") returns the value in eax, which covers probably 99% of all use cases.

When I need a 64-bit value, however, xmm0 is a far better choice, at least in a library that has no problem to Print Str$(xmm0)

It's not my fault that the C/C++ family has problems with accepting xmm regs as input...

[TimoVJL]

It's not my fault that the C/C++ family has problems with accepting xmm regs as input...

There are so called standards, that keeps some features out of question ?
Also i386 was tricky for standards, as CPUs don't rule standards in common programming languages.

[jj2007]

There are so called standards, that keeps some features out of question ?

You want us all to go back to the dark pre-SIMD ages?

[TimoVJL]

There are so called standards, that keeps some features out of question ?

You want us all to go back to the dark pre-SIMD ages?

No, x64 is already for us now 

[daydreamer]

There are so called standards, that keeps some features out of question ?

You want us all to go back to the dark pre-SIMD ages?

Don't forget those dark ages of non SIMD and slow cpu's and tiny ram is what started this fun asm clock cycles reduction, without it we would found it pointless to make code faster with 3+ghz cpu's and very powerful gpus

Some members still enjoy the bigger challenge 16 bit real mode dos coding is

After try coding one non SIMD converter and one SIMD version, I saw the pros and cons and now trying code a hybrid version