Re: is Vax adressing sane today

On Fri, 6 Sep 2024 6:05:35 +0000, Anton Ertl wrote:

jgd@cix.co.uk (John Dallman) writes:

Memory-to-memory instructions, in general, are hard to get to run fast
with today's processors and memory, simply because memory access times
are long enough for many register-to-register instructions to execute.

>
Given modern OoO technology, even VAX can fly.  It does not matter
whether, say,
>
*a++ = *b++ + *c++;
>
is encoded as 1 VAX instruction, or as 4 ARM A64 instructions, or as 7
RISC-V instructions, what goes on inside the OoO engine is pretty
similar in all cases, and so is the performance.
>
In recent years a number of implementations have 0-cycle store-to-load
forwarding, so the misconception that a memory operand is as cheap as
a register operand if only the instruction set has memory operands of
operate instructions is a little bit closer to reality.  It is still a
misconception, because such an implementation can read and write
several times as many registers per cycle as memory operands.
>

A
lot of that time can be hidden with good caches and prefetchers, but if
your memory access patterns are complicated, those speedups can fail to
work.

>
Whether operate instructions in an instruction set have 0, 1, or 3
memory operands makes little difference in that case.
>

One reason for memory-to-memory instructions was to avoid the need to
dedicate registers to operands, but that's not much of a problem these
days, since we have space in the CPU for lots of registers and rename
systems for them.

>
That may have been a consideration in the NOVA or the 6800, but in
case of the VAX with its 16 registers, that corresponds to a
load/store-architecture with 18 registers, so for the VAX this is just
a minor issue.
>
Some time ago I thought a bit about which kind of architecture to
design with the transistor budget of the 6502, but with the RISC
lessons under the belt.  One problem with a big RISC-like register set
is the instruction bandwidth.  You really want to stick to 8-bit
instructions if you only have an 8-bit data bus.  With a register
architecture that means 2-bits for register operands, and that means
you would need a lot of loads and stores in a load/store architecture.
So the narrow instruction word almost forces you to use implicit
register operands or at small special-purpose register sets (e.g., 2
accumulators and 4 index registers, as in the 6809) rather than
general-purpose registers.
>
However, the VAX 11/780 does not have these restrictions.  It has a
wider memory bus and it has a cache.
>

DEC spent a lot of time and money trying to keep VAX competitive and took
too long to accept that was impractical. That was one of the seeds of
their downfall.

>
Either that, or they failed to stick to VAX for the few more years
until they would have developed an OoO implementation, which would
have leveled the playing field again (see Pentium Pro).  The Alpha
came out in 1992, the Pentium Pro in 1995, so if DEC has stuck to the
VAX and managed a timely OoO implementation, they would have needed to
survive just 3 years.  And it seems that they lost a lot of customers
in the transition from VAX to Alpha.
>
Of course, the question is if the customers would have stayed with DEC
if they had continued with the VAX.  The vibe at the time was that
CISCs are doomed.  OTOH, Intel stuck with IA-32 and won with the P6,
and IBM stuck with the S390.  But VAX customers are not S390
customers, and maybe they would have defected to Intel even if the VAX
had been there.

In my opinion, DEC was caught at an ugly time for them. They did not
have the transistor budget for a GBOoO implementation at exactly the
time they also needed a clean transition to 64-bits (even more trans-
istors). DEC did have the transistors for a medium OoO implementation
but unlikely the 64-bit transition.

From what I read, the VAX 9000 was a big nail in the DEC coffin.  In
hindsight they should have canceled the project early, but that does
not mean that they could not have continued with VAX (they could even
have competed with the IBM mainframes, which took quite long to gain
superscalar and OoO implementations).
>
- anton