Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Brett <ggtgp@yahoo.com>
Newsgroups: comp.arch
Subject: Re: is Vax adressing sane today
Date: Sun, 8 Sep 2024 19:15:25 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 102
Message-ID: <vbkt4d$21dfg$1@dont-email.me>
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>
 <2024Sep8.155511@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 08 Sep 2024 21:15:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="23cf8ea07f275bb0c52cd5f4decee680";
	logging-data="2143728"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+BayfUJBoguym+VOLw+Yvc"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:oSy2mP/lPdS3OHp5JZ+nY7OuAM0=
	sha1:vzi1sT5/QiyiXDPJM9Gze6SSVDU=
Bytes: 5776

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.