Re: New Vax - future directions :-)

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

Den 2021-07-05 kl. 19:12, skrev Johnny Billquist:
> 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?
Both.  The two Q instructions that exist would do the same on memory but 
not on registers.
> Also, you would probably want to add a new addressing mode, for quad 
> offset. Which would be rather tricky to do...
Quad addressing mode already exist, you know? :-)
There are as I can tell only two things in the addressing modes that are 
affected;
- Displacement mode > longword. I don't think this can ever be a 
problem, a displacement larger than 32 bits could be written in numerous 
other ways.
- Absolute addressing.  This would solve itself if a mode bit is used as 
thorpej suggested.

Actually, the more I think about it, the more compelling do a mode bit 
look like :-)  It worked well for PDP11 code, so why not for VAX64? :-)

> 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?
It must be changed.  One flat page table is not usable.

> > 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.
Yep.
> > 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.
Basically everyone needs something else than the queue interlock 
instructions... :-)

> > 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...
They are signed.  And strange (EMUL is 64=32*32 bits, EDIV is q32=64/32 
and r32=64%32... ) :-)
> > - 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.
In a C compiler you only have AND, so when translated it usually ends up 
with a COMPL as well.

But AND wouldn't harm anything, in my implementation it would just be a 
one-step microassembler entry, just like BIC.

-- R