The Alpha 21264 CPU: NT's Greatest RISC (1998) • Hacker News Board

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#81

Post by pjmlp » Mon, Aug 10, 2026, 7:39 AM UTC

shdwslrkr wrote: post #44

pjmlp wrote: post #34

Earlier quoted context omitted.

Sure it would, Windows XP 64 bits was alreary on Itanium, and NT versions for PowerPC and MIPS were already dead by then.

First thank you for generously understanding my post despite the vandalism that autocorrect did to it. WindowsNT is remarkably well suited to porting to other arch. This was done on purpose to hedge against x86. Dead one day, reactivated the other. MS needed to brake the 4Gb barrier and they would have done anything to get consumer priced 64bit chips. Itanium was a dog. We had an Itanium SGI "supercomputer". Everythi…

Itanium wasn't set in stone, a few times CPUs were redesigned to fix architecture issues, naturally for WinIntel that became economic unfeasible the moment AMD64 became an alternative.

Without it, Intel would most likely kept iterating and improving Itanium's architecture.

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#82

Post by [deleted] » Mon, Aug 10, 2026, 9:03 AM UTC

somat wrote: post #53

rhelz wrote: post #41

Earlier quoted context omitted.

Most of the barriers for Alpha adoption were problems inherent in the 32-bit to 64-bit transition. Alignment problems, yes, but another killer problem was that 64-bit pointers were twice as large. The software I was writing at the time (EDA) took almost exactly twice as much memory. So if we needed more than 4GB, we could go to a 64-bit machine, but unless you bought even more than 8GB, you couldn't really run on big…

AMD only pressured Intel into adapting the 64-bit extensions to the x86 architecture, The Intel native 64-bit system was the Itanium. Which they were hoping would break x86 and it's messy open legacy that allowed AMD to profit off it. A question on terminology, I come from bsd world so prefer i386, amd64, ia64(the itanium) whereas the linux side appears to prefer x86 x86-64 Nothing wrong with it(it describes the arch…

[deleted]

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#83

Post by p_l » Mon, Aug 10, 2026, 10:05 AM UTC

chasil wrote: post #75

p_l wrote: post #69

Earlier quoted context omitted.

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 i…

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…

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.

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#84

Post by p_l » Mon, Aug 10, 2026, 10:08 AM UTC

ggm wrote: post #78

My memory is that the Alpha and OSF/1 hit at the same time. OSF/1 had a different model of shared library stuff, and I recall it being something which sometimes demanded a reboot to get a runtime cache rebuilt/linked so things worked as you expected. I may be mis-remembering, I think DEC had coded some pull up smarts to optimise the lib -> indirect -> actual call path into the shortest path possible. I also recall th…

Unaligned access was common issue on many RISCs, which depending on specific Unix variant and runtime settings might mean regularly getting SIGBUS for code ported from other architectures.

Without BWX instructions from EV56 (21164A) you also could not make memory access smaller than 32bits

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#85

Post by [deleted] » Mon, Aug 10, 2026, 10:12 AM UTC

hedgehog wrote: post #49

pjmlp wrote: post #34

Earlier quoted context omitted.

Sure it would, Windows XP 64 bits was alreary on Itanium, and NT versions for PowerPC and MIPS were already dead by then.

It's unclear to me what would have likely happened had AMD stayed on IA32 and Netburst been uncontested. Itanium was far too expensive for consumer machines and it seems very possible that Intel would have fumbled IA64 in a way similar to more recent AVX-512 and their big.little efforts. Easy enough to port XP to Itanium, hard to get those machines into Best Buy or the Dell catalog in any way that makes sense. Had AM…

[deleted]

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#86

Post by panick21_ » Mon, Aug 10, 2026, 11:51 AM UTC

drob518 wrote: post #7

jleyank wrote: post #5

I seem to remember that Alpha’s were very fast for the time but their maximum optimization level waived IEEE floating point conformance. This, of course, drove us nuts trying to validate ports of numerically intensive code. Less interesting chips with lower optimization and limited market penetration. Now, HP’s PA-RISC chips…. Those things were fast and easier to work with. Curiously, with SoftPC they could do window…

I worked on the first PA-RISC workstations (“snakes”, 1989-1991). PA-RISC started as a fairly pure RISC design and was consequently very simple and predictable (short pipeline, 1 delay slot, no complex instructions). The philosophy of the design team was to make the system fast with high clock speeds, short pipelines, and big caches, all big fundamental variables in the performance equation. Alpha was much more sophi…

I really liked the PA-RISC design sad they didn't try to compete and became Intel Partner.

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#87

Post by panick21_ » Mon, Aug 10, 2026, 11:59 AM UTC

loph wrote: post #59

It's important in the historical context of the Alpha AXP to also remember the DEC PRISM architecture. Canceled in 1988. One of many architectures killed off by DEC. https://en.wikipedia.org/wiki/DEC_PRISM Killing Prism sent David Cutler into the arms of Microsoft. Another dead architecture was Jupiter: https://en.wikipedia.org/wiki/Jupiter_project Killing Jupiter sent many of DEC's DECsystem-10 customers to IBM. Yea…

