Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Michael S 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: <2025Mar2.234011@mips.complang.tuwien.ac.at> <5pkg9l-kipt.ln1@msc27.me.uk> <2025Mar3.174417@mips.complang.tuwien.ac.at> <2025Mar4.110420@mips.complang.tuwien.ac.at> <2025Mar5.083636@mips.complang.tuwien.ac.at> <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.