Re: Why VAX Was the Ultimate CISC and Not RISC

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.