error: instruction not valid with 32-bit operand size

[vit9696]

Hello!

Starting with nasm 3.x there is an error when trying to assemble the following instructions:

push    strict dword %[Vector] ; This instruction pushes sign-extended 8-byte value on stack
push    strict dword 0      ; 0 will be fixed

Error message:

SecPeiCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:66: error: instruction not valid with 32-bit operand size
SecPeiCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:76: error: instruction not valid with 32-bit operand size

[hpax]

Ah yes... this is a result of how the size prefix does double lifting on instructions like push or pop. "strict" by itself is really enough to inhibit optimization, however, I agree with you that the result is confusing for the programmer and should probably be allowed, or at the very least demoted to a warning since it is unambiguous.

[mikebeaton]

Previously, push strict dword 0 produced 68 00 00 00 00, so a 32 bit (dword) encoding. So unclear why this should even be a warning now? (Maybe I am not clear enough on what the 'double lifting' issue is here?)

Equally push strict qword 0 does and did compile, but also produces 68 00 00 00 00 - there is no 64-bit immediate push (https://www.felixcloutier.com/x86/push) - is not that the one that should be a warning, if anything? Apologies if I'm misunderstanding!

EDIT:

In nasm 2.15:

push    strict byte 12h
push    strict word 1234h
push    strict dword 12345678h
push    strict qword 12345678h

compiles to:

6A 12
66 68 34 12
68 78 56 34 12
68 78 56 34 12

in nasm 3 the third line doesn't compile. I would have expected the keyword (byte, word, dword, qword) to match the size of the emitted instruction's operand [I meant immediate data] (&/or to complain if no such instruction exists), so would have expected the fourth line to be the candidate for deprecation or warning, not the third.

Apologies if I'm missing historical context which explains this.

EDIT 2:

So I have now understood that push strict word 1234h compiles to push small (as IDA disassembly calls it) - it actually pushes a 16 bit value to the stack. Basically, it seems the size prefix (word, dword, qword) corresponds to the size that is pushed, the true 'operand size' (not the size of the immediate value that is used for encoding the operand in the emitted instruction). So then, I would agree with the nasm 3 deprecation of push strict dword after all. But in that case, should not push strict byte become a warning too (it still compiles without a warning)?

On the other hand, if that is the case, what is the way to control the immediate size - if you need to, e.g. for code alignment? It seems like the size prefix remains overloaded between specifying the true operand size and specifying the immediate data size (and has to, because it remains essential to be able to control the latter). Which seems to make the recent change hard to understand, once again.

I guess all this is the 'double lifting' you mentioned!

[mikebeaton]

PUSH	Immediate data size	Size pushed to stack	nasm 2	nasm 3
imm8	byte	qword	push strict byte	push strict byte
imm16	word	word	push strict word	push strict word
imm32	dword	qword	push strict dword or push strict qword or push strict	push strict qword or push strict

Given that 'double lifting' (the same size prefix needs to do something to force/specify the size of both the immediate data and the true operand) exists (and has to!), I'm continuing to vote that it is unclear why push strict dword is the correct one to choose for an error (or even a warning). Given the actual available immediate PUSH instructions push strict qword is (at least arguably?) the only ambiguous sequence.

Also, in context, the fact that push strict dword assembles to an instruction with 32-bit immediate data (sign extended to a 64 bit push) seems much clearer to the more or less casual reader of the code, than that push strict (no size prefix) or push strict qword do, even though all three did compile to that (v2) and the latter two still do (v3).