Live data from Hacker News

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

halfhill.com

11–20 of 91 posts

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

#12
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…

600Mhz Alphas existed when there was 195mhz MIPS

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

#13
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…

VAX compatibility was very important to DEC- the Alpha has hardware to handle the non-IEEE VAX floating point formats.

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

#14

> David Jessel, the Alpha's senior product manager, claims that Alpha fans have nothing to worry about. "Compaq has been fully supportive of the Alpha and is continuing to invest in it," Jessel said. That worked out swimmingly for Alpha... >sigh I never programmed Alpha assembly, so I don't really have a feel for the architecture. I did deploy some Alpha-based boxes running NT, and they were very nice. They didn't fe…

On the hardware side, DEC built very-well engineered hardware. The early Alpha machines were very well designed. Even the PC compatible lines of the era were built to a very high quality standard.

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

#15

> David Jessel, the Alpha's senior product manager, claims that Alpha fans have nothing to worry about. "Compaq has been fully supportive of the Alpha and is continuing to invest in it," Jessel said. That worked out swimmingly for Alpha... >sigh I never programmed Alpha assembly, so I don't really have a feel for the architecture. I did deploy some Alpha-based boxes running NT, and they were very nice. They didn't fe…

My understanding is that after Compaq sold the Alpha IP to intel, and quite a lot of the DNA ended up in Nehalem and Sandy Bridge.

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

#16
post #8
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…

what did they not implement from 754? Given the design of the processor i can imagine them being very aggressive with assumptions around exception handling / traps - iirc this is actually the original reason why Tomasulo algorithm exists because the first out-of-order processors didn't actually make any guarantees about the order that you would observe these side effects.

Alpha punts handling of denormals, infinities and NaNs to software emulation, but that wasn't particularly unusual: some sparc CPUs and early implementations of Arm VFP floating point did the same.

Looking at the alpha architecture manual, the fp emulation traps are imprecise, which imposes constraints on codegen to make it work right: the "trap shadow" extends from the potentially trapping insn until a following trap barrier, and in the shadow you mustn't e.g. use a register more than once as a destination, have a branch, or modify registers that are inputs to any insns in the shadow. (The idea is that the hardware will have already executed some of the insns in the shadow by the time it realises it needs to trap, and the handler has to be able to emulate the trapping insn and resume execution at the insn just after that, so it will re-execute all the insns in the shadow.) That's obviously pretty inconvenient for codegen, so I wouldn't be surprised if the compiler provided some kind of fast-math mode where it didn't trap and you just had to avoid generating denormals, infinities, etc.

I think making the fp using code have to be written carefully to work with the software emulation of edge cases is unusual -- I don't think either sparc or arm imposed that requirement, and instead trap precisely, or at least before anything happens where it would matter that the fp insn is emulated late.

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

#17
post #11

From back when IA-64 (A.K.A. Itanium) was supposed to take Intel to the promised land.

Without AMD, maybe it would have.

No, it wouldn't have.

Without AMD rescuing x86, PowerPC wouldn't have died. MIPS wouldn't have died, and faces with the need to brake the 4Gn barrier on consumer equipment microsoft would have had windows running on three or four competing architectures until 2013 when everything would have switched to ARM.

Itanium would have already been a rotting corpse.

AMD rescued Intel from its own management.

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

#19
post #15

> David Jessel, the Alpha's senior product manager, claims that Alpha fans have nothing to worry about. "Compaq has been fully supportive of the Alpha and is continuing to invest in it," Jessel said. That worked out swimmingly for Alpha... >sigh I never programmed Alpha assembly, so I don't really have a feel for the architecture. I did deploy some Alpha-based boxes running NT, and they were very nice. They didn't fe…

My understanding is that after Compaq sold the Alpha IP to intel, and quite a lot of the DNA ended up in Nehalem and Sandy Bridge.

Not sure about that bit...

What is well known however, is that a bunch of Alpha engineers wound up at AMD, and a lot of that DNA went into the OG Athlon

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

#20
post #7
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 feel like PA-RISC actually landed with a handful of useful somewhat-complex instructions. It always struck me as the best architecture from that era, making the correct trade-off of avoided microcode but adopted stuff like completers and shift-and-add operations to minimize instruction count and maximize work done per pipeline.
Post reply on HN