Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Why VAX Was the Ultimate CISC and Not RISC
Date: Sat, 01 Mar 2025 22:25:26 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 66
Message-ID: <2025Mar1.232526@mips.complang.tuwien.ac.at>
References: <vpufbv$4qc5$1@dont-email.me> <2025Mar1.125817@mips.complang.tuwien.ac.at> <vpvrn5$2hq0$1@gal.iecc.com>
Injection-Date: Sun, 02 Mar 2025 00:19:35 +0100 (CET)
Injection-Info: dont-email.me; posting-host="72521dcefe7f14624b39acf0afcbf4c3";
	logging-data="471148"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+CPLereShh0sj6tjEO1q2f"
Cancel-Lock: sha1:O17AuHMDtBJRRSsVr8X7HCludMk=
X-newsreader: xrn 10.11
Bytes: 4334

John Levine <johnl@taugh.com> writes:
>According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>>The answer was no, the VAX could not have been done as a RISC
>>>architecture. RISC wasn’t actually price-performance competitive until
>>>the latter 1980s:
>>>
>>>    RISC didn’t cross over CISC until 1985. This occurred with the
>>>    availability of large SRAMs that could be used for caches.
>>
>>Like other USA-based computer architects, Bell ignores ARM, which
>>outperformed the VAX without using caches and was much easier to
>>design.
>
>That's not a fair comparison. VAX design started in 1975 and shipped in 1978.
>The first ARM design started in 1983 with working silicon in 1985. It was a
>decade later.

The point is that ARM outperformed VAX without using caches.  DRAM
with 800ns cycle time was available in 1971 (the Nova 800 used it).
By 1977, when the VAX 11/780 was released, certainly faster DRAM was
available.

So I think that, for a VAX-11/780-priced machine, they could have had
a pipelined RISC that reads instructions from two 32-bit-wide DRAM
banks alternatingly, resulting in maybe 3-4 32-bits of instructions
delivered per microsecond for straight-line code without loads or
stores.  And in RV32GC many instructions take only 16 bits, so these
3-4 32-bits contain maybe 5-6 instructions.  So that might be 5-6 peak
MIPS, maybe 3 average MIPS, compared to 0.5 VAX MIPS.  Some VAX
instructions have to be replaced with several RISC instructions, so
let's say these 3 RISC MIPS correspond to 2 VAX MIPS.  That would
still be faster than the VAX 11/780, which reportedly had about 0.5
MIPS.

The other thing is that the VAX 11/780 (released 1977) had a 2KB
cache, so Bell's argument that caches were only available around 1985
does not hold water on that end, either.  So my 1977 RISC project
would have used that cache, too, increasing the performance of the
result even more.

Yes, commercial RISCs only happened in 1986 or so, but there is no
technical reason for that, only that commercial architects did not
believe in such things at the time.  It took research projects from
several sources until the concept had enough credibility to be taken
seriously.  That's why I asked for the magic wand for my time-travel
project.

It's interesting that this lack of credibility apparently includes
IBM, whose research lab pioneered the concept.  They produced the IBM
801 with 15MHz clock, probably around the time of the first VAX, but
the IBM 801 had no MMU; not sure what RAM technology they used.

IBM tried to commercialize it in the ROMP in the IBM RT PC; Wikipedia
says: "The architectural work on the ROMP began in late spring of
1977, as a spin-off of IBM Research's 801 RISC processor ... The first
examples became available in 1981, and it was first used commercially
in the IBM RT PC announced in January 1986. ... The delay between the
completion of the ROMP design, and introduction of the RT PC was
caused by overly ambitious software plans for the RT PC and its
operating system (OS)."  And IBM then designed a new RISC, the
RS/6000, which was released in 1990.

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