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: Fri, 06 Sep 2024 05:38:01 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 40
Message-ID: <2024Sep6.073801@mips.complang.tuwien.ac.at>
References: <vbd6b9$g147$1@dont-email.me>
Injection-Date: Fri, 06 Sep 2024 08:05:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2e85e44354343afe68fe387c30e9d02d";
	logging-data="760128"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18IM53bx7mF44FVYRxKOZTr"
Cancel-Lock: sha1:ZeYmT0duTNbc4rL8eXfNL8ATOfI=
X-newsreader: xrn 10.11
Bytes: 2803

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.

>Heads and tails encoding could actually do this reasonably, and the code
>density would be actually be better than most competitors.

Would it?  Please present empirical data.  Certainly people claim that
instruction sets with one-memory-address load-and-op and
read-modify-write instructions have better code density, but when you
look at the data, there are load-store instruction sets with better
code density (and by quite a lot).  From
<2024Aug21.184537@mips.complang.tuwien.ac.at>:

   bash     grep      gzip
  595204   107636    46744 armhf    16 regs load/store     32-bit
  599832   101102    46898 riscv64  32 regs load/store     64-bit
  796501   144926    57729 amd64    16 regs ld-op ld-op-st 64-bit
  829776   134784    56868 arm64    32 regs load/store     64-bit
  853892   152068    61124 i386      8 regs ld-op ld-op-st 32-bit
  891128   158544    68500 armel    16 regs load/store     32-bit
  892688   168816    64664 s390x    16 regs ld-op ld-op-st 64-bit
 1020720   170736    71088 mips64el 32 regs load/store     64-bit
 1168104   194900    83332 ppc64el  32 regs load/store     64-bit

What is "heads and tails encoding"?

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