Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Why VAX Was the Ultimate CISC and Not RISC
Date: Wed, 12 Mar 2025 11:48:28 +0200
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <20250312114828.00003e99@yahoo.com>
References: <vpufbv$4qc5$1@dont-email.me>
	<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>
	<vqqcm0$3l3i5$1@paganini.bofh.team>
	<2025Mar12.094228@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 12 Mar 2025 10:48:29 +0100 (CET)
Injection-Info: dont-email.me; posting-host="4ef870278692d6db7d7d5b2c405359df";
	logging-data="2657848"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/aqTyJpeNak52/2RU8us7cCwgAGQY6Vfw="
Cancel-Lock: sha1:iMR6joRMW45Hcnvx26RaUaTGFKw=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3626

On Wed, 12 Mar 2025 08:42:28 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> antispam@fricas.org (Waldek Hebisch) writes:
> >Of course, it is possible that VAX designers understood
> >performace implications of their decisons (or rather
> >meager speed gain from complex instructions), but bet
> >that "nice" instruction set will tie programs to their
> >platform.  
> 
> I don't think that they fully understood the performance implications,
> but I believe that creating an appealing environment for software
> developers was a major consideration of the architects: For the
> assembly-language programmers, provide orthogonality; that also makes
> it easy to write compilers (optimility in some form is a different
> story).  The much-critized VAX CALL instruction is designed for a
> software ecosystem where various languages can call each other, there
> exists a common debugger for all of them, etc.  I am sure that they
> were aware that this call instruction was expensive, but they expected
> that it was worth the cost, and also expected that implementors would
> reduce the cost to below what a sequence of simpler instructions would
> cost (looking at REP MOVSB in many generations of Intel and AMD CPUs,
> we see such expectations disappointed; I have not measured recent
> generations, though).
> 
> - anton

It depends on what your call "a sequence of simpler instructions". 
For R/E/CX above, say, dozen 'rep movsb' is faster than a simple
non-unrolled loop of single-byte loads and stores on pretty much any
Intel or AMD CPU since a down of time. If we are talking about this
century, then, at least for Intel, I think that we can claim that the
same is true even relatively to simple loop of 32-bit loads and stores.
If we replace a dozen with hundred or three then it will become true
for loop of 64-bit loads/stores as well.

Or, may be, in your book 5KB of elaborate code that contains unrolled
and non-unrolled loops of YMM, XMM, Rxx, Exx, and byte memory accesses
still considered 'a sequence of simpler instructions' ?
If it is a case then I am not going to argue.