Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: New Vax - future directions :-)

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

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


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.


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


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.

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

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

Home | Main Index | Thread Index | Old Index