Re: is Vax adressing sane today

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.

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"?

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 down side is that it makes your one and two wide implementations
bigger.

- anton