Re: Why VAX Was the Ultimate CISC and Not RISC

On Sun, 2 Mar 2025 9:34:37 +0000, Anton Ertl wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Sat, 1 Mar 2025 11:58:17 +0000, Anton Ertl wrote:

As for code size, we see significantly smaller code for RISC
instruction sets with 16/32-bit encodings such as ARM T32/A32 and
RV64GC than for all CISCs, including AMD64, i386, and S390x
<2024Jan4.101941@mips.complang.tuwien.ac.at>.  I doubt that VAX fares
so much better in this respect that its code is significantly smaller
than for these CPUs.

>
VAX's advantage was it executed fewer instructions (VAX only executed
65% of the number of instructions R2000 executed.)

>
This agrees with my estimate that a CPU with 3 RV32GC MIPS would have
the same performance as a CPU with 2 VAX MIPS.
>

Bottom line: If you sent, e.g., me and the needed documents back in
time to the start of the VAX project, and gave me a magic wand that
would convince the DEC management and workforce

>
You would also have to convince the Computer Science department at
CMU; Where a lot of VAX ideas were dreamed up based on the success
of the PDP-11.

>
Yes, include that in my magic wand.
>

A pipelined machine in 1978 would have had 50% to 100% more circuit
boards than VAX 11/780, making it a lot more expensive.

>
What makes you think that a pipelined single-issue RV32GC would take
more circuit boards than VAX11/780?

a) 68000, 010, 020 were latch based implementations using cross coupled
sense amps as the flop-part of the latch.
b) 88110 was a non-overlapping clock dual latch design.
~2/3rds of 68000 transistor count was in the 2 levels of ROM (it was
both microcoded and nano-coded.)
So, comparing the area of the 88100 integer unit to the 68020 integer
unit, and certain making adjustments, the pipeline integer unit took
a lot more area in the latching of operands and results.
Where 68020 would read an operand, run it though integer calculation
and write it back to the still asserted register select line, with
only staging (delay) latches in the loop. Now, the loop took 2
cycles, but an R2000 it took 4 (Decode, EX, Cache, writeback).
There are a lot more flip-flops in the pipelined path that in the
"use latches to create optimal delay" unpipelined path.

                                    I have no data about discrete
implementations, but if we look at integrated ones and assume that the
number of transistors or the area corresponds to the number of circuit
boards in discrete implementations, the evidence goes in the opposite
direction:
>
Transistors area proc CPU
125,000    74.82 3um  MicroVAX 78032 (integer-only, some instructions
missing)

huge portion of the transistor count was ROM

 68,000    44   3.5um 68,000 (integer-only, no MMU)

2/3rds of the transistor count in ROM
So, here we are only using ~20K transistors for {address, data, pc, and
pins}. Now revisit your comparisons.

 45,000    58.52 2um  ROMP (integer-only, no MMU, three pipeline stages)

Twice the 68K data path transistor count.

 25,000    50    3um  ARM1 (integer-only, no MMU, pipelined)

This gives some credence that is can be done

110,000     ?   1.2um SPARC MB86900 (integer-only, pipelined)
110,000    80     2um MIPS R2000 (integer-only, pipelined)

These two counteract that credence, with 40K of those transistors
found in the windowed register file.

>
It seems that the MMU cost a lot of transistors, while the pipelining
did not, as especially the ARM1 shows.
>

The design point you target for the original VAX would have taken
significantly longer to design, debug, and ship.

>
What makes you think so?  A major selling point of RISC especially
compared to the VAX was that the reduced instruction-set complexity
reduces the implementation effort.

Reduces the effort is you have a RISC ISA, it does not reduce the
effort as much if you have a VAX ISA with al of its decoding "stuff".

                                   And the fact that the students of
Berkeley and Stanford could produce their prototypes in a short time
lends credibility to the claim.

Student projects run in quanta of semesters, often building on the
work of the previous students in the previous semesters,  guided
by professors with an overall direction moving forward. This is not
different than the VAX prototype designs at CMU.
But academic efforts do not result in industrial quality products.
So, the time lines in academia are fundamentally different than in
industry.
<snip>

>
You write that VAX work began in 1973; it was introduced in 1977 (but
when where machines shipped to customers?), which would mean that
development also took 4 years.  According to
<https://en.wikipedia.org/wiki/VAX-11>, development began in 1976, but
that is hard to believe, especially given the CISC-based problems such
as having to keep many pages in physical memory at the same time.

I remember walking by the 12 person conference room in the CS
part of CMU in 1973 and listening to the participants discuss
making a bigger-better PDP-11. The topics was quite advanced
at that moment, but I can vouch for the '73 date. I had been
using PDP-11 ISA for 6-months at that point and was significantly
impressed with it, more so that PDP-10, or IBM 360/67.
Another time I was walking by they were talking about how to
adjust BLISS so that it ran well on the "Bigger and better PDP-11".
Grayson, Bell, and Newell were at both meeting along with a host
of students.
<snip>

>
- anton