Author Topic: What is 32-bit offset that NASM leaves room for when assembling?  (Read 7090 times)

Offline andoram

  • Jr. Member
  • *
  • Posts: 3
What is 32-bit offset that NASM leaves room for when assembling?
« on: November 16, 2015, 12:13:32 AM »
In the beginning of the Chapter 12: Troubleshooting of the NASM docs it is said that:

Quote
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?

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: What is 32-bit offset that NASM leaves room for when assembling?
« Reply #1 on: November 16, 2015, 10:36:08 AM »
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


Offline andoram

  • Jr. Member
  • *
  • Posts: 3
Re: What is 32-bit offset that NASM leaves room for when assembling?
« Reply #2 on: November 16, 2015, 03:53:57 PM »
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?

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: What is 32-bit offset that NASM leaves room for when assembling?
« Reply #3 on: November 16, 2015, 04:21:50 PM »
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