Re: is Vax adressing sane today

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

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.