Hacker News Reader

Comment by aluminum96 | Hacker News Reader

This is slightly off topic -- it's about an old supported microarchitecture -- but Linux still supports DEC Alpha, despite no chip with that architecture having been developed since 2004.

DEC Alpha has extremely weak memory ordering. [1] In fact, it's the weakest ordering of any arch supported by linux, which includes extra fence instructions to support it. The memory model is crazy weak, but it apparently allows for extra speculative execution parallelism.

[1] Awesome Raymond Chen post, totally worth a read: https://devblogs.microsoft.com/oldnewthing/20170817-00/?p=96...

View on HN

Linux doesn't do anything special for alpha's dependent-loads-reordering any more. smp_read_barrier_depends() was removed and the ordering concerns pushed down into other primitives.

Apparently the L1 cache was implemented with two blocks handling even and odd lines, and they would process coherency operations out of order with respect to one another which is why dependent loads can see data out of order. So not additional speculative execution parallelism but probably a simpler physical design for the cache.

When I was at the University of Birmingham in the 90's there was an entire lab of SparcStations that was always overly busy ... but I always preferred the much quieter lab that was hardly used which was replete with DEC Alpha machines - they ran rings around the Sparc's that the university had.

I also went to university in the 1990s, at McGill in Montreal, and we also had labs full of different architectures/vendors' workstations -- Sparc lab, Alpha lab, NeXT lab, RS6000 lab (with AIX), and a brand-new Linux lab, but that clearly that wasn't going to go anywhere.

I don't miss having to think about architecture and different Unix variants all the time, but I do miss the variety.

One question: why?

Is this still used en masse somewhere and needs updates? Consider me 100% ignorant.

Why support real hardware? Old as Alpha AXP CPUs are they are still orders of magnitude faster than emulating the instruction set.

Why care about the instruction set? It a very good regression test for the kernel locking primitives and data structures. Something "boring" like x86 with its TSO memory model will hide bugs.

Is there something special about Alpha that makes it hundreds of times harder to emulate? X86 Windows XP on my M1 MacBook runs CPU bound workloads faster than my XP machine in 2004 did and that's not even using the extra X86 emulation specific parts of the M1 cores, just bog standard QEMU.

Probably because a lot of effort goes into optimising x86 emulation to be as efficient as possible, whereas I doubt anyone is motivated to make the same investment in DEC Alpha emulation. In practice that will make Alpha emulation slower than x86, quite apart from any technical features of their respective architectures which may impact the efficiency of emulation.

Right. There's no fundamental impediment to writing a super fancy JIT translator from Alpha to another architecture.

Such a thing actually exists as part of VMS! DEC was one of the first to use binary translation commercially like that. First to run VAX code on Alpha, and then Alpha code on Itanium. And now Alpha and VAX code on x86. (Doesn't look like VSI will bother with Itanium to x86 on the assumption customers will have source.)

Is it _really_ a bug if it functions correctly on supported hardware?

Probably a combination of nostalgia, sunk cost fallacy, pride at having so many supported arches, a reluctance to inconvenience some hypothetical person who's still using DEC Alphas and trying to keep them on the latest kernel, and lack of motivation for someone to remove them (probably due to no one feeling that dead code is in any way a bother).

It keeps the code portable and potentially keeps working computers out of a landfill.

I really, really wanted one of those 64-bit alphas to use for Lightwave 3D in the 90s!

Reply on news.ycombinator.com