So in other words, it's a 32-bit address space in 64-bit mode? I thought that wasn't possible with x86-64... in fact the biggest mistake I think with x86-64, after some(admittedly not much) reading of the manuals is that it wasn't like the 16/32-bit where you could independently choose the default operand and address sizes, and use 32-bit addresses or registers in 16-bit mode and vice-versa.

Not sure what you were reading, but to the best of my knowledge, long mode retains almost all of the 32-bit instructions, only a relative handful were ripped out.

Code running in 32-bit protected mode can't access 64-bit instructions or registers, of course, but that's a different issue. x32 is basically just long mode code that limits itself to instructions that use 32-bit addresses.

You can jump between 32-bit and 64-bit modes in a 64-bit Windows and Linux by switching between the 0x23 and 0x33 code segments. Like so:

    BITS 32
    start:
        call far 0x33:code64
    code32:
        nop ; resume
    code64:
    BITS 64
        xor rax, rax
    BITS 32
        retf ; return to 0x23:code32

That's interesting that the CS values are the same in windows and linux, more than a coincidence... Is this part of some x86_64 ABI spec?

After checking the docs, it seems the fast syscall instructions force the GDT to be laid out in a specific order. Since the segment values (selectors) are really offsets into the GDT, it makes sense that they end up being the same.

Very interesting. Is there one that lets you go into 16-bit mode too? ;)

Probably not; according to wikipedia you cannot go to virtual8086 mode from "long mode" (aka 64bit mode), which also explains why 64bit windows no longer ship an NTVDM or run 16bit dos and windows applications.

> Code running in 32-bit protected mode can't access 64-bit instructions or registers, of course, but that's a different issue.

That's what I was referring to - in 16-bit realmode you can use 32-bit registers and addressing modes with prefix bytes just like you can use 16-bit operands or addresses in 32-bit mode, and in protected mode both 16 and 32-bit segments can coexist in the same system. But it looks like 64-bit is completely isolated from that, although they could've used some other prefices, enabling access to 64-bit operands (including the extra registers) and addresses from any mode, and also allow coexistence of 64-bit segments with existing 32- and 16-bit segments. Then x32 wouldn't really need to exist; it would just be a 32-bit segment with instructions that use 64-bit operands.

x32 uses 64 bit registers to address memory in a theoretically 64 bit space. It simply decides to map all memory within the bottom 32 bits so that when it stores the pointers to memory they are 32 bits wide.

It might be more efficient than full-on 64 bit programs as long as a single process is ok with <4gb ram.

Debian has some work in progress on a port to x32 here: https://wiki.debian.org/X32Port

But it looks like they had the foresight to disable it for regular kernels because of security concerns: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708070#10