> And DEC alpha.

I really wish all these "open source" chips would just steal the DEC Alpha microarchitecture and implement it. It's been almost 20 years--even the patents on EV7 should have run out by now.

It was a really clean, mostly orthogonal microarchitecture that had most of the really annoying implementation corners filed down. EV5 is a very straightforward chip and maps very well to low power implementations (see StrongARM). EV6 is pretty straightforward in modern technology nodes.

And, best of all, it's documented. Compilers exist. Operating systems exist. Old hardware exists that can be used for validation and initial development. It wouldn't require you to build an entire ecosystem up front in order to bootstrap.

IIRC one of those homegrown Chinese HPC chips were rumored to more or less use the Alpha ISA.

That being said, I wonder if at this point all the low level software (kernels, toolchains etc.) have bitrotted to the point that you're not buying much, if anything, compared to using RISC-V.

And it's not like Alpha doesn't have those irritating ISA idiosyncrasies. E.g. the most crazily relaxed memory model known to man. No byte load/store until, uh, EV56(?). And it's big endian, which per se isn't wrong in any way, you'll just be dealing with endian bugs forever and ever when porting since the rest of the computing universe, for better or worse, has converged on little endian (x86, ARM, even Linux on OpenPOWER)

Regarding the big-endian nature of it: kinda, but also kinda not. Network endianness is generally big, so it'd work well in those instance without needing to do any juggling. Plus (speaking from experience many decades ago on the 68k) reading big-endian memory was so much easier that trying to decipher things in a hex editor on ix86. Though, granted, this is both apocryphal and a minor thing to worry about.

You'd be surprised how many workloads end up spending large amounts of time in memcmp / strcmp. The chief advantage of big-endianness is that a 64-bit read is already in the order necessary for strcmp or memcmp. This means you don't need specialized instructions for fast strcmp / memcmp. Though, I would guess in a pipelined implementation with good pre-fetch logic, you'll usually not pay any time penalty (and only a single instruction in size penalty) for a byte order swap instruction in the middle of strcmp / memcmp.

> No byte load/store until, uh, EV56(?).

I believe that you can blame a MIPS patent for that, IIRC.

> And it's big endian, which per se isn't wrong in any way, you'll just be dealing with endian bugs forever and ever

Actually, that was one of the biggest benefits to porting Linux to Alpha. A HUGE number of assumptions got cleaned up. I suspect the current ARM ports of Linux would be almost a decade behind without that.

That's what some people were doing with SuperH; I don't know how the project has progressed.

https://lwn.net/Articles/647636/

[If you wanted to resurrect the Alpha, though, please do not resurrect the crazy memory consistency semantics, where you need to put a full memory barrier between

    r0 = load(&x);
    r1 = load(r0);

Do you have any pointers to good documentation on the Alpha memory semantics?

The memory semantics are of course so lax so that the processor doesn't need to check the computed addresses of all in-flight stores before issuing a concurrent memory operation. My understanding is that it's mostly a footgun for assembly programmers, but I'd love to see any estimates of the speed and power efficiency benefits of the lax memory semantics.

This is one of the raging debates within the RISC-V group and elsewhere. Is weak memory semantics really worth it or can x86 style TSO be implemented optimally.Lot of anecdotal evidence but no conclusive experiment. As part of our work we hope to try multiple memory models in our I-class and get some definitive answers.RISC-V by the way supports ARM/PPC style weak memory model or optionally an x86 style TSO.

ARM/PPC is fine, but Alpha took it too far in my opinion (and also didn't have a read memory barrier instruction---nowadays acquire and release memory barriers would probably be preferrable).

How else will I be able to bank the lower-level cache for the absolute highest in performance?

+1 for using the archaic phrase "tough row to hoe", and for using it correctly. :-) In the few times I've heard someone say it, they say "road to hoe" which doesn't really make sense.