Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Why VAX Was the Ultimate CISC and Not RISC
Date: Sun, 2 Mar 2025 16:35:35 -0600
Organization: A noiseless patient Spider
Lines: 195
Message-ID: <vq2mg2$vnod$1@dont-email.me>
References: <vpufbv$4qc5$1@dont-email.me>
 <2025Mar1.125817@mips.complang.tuwien.ac.at>
 <dde4cf4961bc821b99d96fc830ad53bd@www.novabbs.org>
 <2025Mar2.103437@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 02 Mar 2025 23:35:46 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a4cd612affcc1148eabb86759e7b6b28";
	logging-data="1040141"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18kzvybNBIISQ1488GbtdbV7OON2Mo8ncw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:FQ2LVjNwsGziZjZrJjU2K6n0g4A=
In-Reply-To: <2025Mar2.103437@mips.complang.tuwien.ac.at>
Content-Language: en-US

On 3/2/2025 3:34 AM, 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.
> 

Quick test...

Running Dhrystone:
   XG2, 90908
     33.6 MIPs
     51.74 VAX MIPS
   RV64G, 68965 ("GCC -O3")
     35.5 MIPs
     39.25 VAX MIPS

Where, the theoretical claim is VAX MIPs is the Dhrystone score divided 
by 1757.

So, in this case, both came out less than 1 DMIPS/MHz, but:
   1.54 VAX MIPs per XG2 op;
   1.11 VAX MIPs per RV64 op.


Comparing ".text" size in this case:
   RV64G:
     .text    145K
     .rodata    9K
   XG2:
     .text     71K
     .rodata    0K

Initially, ".text" was bigger for XG2, but then noted I was static 
linking the whole kernel (it shrank a fair bit after switching to only 
linking the C library).

That and switching back to performance-tuned compiler options (had 
previously set slower options for debugging Quake, which is sharing the 
same Makefile in this case).


The RISC-V build also static-links the same C library (a highly modified 
PDPCLIB).

Note that GCC is set to prune unreachable code.


Not actually sure why there is a 2x size difference, nothing obvious 
stands out in the instruction-use stats (most obvious XG2 exclusive 
features are not seeing all that much use in Dhrystone).

Note that this is the uncompressed size (the LZ compressed binary size 
being 50K in this case).



Note here that RV64GC would reduce ".text" to around 116K but also 
reduces Dhrystone score to around 56K...

But, IMHO, RISC-V has kinda foot-gunned itself with the design of 'C'.
Both a dog-chewed mess and seemingly not particularly effective either 
(though, my CPU core takes a performance penalty in this case, due to 
needing to fall back to scalar operation to deal with 16-bit instructions).




>>> 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?  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)
>   68,000    44   3.5um 68,000 (integer-only, no MMU)
>   45,000    58.52 2um  ROMP (integer-only, no MMU, three pipeline stages)
>   25,000    50    3um  ARM1 (integer-only, no MMU, pipelined)
> 110,000     ?   1.2um SPARC MB86900 (integer-only, pipelined)
> 110,000    80     2um MIPS R2000 (integer-only, pipelined)
> 
> 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.  And the fact that the students of
> Berkeley and Stanford could produce their prototypes in a short time
> lends credibility to the claim.  We also have some timelines we can
> compare:
> 
> <https://en.wikipedia.org/wiki/PA-RISC> says:
> |In early 1982, work on the Precision Architecture began at HP
> |Laboratories, defining the instruction set and virtual memory
> |system. Development of the first TTL implementation started in April
> |1983. With simulation of the processor having completed in 1983, a
> |final processor design was delivered to software developers in July
> |1984. Systems prototyping followed, with "lab prototypes" being
> |produced in 1985 and product prototypes in 1986.[7]
> |
> |The first processors were introduced in products during 1986.
> 
> <https://www.hpmuseum.net/display_item.php?hw=836> writes:
> |The 3000/930 and 3000/950 were both announced in March of 1986 but did
> |not ship until the second half of 1987.
> 
> So here we actually have a discrete implementation of a RISC.
> 
> 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.
> 
> <https://people.computing.clemson.edu/~mark/330/eagle.html#timeline>
> says about the Data General Eclipse MV/8000:
> |spring 1978 - Eagle project starts
> |summer 1978 - recruiting of Hardy Boys and Microkids
> ||April 1979 - projected Eagle completion date (missed)
> |June 1979 - West presents Eagle at Product Board Meeting
> |mid-1979 - Eagle supporter and VP of Engineering Carl Carmen leaves DG
> |October 1979 - Gallifrey Eagle moved to software department
> |November 1979 - Tom West transferred
> |2H79 and early 1980 - difficulties with PAL supplier;
> |                      hardware debugging and software development continue
> |April 1980 - public announcement of MV/8000
> |fall 1980 - Eclipse group reorganized
> 
> It's not clear when the MV/8000 was delivered to the customers.
> 
> The same timeline also contains Data General's Plan A (Eagle was Plan
> B), the more ambitious FHP which makes the writable control store
> available to third-party software, i.e., it's in a way a further step
> in the thinking that led to CISC:
> 
> |July 1975 - FHP project starts
> |September 1977 - EGO vs. FHP meeting; FHP version promised in a year
> |early 1979 - news that FHP will miss deadline "by a huge margin"
> |November 1981 - FHP demo
> 
> BTW, the existence of writable control stores before the release of
> the VAX is further counterevidence to the claim that at the time of
> the VAX, microcode ROM was so much faster and that fast SRAM was not
> an option: The DEC PDP-10 KL10 (1975) has 80*1280bits (12.5KB) or
> 80*2K bits (20KB) of WCS, depending on the model, and they were the
> machines that the VAX-11/780 was going to replace.  So not only did
> RISCs not need cache to perform better than a VAX-11/780, for a
> machine in the price class of the VAX-11/780 you could also have cache
========== REMAINDER OF ARTICLE TRUNCATED ==========