Re: New Vax - future directions :-)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> So, some thought about expanding the Vax architecture.

Likewise.  The below are intended to provoke thought.  They're not even
all consistent with one another.

> 64-bit:
> For userspace; the vax architecture itself leave the door open for
> expanding the word size.    The instructions are all defined to use
> only the part of a register it needs, so adding a bunch of 'Q'
> instructions are a no-brainer.

Yes...but do you still have only 16 GPRs?  Legacy instructions
obviously have to, for compatability, unless you have a global mode bit
(which personally I would prefer to avoid).  I can't help wondering if
preserving legacy compatability isn't the higher price and it mightn't
be better to redesign the instruction set with 5 or maybe even 6 bits,
instead of 4, for register number.  I find this pushing me towards
16-bit instruction stream units...and that makes me wonder to what
extent it would be fair to call the result a VAX.  But see below.

> Argument reference will work as before.

Naturally.

> The JMP/JSR/RET/... might need a Q counterpart, since it suddenly
> store/require 8 bytes instead of 4.

And that's another issue with preserving legacy compatability.

> Kernel; the hardware structures (SCB, PCB, ...) must all be expanded.
> Memory management changed (but the existing leave much to wish for
> anyway).  All this is probably a quite simple update to the
> architecture.

All true...but it leaves me asking how much you can change and still
preserve the elegance that makes a VAX feel like a VAX.

Possible thought: make addresses bit addresses, rather than a octet
addresses.  The VAX is not only the CISC end of the CISC/RISC spectrum;
it is also the "alignment doesn't matter" end of the alignment
spectrum.  Push that all the way to not requiring even octet alignment,
making the addressing unit the bit instead of the octet, and that opens
the door to things like nine- or ten-bit addressing mode specifiers
without too much disruption, thus permitting 32 or 64 GPRs.  With 32
new address bits, I'd say we can afford to burn three of them.

Of course, this means giving up historical VAX binary compataibility,
unless you go with a mode bit.

> IEEE floating point:

Not sure what I think here.

Considered abstractly, I prefer IEEE floats to VAX floats; the IEEE
scheme fixes a number of issues with the VAX scheme.

But I also do not like monocultures, and IEEE floats are one.

> The F, G and H matches in layout the IEEE Single, Double and Extended
> but the exponent bias is slightly different and subnormal values are
> missing.

So are (quiet) NaNs and infinities.  (Reserved operands are,
approximately, _signaling_ NaNs; VAX FP has nothing like quiet NaNs.)

> Multiprocessor: [...]

I'd say, be careful to not design MP out, but "first make it work, then
make it better".

> Convenience:

> Even though there are 288 instructions, a few are missing that would
> be nice.  For example;

> - Unsigned mul/div.  Vax only have signed.

True.  This matters slightly less if you go 64-bit, but I _would_ like
to see EMULU and EDIVU - and I'd like to see an EDIV/EDIVU variant that
returns the full quotient instead of just the low half.

> - logical shift right.  Vax have EXTZV, but it is an unneccessarily
> complicated instruction.

You might consider scrapping bitfield support entirely.  If you go with
bit-addressible memory, you don't need it anyway except possibly to
trim-to-width as part of the load.  (There's a certain amount of
inconsistency in that the VAX is not, in general, a load/store
architecture, but when it comes to bitfields it is.)

> - AND.  Vax have BIC instead, but that (almost) always require a
> complement as well.

Only if you're ANDing with a run-time value, without a complement.  I'm
not sure whether A&B or A&~B is commoner (when B isn't a compile-time
constant; if it is, the difference borders on ignorable).  I must admit
it would be nice, though.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B