Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: is Vax adressing sane today
Date: Sun, 08 Sep 2024 13:55:11 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 83
Message-ID: <2024Sep8.155511@mips.complang.tuwien.ac.at>
References: <vbd6b9$g147$1@dont-email.me> <memo.20240905225550.19028d@jgd.cix.co.uk> <2024Sep6.080535@mips.complang.tuwien.ac.at> <vbiftm$ui9$1@gal.iecc.com>
Injection-Date: Sun, 08 Sep 2024 17:11:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d5e623bbaa085cebf149e53e66f130a5";
	logging-data="2078153"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/EhBzrop2d7zgt82O8VrcT"
Cancel-Lock: sha1:wApmD4nbuUnNsJ6eGzJzn2BIPJM=
X-newsreader: xrn 10.11
Bytes: 4560

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?

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>