Disassembly

[HellOfMice]

When we write our code sometime we donn't  take care what the assembler really selects: MOV [A + B],al or MOV [B + A],al
it is the same but there are cases when it is not possible to proceed like this.

I take this case always with ADC but is is good for many others opcodes:

10 1C 0C   ADC BYTE PTR [RCX + RSP],BL   => Base = RSP = 100; Index = RCX = 001   00 001 100 => [(1 * RCX) + RSP] => 10 1C 0c
10 1C 0C   ADC BYTE PTR [RSP + RCX],BL   => Base = 000 = 000; Index = 000         00 000 001 => Invalid

MODREGR/M : 1C = 00 011 100 => SIB
Identifies BL (011) and a SIB (100)
SIB = 00 001 100 Scale = 00 => Scale = (1 *)
Index = 001 => RCX
Base = 100  => RSP
So we get ADC [(1 * RCX) + RSP)] => 10 1C 0C => GOOD
----------------------------------------------------------------------
ADC BYTE PTR [RSP + RCX],BL
is Invalid because the Index 100 sets adresse to 0
[(1 * 0) + RCX] for this code AMD says:

Register specification is null. The scale index portion of the indexed register-indirect effective address is set to 0.

In the SIB bits 7-6 = Scale, 5-3 = Index, 2-0 = Base

If that could be encoded it could not be with
an even code, because the value of RCX is 001 so 0C is FALSE

If we apply the AMD rule, the result is ADC [(1 * 0) + RCX],BL
=> ADC [RCX],BL => SIB = 00 000 001
and the whole opcode is 10 1c 01 but is shorter with 10 01
----------------------------------------------------------------------
I have tried to join INTEL and AMD forum without success because I should like
to if I make an error or not and should like to know the reason of this encoding form.
If someone as some information, I hope he will share them

[TimoVJL]

Have to confess, that you have a challenging project 

For me, supporting Pelle's C have been enough.
Pelles C debug format could be a interesting project to someone.
A debug coff format isn't enough for new debuggers and analyzers.

[HellOfMice]

Yes it is a great challenge and I don't want to do like everyone does. A big problem will be to detect alignment because it does not always use NOP but prefixes. It is hard to find valid informations and when found it is hard to understand.
Rather than taking the opcode in tables, I search all the possibilities. For now I have found 80 000 cases but I am reducing this number drasticaly. In my test I added prefixes that are not used in normal coding. For example if the 66h prefix is before a REX prefix, the REX prefix has the priority so the 66h has no reason to be there.

Now I have many docs that correct the error I have made. The X64 is a strange processor, for me it is an X32 extended, with just 64 bits registers but it can't address memory > 32 bits! You can address the same memory with a 64 bits register or with a 32 bits register!

With this processor you always change from 16 bits to 32 bits to 64 bits! You loose speed. I think that it is better to stay in 64 bits mode and don't use 32 or 16 bits.
That means when calling a windows function don't put on the stack 32 bits registers but 64 bits registers. That creates more trafic on band width.

Thank you to support me

A+

Philippe

[HellOfMice]

This afternoon, in a message I said that I had found 80,000 combinations for ADC, but that I was doing and that it was going down a lot, drastically. Indeed, the number of combinations has really changed, but not in a good way, now I have 249,817! And I didn't generate everything.

I have the impression that people are going to make fun of me.

Too bad, we're here for that too.

[HellOfMice]

Now all that has been simplified and resumed in 130 lines.