Re: New Vax - future directions :-)

[Johnny Billquist <bqt%update.uu.se@localhost>]

On 2021-07-03 15:46, Anders Magnusson wrote:
> So, some thought about expanding the Vax architecture.

Interesting topic, yes...

> 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.  Argument reference will work as before.

Indeed. There are even some instructions that already exists in Q 
format. However, I am unclear what actually happens if you do a

CLRQ R0

does it clear R0 and R1, or just R0?

Also, you would probably want to add a new addressing mode, for quad 
offset. Which would be rather tricky to do...
And how would register mask pushing at CALL work? Would they push 8 
bytes per register instead of 4? That could mess things up...

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

Yes.

> Kernel; the hardware structures (SCB, PCB, ...) must all be expanded. 

Obviously.

> Memory management changed (but the existing leave much to wish for anyway).

The memory management of the VAX is a bit messy, I agree. But at the 
same time, do you want to change it?

> All this is probably a quite simple update to the architecture.

Maybe... Not entirely convinced (yet).

> IEEE floating point:
> The current floating point formats are very like IEEE formats (compared 
> to other pre-IEEE formats).  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.
> By adding the three IEEE formats I think it would require very few extra 
> gates to make it behave like the DEC FP instead.

Should be easy to take inspiration from the Alpha here, since it has 
both VAX and IEEE FP.

> Multiprocessor:
> Vax have had multiprocessor support since ~forever, but it may be a good 
> idea to revise the interlock instructions.
> There are only 7 of them and a few more would be nice.
> Having it in a FPGA would make it simple to clone up many Vaxen in the 
> same cheap chip :-)

Agreed. The interlock instruction repertoire have always seemed a bit 
strange to me.
And unfortunately, when I tried to make efficient use of it in NetBSD 
many years ago, it turned out to be pretty impossible. NetBSD 
essentially requires the CAS instruction, so adding that would be a big win.

> Convenience:
> Even though there are 288 instructions, a few are missing that would be 
> nice.  For example;
> - Unsigned mul/div.  Vax only have signed.

Trying to remember if EMUL/EDIV could be be used here, but I suspect you 
already concluded they can't then...

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

Agreed. This is also always a pain on the PDP-11. A logical shift right 
is something I miss a lot.

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

Funny. It's the same on the PDP-11, but quite honestly, I actually find 
it way more useful to have BIC than AND. When I have AND, I need to do 
complements a lot, because in the majority of all cases, what I am 
interested in is clearing bits out.

If you just want to check if a bit is set, then you use BIT anyway, 
which is doing an AND, but it just sets the condition codes.

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol