AsciiHextoDword (SSE2 version)

[zedd151]

Yep, this is what i plan to do. Using other arguments to store the returned values of the conversion and leave eax to the error return.

But shouldn't  eax/rax hold either the returned value of the conversion, unless an error condition is met, then return a defined error code in eax/rax instead?  Seems more logical. And probably aligns better with most usage from what I have seen.

The other variables (address passed as arguments - if used) can hold any other additional info needed by the caller.

[NoCforMe]

But shouldn't  eax/rax hold either the returned value of the conversion, unless an error condition is met, then return a defined error code in eax/rax instead?

Well, think about it:
You could do that, so long as the conversion values are all positive, in which case the error codes would have to be negative.

If the conversion value could be either positive or negative, this wouldn't work.

It's the old problem of trying to return two things at once. Probably better to return the error status in EAX and the converted value in a pointed-to variable.

[zedd151]

Good point. I forgot about possible intended negative conversion values.   

[guga]

Yep, this is what i plan to do. Using other arguments to store the returned values of the conversion and leave eax to the error return.

But shouldn't  eax/rax hold either the returned value of the conversion, unless an error condition is met, then return a defined error code in eax/rax instead?  Seems more logical. And probably aligns better with most usage from what I have seen.

The other variables (address passed as arguments - if used) can hold any other additional info needed by the caller.

