4 ms·

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

by snvzz 3y ago

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

userbinator 3y ago
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.
- mepian 3y ago
  Intel is going to lose because it ditched Ring 1 and 2, sure.
  - userbinator 3y ago
    ...and everything else that made the PC great.
    - snvzz 3y ago
      When was the PC ever great? I must be missing something, as while popular, it is and has always been a mess.
  - StillBored 3y ago
    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 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.
    - snvzz 3y ago
      >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.
StillBored 3y ago
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 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.
- snvzz 3y ago
  >an architecture to match a modern low transistor budget microcontroller That is the erroneous assumption. RISC-V is no such thing.
- userbinator 3y ago
  Fun fact: VIA's "alternate instruction set" that gives access to the uops shows that it's basically a slightly modified MIPS, with more useful x86-ish addressing modes and instructions. Maybe we'll see RISC-V backends with x86 frontends in the future.

by snvzz 3y ago

userbinator 3y ago

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.

mepian 3y ago
Intel is going to lose because it ditched Ring 1 and 2, sure.
- userbinator 3y ago
  ...and everything else that made the PC great.
  - snvzz 3y ago
    When was the PC ever great? I must be missing something, as while popular, it is and has always been a mess.
- StillBored 3y ago
  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 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.
  - snvzz 3y ago
    >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.

StillBored 3y ago

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

snvzz 3y ago
>an architecture to match a modern low transistor budget microcontroller That is the erroneous assumption. RISC-V is no such thing.
userbinator 3y ago
Fun fact: VIA's "alternate instruction set" that gives access to the uops shows that it's basically a slightly modified MIPS, with more useful x86-ish addressing modes and instructions. Maybe we'll see RISC-V backends with x86 frontends in the future.