What is 32-bit offset that NASM leaves room for when assembling?

[andoram]

In the beginning of the Chapter 12: Troubleshooting of the NASM docs it is said that:

We sometimes get `bug' reports about NASM generating inefficient, or even `wrong', code on instructions such as ADD ESP,8. This is a deliberate design feature, connected to predictability of output: NASM, on seeing ADD ESP,8, will generate the form of the instruction which leaves room for a 32-bit offset.

Can someone please elaborate on how and where the 32-bit offset is used?

[Frank Kotler]

Use "-O0" to see that behavior. Nasm hasn't done that by default since... well, a long time. Since John Coffman added the "optimization" code. Good catch, Andoram!

Best,
Frank

[andoram]

Frank, thank you for your answer.

I see that without -O0 flag add esp, 0x10 and add esp, byte 0x10 are both translated to 83 c4 10 opcode sequence. While with -O0 flag NASM generates 81 c4 10 00 00 00 opcode sequence for the add esp, 0x10 instruction.

It is probably not important, but what do you call a 32-bit offset in this case? Is it alignment of the operand to 4 bytes?

[Frank Kotler]

I don't think alignment has anything to do with it. Generally, the size of source and destination must match, but there are "signed byte" varients of certain instructions - "arithmetic" instructions generally - in which an operand can be stored as a byte and sign-extended to a word or dword (or qword, I guess). Original versions of Nasm didn't have the wit to figure out when these forms were available. Foolish, because if we attempted "add edx,  byte 129" Nasm would generate a warning (only a warning - even if it was plain wrong like add edx, byte 256). But that was all a long time ago...

Best,
Frank