6 ms·

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 ou

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.

pbsd 13y ago
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
- 0x0 13y ago
  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?
  - pbsd 13y ago
    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.
- userbinator 13y ago
  Very interesting. Is there one that lets you go into 16-bit mode too? ;)
  - 0x0 13y ago
    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.
userbinator 13y ago
> 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.

pbsd 13y ago

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

0x0 13y ago
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?
- pbsd 13y ago
  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.
userbinator 13y ago
Very interesting. Is there one that lets you go into 16-bit mode too? ;)
- 0x0 13y ago
  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.

userbinator 13y ago

> 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.