Re: New Vax - future directions :-)

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jul 4, 2021, at 3:42 AM, Anders Magnusson <ragge%tethuvudet.se@localhost> wrote:
> 
> Agreed.  No reason to make a 64-bit VM system in any way be similar to the old one.
> Better to make it match the requirements of today.  The Alpha VM might be a good one to look at, yes.

You will want something like FOE (fault-on-execute) so that you can support “W^X".  Actually, if you implement the VM machinery with separate I- and D- TLBs, then it might be easiest to simply have a separate “valid” bit (PG_IV) to indicate a PTE is valid for the ITLB, and rename PG_V to PG_DV and have it mean valid for DTLB.  In 32-bit mode, just wire PG_DV to PG_IV internally before the TLB selection logic and have it work as it does today.

I think it’s reasonable to forego mod/ref entirely in 64-bit mode.  The software interfaces we have in the kernel today make it not very expensive to emulate, and it would likely save a fair amount of FPGA space to leave it out.

One thing you could decide to do is to have separate hardware pointers for the kernel-mode table vs the user-mode table, which like how the VAX works now of course (with the SBR vs the P0 / P1 BRs).  That would simplify things a little at the software level (because there would be no need to update all of the user tables whenever an additional kernel page table is added; see the Alpha pmap_growkernel()).  The downside of this is that you would always use exactly one more (I assume 8K) page of memory because the kernel level-1 table would be a separate page, so it’s maybe not worth doing since the software complexity of just having a single PTBR isn’t that huge (and adding kernel level-2 tables isn’t a very frequent occurrence… although I should instrument it in the Alpha pmap just for kicks…)

> :-)  I tend to really agree with you here.  Also, since all other instructions work this way, marginally extra hardware would be needed.
> That would be three instructions,  like:
> 
>     CASBI    mb,rb,rb
>     CASWI   mw,rw,rw
>     CASLI    ml,rl,rl

Don’t forget CASQI in 64-bit mode :-)

>> IIRC, the compiler makes pretty good use of the bitfield insns, so I think you pretty much need to keep them.
> No reason to remove them at all, but they are inefficient. Currently the are about 30 microassembler steps due to the complicated syntax.
> Having them in pure hardware would make the faster, but it takes much hardware.
> 
> Here is the microassembler bitfield extraction subroutine just to give a hint.  Note that all common logical functions are only one microinstruction.

Clearly will need a new tuning flag for the compiler to tell it to avoid the bitfield insns :-).  I don’t recall if they’re that slow on a “real” VAX…

-- thorpej