61–70 of 86 posts
Earlier quoted context omitted.
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.
Intel is going to lose because it ditched Ring 1 and 2, sure.
This makes no sense to me. Backward compatibility is a huge competitive advantage for Intel, and IMHO, it's royally messed up that vm86 mode doesn't work in 64-bit mode. 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 mes…
and has drivers to use Windows GDI so you don't have to mess around with drivers 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.
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).
If I had to list one hundred ways x86 could be improved, not booting in 16-bit mode wouldn't be on it. It's just an incantation. There's no fallout from it. If we're talking firmware, the gigantic mess that used to be called ACPI, still leave users suffering every day for example.
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.
Earlier quoted context omitted.
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.
Intel is going to lose because it ditched Ring 1 and 2, sure.
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.
Do not want. 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 competit…
>Maybe it's time for a CISC-V...? 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.
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.
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…
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
Earlier quoted context omitted.
>Maybe it's time for a CISC-V...? 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.
Easing the transition until x86 can be relegated to emulation. Uh, isn't that the point? X86 has been "emulated" since the P6/nexgen 586. That is why people talk about the architecture not mattering much anymore in the face of very similar OoO microarchitectures running arm/ppc/x86/etc code. Or I guess you could look at it another way, CISC won because it turns out that implementing specific high level functions like…
That is the erroneous assumption. RISC-V is no such thing.
Earlier quoted context omitted.
and has drivers to use Windows GDI so you don't have to mess around with drivers 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?
Yes, here is how to do it: 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.
Earlier quoted context omitted.
Unless they want to complete eliminate 16-bit operations, it won't matter. ...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.
What they're getting rid of is all of the extra fun memory management modes the x86 processor has, condensing everything down into just the paging mode with extremely gimped segment support that's all that's available in x86-64. That suggests to me that someone within Intel is thinking about basically rewriting the memory subsystem, where having to support all the fun things like real mode or virtual 8086 mode is muc…
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.
Earlier quoted context omitted.
Intel is going to lose because it ditched Ring 1 and 2, sure.
I wonder... With MS's virtualization based security, and the Arm/Cheri proposals, if it isn't time to revisit much of the capability hardware that AMD removed when they designed long mode. Never mind the long list of C mitigation hardware that both intel and arm are now reinventing. The 4 layer security architecture that the 386 originally proposed, user, privileged library/service, driver space, and kernel, now with…
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.