Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Why VAX Was the Ultimate CISC and Not RISC
Date: Fri, 7 Mar 2025 15:23:02 +0100
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <vqevg6$3iv5i$1@dont-email.me>
References: <vpufbv$4qc5$1@dont-email.me>
 <2025Mar1.125817@mips.complang.tuwien.ac.at> <vpvrn5$2hq0$1@gal.iecc.com>
 <2025Mar1.232526@mips.complang.tuwien.ac.at> <vq2dfr$2skk$1@gal.iecc.com>
 <2025Mar2.234011@mips.complang.tuwien.ac.at> <5pkg9l-kipt.ln1@msc27.me.uk>
 <2025Mar3.174417@mips.complang.tuwien.ac.at> <vq4qav$1dksd$1@dont-email.me>
 <vq5dm2$1h3mg$5@dont-email.me> <2025Mar4.110420@mips.complang.tuwien.ac.at>
 <vq829a$232tl$6@dont-email.me> <2025Mar5.083636@mips.complang.tuwien.ac.at>
 <vqdljd$29f8f$2@paganini.bofh.team> <20250307135702.00000976@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 07 Mar 2025 15:23:03 +0100 (CET)
Injection-Info: dont-email.me; posting-host="81fbb9cf14c37b98f12a3e0df4167174";
	logging-data="3767474"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+oHWLuN7mvBdYxIiE2E3xZAdkSD2iMo5U14MgXDfN4bw=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101
 Firefox/128.0 SeaMonkey/2.53.20
Cancel-Lock: sha1:xuzO6qqJwvQZKhh4fhgAQ7TDiUs=
In-Reply-To: <20250307135702.00000976@yahoo.com>
Bytes: 4155

Michael S wrote:
> On Fri, 7 Mar 2025 02:27:59 -0000 (UTC)
> antispam@fricas.org (Waldek Hebisch) wrote:
> 
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> By contrast, making good use of the complex instructions of VAX in a
>>> compiler consumed significant resources (e.g., Figure 2 of
>>> https://dl.acm.org/doi/pdf/10.1145/502874.502876 reports about a
>>> factor 1.5 more code in the code generator for VAX than for
>>> RISC-II). Compilers at the time did not use the CISCy features
>>> much, which is one reason why the IBM 801 project and later the
>>> Berkeley RISC and Stanford MIPS proposed replacing them with a
>>> load/store architecture.
>>
>> VAX intstructions are very complex and much of that complexity
>> is hard to use in compilers.  But even extremaly simple compiler
>> can generate load-op combinations decreasing number of instructions.
>> Rather simple hack is enough to combine additions in address
>> artihmetic into addressing mode.  Also, operations with two or three
>> memory addresses are easy to generate from compiler.  I think
>> that chains of pointer dereferences in C should be not hard to
>> convert to indirect addressing mode.
>>
>> I think that state of chip technology was more important.  For
>> example 486 has RISC-like pipeline with load-ops, but load-ops
>> take the same time as two separate instructions.  Similarly,
>> operations on memory take the same time as load-op-store.
>> So there were no execution time gain from combined instructions
>> and clearly some complication compared to load/store
>> architecture.
> 
> In specific case of i486, with its small (8KB) unfied I+D cache,
> you will see good gain from load+Op combining, even if going by cycle
> count in the manual they are the same.
> For Pentium , not necessarily so.

Right:

My Pentium-optimized Word Count program ran nearly twice as fast (in 
cycle counts) on a Pentium as on a 486. The inner loop was inverted to 
maximize the load-use distance and I got close to perfect pairing:

 From memory, similar to

REPT 64
   add ax,dx
   mov dx,increment_table[bx]
   mov bl,[es:di]	;; 64 KB table to classify a pair of chars
   mov di,[si+OFFSET]

   add ax,dx
   mov dx,increment_table[bx+16]
   mov bh,[es:di]
   mov di,[si+OFFSET+2]
ENDM

On the Pentium this was only possible with separate load and operate 
instructions.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"