Envisioning a Simplified Intel Architecture
intel.com
intel.com
*cough*[1]
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.
> 16-bit and 32-bit protected mode are not supported anymore and cannot be entered. The CPU always operates in long mode. The 32-bit submode of Intel64 (compatibility mode) still exists.
I don't believe it's that simple (or obvious, since you seem to be mistaken).
" 3.3 Removal of 16-Bit and 32-Bit Protected Mode
16-bit and 32-bit protected mode are not supported anymore and cannot be entered. The CPU always operates in long mode. The 32-bit submode of Intel64 (compatibility mode) still exists. ... "
This is somewhat beyond my knowledge of system programming, but my read is that it's just possible to support 32-bit guest kernels in the VM with some more emulation of the de-supported instructions. I don't know how many of those instructions already cause VM exits.
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 right now. So most 32-bit software shouldn't be affected, unless you're getting really dirty with the segmentation features or trying to support something like Win16.
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.
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:(
If we're talking firmware, the gigantic mess that used to be called ACPI, still leave users suffering every day for example.
If it's 2% of instruction cost, then kill it with fire. If it's raising the development cost by 1%, kill it with fire. If it's a fixed cost and isn't hurting anything, then meh.
...and eliminating 16-bit operations would be pure ideologically-driven stupidity, given how many classic RISCs with word-width-operations-only suffered greatly and the ones that survived (like ARM) evolved to add them back in.
To be honest, there are two legacy x86 features which I suspect do have a noticeable tax on the support in the execution units: the x87 FPU stuff (due to the 80-bit floating-point types, and a variety of hardware-implemented transcendental instructions that need to be supported), and the legacy addressing modes.
If they're going to still support virtualisation to run legacy code, which is what the article is implying, they'll still need the logic to deal with all the existing modes being used inside a VM.
...and those modes are honestly not hard to support. (Protected mode) segmentation is far simpler than paging, and realmode is even easier given that the original 8086 with its 29k transistors could implement it.
Or, they are adding something new that puts them over that budget, and cleaning up the conditional branching lets them stay under it.
> ...and those modes are honestly not hard to support.
I have to imagine that there's a decent amount of extra logic in the load/store units to use the current processor mode to work out memory semantics, and now I'm thinking about questions like "what would happen if one thread is in virtual 8086 mode while the hyperthread partner isn't". That's a noticeable burden in things like validation.
And even if the implementation of segmentation is simpler than paging, that's not the issue; the issue is that it's a different pathway, and potentially one that cuts deep into the execution unit. If it's the sort of thing where eliminating support for anything other than paging means getting an L1 cache hit back one cycle faster... then sign me up.
If we're talking firmware, the gigantic mess that used to be called ACPI, still leave users suffering every day for example.
So please explain.
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 multiple instruction sets? Or provide some sort of programmable microcode section so emulators aren't done in software?
While I'm bitching, what happened to actually running multiple OSes at once? I have like 16 cores, gigabytes of RAM, multiple display outputs ... why can't I actually run both Linux and Windows and OSX all at once without some bad virtualization container inside one overarching OS? Like, can't Intel manage that with chipset and CPU logic?
Intel (and AMD) are DESPERATE to figure out things to get people to use all their extra cores and silicon for. Well, how about making multiple OS on the same machine an actually pleasant experience? Hell, I would love to run a smartphone OS as well.
why can't I actually run both Linux and Windows and OSX all at once without some bad virtualization container inside one overarching OS? Like, can't Intel manage that with chipset and CPU logic?
So, you could build a PC based LPAR hypervisor. It would just be limited to the SRIOV capable devices, or plugging in piles of adapters, each one uniquely bound to a single partition. Ex: https://www.hitachi.com/rev/pdf/2012/r2012_02_104.pdf
Nvidia did something sort of similar to this, but couldn't get licensing to use x86. https://en.wikipedia.org/wiki/Project_Denver
One DOS application I use was hurt by this: "old DOS OrCAD". It works well in Windows-XP on a 32-bit machine, but does not work at all in 64-bit Windows. (It's actually a 32-bit DPMI program and has drivers to use Windows GDI so you don't have to mess around with drivers).
More evidence: IBM 360 mainframe software still works in Z/OS.
It might be worth it for non-generic computing devices like cell phones, but Intel missed the boat there already.
How many people in the PC market still use 16-bit applications?
Why not? The bits don't decay.. Yes, this leads to an architectural mess, but I'm talking about a competitive business advantage.
> Yes, this leads to an architectural mess
Right there.
There's no notable advantage in supporting a very small minority of the applications out there, at the cost of keeping units useless for the 99%.
Potentially one if a large customer's paying you for it.
At work, I'm helping a client upgrade from a decade old version (v12) of our product and having to copy over the switches to keep the even older (v11 and previous) behaviours
I’m quite sure we will be OK without support for 16-bit instructions.
An 8086 has 29000 transistors. A modern CPU has several billion. The amount needed to implement the 16-bit subset of the ISA is an absolutely tiny fraction of the total area.
A few of the cost of legacy:
* exponential growth in verification space (each feature combines with all other features),
* design complexity (effort that could be spent better),
* area/power/cycle time overhead (all options require more ports to muxes, more wires to run, etc.)
* and most importantly, opportunity costs: some optimization tricks can't be pursued because the assumptions would break for legacy code
The legacy tax is real
I won't give away too much of my personal history, but it suffices to say I've worked with x86 at the hardware level before.
each feature combines with all other features
They do, but orthogonally.
effort that could be spent better
Effort that has already been spent.
all options require more ports to muxes, more wires to run, etc
It's all ultimately split into uops anyway.
some optimization tricks can't be pursued because the assumptions would break for legacy code
What assumptions in particular?
Microsoft could have used emulation to keep old 16-bit x86 apps working with Windows for AMD64 (in fact they had done this before for non-x86 architectures) but I guess they weren't interested. WINE and DOSBox did it though.
And if you have very old but important windows legacy software you either want to also run old hardware and windows OS anyway or run enumeration anyway.
On linux this is somewhat already the case, most distroes are by now for OS 64bit only with at most 32bit application support but not always enabled by default.
This was a thing? So, would it still run in the "MS-DOS Command Prompt" in Windows but talk directly to Windows for its screen drawing?
https://airborn.com.au/layout/vddtest.html
A 16-bit DOS application using DirectX..
In the case of OrCAD this was very easy because it already had plug-in architecture for graphics. It had this because even the mouse was not standardized in the early days.
You can blame AMD for that and the other dubious decisions in the design of amd64 in general.
vm86 doesn't work in 64-bit mode, but you can simply temporarily switch down to 32-bit mode, and them vm86 works just fine. Early amd64 Linux would do this, and there was even a kernel module to do it after they dropped support for it.
Microsoft had other reasons to drop 16-bit support in Windows 64.
Namely, planned obsolescence. They realised that forcing people to consume could squeeze a little more $$$ from them.
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.
Maybe Moore's Law really is dead.
/tears for the end of Moore's Law, just shortly after that great man passed away.
Okay that's a bit heavy on the retcon, don't you think?
but also it's a stretch in general as for personal computers arm is the dominant platform since years (there are way more phones, tablets, etc. then x86 laptops/desktops by now, all of which fit the original definition of personal computer)
I wish AMD had started this instead of Intel so they could call it AE86.
A large amount of server software can be reasonably ported to a new architecture. New platforms can adopt new architectures (phone/tablet, AR/VR). General purpose software like a web browser abstracts hardware, as does very popular software (as Facebook had, and WeChat does).
Apple hasn't been tied to architectures and transitioned a number of times, always optimizing the whole rather than optimizing intermediate/stationary fixed points. If Intel is to make it to the next phase, it needs more than incremental improvements to compete. I hope that there's a path/future for AMD and Intel to evolve x86 and thrive but it won't be a given or easy.
Did they not learn from the https://en.wikipedia.org/wiki/Intel_80376 or the infamous Itanic?
The almost 50 years of backwards compatibility (along with the accompanying creation of a huge amount of documentation) is one of the strongest reasons for choosing the x86/PC.
With each feature removal, they weaken that argument and push their (prospective) customers towards reconsidering all the other competitive CPUs out there like ARM, MIPS, RISC-V, etc. that are not distant in performance.
Intel has made SoCs for phones, tablets, and other miscellaneous devices, but they weren't PC-compatible. Not surprisingly, they were not well-received.
Related: https://news.ycombinator.com/item?id=8091290
Maybe it's time for a CISC-V...?
Edit: apparently respecting history is not a popular opinion.
I believe the only path forward for x86 is to be a "x86 accelerator", a x86 mode in some future AMD/Intel RISC-V processors, perhaps limited to unprivileged "usermode".
Easing the transition until x86 can be relegated to emulation.
The devil reveals itself. Competitors have infected Intel and are trying to destroy it from within.
x86 without the legacy is just another ISA, and Intel is going to lose if it tries to go down that path.
I must be missing something, as while popular, it is and has always been a mess.
The 4 layer security architecture that the 386 originally proposed, user, privileged library/service, driver space, and kernel, now with the addition of a hypervisor layer would be a good starting place for modern OS privilege separation. Plus base + size restricted pointers with an attached privilege provided by the 386's variable length segments are the kinds of things that CHERI is trying to bolt on using a slightly different paradigm. Even call gates if used between different modules/etc would have acted as a control flow mitigation technique likely partially obliviating the need for CET, PAC and BTI.
So it wouldn't surprise me at all, if in another 20 years 90% of the 386's capability model has been bolted back onto AMD's long mode in a slightly different, and likely worse way.
It will surprise me if x86 or arm are still relevant 3 years from now.
The way I see it, as the first batch of very high performance designs releases, including but not limited to Ventana Veyron before year end, as well as Tenstorrent Ascalon in 2024, it will be obvious to any leftover skeptics in the industry that it is over, and RISC-V has won.
Easing the transition until x86 can be relegated to emulation.
Or I guess you could look at it another way, CISC won because it turns out that implementing specific high level functions like say AES, memcpy or vector ops are better implemented with explicit hardware blocks, or provide additional hinting that gives the micro architecture an advantage, while the costs of cracking inconvenient sequences into simpler ones means that effectively the processor designer has the choice between attempting to build hardware for something like Arm's Load/store Multiple or simply breaking it into a sequence of uOps (which one might suggest is basically the modern equivilant of micro code).
And this is why I'm a bit skeptical of RISC-V at the moment. No serious architect of high performance microprocessors can think that designing an architecture to match a modern low transistor budget microcontroller is a good design choice. Because like every other single RISC processor, what happens over time is that they are forced to add higher level instructions for the additional hinting they can provide. If you look at the past 10 years of arm architecture updates you can read between the lines of "the RISC solution for X we were using couldn't compete with vendor Y's product so we added this instruction/etc to solve the problem". Same with POWER, they even gave up on their famous inverted page tables because it was basically a software managed TLB and it turns out building page walking hardware is a better solution than writing software to do it. Its also how no one takes a processor without some kind of SIMD seriously anymore.
That said, its not like RISC-V can't evolve into something "good enough" its just going to be stuck with a bunch of ugly baggage by the time it gets there because its starting with a false set of premises.
That is the erroneous assumption. RISC-V is no such thing.
Maybe we'll see RISC-V backends with x86 frontends in the future.