Hello,

I'm new to Intel instructions encoding, so I may be mistaken. In that case, please feel free to tell me why I'm wrong.

But during some tests, I encountered that the following basic assembly code:
use64
mov al, [42]
would produce this output using fasm:
8A 05 24 00 00 00

- 8A makes sense. Intel doc says that "8A /r" means "Move r/m8 to r8"
- 05 is logically the modR/M, composed of:
- mod 00 (address of operand will be provided)
- reg 000 (al)
- r/m 101 (disp32)
=> 00000101b = 05h
- then "24 00 00 00" should be the 32 bits operand, representing the address we want to copy the value from.
But 42d != 24 00 00 00 (=36d)

To double check my understanding, I ran the same test using nasm.
In that case, the encoding is a bit different:
8A 04 25 2A 00 00 00
that I undestand as being a more verbose way to say the same thing, except that it uses the indirection of a dummy SIB byte.
But at least I can explain the operand value of "2A 00 00 00" since 2Ah = 42d

What do I miss? I don't want to believe that this can be a bug in fasm.

Thanks a lot for your help,

Tom

In the long mode fasm automatically generates RIP-based addressing by default, unless you enforce use of absolute addressing (see section 2.1.19 of the manual). Therefore the instruction that gets generated by is in this case the same as: Note that the offset is going to change if the position of instruction in memory is different, for example: generates the same instruction as:
PS. The r/m field value 101b in the long mode does not have the same meaning as in the legacy mode.

Of course, I took it for granted that the address was an absolute one!
I have to dig and learn more about this new (for me) RIP-relative addressing.

Thank you very much for your precise, structured and very quick answer, Tomasz!

Tom

Ah, if I may, I notice that

is not encoding using RIP-relative addressing, even if it is shorter than the SIB-based addressing.

But there may be a technical reason for that (maybe a shorter latency with this kind of encoding of the instruction)...

Tom

Instruction latency and throughput is not a consideration inside fasm. Each CPU and code stream is different so there isn't really a way for the assembler to know.

For your code above, which I assume is using 32 bit mode, there is no EIP addressing mode. RIP addressing is only possible in 64 bit mode.

Thank you revolution,

It is valuable to know that latency has no impact on FASM output. I share your point of view.

Please forgive me for two mistakes I made:
- not giving the context of my code (prefixed by use64, as previously)
- confusing the output of FASM and the one of NASM that I used to double check my results.

Using FASM, the output of:

is the shortest possible, RIP-relative addressing based:


Only NASM outputs the longer SIB and absolute addressing based output.

Sorry for the confusion, and again, thank you both very much for the responsiveness and the quality of your answers.

Tom