OSDev.org

I noticed that nasm do not generate the REX.w prefix with 64-bit retf

For example, I have this code within BITS 64 section: As you can see, I need to hand code the prefix. Is it a bug in nasm or do I suppose to manually type the prefix whenever needed? I'm new to all these REX stuff.

Oh I see that NASM manual said "yasm insert REX automatically", but I guess nasm itself do not, or it might not in 2.09.10 which I'm using.

Hi,

bluemoon wrote:As you can see, I need to hand code the prefix. Is it a bug in nasm or do I suppose to manually type the prefix whenever needed? I'm new to all these REX stuff.

For normal 64-bit code (where everything is "flat"), there's no reason to use far calls and far returns, except for returning to 16-bit or 32-bit code. For rare cases (like shifting to a different GDT where CS uses a different descriptor number) you'd have to use "a64 retf".


Cheers,

Brendan

a64 has no effect. The output from nasm for "a64 retf" is: I still need to manually code that 0x48. But I got your point, retf with operand size=64 is rare case.

Brendan wrote:For normal 64-bit code (where everything is "flat"), there's no reason to use far calls and far returns, except for returning to 16-bit or 32-bit code.

Or it could be a return to user mode.

According to the Intel Manual:

In 64-bit mode, the default operation size of this instruction is the stack-address size, i.e. 64 bits.

I'm not 100% sure, but from the sounds of that, it doesn't look like you need a REX prefix.

Rudster816 wrote:According to the Intel Manual:

In 64-bit mode, the default operation size of this instruction is the stack-address size, i.e. 64 bits.

I'm not 100% sure, but from the sounds of that, it doesn't look like you need a REX prefix.

Yes it's not needed. IRET on the other hand does need REX.

However, someone also wrote on the wiki: X86-64_Instruction_Encoding

1: The following instructions default to (or are fixed at) 64-bit operands and do not need the REX prefix for this: CALL (near), ENTER, Jcc, JrCXZ, JMP (near), LEAVE, LGDT, LIDT, LLDT, LOOP, LOOPcc, LTR, MOV CR(n), MOV DR(n), POP reg/mem, POP reg, POP FS, POP GS, POPFQ, PUSH imm8, PUSH imm32, PUSH reg/mem,
PUSH reg, PUSH FS, PUSH GS, PUSHFQ and RET (near).

I suppose the RET(near) is implying RETF is not default to 64-bit. Anyway, REX.w = 1 is needed in my case to explicitly set to use 64-bit operands.
btw, yasm does generate REX for this automatically. berkus is right, I should switch to yasm.

bluemoon wrote:I suppose the RET(near) is implying RETF is not default to 64-bit. Anyway, REX.w = 1 is needed in my case to explicitly set to use 64-bit operands.
btw, yasm does generate REX for this automatically. berkus is right, I should switch to yasm.

A few years ago someone on the list (I think it was Owen) tested some machines and found that FAR CALL in 64bit mode only works on Intel machines. It does not work on AMD machines. The Intel docs imply that it works while the AMD docs say that it doesn't work. So the docs are reasonably 'correct'.

There is a good chance that the same applies to FAR RET.

I think care is needed here and you may find that you code does not work on all machines. To be sure you really should use the documented method which is to use an IRET.

OK Thanks for the advice.

EDIT: I got the iret worked. The sad news is that nasm 2.09 does not emit REX for iret as well (and yasm does emit REX, for the same code).
EDIT2: IRETQ does the tricks. Time for me to re-read the assembler manual for 64-bit stuff.

Bluemoon, I found the thread. Actually it seems that Owen did try FAR RET and it worked. I would still be cautious though. IRET is the documented method and will always work.

http://forum.osdev.org/viewtopic.php?f= ... 51&start=0