Author Topic: Choosing between accumulator, SIB and ModR/M  (Read 17138 times)

Offline Marat Dukhan

  • Jr. Member
  • *
  • Posts: 4
Choosing between accumulator, SIB and ModR/M
« on: November 15, 2012, 11:50:07 PM »
I have few related questions:
1. Is there a way to force NASM to use SIB form for memory operands which are normally encoded with only ModR/M?
2. Is there a way to force NASM to use ModR/M form for instructions which normally use different encoding (e.g. PUSH ecx; ADD eax, 10)?

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Choosing between accumulator, SIB and ModR/M
« Reply #1 on: November 16, 2012, 05:29:11 PM »
I guess you could rewrite Nasm. I don't think there's any "easy" way. Is there something wrong with the way Nasm's doing it?

Offline Marat Dukhan

  • Jr. Member
  • *
  • Posts: 4
Re: Choosing between accumulator, SIB and ModR/M
« Reply #2 on: November 16, 2012, 06:35:04 PM »
I want to do alignment of instructions in a better way than just inserting NOPs or prefixes. Manipulating instruction forms is an obvious way to achieve that.

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Choosing between accumulator, SIB and ModR/M
« Reply #3 on: November 16, 2012, 08:24:32 PM »
Okay. So you'd need to switch back and forth "at will"? I think that would take a major re-write. Do you have reason to think that longer instructions would be "better" than a few "nop"s? (I don't know)

Best,
Frank


Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 429
  • Country: us
Re: Choosing between accumulator, SIB and ModR/M
« Reply #4 on: November 16, 2012, 08:29:38 PM »
Within the .TEXT segment use a sequence of db "YOUR_OPCODE" statements to insert exactly what you want where you want it.

Offline Marat Dukhan

  • Jr. Member
  • *
  • Posts: 4
Re: Choosing between accumulator, SIB and ModR/M
« Reply #5 on: November 16, 2012, 09:39:03 PM »
Okay. So you'd need to switch back and forth "at will"?

I would prefer it to work on per-instruction basis. For example, now I can write

Code: [Select]
MOVDQA xmm0, [esi]or
Code: [Select]
MOVDQA xmm0, [byte esi + 0]or
Code: [Select]
MOVDQA xmm0, [dword esi + 0]
to switch between no offset, byte offset, and dword offset. It would be good if I could also specify something like

Code: [Select]
MOVDQA xmm0, [sib esi]
to force NASM to use SIB.

Similarly, I can write

Code: [Select]
DS ADD eax, 10
to add a DS segment prefix to this instruction. I want to also have an option to write e.g.

Code: [Select]
MODRM ADD eax, 10
to encode ADD eax, 10 using ModR/M scheme.

Do you have reason to think that longer instructions would be "better" than a few "nop"s? (I don't know)

For high-performance code modern processors often require certain alignment of instructions, e.g. for Intel Atom pairs of instructions should be aligned on 8-byte boundary, and for Intel Nehalem they should be aligned on 16 bytes. However, adding NOPs decreases the efficiency of instruction decoder (which is exactly what I want to improve with this optimization), and the same problem arises when using prefixes for aligning instructions. So changing instruction forms is the best option.
« Last Edit: November 16, 2012, 09:47:10 PM by Marat Dukhan »

Offline Marat Dukhan

  • Jr. Member
  • *
  • Posts: 4
Re: Choosing between accumulator, SIB and ModR/M
« Reply #6 on: November 16, 2012, 09:40:50 PM »
Within the .TEXT segment use a sequence of db "YOUR_OPCODE" statements to insert exactly what you want where you want it.

I want the code to be human-readable, so this is not an option for me. Besides that, it will not generate relocs.
« Last Edit: November 16, 2012, 09:47:53 PM by Marat Dukhan »

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 429
  • Country: us
Re: Choosing between accumulator, SIB and ModR/M
« Reply #7 on: November 16, 2012, 11:20:11 PM »
Feel free to post your suggestion to the dev mail list:
https://lists.sourceforge.net/lists/listinfo/nasm-devel