Missing AsciiHexToDW in masm32 and

[Ian_B]

Sorry, Hutch, it wasn't an attack on yours or anyone's code, just a comment about what I felt was the pointlessness of timing it in that state. And yes, I'd be interested to see how the timings do compare with mine, as you would be directly comparing a routine which only uses (a lot of) fast arithmetic against one which only uses (presumably slower) memory accesses, which I think would be instructive. But obviously much of the overhead of my code is supporting the errorhandling, which would be needed in any case. There's also the matter of the entry/exit push/pop sequence of course. But I'd like to see how it fares in a level playing field.

IanB

[ToutEnMasm]

Hello,
Glad to see you want to add it in the masm package.
Can you call it with an another name than H2d ?.
There is several conversions functions in masm32 and a short name isn't an advantage with an editor,but making errors is very possible with shorts names.

                                             ToutEnmasm

[hutch--]

 :bg

Never fear, the naming is the easy part. what I have been doing with the library over time is distinguishing between small and efficient algorithms and extended versions so that there is a choice of small efective code or more specialised high speed streaming algorithms and it looks like there is some good designs available to do both. When you have played with multiple versions you get a pile of compacted names but I would think somthing like "hex2dw" and "h2dw_ex" would make enough sense not to be confused with other algo names.

[hutch--]

Lingo,

Have a look at this one, it is testing up about 30% faster than your last one. The idea I had in mind is if we can get enough pace out of the direct fall through, there may be a way to add checking for the character count in the hex string and still end up with a fast algo.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

align 16

h2dword proc phex:DWORD

    push esi

    mov esi, [esp+8]

    movzx ecx, BYTE PTR [esi]
    mov ah, [tbl1+ecx-48]
    movzx edx, BYTE PTR [esi+1]
    add ah, [tbl2+edx-48]

    movzx ecx, BYTE PTR [esi+2]
    mov al, [tbl1+ecx-48]
    movzx edx, BYTE PTR [esi+3]
    add al, [tbl2+edx-48]

    rol eax, 16

    movzx ecx, BYTE PTR [esi+4]
    mov ah, [tbl1+ecx-48]
    movzx edx, BYTE PTR [esi+5]
    add ah, [tbl2+edx-48]

    movzx ecx, BYTE PTR [esi+6]
    mov al, [tbl1+ecx-48]
    movzx edx, BYTE PTR [esi+7]
    add al, [tbl2+edx-48]

    pop esi

    ret 4

h2dword endp

OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««


[lingo]

Hutch, :lol

"Have a look at this one, it is testing up about 30% faster than your last one."

Theoretically impossible due to dependency
(every 2nd instruction of your code depends on the result of the preceding one)

Code Select Expand


    movzx ecx, BYTE PTR [esi]
    mov     ah, [tbl1+ecx-48] ; ecx depends on prev instruction

    movzx edx, BYTE PTR [esi+1]
    add ah, [tbl2+edx-48] ; edx depends on prev instruction
    ... etc.

I can't test it on AMD but times on my P4 3.6 GHz with XP SP2 are:

Code Select Expand


C:\TEMP1>h2dw.exe
Please terminate any high-priority tasks and press ENTER to begin.


Hex2Dword  Tests:

Hex2Dw  -  hutch : 62  clocks; Result: -48632537
Hex2Dw  -  lingo : 23  clocks; Result: -48632537
Hex2Dw1 -  hutch : 30  clocks; Result: -48632537

Press ENTER to exit...

".. a way to add checking for the character count in the hex string"

Who needs that?
and what if other guy wants to do additional "mandatory" checking? :lol

Regards,
Lingo

[attachment deleted by admin]

[Ian_B]

".. a way to add checking for the character count in the hex string"

Who needs that?
and what if other guy wants to do additional "mandatory" checking? :lol

Who needs that? Anyone who wants to know they've actually converted a 8-character CRC and not just wasted code and time converting some arbitrary byte sequence and producing a nonsensical result.

Seeing as the number one use for CRCs is in external sources to confirm the validity of a byte sequence or file, then the logical result of checking the CRC value is to decide whether to junk the file or not. If I'm going to make a decision like that, I'd want to know whether I read the CRC value right, and I think MOST people would. If that's your attitude to checking data before you use it, then I feel sorry for anyone who would use a piece of software you write, it would either fail to do anything useful at all if fed incorrect data or it would be too dangerous to risk having on your hard disk and running. But keep writing "clever" code that makes no checks on what it works on if you like, just accept it has no worth or value in the real world outside your ivory tower.

IanB

[hutch--]

Lingo,

It seems the code is very dependent on the Prescott PIV I am using. I tested the same test piece on the AMD and it was far slower so the read after write dependency effecs the AMD where the particular instruction ordering is a lot faster on the PIV. When I get a bit more time I will have a play with it.

LATER :

I have kept playing with this algo on the PIV but I cannot get any variant faster. These are the times I am getting. The 12345678 is the last hex number in the test and its used to ensure that variants were producing the correct results. The AMD does not seem to like code of this density and is a lot slower. Lingo's version appears to be fast on both the PIV and AMD but not as fast on thre PIV as the one in this example.


PIV results
-----------
12345678
1141 lingo
12345678
813 hutch
12345678
1141 lingo
12345678
813 hutch
12345678
1297 lingo
12345678
813 hutch
12345678
1141 lingo
12345678
813 hutch


[attachment deleted by admin]

[hutch--]

Here is a try at making a fall through table driven hex to dword algo. Its rough and needs serious optimisation but it seems to be returning the correct results. It will accept variable length hex input but no leading "0x" and no trailing "h". It will accept characters up to 8 in length as the input hex string and it does not require a leading "0" if the first hex character is not between 0 to 9.

Ian has already published a good compact version, what I am trying for here is a larger version that can be used for streaming where only speed matters.

[attachment deleted by admin]