Re: is Vax addressing sane today

On Fri, 04 Oct 2024 07:05:34 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

George Neuner <gneuner2@comcast.net> writes:

You are, of course, aware that the complex "x86" instruction set is an
illusion and that the hardware essentially has been a load-store RISC
with a complex decoder on the front end since the Pentium Pro landed
in 1995.

>
Repeating nonsense does not make it any truer, and this nonsense has
been repeated since at least the Pentium Pro (1995), maybe already
since the 486 (1989).  CISC and RISC are about the instruction set,
not about the implementation.  And even if you look at the
implementation, it's not true: The P6 has microinstructions that are
~100 bits long, whereas RISCs have 32-bit and 16-bit instructions.
The K7 has load-store microinstructions; RISCs don't have that.

Anton, you know very well that the hardware does not execute the "x86"
instruction set but only /emulates/ it.  The decoder translates x86
instructions into sequences of microinstructions that perform the
equivalent operations.  The fact that some simple instructions
translate one to one does not change this.

In more recent CPUs, AMD tends to work with macro-instructions between
the decoder and the reorder buffer (i.e., in the part that in the
Pentium Pro may have been used as the justification for the RISC
claim); these macro instructions are load-and-op and read-modify-write
instructions.
>
John Mashey has written about the difference between CISC and RISC
repeatedly <https://homepages.cwi.nl/%7Erobertl/mash/RISCvsCISC>, and
he gives good criteria for classifying instruction sets as RISC or
CISC, and by his criteria the 80286 and IA-32 instruction sets of the
Pentium Pro clearly both are CISCs.  I have recently
<2024Jan12.145502@mips.complang.tuwien.ac.at> used his criteria on
instruction sets that Mashey did not classify (mostly because they
were done after his table), and by these criteria AMD64 is clearly a
CISC, while ARM A64 and RISC-V are clearly RISCs.
>
In searching for whether he has written something specific about
IA-32, I found <https://yarchive.net/comp/vax.html>, which is an
earlier instance of the recent discussion of whether it would have
been better for DEC to stick with VAX, do an OoO implementation and
extend the architecture to 64 bits, like Intel has done:
<https://yarchive.net/comp/vax.html>.  He also discusses the problems
of IA-32 there, but mainly in pointing out how much smaller they were
than the VAX ones.
>
I don't agree with all of that, however.  E.g., when discussing a VAX
instruction similar to IA-32's REP MOVS, he considers it to be a big
advantage that the operands of REP MOVS are in registers.  That
appears wrong to me; you either have to keep REP MOVS in decoding (and
thus stop decoding any later instructions) until you know the value of
that register coming out of the OoO engine, making REP MOVS a mostly
serializing instruction.  Or you have a separate OoO logic for REP
MOVS that keeps generating loads and stores inside the OoO engine.  If
you have the latter in the VAX, it does not make much difference if
the operand is on a register or memory.  The possibility of trapping
during REP MOVS (or the VAX variant) complicates things, though: the
first part of the REP MOVS has to be committed, and the registers
written to the architectural state, and then execution has to start
again with the REP MOVS.  Does not seem much harder on the VAX to me,
however.
>
- anton