Ok, but the new version i´m making converts a qword (64 bits(, so it couldn´t return in eax, because it won´t fit. So, to prevent using edx as the other part of the qword, better passing the value on a output buffer pointed by a parameter on the function.

Btw, if the user wants to convert only a 32bit hexadecimal value (a dword), he could then also use the function made to convert a qword, because the output buffer will fit anyway for both types of inputs.  That´s teh problem i´m facing right now to find teh proper index for both cases without affecting the performance.

[guga]

But shouldn't  eax/rax hold either the returned value of the conversion, unless an error condition is met, then return a defined error code in eax/rax instead?

Well, think about it:
You could do that, so long as the conversion values are all positive, in which case the error codes would have to be negative.

If the conversion value could be either positive or negative, this wouldn't work.

It's the old problem of trying to return two things at once. Probably better to return the error status in EAX and the converted value in a pointed-to variable.

Agree

[sinsi]

Probably better to return the error status in EAX and the converted value in a pointed-to variable.

That's what I am starting to do after noticing that Windows (interfaces for example) will just return a HRESULT in EAX.
Any returned variables are returned via an address passed to the function.

[NoCforMe]

Probably better to return the error status in EAX and the converted value in a pointed-to variable.

That's what I am starting to do after noticing that Windows (interfaces for example) will just return a HRESULT in EAX.
Any returned variables are returned via an address passed to the function.

On the other hand:
Since I assume you're writing assembly-language code, why not just use EDX (RDX) to pass the other value? As long as your code isn't being used by any high-level language, why not use the easy way? That's what I do. (Just make sure you self-document this behavior.)

[sinsi]

Probably better to return the error status in EAX and the converted value in a pointed-to variable.

That's what I am starting to do after noticing that Windows (interfaces for example) will just return a HRESULT in EAX.
Any returned variables are returned via an address passed to the function.

On the other hand:
Since I assume you're writing assembly-language code, why not just use EDX (RDX) to pass the other value? As long as your code isn't being used by any high-level language, why not use the easy way? That's what I do. (Just make sure you self-document this behavior.)

It's not following the ABI

[NoCforMe]

ABI? Schmabi.

At least for 32-bit programs: in my own code I feel free to do this, since EDX is a "scratch" register anyhow. The WinAPI isn't even going to know what I'm doing behind its back, and what it doesn't know can't hurt me.

Dunno about x64, but really, what's stopping you from using RDX to pass parameters back (that is, from callee to caller)? It's a volatile register, so who cares?

[sinsi]

All I have to remember is that EAX=0 is success.
Same way that in 64-bit code I always allocate shadow space, even though I don't use it.

Habit. Don't have to think.

[jj2007]

why not just use EDX (RDX) to pass the other value?

That's what I do sometimes. For example, Instr_() returns the index in edx and the pointer to the match in eax. It's documented and it's not meant for use in C/C++

[TimoVJL]

why not just use EDX (RDX) to pass the other value?

That's what I do sometimes. For example, Instr_() returns the index in edx and the pointer to the match in eax. It's documented and it's not meant for use in C/C++

When returning struct/class,
Plain old data (POD) return values 32 bits or smaller are in the EAX register
POD return values 33–64 bits in size are returned via the EAX:EDX registers.

[guga]

Ok, guys, done, but i´m in doubt on how the data should be displaced

Code Select Expand

; ---------------------------------------------------------------------------

ShiftTbl        struc ; (sizeof=0x20, mappedto_30)
ShiftTbl_Data0  dd 28
ShiftTbl_Data1  dd 24                    ; base 10
ShiftTbl_Data2  dd 20                    ; base 10
ShiftTbl_Data3  dd 16                    ; base 10
ShiftTbl_Data4  dd 12                    ; base 10
ShiftTbl_Data5  dd 8
ShiftTbl_Data6  dd 4
ShiftTbl_Data7  dd 0
ShiftTbl        ends

the same as: ShiftTbl  ShiftTbl <28, 24, 20, 16, 12, 8, 4, 0>


; =============== S U B R O U T I N E =======================================

; Attributes: bp-based frame

AsciiHex2dw_Ex4 proc near               ; CODE XREF: start+2D↑p
                                        ; .text:0042BF57↑j

Lenght          = dword ptr -4
pString         = dword ptr  8
pOutput         = dword ptr  0Ch

                push    ebp
                mov     ebp, esp
                sub     esp, 4
                push    ecx
                mov     eax, [ebp+pString]
                movdqu  xmm0, xmmword ptr [eax]
                xorps   xmm1, xmm1
                pcmpeqb xmm0, xmm1
                pmovmskb ecx, xmm0
                bsf     cx, cx
                jnz     short loc_42BF84
                mov     ecx, 16

loc_42BF84:                             ; CODE XREF: AsciiHex2dw_Ex4+1D↑j
                mov     [ebp+Lenght], ecx
                dec     ecx
                movdqu  xmm0, xmmword ptr [eax]
                psubb   xmm0, Mask1
                movdqa  xmm1, xmm0
                pcmpgtb xmm1, Mask2
                pand    xmm1, Mask3
                psubb   xmm0, xmm1
                movdqa  xmm1, xmm0
                pand    xmm1, Mask4a
                pxor    xmm0, xmm1
                psllw   xmm0, 4
                pslld   xmm0, 8
                por     xmm0, xmm1
                pshuflw xmm0, xmm0, 1Bh
                psrld   xmm0, 8
                psllw   xmm0, 8
                psrlw   xmm0, 8
                movdqa  xmm1, xmm0
                packuswb xmm0, xmm0
                pshufd  xmm1, xmm1, 1Eh
                pshuflw xmm1, xmm1, 1Bh
                packuswb xmm1, xmm1
                movd    eax, xmm0
                mov     edi, [ebp+pOutput]
                mov     ecx, ShiftTbl[ecx*4]
                cmp     [ebp+Lenght], 8
                jbe     short loc_42C014
                movd    ecx, xmm1
                mov     [edi+4], ecx
                mov     ecx, 0

loc_42C014:                             ; CODE XREF: AsciiHex2dw_Ex4+A6↑j
                shr     eax, cl
                mov     [edi], eax
                mov     eax, [ebp+Lenght]
                pop     ecx
                mov     esp, ebp
                pop     ebp
                retn    8
AsciiHex2dw_Ex4 endp
Mask 1, Mask2, Mask3 and Mask4a are the same as before. I just added a table of indexes (previously it contained all 1 indexes but since i´m in doubt i placed ony the 1st 8 here.


it works like:
[SzInputHex:  B$ "43210F2A45B7", 0 ] ; our string
[Output: Q$ 0] ; A buffer with 8 bytes long

call AsciiHex2dw_Ex4 SzInputHex, Output

The problem is that, currently it displays the data in this order:
Output dd 43210F2A
       dd 000045B7

But, is it supposed to return like this ? Is it correct or should be ?...
Output dd 00004321
       dd 0F2A45B7
or
Output dd 43210F2A
       dd 45B70000

Right ?

In eax it returns the size of the string

I´m a bit confused because on RosAsm debugger it correctly shows the return as (Which is supposed to be correct):

Output dd 43210F2A
            dd 000045B7

But Idapro debugger is showing me this in memory:

Output dd 43210F2Ah
dd 45B70000h

[guga]

Is it producing the correct result and perhaps ida displays the order of the data on a different way than in RosAsm, or i´m missing something ?

I tested with the other version (The one that works only for a dword), and if i use a sequence, like:
    mov edi SzInputHex
    call AsciiHex2dwNew edi
    mov D$Output eax
    add edi 8
    call AsciiHex2dwNew edi
    mov D$Output+4 eax

It correctly displays the result as:
Output dd 43210F2A
       dd 000045B7

Which is the same result on the Qword version (AsciiHex2dw_Ex4 ). Btw..i´ll rename the function to AsciiHex2Qword or AsciiHex2_Ex or something like that to distinguish from the Dword version.

[guga]

Damn, forget the last post.

It´s just showing the proper result in one test i made.

The former shift table i was using during the tests was correct. I´ll review the code and set the proper indexes.

It won´t work if the input is
[SzInputHex:  B$ "6543210F2A45B7", 0 ]