0

Reading Intel's big manual, I see that if you want to return from a far call, that is, a call to a procedure in another code segment, you simply issue a return instruction (possibly with an immediate argument that moves the stack pointer up n bytes after the pointer popping).

This, apparently, if I'm interpreting things correctly, is enough for the hardware to pop both the segment selector and offset into the correct registers.

But, how does the system know that the return should be a far return and that both an offset AND a selector need to be popped?

If the hardware just pops the offset pointer and not the selector after it, then you'll be pointing to the right offset but wrong segment.

There is nothing special about the far return command compared to the near return version.

They both look identical as far as I can tell.

I assume then that the processor, perhaps at the micro-architecture level, keeps track of which calls are far and which are close so that when they're returned from, the system knows how many bytes to pop and where to pop them (pointer registers and segment selector registers).

Is my assumption correct?

What do you guys know about this mechanism?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847

1 Answers1

1

The processor doesn't track whether or not a call should be far or near; the compiler decides how to encode the function call and return using either far or near opcodes.

As it is, FAR calls have no use on modern processors because you don't need to change any segment register values; that's the point of a flat memory model. Segment registers still exist, but the OS sets them up with base=0 and limit=0xffffffff so just a plain 32-bit pointer can access all memory. Everything is NEAR, if you need to put a name on it.

Normally you just don't even think about segmentation so you don't actually call it either. But the manual still describes the call/ret opcodes we use for normal code as the NEAR versions.

FAR and NEAR were used on old 86 processors, which used a segmented memory model. Programs at that time needed to choose what kind of architecture they wished to support, ranging from "tiny" to "large". If your program was small enough to fit in a single segment, then it could be compiled using NEAR calls and returns exclusively. If it was "large", the opposite was true. For anything in between, you had power to choose whether local functions needed to be able to be either callable/returnable from code in another segment.

Most modern programs (besides bootloaders and the like) run on a different construct: they expect a flat memory model. Behind the scenes the OS will swap out memory as needed (with paging not segmentation), but as far as the program is concerned, it has its virtual address space all to itself.

But, to answer your question, the difference in the call/return is the opcode used; the processor obeys the command given to it. If you mistake (say, give it a FAR return opcode when in flat mode), it'll fail.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Dúthomhas
  • 8,200
  • 2
  • 17
  • 39
  • OK. Say there are actually different forms of the return instruction after all. Got it. Thanks. –  Sep 13 '17 at 02:05
  • No, normal code uses NEAR call/ret, which doesn't modify CS. That's the whole point of a flat memory model. A `ret far` pops a new CS:RIP from the stack, a normal `ret` just pops a new `RIP` from the stack. And for example, x86 conditional branches are *only* available in NEAR (rel32) and SHORT (rel8) form, not far. – Peter Cordes May 23 '19 at 19:16
  • But yes the first sentence is correct; near and far jumps have separate opcodes. – Peter Cordes May 23 '19 at 19:18
  • 1
    @Dúthomhas: **NEAR and FAR still have specific technical meanings on modern x86. Everything is NEAR, because you can access all mem with 1 segment**. A FAR jump changes CS as well as IP/EIP/RIP. That doesn't let you access more memory (in a flat model), but it can e.g. change from 32 to 64-bit mode by selecting a different code segment descriptor in the GDT. Normal code uses [`0xc3 ret`, not `0xcb ret far`](https://www.felixcloutier.com/x86/ret). FAR call/return is much slower. Like on Core2, RETF is one per 78 cycles, vs. 1 per 2 cycles, according to https://agner.org/optimize/ – Peter Cordes May 23 '19 at 21:56