Re: is Vax adressing sane today

MitchAlsup1 <mitchalsup@aol.com> wrote:

On Thu, 5 Sep 2024 21:03:37 +0000, Brett wrote:
 

 
 
Is Vax addressing sane today?
 
I am not talking indirect addressing, that is stupid.
 
It has been determined from trusted sources that add from memory and add
to memory as used in x86 are sane, and not much of a problem.
 
But Vax allows all three arguments to be in memory with different
pointers.

 
With modern compiler technology 88% of instructions need only 1
constant--thus VAX provides too many, along with providing address
modes that require sequential decoding.
 
Most ISAs do not provide "enough" constants, VAX provides too many.
Where "enough" covers::
 
    SLA    R9,#1,R17        // this is 1 instruction
    DIV    R9,#24,R17       // ibid
    FDIV   R8,#3.14159265358928,R17

In C++ game code there are places where you are loading from two structures
and storing into a third structure. Three offsets are needed and used.

Most commonly you need two offsets as you are building a new structure from
the old one. The example being building the polygon display lists
structures from your source structures which contain X,Y,Z and R,G,B,A and
weights, and other info.

The benchmarks you are using are out of date, using arrays instead of
structures. Arrays are rare in game code, it’s all structures.

Not Fortran arrays, C++ structure spaghetti.

Is this sane, just a natural progression if you allow memory operands?

 
Having watching this in real time:: in 1970 we needed more/better
constants, then PDP-11 came around and we liked it, then at the end
of the decade VAX cam along and we loved it, only later recognizing
that it had fallen for the second system syndrome--becoming overly
complicated without benefit--the address space was definitely needed
the address modes no so much.
 

Packing three offsets in an instruction that can be decoded reasonably
is a whole other problem…

 
Realistically, modern compilers have advanced to the point where
anything more than 1` constant per instruction is overkill--
harder to build and delivering no more performance.
 

Heads and tails encoding could actually do this reasonably, and the code
density would be actually be better than most competitors. Heads and
tails is not that easy, but it’s not x86 difficult.

 
Another encoding scheme is segmenting the OpCode into 2 components
1) goes to the function unit to convey the kind of calculation
  to be performed,
2) goes to the forwarding logic to convey how to route bits into
  calculation.
 
Some might consider the concatenation of both to the be OpCode
but that obscures what to do with when to do it.