[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New Vax - future directions :-)
> 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…
Main Index |
Thread Index |