[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New Vax - future directions :-)
Den 2021-07-04 kl. 19:10, skrev Jason Thorpe:
Hm, I think I'll leave this for the future when development has come so
far :-) I think it's best to focus on getting the 32-bit vax work first...
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:
Don’t forget CASQI in 64-bit mode :-)
I'll try not to :-)
Well, it get faster if it's plain hardware, but it requires quite much
The problem is that it may span up to 5 bytes referenced, which as well
may be in two consecutive registers.
Also, the memory references must be longword aligned, so that it won't
create page faults if it end up on a page boundary.
At last, it is a 35-bit bit-pointer in memory, which first must be
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…
No, the bitfield instructions are not nice.
Main Index |
Thread Index |