Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: is Vax adressing sane today
Date: Sat, 07 Sep 2024 05:17:18 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 54
Message-ID: <2024Sep7.071718@mips.complang.tuwien.ac.at>
References: <vbd6b9$g147$1@dont-email.me> <2024Sep6.073801@mips.complang.tuwien.ac.at> <vbfh2l$toif$1@dont-email.me>
Injection-Date: Sat, 07 Sep 2024 07:37:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e4c6793cf2ee4fe2677c2684f18157c3";
	logging-data="1277551"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/GrJRTKs+nR4PEg+7AH0up"
Cancel-Lock: sha1:eWuUozKOQ1dq+fA/WjC4PaObMZU=
X-newsreader: xrn 10.11
Bytes: 3556

Brett <ggtgp@yahoo.com> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Brett <ggtgp@yahoo.com> writes:
>>> But Vax allows all three arguments to be in memory with different pointers.
>>> 
>>> Is this sane, just a natural progression if you allow memory operands?
>> 
>> In combination with supporting unaligned accesses (but excluding
>> indirect addressing), it means that an instruction can access 6 pages,
>> and so the TLB (and/or TLB loader) has to be designed to support that.
>> Likewise, the OS has to be designed to load all 6 pages into physical
>> RAM without evicting one of these pages again.  So this kind of
>> architecture increases the design complexity.  And I don't see a
>> benefit from this design.
>
>The memory system is pipelined, once you load the first of the three
>values, you do not care if that cache line is evicted while you load the
>second.
>
>Caches are 16 way today, one does not worry about cache line evictions, it
>just works.

I did not write about caches, but yes, for TLBs a (the?) solution is
to have the ITLB to be at least 6-way.

It's unclear how pipelining should help.  The VAX 11/780 was not much
pipelined and can also do the memory accesses one after the other;
this did not protect it from the complexity coming from x memory
accesses in a single instruction.  E.g., all the pages accessed by an
instruction have to be in physical memory, or maybe support
interruptable instructions; in any case, there is complexity.

>>> Heads and tails encoding could actually do this reasonably, and the code
>>> density would be actually be better than most competitors.
....
>> What is "heads and tails encoding"?
>
>128 bit or larger packets with the fixed size opcodes on the front, and the
>variable sized data and offsets packing in from the end. You get variable
>length instruction density with easier faster wide decoding. And also using
>memory operands give you another density bonus on top.

The only reason for VAX-style instructions is if you want to implement
the VAX instruction set, because you want to run software for the VAX
(and that reason started to vanish three decades ago and is now almost
gone).  Also, decoding variable-length instructions is a solved
problem: Intel's P-cores and AMD's Zen-Zen5 cores solve it with
microcode caches, and Intel's recent E-cores (Tremont, Gracemont,
Chrestmont, Skymont) solve it by having 2-3 3-wide decoders.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>