Re: New Vax - future directions :-)

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jul 3, 2021, at 2:58 PM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> 
> 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.

Honestly, I don’t see a great deal of need to extend the register file on a hypothetical VAX-64.  The VAX doesn’t feel especially register-starved because of its rich set of addressing modes.

>> 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.

As I stated before, I think a PSL mode bit to enable “64-bit mode” is perfectly acceptable here, and once it is enabled, it automagically turns all of the control flow insns into Q variants.

>> 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.

I think you can preserve quite a lot.  Honestly, the standard “VAX-32” VM layout is pretty limiting; I don’t consider it “elegant” at all.  Adopt the Alpha OSF/1 style address map that gives you distinct “user” and “kernel” segments, as well as a large direct-mapped segment, and if you want Executive and Supervisor modes, add a couple of PTE bits to enable those restrictions in the User segment.

As for the PCB, I would just do away with P{0,1}{B,L}R and replace them with a single PTBR that points to a 3-level table like the Alpha OSF/1 PALcode uses.  Presumably, a VAX-64 system would have a reasonable amount of memory connected to it (I mean, otherwise why would you bother with a 64-bit mode?), so just use 8K page size when in 64-bit mode like Alpha uses.  Since presumably VAX-64 would have a HW table-walker, you don’t need the VPTBR that Alpha has (there is really only there for the PALcode to use).

> 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.

I don’t really see the point in this, really.  Seems too clever by half, different-and-weird as its own end.

>> 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.

Well, it also means “hey, more software works!”.

>> 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.)

I already suggested a perfectly workable solution to this problem - use the software-completion model that the Alpha uses.  QNaNs and a bunch of other exceptional conditions are handled by trapping and interpreting the instruction in a soft-float library.  I don’t see why the Alpha FP model couldn’t just be used wholesale in a hypothetical VAX-64.

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

A compare-and-swap instruction would pretty much cover anything that needs to be done.  Essentially all of the synchronization primitives used by the NetBSD kernel are built upon it.  Now, it MIGHT be easier to implement LDx_L / STx_L in the hardware (but maybe not when you consider peripherals that can access main memory), but it doesn’t seem very VAX-like … whereas something like a CASL3 that updates Z to indicate success/failure does seem pretty VAX-like :-)

> 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.)

IIRC, the compiler makes pretty good use of the bitfield insns, so I think you pretty much need to keep them.

>> - 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.

Alpha kept BIC, but added AND and I think having AND would be pretty valuable.  It should be pretty cheap to add in hardware, too, since you already need machinery to complement the second operand in the ALU for subtraction … you just need a way to signal that you want a ones-complement instead of a twos-complement.

-- thorpej