[spamizbad]

A lot of these architecture have some drawbacks in modern times.

Alpha’s loosey-goosey memory model makes multithreaded code on SMP systems more challenging. Linux utilizes its Alpha port as a worst-case testbed for data race conditions in its kernel.

SPARC’s register windows are anachronistic and complicate the implementation of CPUs, and I’d guess also make it more difficult to build OoOE cores (so many SPARC chips are in-order, why?)

POWER isn’t so bad though. It’s open enough where you could build your own lower-cost core if you wanted. There’s nothing intrinsic to the ISA that would mandate an expensive chip other than volume constraints.

PA-RISC put up some great numbers back in the day but between the Compaq acquisition (bringing with it Alpha) and Itanium it was chronically under-resourced. They had a great core in the early 90s and basically just incrementally tweaked it until its death.

[classichasclass]

You could even build your own Power ISA system with Microwatt, which is fully synthesizeable and growing by leaps and bounds.

https://github.com/antonblanchard/microwatt

(Disclaimer: minor contributor)

I really liked PA-RISC. I thought it was a clean ISA with good performance at the time and avoided many of the pitfalls of other implementations. I think HP didn't want to pour lots of money into it to keep it competitive, though, and was happy to bail out for Itanium when it was viable. My big C8000 is a power hungry titan, makes the Quad G5 seem thrifty.

[monocasa]

IDK, I never really liked PA-RISC, but to be fair I was always able to look at it from a hindsight perspective. Looking back it seems to have most of the RISC issues that complicate modern ISA design. Like branch delay slots, having a multiply instruction wasn't RISCy enough for it to bother with, etc.

[userbinator]

...and MIPS has the weird branch delay slots as well as pretty horrible code density.

If you look at ARM, particularly the 64-bit version, you'll notice it attempts to squeeze multiple operations into a single 32-bit "instruction". It's still called RISC, but not really "reduced" anymore.

[mastax]

Nowadays RISC seems to mean "load-store architecture" but I think the term should be left in the 90s. CS curriculum is slow to evolve.

[klelatti]

Not sure anyone sees "pure" RISC as being an advantage these days though. Didn't Intel demonstrate that you could get RISC-like performance from a CISC ISA even with all the drawbacks of x86 (instruction decoding complexity etc).

[bsder]

> Alpha’s loosey-goosey memory model makes multithreaded code on SMP systems more challenging.

I thought Alpha and ARM were the same with respect to that.

ARM had some fairly nasty to track down XFS file system corruption bugs for quite a while for exactly this reason.

The issue has always been that x86 goes out of its way to generally be more forgiving than the spec.

[asveikau]

> Linux utilizes its Alpha port as a worst-case testbed for data race conditions in its kernel.

Is that still true in the present tense? Anybody doing this in 2021? Seems like alpha has been dead for a long time.

[bonzini]

Not Linux but the Linux formal memory model. The idea is that the compiler optimizations can be as nasty as the Alpha out of order execution engine and cache. The Linux code has to cater for these optimizations even though it will not result in an actual assembly instruction on anything except the Alpha. Problem is, on Alpha there's indeed an actual price to pay in performance for that nastiness.

[asveikau]

I suspect you misunderstand the question. My question is if anybody is presently using alpha hardware to verify such correctness. I understand memory models and barriers etc. and that alpha is one of the most relaxed on this front, that it historically influenced the kernel code and was previously very important test hardware. But the hardware is now very dated, to the point where it might not be good test hardware.

[bonzini]

The answer to that question is no, but the Alpha is still considered the least common denominator even though the hardware is obsolete. When people write litmus tests for the Linux memory model they are still validated against Alpha semantics, because compiler optimizations have the same reordering effects as the weird caches of Alpha processors.

(The stroke of genius of the C++11 memory model, compared to the older Java memory model, was that reordering could be treated the same way no matter if performed by processors or compilers).

[mhh__]

I know that GCC for example is tested on a bunch of wacky old - read: obsolete ;) - hardware, so it's certainly possible that the same is true for Linux.