Jupiter was just a PDP-10, I don't think killing Jupiter was bad. The VAX was insanely successful and adopted by a large amount of people. And Jupiter was a very expensive project and it basically failed to do what it wanted to do and was already late. They stopped with PDP-10 because nobody seemed to be able to make a next generation architecture work.

Arguably, all ECL projects should have been killed, even Venus.

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#88

Post by thequux » Mon, Aug 10, 2026, 12:02 PM UTC

pjmlp wrote: post #80

hedgehog wrote: post #49

Earlier quoted context omitted.

It's unclear to me what would have likely happened had AMD stayed on IA32 and Netburst been uncontested. Itanium was far too expensive for consumer machines and it seems very possible that Intel would have fumbled IA64 in a way similar to more recent AVX-512 and their big.little efforts. Easy enough to port XP to Itanium, hard to get those machines into Best Buy or the Dell catalog in any way that makes sense. Had AM…

It is all what ifs by now, however I firmly believe if there was no other option other than Wintel, Intel would keep pushing Itanium and sort out the design issues. The thing with AMD64 is that now there is this myth that there was no other alternative than keeping up with x86, and Itanium redesigns for some magical reason were impossible. Other than those redesigns never happened, because AMD64 made economic invalid…

Itanium has well over a kilobyte of general-purpose registers. That's lovely for single-process performance, but it absolutely slaughtered context switch time given the available memory bandwidth at the time. On top of that, it was fiendishly difficult to actually find instructions that could fill the instruction stream, and thus i-cache utilization was a disaster. On top of all of that, it exposed far too much microarchitecture to userspace: it would forever be pinned to having three execution ports with very specific capabilities, and any changes to the µarch would have resulted in all of the complicated register rename and instruction scheduling hardware that VLIW was supposed to avoid.

I'll grant that it seemed like a decent idea at the time, but there was enough risk there that I can only describe Intel's all-in stance on Itanium to have been a blunder.

(There's a worthwhile distinction to be made between a blunder and a mistake. Mistakes are calculated risks that don't pan out, whereas a blunders is something that should have been obvious that it would go poorly when the decision was made. Losing your savings in the stock market from a surprise dip is a mistake. Losing your savings by betting it all on 14 in Vegas is a blunder. Similarly, the design of Itanium was a mistake. Betting the company on it was a blunder.)

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#89

Post by drob518 » Mon, Aug 10, 2026, 3:39 PM UTC

panick21_ wrote: post #86

drob518 wrote: post #7

Earlier quoted context omitted.

I worked on the first PA-RISC workstations (“snakes”, 1989-1991). PA-RISC started as a fairly pure RISC design and was consequently very simple and predictable (short pipeline, 1 delay slot, no complex instructions). The philosophy of the design team was to make the system fast with high clock speeds, short pipelines, and big caches, all big fundamental variables in the performance equation. Alpha was much more sophi…

I really liked the PA-RISC design sad they didn't try to compete and became Intel Partner.

The HP silicon team that I worked with went on to develop Itanium silicon (they were not responsible for the architecture, just the implementation).

Re: The Alpha 21264 CPU: NT's Greatest RISC (1998)

#90

Post by hedgehog » Mon, Aug 10, 2026, 5:26 PM UTC

thequux wrote: post #88

pjmlp wrote: post #80

Earlier quoted context omitted.

It is all what ifs by now, however I firmly believe if there was no other option other than Wintel, Intel would keep pushing Itanium and sort out the design issues. The thing with AMD64 is that now there is this myth that there was no other alternative than keeping up with x86, and Itanium redesigns for some magical reason were impossible. Other than those redesigns never happened, because AMD64 made economic invalid…

Itanium has well over a kilobyte of general-purpose registers. That's lovely for single-process performance, but it absolutely slaughtered context switch time given the available memory bandwidth at the time. On top of that, it was fiendishly difficult to actually find instructions that could fill the instruction stream, and thus i-cache utilization was a disaster. On top of all of that, it exposed far too much micro…

As pjmlp points out we don't know what would have happened if Intel had spent another few billion dollars re-implementing IA64 in a lower cost / lower power form. To me one of the big lessons of the last few decades is that pragmatic microarch has convergent evolution due to the same underlying constraints of expensive memory access, clock speed scaling limits, general non-determinism of everything surrounding the core, etc, and within reason the ISA will end up conformed to those limits in a way that makes the initial ideology (RISC, CISC, VLIW) not so important. For example RISC is simple, except once you mix OoO, compressed instructions, macro op fusion, etc, those all have externally visible effects so c'est la vie simplicity.

One can imagine an evolution of IA64 that conceded microarchitectural complexity to allow adoption of a more compact instruction format with dependency tags rather than fixed bundle width, resulting in something more like an evolution of P6 with a different face, better x86 compatibility, and still ISA uniformity with the big iron. Or an evolution that involved buying Transmeta and adding IA64 support to that.

Obviously Intel didn't end up doing any of these things, probably because distribution strength and process superiority allowed them to do less and still post strong quarterly numbers. I'm not even sure if it was a blunder given the local incentives of the people who worked there at the time.