upvote
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 sophisticated but also a lot more complex. The Alpha memory model, in particular, was quite complex with lots of cache control and barrier primitives, IIRC. But it could fly when you got the stars to align.

Edit: Alpha also came out later and PA-RISC also got more complex in later generations.

reply
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.
reply
Yea, there were things like shift and add to do multiplication more efficiently, but they were all one-cycle instructions. It was very regular that way, all designed around a clean pipeline without a stalls or bypassing. But, consequently, it originally didn’t even have integer multiplication or division, just shift and add and a “divide step” that you could repeat/loop. Looking at the instruction set just now, I chuckled at how simple it was. It makes RISC-V look complex.

See: ftp.parisc-linux.org/docs/arch/pa11_acd.pdf

Edit: actually, it did have fixed point multiply via the floating point unit (opcode XMPYU). No fixed point divide, though.

reply
VAX compatibility was very important to DEC- the Alpha has hardware to handle the non-IEEE VAX floating point formats.
reply
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.
reply
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.

reply
Thinking longer about Alpha's imprecise faults made me realize that signaling NaNs can be quite useful in such case
reply
600Mhz Alphas existed when there was 195mhz MIPS
reply
turns out there is more involved in performance than just clock rate

who knew? (everyone)

reply
And the Alpha was faster

The last line of the parent post makes it sound as if the chips didn't exist at the same time.

reply