Actually, John Mashey said he'll write about the technical aspects in Part III on RealWorldTech, but Part III was never completed.
> In Part III, I’ll sketch some of the tough issues for implementing the VAX, as best I can. In particular, I will note the ISA features that might make things harder for VAX than for x86, to do 2 or 4-issue superscalar, or a full blown out-of-order design. In particular, what this means is that you can implement a type of microarchitecture, but it gains you more or less performance dependent on the ISA and the rest of the microarchitecture. For instance, the NVAX design at one point was going to decode 2 specifiers per cycle, but it was found to add too much complexity and only get a 2% performance increase.
---
Interestingly, the relatively elegant and orthogonal CISC design of VAX makes the implementation of an out-of-order & pipelined CPU more difficult than x86, an unorthogonal CISC. There were real technical problems. Not to say they can't be overcame, but the combination of both the technical and economic factors made a competitive VAX CPU unfeasible.
Here are some highlights, please read the original link for the complete thread.
---
> Well, a few years later Dileep Bhandarkar, then employed at Intel, wrote a paper where he claimed (IIRC) that the performance advantage of RISCs had gone (which I did not take very seriously at the time); unfortunately I don't know which of his papers that is; I just looked at "RISC versus CISC: a tale of two chips" and it looks more balanced than what I remember.
That was another fine paper from Dileep, but the conclusion: X86 can be made competitive with RISC is not the same as: VAX can be made competitive with RISC
> >BOTTOM LINE:
> >
> >DEC had every motivation in the world to keep extending the VAX as long as possible, as it was a huge cash cow. DEC had plenty of money, numerous excellent designers, long experience in implementing VAXen. BUT IT STOPPED BEING POSSIBLE TO DESIGN COMPETTIVE VAXen...
> Looking at what Intel and AMD did with the 386 architecture, I am convinced that it is technically possible to design competetive VAXen; I don't see any additional challenges that the VAX poses over the 386 that cannot be addressed with known techniques; out-of-order execution of micro-instructions with in-order commit seems to solve most of the problems that the VAX poses, and the decoding could be addressed either with pre-decode bits (as used in various 386 implementations), or with a trace cache as in the Pentium 4.
You're entitled to your opinion, which was shared by the VAX9000 implementors.
Many important senior VAX implementors disagreed. I've posted some of the reasons why VAX was harder than X86, years ago. Of course you can do these things, but different ISAs get different mileage from the same techniques.
> Of course, on the political level it stopped being possible to design competetive VAXen, because DEC had decided to switch to Alpha, and thus would not finance such an effort, and of course nobody else would, either.
Ken Olsen loved the VAX and would have kept it forever. Key salespeople told him it was getting uncompetitive, and engineers told him they couldn't fix that problem, and they'd better start doing something else.
FUNDAMENTAL PROBLEM Certain VAX ISA features complexify high-performance parallel implementations, compared to high-performance RISCs, but also to IA-32.
The key issue is highlighted by Hennessy & Patterson [1, E-21]]: "The VAX is so tied to microcode we predict it will be impossible to build the full VAX instruction set without microcode."
Unsaid, presumably because it was taken for granted is:
For any higher-performance, more parallel micro-architecture, designers try to reduce the need for microcode (ideally to zero!). Some kinds of microcoded instructions make it very difficult to decouple:
A) Instruction fetch, decode, and branching
B) Memory accesses
C) Integer, FP, and other operations that act on registers
Instead, they tend to make A&B, or A&C, or A,B&C have to run more in lockstep.
It is hard to achieve much Instruction Level Parallelism (ILP) in a simple microcoded implementation, so in fact, implementations have evolved to do more prefetch, sometimes predecode, branch prediction, in-order superscalar issue with multiple function units, decoupled memory accesses, etc, etc. ISAs often had simple microcoded implementations [360/30, VAX-11/780, Intel 8086] and then evolved to allow more pipelining. Current OOO CPUs go all-out to decouple A), B), and C), to improve ILP actually achieved, at the expense of complex designs, die space, and power usage.
Some ISAs are more suitable for aggressive implementations, and some make it harder. The canonical early comparison was the CDC 6600 versus the IBM 360/91; the even stronger later one would be Alpha versus VAX. A widespread current belief is that the complexity, die cost, and propensity for long wires of high-end OOOs may have reached diminishing returns, compared to multi-core designs with simpler cores, where the high-speed signals can be kept in compact blocks on-chip.
IA-32 has baroque, inelegant instruction encoding, but once decoded, most frequently-used instructions can be converted to a small number (typically 1-4) micro-ops that are RISC-like in their semantic complexity, and certainly don't need typical microcode. As noted earlier in this sequence, the IA-32 volumes can pay for heroic design efforts.
The VAX ISA is orthogonal, general, elegant, and easier to understand, but the generality, but it also has difficult decoding when trying to do several operands in parallel. Worse, numerous cases are possible that tend to lockstep together 2 or 3 of A), B), or C), lowering ILP, or requiring hardware designs that tend to slow clock rate or create difficult chip layouts. Even worse, a few of the cases are even common in some or many workloads, not just potential.
As one VAX implementor wrote me: "it doesn't take much of a percentage of micro-coded instructions to kill the benefits of the micro-ops."
That is a crucial observation, but of course, the people who really know the numbers tend to be the implementers...
It is interesting to note that the same things that made VAX pipelining hard, and inhibited the use of a 2-issue superscalar, also make OOO hard. Some problems are easier to solve, but others just move around and manifest themselves in different ways. - decode complexity - indirect addressing - multiple side-effects - some very complex instructions - subroutine call mechanism
Following is a more detailed analysis, showing REFERENCES first (easier to read on Web), briefly describing OOO, and then going through a sample of troublesome VAX features, and comparing them to IA-32, and sometimes S/360. CONCLUSION that wraps all this together with DEC's CMOS roadmap in the early 1990s to show the difficulty of keeping the VAX competitive.