3 ms·

If as many people worked on SPARC CPUs as Intel had/has working on x86 CPUs, would some of these problems have been solved? A modern x86_64 chip is immensely co

If as many people worked on SPARC CPUs as Intel had/has working on x86 CPUs, would some of these problems have been solved? A modern x86_64 chip is immensely complicated internally. Also, would register windows have caused speculative execution problems analogous to "Spectre"? You did have to keep some weird number of bytes (96?) available for register spills when you created a new stack frame. It might be possible to get Spectre like leaks from the kernel in that spill zone.

akira2501 3y ago
> If as many people worked on SPARC CPUs as Intel had/has working on x86 CPUs, would some of these problems have been solved? Unlikely, they optimized for the wrong case, and made multitasking context switches very painful. From the kernel's perspective, you could add hardware workarounds, but they would be unwieldy and likely hard to code securely around. > A modern x86_64 chip is immensely complicated internally. Any OOO chip is going to be. x86 has somewhat more complicated instruction decoders due to variable length instructions, but past that, it's not very much more or less complicated than any other contemporary ISA. > would register windows have caused speculative execution problems analogous to "Spectre"? Any processor with a cache that is modified by speculative execution is vulnerable to Spectre.
- pcwalton 3y ago
  There's a big difference in complexity between OoO implementations of RISC-V like BOOM and a modern x86-64 CPU.
  - akira2501 3y ago
    There's a big difference in performance too. Which is why the BOOM has several versions, continually adding more advanced parts to chase performance. I look at the BOOMv3 layout and all I see is an old "Netburst Pentium." Which is probably why it sees AWS Graviton as it's main competition. So, the "lack of complexity" comes from a "lack of sophistication." There are no free lunches is the point and you're going to end up with a chip that's just as complex as any other OOO out there, and very little of that complexity is going to be due to the ISA, once you match performance.
- zdw 3y ago
  I wonder how much the massive amounts of SMT in later T-series SPARC chips (up to 8 threads/core IIRC) helped deal with this issue - if you can just spin up a new thread with it's own set of register windows, does the OS-level context switch penalty still hurt as much?
shrubble 3y ago
Yes, given that Intel's ability to have smaller process sizes helped greatly to paper over any design flaws. The first SPARC V7 CPU had 110k transistors on 1300nm process to the 386DX's 275k on 1000nm and less process.

akira2501 3y ago

> If as many people worked on SPARC CPUs as Intel had/has working on x86 CPUs, would some of these problems have been solved? Unlikely, they optimized for the wrong case, and made multitasking context switches very painful. From the kernel's perspective, you could add hardware workarounds, but they would be unwieldy and likely hard to code securely around. > A modern x86_64 chip is immensely complicated internally. Any OOO chip is going to be. x86 has somewhat more complicated instruction decoders due to variable length instructions, but past that, it's not very much more or less complicated than any other contemporary ISA. > would register windows have caused speculative execution problems analogous to "Spectre"? Any processor with a cache that is modified by speculative execution is vulnerable to Spectre.

pcwalton 3y ago
There's a big difference in complexity between OoO implementations of RISC-V like BOOM and a modern x86-64 CPU.
- akira2501 3y ago
  There's a big difference in performance too. Which is why the BOOM has several versions, continually adding more advanced parts to chase performance. I look at the BOOMv3 layout and all I see is an old "Netburst Pentium." Which is probably why it sees AWS Graviton as it's main competition. So, the "lack of complexity" comes from a "lack of sophistication." There are no free lunches is the point and you're going to end up with a chip that's just as complex as any other OOO out there, and very little of that complexity is going to be due to the ISA, once you match performance.
zdw 3y ago
I wonder how much the massive amounts of SMT in later T-series SPARC chips (up to 8 threads/core IIRC) helped deal with this issue - if you can just spin up a new thread with it's own set of register windows, does the OS-level context switch penalty still hurt as much?

shrubble 3y ago

Yes, given that Intel's ability to have smaller process sizes helped greatly to paper over any design flaws. The first SPARC V7 CPU had 110k transistors on 1300nm process to the 386DX's 275k on 1000nm and less process.