Re: is Vax adressing sane today

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>