←back to thread

Athlon 64: How AMD turned the tables on Intel

(dfarq.homeip.net)
331 points giuliomagnifico | 5 comments | 25 Sep 25 18:09 UTC | HN request time: 0.001s | source
Show context
deaddodo ◴[25 Sep 25 20:01 UTC] No.45378189[source]▶
Nitpick: The author states that removal of 16-bit in Windows 64 was a design decision and not a technical one. That’s not quite true.

When AMD64 is in one of the 64-bit modes, long mode (true 64-bit) or compatibility mode (64-bit with 32-bit compatibility), you can not execute 16-bit code. There are tricks to make it happen, but they all require switching the CPU mode, which is insecure and can cause problems in complex execution environments (such as an OS).

If Microsoft (or Linux, Apple, etc) wanted to support 16-bit code in their 64-bit OSes, they would have had to create an emulator+VM (such as OTVDM/WineVDM) or make costly hacks to the OS.

replies(3): >>45378270 #>>45378503 #>>45378862 #
jcranmer ◴[25 Sep 25 20:24 UTC] No.45378503[source]▶
I've written code to call 16-bit code from 64-bit code that works on Linux (because that's the only OS where I know the syscall to modify the LDT).

It's actually no harder to call 16-bit code from 64-bit code than it is to call 32-bit code from 64-bit code... you just need to do a far return (the reverse direction is harder because of stack alignment issues). The main difference between 32-bit and 16-bit is that OS's support 32-bit code by having a GDT entry for 32-bit code, whereas you have to go and support an LDT to do 16-bit code, and from what I can tell, Windows decided to drop support for LDTs with the move to 64-bit.

The other difficulty (if I've got my details correct) is that returning from an interrupt into 16-bit code is extremely difficult to do correctly and atomically, in a way that isn't a problem for 32-bit or 64-bit code.

replies(1): >>45379259 #
deaddodo ◴[25 Sep 25 21:20 UTC] No.45379259[source]▶
Executing 16-bit code in Compatibility Mode (not Long Mode) is possible, that's not the problem. The problem is lack of V86 allowing legacy code to run. So Real Mode code is out wholesale (a sizable chunk of legacy software) and segmented memory is out in Protected Mode (nearly the totality of remaining 16-bit code).

So yes, you can write/run 16-bit code in 64-bit Compatibility Mode. You can't execute existing 16-bit software in 64-bit Compatibility Mode. The former is a neat trick, the latter is what people actually expect "16-bit compatibility" to mean.

replies(2): >>45379548 #>>45432033 #
jcranmer ◴[25 Sep 25 21:46 UTC] No.45379548{3}[source]▶
> segmented memory is out in Protected Mode (nearly the totality of remaining 16-bit code).

No, segmented memory is exactly what you can get working. You set up the segments via the LDT, which is still supported even in 64-bit mode; this is how Wine is able to execute Win16 code on 64-bit Linux. (Reading Wine code is how I figured out how to execute 16-bit code from 64-bit code in the first place!)

What doesn't work, if my memory serves me correctly, is all the call gate and task gate stuff. Which is effectively building blocks for an OS kernel that everyone tossed out in the early 90s and instead went with kernel-mode and user-mode with the syscalls (first software interrupts and then the actual syscall instruction in x86-64). You don't need any of that stuff to run most 16-bit code, you just need to emulate the standard Windows DLLs like kernel, ntdll, and user.

replies(1): >>45382621 #
1. deaddodo ◴[26 Sep 25 04:24 UTC] No.45382621{4}[source]▶
Neither the AMD nor Intel TRMs agree with you. Both confirm that, even with LDTs, segments will not function with the legacy 16-bit wraparound; nor can you run 16-bit code segments. Fairly critical for most 16-bit software. Not to mention another critical incompatibility issue (for some software) that you yourself pointed out: far pointers.

And again, that only covers protected mode software, it doesn’t even touch the sheer cliff that is Real Mode (gating issues, for instance).

You wrote 16-bit code with knowledge of the limits imposed by Long Mode. Congrats. Too bad none of the thousands of pieces of software written in the 80s and 90s had that hindsight, so didn’t. The conversation is about running legacy code, not your/bespoke code.

replies(1): >>45382874 #
2. jcranmer ◴[26 Sep 25 05:09 UTC] No.45382874[source]▶
I'm successfully running code that was written 10 years before x86-64 was invented on Linux x86-64. You can, too--just find some Win16 software online somewhere and run it under wine, and confirm that it's running without any hardware emulation mode enabled.

And yes, this code is using far pointers.

Do you need me to post my code that loads and executes a NE executable to believe that it's possible?

FWIW, here's what the Intel manual says about running 16-bit code in IA-32e mode:

> In IA-32e mode, the processor supports two sub-modes: compatibility mode and 64-bit mode. 64-bit mode provides 64-bit linear addressing and support for physical address space larger than 64 GBytes. Compatibility mode allows most legacy protected-mode applications to run unchanged.

> In IA-32e mode of Intel 64 architecture, the effects of segmentation depend on whether the processor is running in compatibility mode or 64-bit mode. In compatibility mode, segmentation functions just as it does using legacy 16-bit or 32-bit protected mode semantics.

Those don't sound to me like statements saying that there's no way to get 16-bit legacy applications running on 64-bit mode. Quite the contrary, they're saying that you should expect them to work largely the same.

What does the Intel manual say is actually broken in compatibility mode? This:

> Compatibility mode permits most legacy 16-bit and 32-bit applications to run without re-compilation under a 64-bit operating system. [...] Compatibility mode also supports all of the privilege levels that are supported in 64-bit and protected modes. Legacy applications that run in Virtual 8086 mode or use hardware task management will not work in this mode.

replies(1): >>45387461 #
3. deaddodo ◴[26 Sep 25 15:14 UTC] No.45387461[source]▶
Funny you gloss over the most important part:

> Legacy applications that run in Virtual 8086 mode or use hardware task management will not work in this mode.

That being said, this isn't worth arguing over. If you can provably run late 1980s-early 1990s 16-bit code in AMD64 compatibility mode, with full execution protections and support of even most not all commercial software; that goes against the general understanding of those architectures. Document it and add it to the academic sphere to expand the knowledge.

replies(2): >>45387859 #>>45389727 #
4. jcranmer ◴[26 Sep 25 15:48 UTC] No.45387859{3}[source]▶
I can see that DOS applications might require Virtual 8086 mode, but from what I can tell, almost no Win16 applications require it nor require hardware task management (I'm not even sure I'm aware of any application that uses hardware task management!).

Granted, Win16 is not an especially long period of active application development, but I would expect that the vast majority of Win16 applications would work perfectly fine in x86-64 compatibility mode. I know that the ones I have played with do.

5. Agingcoder ◴[26 Sep 25 18:45 UTC] No.45389727{3}[source]▶
I love your answer.

It’s honest, and actually typical of this kind of problem space where what’s possible exceeds what was expected.

It reminds me of what coders did with older atari st machines to achieve overscan and a whole bunch of other tricks. The manuals explicitly stated that some things were not possible or would cause machine resets … except that there was a way.