On 2021-07-07 20:02, Paul Koning wrote:
On Jul 7, 2021, at 1:42 PM, Johnny Billquist <bqt%update.uu.se@localhost> wrote: On 2021-07-07 18:42, Anders Magnusson wrote:Den 2021-07-07 kl. 17:22, skrev Hans Rosenfeld:No split I/D space, no FP, any kind of trap exits out to VAX mode, anything that depends how the memory management of the PDP-11 works will have issues... Even some instructions you might play with are missing (but I don't think most people would miss them, especially not since we don't have split I/D space anyway). Very few 2.11BSD programs would work in this environment... The most serious limitation is the lack of split I/D space.So I guess we have another few feature requests, then... :)Maybe add I/D segment registers for PDP-11 compatibility mode?"Segments"? It's a straight forward page table. The only "odd" thing is that the page don't have to actually map the whole part of it. But you have a direct mapping from a specific virtual address to a specific page. It can't move around, no matter how much you play with the MMU.If we go for something with 8k pages in the future XVAX it might fit quite nicely :-)Yes. Since the PDP-11 pages are 8K it would fit pretty nice. However, the fact that the PDP-11 page don't have to fill the whole 8K can maybe throw some wrenches in somewhere.The PDP11 MMU does several things the VAX can't do. 8kB pages isn't a problem, that's just 16 VAX PTEs. But valid page length is a multiple of 64. VAX can emulate a multiple of 512 but not other length values. I don't suppose that's a problem in most cases. For example, while RSTS uses this in the kernel I don't think it does for user mode pages. "Expansion direction" doesn't make things any harder; for multiples of 512 length the equivalent VAX pages are straightforward, and for other lengths you'd have to round up the length in either case.
Right. And in fact, in RSX, the API even includes a mode bit if you want the size and address rounded to 512 byte values.
PDP11 physical addresses are also multiples of 64 bytes, and I assume that capability may get used in memory-resident shared libraries. Or are those overlay segments rounded to multiples of 512? I would think not because that would waste physical memory, not something you'd want to do on a PDP11.
I would assume it goes with 64 byte multiples to just maximize the usage. Resident libraries are both a question of size and location. But it has no impact on applications, as they will get them on an 8K boundary anyway, and nothing else will appear until the next page, which is 8K later no matter what.
But internally, when it comes to reserving memory for both libraries and memory resident overlays, I would assume TKB will pack things as much as possible. But I haven't checked if it is possible to make TKB use the 256 byte variant option for this...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol