OMake misassembling some instructions

[chuggafan]

Apparently, this is the reason my strlen implementation this time is failing, for some reason.

The exact issue:

;File test.s
;Compiler version OCC Version 7.0.1
        section code align=2        use32
        section data align=8        use32
        section bss  align=8        use32
        section const  align=8        use32
        section string  align=2        use32
        section tls  align=8 use32
        section cstartup align=2 use32
        section crundown align=2 use32
        section tstartup align=2 use32
        section trundown align=2 use32
section code
[global _main]
; main
_main:
; Line 1: int main() 
L_1:
; Line 3:     return 0;
        pmovmskb ecx, xmm0
        xor     eax,eax
; Line 4: } 
L_2:
        ret
section data
section const

When I investigate the test.exe generated from this (which for some reason is statically linking basically everything when I do occ test.s, so this somehow generates a .exe of 200kbytes in size, this includes C++ stuff), this disassembles to (per WinDBG):

_main:
0040101a 0fd7c8       pmovmskb ecx, mm0
0040101d 33c0         xor     eax, eax
0040101f c3           ret

This should be the last piece of the puzzle as to getting my strlen working.
Once my strlen is working, I'll commit it and then go back to memcpy or memmove.

[chuggafan]

In this case, I think it's because when we're dealing with the xmm registers we're not adding the 0x66 byte to the beginning, I'm going to double check this in the listing file, if that's the case then this should be an incredibly simple fix. (That I also am utterly confused about:

    <Opcode Name="pmovmskb" op="0x0f:8 0xd7:8" >
      <Operands Name="'modreg:reg32', 'rm:mmrm'" mand="" mod="'modreg.Ord'" R="'modreg.R'" W="'modreg.W'" />
      <Operands Name="'modreg:reg64', 'rm:mmrm'" mand="0x66:8" mod="'modreg.Ord'" R="'modreg.R'" W="'modreg.W'" />
      <Operands Name="'modreg:reg32', 'rm:sserm'" mand="" mod="'modreg.Ord'" R="'modreg.R'" W="'modreg.W'" />
      <Operands Name="'modreg:reg64', 'rm:sserm'" mand="0x66:8" mod="'modreg.Ord'" R="'modreg.R'" W="'modreg.W'" />
    </Opcode>

This should be handled, right?)

[chuggafan]

Simple fix, it's that the 0x66 addition was confused as being for marking whether or not this was for reg64. That actually has nothing to do with it, reg64 is implied by being in 64-bit mode vs being in 32-bit mode.
https://www.felixcloutier.com/x86/pmovmskb

    <Opcode Name="pmovmskb" op="0x0f:8 0xd7:8" >
      <Operands Name="'modreg:reg32', 'rm:mmrm'" mand="" mod="'modreg.Ord'" R="'modreg.R'" W="'modreg.W'" />
      <Operands Name="'modreg:reg64', 'rm:mmrm'" mand="" mod="'modreg.Ord'" R="'modreg.R'" W="'modreg.W'" />
      <Operands Name="'modreg:reg32', 'rm:sserm'" mand="0x66:8" mod="'modreg.Ord'" R="'modreg.R'" W="'modreg.W'" />
      <Operands Name="'modreg:reg64', 'rm:sserm'" mand="0x66:8" mod="'modreg.Ord'" R="'modreg.R'" W="'modreg.W'" />
    </Opcode>

This is all I needed to change to get WinDBG to decompile this properly, now onto more checking of what's going on with my changes!

[LADSoft]

thank you for digging into this!

I haven't been using windbg although maybe I should, maybe that would be better. I used borland's turbo debug (circa 2000) up until about two years ago when windows 11 finally squashed it... now im using visual studio as it will load executables. I suppose it would really help to have pdb support for the windows debuggers, but im still able to get by with simple map files although it is a bit clunky ::

[chuggafan]

Yhea, my strategy here was WinDbg + map file.
I actually fixed this in my latest push that made strlen an SSE2 based system.
We should probably add directly in occ to link and produce a map file instead of needing to pass /pl/m in order to generate the map via occ(?).
Might make it easier, though it would blur the line between occ as a linker and occ as the compiler.