Skip to content

Comment on The Alpha 21264 CPU: NT's Greatest RISC (1998)parent

Comments

The issue was not that Alpha ISA was impossible to scale down.

The issue was that DEC lacked the resources to run a completely new microarchitecture design to target low-power platforms, and the failure was trying to push an extreme performance chip into low-power envelope instead of designing a new one.

AFAIK with ARM the difference is that they started with low-power underpowered chip and modified it to bring the performance up.

You'd have probably similar issues trying to make a phone using Fujitsu A64FX (the supercomputer ARM) into low-power chip.

This interview with Allen Baum seems to imply that DEC was quite aware of what could easily be done with Alpha, and what could not.

I'm also assuming that ARM code density was better than Alpha (conditional opcodes being a major contributor).

"Well, we were looking at doing a low power Alpha and decided that just couldn’t be done, and then looked at the ARM. We think we can make an ARM which is really low power, really high performance, really tiny, and cheap, and we can do it in a year...

"Well, I worked on the StrongARM 1500, which was a very interesting product. It was an ARM and a DSP kind of highly combined... And then we finished that project and our group in Palo Alto, we were just gonna start an Alpha project."

https://archive.computerhistory.org/resources/access/text/20...

An important thing to consider is that DEC simply didn't have enough CPU design teams, which is also why Alpha essentially had only one-and-half model in the works throughout its history - and the half came from smashing smallest chipset variant into single chip with the CPU for pretty bad performance (too slow memory, mainly). A low-power Alpha CPU would have to be a from scratch design, even if arguably simple to implement ISA-compatible chip.

StrongARM was developed in partnership with ARM, not starting from zero, applying some of the techniques Digital developed with Alpha to ARM - reputedly creating the idea that ARM could be fast at all

DEC also blew a fortune on the ECL VAX.

"Meanwhile, the engineering team's predictions about the relentless march of CMOS proved true. By 1991, the NVAX was also on the market, offering roughly the same performance for a tiny fraction of the cost and size. At lower performance settings the same design was available in desktop form, outperforming all previous VAX machines. The 9000 managed not only to lose billions of dollars, but also led to the ending of several much more promising designs."

https://en.wikipedia.org/wiki/VAX_9000

DEC also lost Dave Cutler's team over PRISM, which was also a deep cut. Deeper than the ECL disaster? Debatable.

DEC had no hope in the ECL money furnace and the loss of the VMS architect.

Arguably the ECL was just digging themselves deeper, the real failure was upper management fighting any suggestion that VAX has played out and should be replaced. EDIT: Then there's the infighting between "big ECL VAX" and everyone else, which was very resource draining.

All the CISC vs RISC literature that brought us the memes about "expensive decode" talked mainly about VAX and m68k as CISC. By comparison, x86 was always closer to RISC designs if only by accident of limited resources of 8086. Even NVAX had, IIRC, ridiculously large microcode - and with orthogonal ISA you had to accept every instruction could balloon info long multi step microcode loop before you even start feeding the ALU.

Making such complex ISA fast was harder than x86 which in 1990s, with NVAX requiring pipelined decoder in Ibox to feed the rest and non trivially depending on possibility of Mbox (memory) requests from I and E boxes to overlap between two instructions to feed the beast.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.