Little tricks

[jj2007]

A simple endless loop with two breaks, where edx is a string pointer:

Code Select Expand

  .While 1
.While 1
mov al, [edx]
.Break .if !al || al>=48  ; exit if al is "0" or above
inc edx
.Endw
.Break .if !al
(... do useful things)
  .Endw

Code Select Expand

  .While 1
.While 1
mov al, [edx]
.Break .if !al || al>47  ; exit if al is "0" or above
inc edx
.Endw
.Break .if Zero?
(... do useful things)
  .Endw
The difference lies in the second break:
- the first case will translate to test al, al + je somelabel
- the second case will translate to je somelabel

[jj2007]

HexString to binary conversion:

Code Select Expand

AMD Athlon Gold 3150U with Radeon Graphics      (SSE4)

19097   cycles for 100 * MasmBasic Val
40822   cycles for 100 * CRT sscanf
2641    cycles for 100 * Masm32 SDK hex2bin
1885    cycles for 100 * HexStr2XX (128-bit)
1725    cycles for 100 * xVal

18871   cycles for 100 * MasmBasic Val
40515   cycles for 100 * CRT sscanf
2632    cycles for 100 * Masm32 SDK hex2bin
1937    cycles for 100 * HexStr2XX (128-bit)
1617    cycles for 100 * xVal
The last two are clearly the fastest algos:
- HexStr2XX can handle a string like "1111567890aBcDeF2222567890aBcDeF" and returns the correct result in xmm0.
- xVal is faster but handles only "1111567890aBcDeF", i.e. a QWORD.

I want to keep only one of them. What is more important, the option to read  a 128-bit value, or more speed?

I know that both aspects are completely irrelevant for practical work, but I still need to take a decision...

[NoCforMe]

I want to keep only one of them. What is more important, the option to read  a 128-bit value, or more speed?

Looks to me as if HexStr2XX() gives you (almost) the best of both worlds, no?

Code Select Expand

1885    cycles for 100 * HexStr2XX (128-bit)


[fearless]

128bit (32 chars) could be useful for MD5 or GUID strings (without the '-' for the GUID parts - or 36 chars with them)

For something using SHA-1 would need 160 bits (40 chars) or SHA-256 256bits (64 chars)

a hex to string using 256bits (64 chars) could be useful then.

[jj2007]

128bit (32 chars) could be useful for MD5 or GUID strings

That is certainly possible. I wonder, though, what one could do with the resulting xmm0 content. Are there any APIs that require xmm regs as arguments?

a hex to string using 256bits (64 chars) could be useful then.

I've searched a lot but couldn't find instructions to move xmm regs to the upper half of e.g. ymm0.

Maybe the best 256-bit option would be a macro that uses the 128-bit algo twice, see attached image. Code:

Code Select Expand

  Let edi=Replace$(offset IID_IWebBrowser2$, "-", 0)  ; get rid of "-"
  deb 4, "GUID", x:xVal(edi, 128), x:xmm1
If you got the result in xmm0 and xmm1, how would you use the two regs then?

P.S.: This is a spin-off from Randy Hyde's Hexadecimal string to numeric function thread.

[daydreamer]

I think reading a big source file,add code to find all 'h', '$', "0x" to position hextoint to right character for every hexadecimal number in code
If find other kind of numbers, call binary,decimal, octal conversion instead