Re: is Vax adressing sane today

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

John Levine <johnl@taugh.com> writes:

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:

Given modern OoO technology, even VAX can fly.  It does not matter
whether, say,
 
*a++ = *b++ + *c++;
 
is encoded as 1 VAX instruction, or as 4 ARM A64 instructions, or as 7
RISC-V instructions, what goes on inside the OoO engine is pretty
similar in all cases, and so is the performance.

 
It is my impression that unwinding all the side effects if the
reference to "c" causes a page fault was painful.

 
Yes, that was certainly a problem when using the implementation
techniques of the day.  With an OoO implementation, if any of the
operations of the instruction causes an exception, none of the
results of any of the operations are commited.  Problem solved.
 
Or almost: I expect that it's more complex to implement a reorder
buffer that deals with such monster instructions than one that deals
just with RISC-V instructions.
 

Particularly
keeping in mind that b and c could be the same register, and if the
code were this:
 
*a++ = *b++ - *b++
 
the order of increments and fetches matters.

 
Yes, but the decoder produces operations as defined by the
architecture.  I don't know how VAX specifies the order, but a simple
translation could be
 
# at the start, b is in p1, and a is in p6
p0 = *p1   #*b
p2 = p1+4  #b++
p3 = *p2   #*b
p4 = p2+4  #b++
p5 = p2-p4
*p6= p5    #*a = ...
p7 = p6+4  #a++
#at the end, b is in p4 and a is in p7
 
where p0..p7 are physical registers.  If there is an exception in any
of the operations, b stays in p1 and a stays in p6.
 

It is my impression that even when the Vax was designed, it was
already becoming evident that the Vax's super dense super encoded
instruction set was not going to be a long term winner. The IBM 801
project was well along in 1975 when they started designing the Vax.

 
The question is how much was known about the IBM 801 at the time.
According to <https://en.wikipedia.org/wiki/OpenVMS>, the VAX project
started in April 1975.  Data General's Fountainhead project (FHP)
started in July 1975.  Intel started the iAPX 432 in 1975 or 1976,
Zilog started the Z8000 after recruiting Bernard Peuto in March 1976
<https://thechipletter.substack.com/p/captain-zilog-crushed-the-story-of>.
Motorola started the 68000 project in late 1976, and National
Semiconductor obviously knew about the VAX when they designed the
32016 (they originally wanted to implement the VAX instruction set,
but in the end did something incompatible for legal reasons).  All
these projects used CISCy designs rather than RISCy designs.  FHP was
a bit special in making the writable control store an architectural
feature (so it did not have just one instruction set); the thinking
behind it is the "closing the semantic gap" idea that gave us
architectures like the VAX.
 
The first commercial RISCs were delivered in 1986 (including from IBM
itself).  Apparently the industry took that long to absorb the ideas
from the IBM 801 and turn them into a commercial product.
 
It would be interesting to take a time machine to, say, 1976, to go to
any of these companies and try to convince them to do a RISCy CPU.
How hard would it be to convince them?  Would technical arguments be
sufficient, or would one have to wave with money (as a customer or
investor)?  And how would such a CPU do in the marketplace?

The IBM 801 was boring and did not have a patent moat protecting it.

We have talent, we can build something more complex that keeps out
competition that does not have our talent.

They had no idea that complexity doubling every two years was going to
crush all those complex ideas. Instead they thought more transistors would
keep letting them add ever more complex features.

They had no idea that they would crash into the clock speed wall, and if
they did that argues for more complexity in the same clock time to get more
done.

They had no idea that they would be building eight wide designs.
This is the critical idea that made RISC popular. They figured out that
they had been too smart for their own good.

We are post RISC now and adding complexity that gets more work done per
operation, with less tracking. Three sources and two destinations will be
the rule. Load with address update, add with shift, three way add with
logical operations is next. The FPU already has MAC.