Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Sat, 05 Oct 2024 00:13:24 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <ite1gj5ns460ual9bk35vvo20fl047ar25@4ax.com>
References: <vdg3d1$2kdqr$1@dont-email.me> <memo.20241001101211.19028o@jgd.cix.co.uk> <20241001123426.000066c1@yahoo.com> <2024Oct1.182625@mips.complang.tuwien.ac.at> <vdknel$3e4pf$9@dont-email.me> <2024Oct3.085754@mips.complang.tuwien.ac.at> <vdne1a$3uaeh$4@dont-email.me> <m1rufjhpi09m9adedt87nrcdfmij1i8pvb@4ax.com> <2024Oct4.090534@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: i2pn2.org;
	logging-data="626498"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="h5eMH71iFfocGZucc+SnA0y5I+72/ecoTCcIjMd3Uww";
User-Agent: ForteAgent/8.00.32.1272
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4657
Lines: 65

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