Hacker News Reader

Comment by johndoe0815 | Hacker News Reader

The world would be much nicer if we still had new Alpha CPUs. It was intended to be a CPU architecture that lasts 25 years and Digital intended the architecture to support a 1000x increase in performance during that time.

Now we have RISC-V reinventing the wheel. Not the worst outcome, but we could have had it so much better...

View on HN

DEC designed StrongARM pretty much immediately after Alpha shipped because Alpha chips ran hot as frick and DEC engineers didn’t see a path to low-power Alpha.

Do you know a good paper on the development of StrongARM?

I don't know if they're "good".

StrongArm Punches Up ARM Performance by Jim Turley:

https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/091504....

StrongARM: A High-Performance ARM Processor by Rich Witek and JamesMontanaro

http://gec.di.uminho.pt/MInf/ac0203/ICCA03/strongARM.pdf

Much as some aspects of the Alpha were great its weak memory model would have resulted in even more concurrency issues than we have now, and way more explicit fences.

It couldn't even handle unaligned access in it’s original form. Surely an architecture to last for 25 years.

Not handling unaligned access gracefully is a classic RISC "feature", as part of the general simplification of a processor to its basics. I'm not sure if it's really an Alpha specific thing. Plus they added some instructions to ease the pain in 1996.

The main issue people tend to bring up with Alpha is the very loose memory model, of the "things happen, but different processors may not really agree on the order they happened in" type of thing (plus, isn't it rude to want to know what other cores have in their cache?). Which would be a pain in our modern multicore world.

Of course we don't know how things would've evolved over time, ARM (at least on big cores[1]) shifted towards the forgiving model for unaligned access, it's possible over time Alpha would've similarly moved to a more forgiving environment for low level programmers.

[1] On embedded stuff, you're going to the Hardfault handler.

Alpha had a super loosy-goosy memory model because iirc the cache size they wanted couldn’t be built with the performance they needed on the process they had, so they made it from two wholly independent cache banks, both serving the same core through a shared queue.

BWX does not help with unaligned accesses, but solves the fact that original Alpha did not even have instructions for memory accesses smaller than word. Which kind of becomes an issue when you start building the systems on PC-like hardware (another related “feature” is that EV5 does not have equivalent to MTRRs, but dealing with the weirdness of VGA framebuffer accesses is part of the architecture specification by means of hardcoded uncached memory region).

TBH, I'm not an expert on Alpha, and wow, as an embedded programmer by trade, that's really wacky way of handling memory access. I guess it made more sense in the minicomputer world where you control the whole stack, but as a more general purpose architecture its well, not the greatest is it.

There is a lot of good things to be said about Alpha and it is probably the most RISC of all 90's RISC ISAs, but the actual hardware is full of weirdness and all the real CPUs were deeply pipelined OoO designs (think Intel NetBurst) that prioritized high clock rates and huge straight-line throughput above all else (which is also why that ran really hot and could not be really scaled down for embedded use). Taking good ideas from that while discarding the “speed-demon” design is a part of why AMD become relevant again in 00's with amd64 cementing that position (but well, AMD K7 is very much Alpha-related design, to the extent that the chipsets are interchangeable between K7 and EV6. The interesting part of that is that these CPUs do not have FSB in the “bus” sense, but there is a point-to-point link between CPU and chipset).

AMD using an Alpha bus for early Athlons feels like a weird lost opportunity. Cheap x86 aimed motherboards that can run also run Alpha chips with Windows 2000 + FX!32 for compatibility, it might’ve had a chance to shine, albeit a slight chance. Sadly by then Compaq had already boarded the Itanic…

If your code contains unaligned access, you’re doing something wrong in the first place.

Reply on news.ycombinator.com