Path: ...!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Why VAX Was the Ultimate CISC and Not RISC
Date: Fri, 7 Mar 2025 20:25:44 +0000
Organization: Rocksolid Light
Message-ID: <41edf61c50a92e9d029d69dd61a6fb5f@www.novabbs.org>
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> <vqdrh9$3cdrc$1@dont-email.me> <UfIyP.154326$OrR5.25311@fx18.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3333570"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$ii5URUKU3pfaR.n2cL/9tO..n3Bx7i5CBzRPrnLXXkNUWp3DquQJK
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
Bytes: 4115
Lines: 57

On Fri, 7 Mar 2025 19:59:47 +0000, EricP wrote:

> Lawrence D'Oliveiro wrote:
>> On Fri, 7 Mar 2025 02:27:59 -0000 (UTC), Waldek Hebisch wrote:
>>
>>> VAX intstructions are very complex and much of that complexity is hard
>>> to use in compilers.
>>
>> A lot of them mapped directly to common high-level operations. E.g.
>> MOVC3/
>> MOVC5 for string copying, and of course POLYx for direct evaluation of
>> polynomial functions.
>
> How the VAX Lost Its POLY (and EMOD and ACB_floating too), 2011
> https://simh.trailing-edge.com/docs/vax_poly.pdf
>
>> In a way, one could say that, in many ways, VAX machine language was a
>> higher-level language than Fortran.
>
> And the decimal instructions for COBOL (also on some PDP-11's).
>
> The only reason to add complex instructions like MOVC3, MOVC5 and
> others SKIPC, SPANC, etc is if hardware can do a better job than a
> software subroutine. And you only add those instructions when you
> know you can afford the hardware, not in anticipation that someday
> we might do a better job.
>
> The reason VAX and 8086 benefit from string instructions is because
> they are sequential processors. It allows them to do decode once and
> sit in a tight loop doing execute. But both still move byte-by-byte
> and do not attempt to optimize memory access operations.
> Also the sequencer is sequential so the loop counting and branch testing
> each take microcycles.
>
> So there is some benefit when comparing a VAX MOVc3 to a VAX subroutine,
> but not compared to a pipelined TTL RISC.
>
> If it is a pipelined RISC then decode is overlapped with execute
> so there is no advantage to these complex instructions vs a RISC
> subroutine doing the same in a loop.

You forgot the word "sequentially" in the previous sentence.

>                                      And the RISC subroutine might be
> faster because it can overlap the loop count and branch with memory
> access.
>
> In both cases the real advantage is when you can afford the HW to
> optimize bus accesses as this is where the majority of cycles are spent.
> When you can afford the HW optimizer then you add them.

As to MOVc3; once your cache supports wide access (in support of
64-bit misaligned access) you can get 128-bits read or written
per cycle per port. So, there is very little added to the HW in
order to support doing MOVc3 stuff at 64-bits per cycle:: in cycle
1 we read 128-bits, in cycle 2 we write 128-bits and increment the
iterator. For startup and terminations, the incrementation of the
iterator creates a mask shutting down the lanes byte by byte.