[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New Vax - future directions :-)
Den 2021-07-03 kl. 20:58, skrev Mouse:
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.
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.
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.
Exactly, therefore having IEEE as the underlying format would be
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
So are (quiet) NaNs and infinities. (Reserved operands are,
approximately, _signaling_ NaNs; VAX FP has nothing like quiet NaNs.)
- 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
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.
Main Index |
Thread Index |