Re: New Vax - future directions :-)

[Anders Magnusson <ragge%tethuvudet.se@localhost>]

Den 2021-07-03 kl. 20:58, skrev Mouse:
> > 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.
Due to the argument encoding it would be something completely new to 
address more than 16 registers.
Also, I don't think it's not necessary.  IIRC have read some research 
result once where it was found that the increased speed of the resulting 
code were marginal for an architecture with more than 16 registers.
> > 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.
But it may save space if using 32-bit instructions.
> > 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.)
Exactly, therefore having IEEE as the underlying format would be 
reasonable simple.
> > - 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.)
Currently I have implemented EXTV/INSV in microassembler.
> > - 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.
-- R