Hacker News Reader

Comment by gsg | Hacker News Reader

DEC deliberately moved away from VAX to work on Alpha, which performed quite well for its time.

John Mashey made some interesting comments on the (lack of) future prospects for the VAX here: http://yarchive.net/comp/vax.html

View on HN

Does anyone know the inside story behind the Titan [1], and what ever became of it? Brian Reid showed me a room full of them when I visited him at DECWRL in Palo Alto by the greasy transformer vault [2], and they seemed vastly majestic and toasty warm. I bet they really kept that rancid grease hot!

[1] https://archive.org/stream/bitsavers_dectechrep_207144/WRL-8...

[2] http://milk.com/wall-o-shame/bucket.html

But reading http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_dens..., Alpha didn't have high code density. Caveat here is that they may have been better at hand-optimizing CPUs they are familiar with or where information is easier to Google. That would favor x86, for instance. Note, however, that they get way smaller code for PDP-11 and VAX than for Alpha.

Due to the way instruction fetch and dispatch worked on the first few generations of the Alpha, you had to put in lots of NOPs to get decent performance.

ctrl+f "FUNDAMENTAL PROBLEM" to find his writeup of the actual difficulties of fast VAX implementations, including ways that x86 is easier than VAX. The big whammy is string ops where the length operand can be indirectly-addressed.

x86 string ops, which are a lot simpler, were slow until pretty recently.

The best thing I remember was PALcode: a nice cross between microcode and assembler. So many uses for that: accelerators, atomic operations, security primitives, and so on. I really wish the x86's had that feature instead of their SMM, etc garbage.

Reply on news.ycombinator.com