Unexpected Operand in Decoder Output for Multi-byte NOP Instructions

[zouxianyu]

The Intel Software Developer's Manual defines three encodings for the NOP instruction:

• NOP
• NOP r/m16
• NOP r/m32

Additionally, Intel recommends specific multi-byte NOP encodings for alignment purposes, as shown below:

Length	Assembly	Byte Sequence
2 bytes	66 NOP	66 90H
3 bytes	NOP DWORD ptr [EAX]	0F 1F 00H
4 bytes	NOP DWORD ptr [EAX + 00H]	0F 1F 40 00H
5 bytes	NOP DWORD ptr [EAX + EAX*1 + 00H]	0F 1F 44 00 00H
6 bytes	66 NOP DWORD ptr [EAX + EAX*1 + 00H]	66 0F 1F 44 00 00H
7 bytes	NOP DWORD ptr [EAX + 00000000H]	0F 1F 80 00 00 00 00H
8 bytes	NOP DWORD ptr [EAX + EAX*1 + 00000000H]	0F 1F 84 00 00 00 00 00H
9 bytes	66 NOP DWORD ptr [EAX + EAX*1 + 00000000H]	66 0F 1F 84 00 00 00 00 00H

However, when these instructions are disassembled using Zydis, the decoded output differs slightly:

Length	Decode Result
2 bytes	nop
3 bytes	nop [rax], eax
4 bytes	nop [rax], eax
5 bytes	nop [rax+rax*1], eax
6 bytes	nop [rax+rax*1], ax
7 bytes	nop [rax], eax
8 bytes	nop [rax+rax*1], eax
9 bytes	nop [rax+rax*1], ax

This reveals a discrepancy: Zydis sometimes interprets multi-byte NOP sequences as having an additional operand.

[mappzor]

Seems this issue is basically an inverse of #539. We should probably review all nops and handle them in a uniform way, with or without extra operands. Personally I'm not sure which version would be better.