81–86 of 86 posts
That Intel has to thread carefully to dump in-hardware 16 bit compatibility mode in 2023 is just sad.
I can also see why who does not have to deal with so much baggage on their shoulders is capable of being much more nimble and drive innovation.
Finally I can now better understand why Apple dumps an ISA every decade or so.
> Since its introduction over 20 years ago, the Intel® 64 architecture became the dominant operating mode. *cough*[1] [1] https://en.wikipedia.org/wiki/X86-64#History
I guess we should be thankful they aren’t still calling it EM64T :) I’ve also heard that the term AMD64 also originated from marketing—the internal name during development was x86-64 (which everybody but Microsoft ended up calling it anyway).
The fact that ia32 (and it's sub-classifiers: i386, i486, etc) is still somewhat used, while amd64 has almost completely disappeared is 100% due to Intel's marketing shenanigans in the 00s.
Earlier quoted context omitted.
I guess we should be thankful they aren’t still calling it EM64T :) I’ve also heard that the term AMD64 also originated from marketing—the internal name during development was x86-64 (which everybody but Microsoft ended up calling it anyway).
"amd64" is the official name, per AMD; just as "ia32" is the official name of x86-32, per Intel. The fact that ia32 (and it's sub-classifiers: i386, i486, etc) is still somewhat used, while amd64 has almost completely disappeared is 100% due to Intel's marketing shenanigans in the 00s.
For those truly too lazy to click through to the article, x86-S stands for "simplified," with the idea being to boot directly into 64-bit mode instead of booting into 16-bit and bootstrapping to 64-bit mode. 16-bit mode would be removed entirely. It's not clear to me if 32-bit mode would be axed as well, or if it would be retained (maybe partially).
Ok, so maybe you do that in boot order or some boot motdes. But ... remove it? There is SO MUCH silicon these days, honestly I think CPUs should start putting instruction set compatibility cores in, so you still dedicate .5% to a 16 bit compatibility core, 1% to the 32 bit mode, and maybe even an ARM mode. Honestly, since all CPUs are basically fronted by microcode, why can't modern CPU microcode be compatible with m…
Nvidia did something sort of similar to this, but couldn't get licensing to use x86. https://en.wikipedia.org/wiki/Project_Denver
For those truly too lazy to click through to the article, x86-S stands for "simplified," with the idea being to boot directly into 64-bit mode instead of booting into 16-bit and bootstrapping to 64-bit mode. 16-bit mode would be removed entirely. It's not clear to me if 32-bit mode would be axed as well, or if it would be retained (maybe partially).
> It's not clear to me if 32-bit mode would be axed as well, or if it would be retained (maybe partially). I've been reading the detailed pdf to see more details. It looks to me like 32-bit mode, specifically in the sense of a 32-bit distribution of modern software, is being retained. Segments would be converted more towards their 64-bit extremely attenuated mode, rather than the more robust functionality they have r…
Which, ten years down the line, should free up a bit more opcode space when they decide to no longer support CS/DS/ES/SS segment prefixes. The space could be used for instructions that are the same in 32-bit and 64-bit modes.
The primary ("first byte") opcode space is quite busy in 32-bit mode. Intel and AMD figured out a way to "hide" extra instruction prefixes in illegal modes of certain 16/32-bit instructions. Intel did this with the VEX prefix and AMD did it with the XOP prefix. The instructions they chose were LES/LDS and POP. This is the reason why some of the bits in those multi-byte prefixes have to be inverted, btw.
Having 4 clean bytes available with no need for such silly games should prove useful in the future.
The 4 string I/O instructions they suggest removing will be useful immediately.
Removing all ring 3 I/O instructions (also part of the plan) will free up 8 further bytes in the primary opcode map for user space code. This could perhaps be used to provide shorter aliases of certain existing encodings -- so the instructions in question would still be available for kernels but applications would see better encoding density.
And then there is the 67h byte being freed as well due to removing address size overrides.
If they are sensible, they will also remove the BOUND instruction from 32-bit mode, but that is not in the current version of the plan.
So what are the benefits?
Free space in the primary opcode map => better encoding density... and they might not be doing this to give us shorter programs. They might be doing this so the parallel instruction decoders can handle more instructions per cycle.
Getting rid of 16-bit data will make the data flow engine in future CPUs simpler (no more partial register stalls).
They also get to remove lots and lots of special cases that undoubtedly cost engineering time and validation time.
Earlier quoted context omitted.
> It's not clear to me if 32-bit mode would be axed as well, or if it would be retained (maybe partially). I've been reading the detailed pdf to see more details. It looks to me like 32-bit mode, specifically in the sense of a 32-bit distribution of modern software, is being retained. Segments would be converted more towards their 64-bit extremely attenuated mode, rather than the more robust functionality they have r…
> Segments would be converted more towards their 64-bit extremely attenuated mode, rather than the more robust functionality they have right now. Which, ten years down the line, should free up a bit more opcode space when they decide to no longer support CS/DS/ES/SS segment prefixes. The space could be used for instructions that are the same in 32-bit and 64-bit modes. The primary ("first byte") opcode space is quite…
The document explicitly says that segment prefixes are _ignored_.
> Removing all ring 3 I/O instructions (also part of the plan) will free up 8 further bytes in the primary opcode map for user space code.
It does not unless the same codes are removed in ring 0 as well. But if ring 0 IO commands are converted to multibyte, why ring 3 IO commands can't get the same?
> And then there is the 67h byte being freed as well due to removing address size overrides.
Again, not ignored - unsupported styles get GP instead.
> Free space in the primary opcode map => better encoding density...
Won't happen. More so, most encodings are shared with 32-bit mode and still developed this way.
> Getting rid of 16-bit data will make the data flow engine in future CPUs simpler (no more partial register stalls).
This is missed as well. 16-bit data are still handlable. Only addressing is disallowed.
> So what are the benefits?
Seems pretty none among what you listed:(