Re: MMU using base and bound

On Thu, 10 Apr 2025 19:31:40 +0000, Stephen Fuld wrote:

On 4/10/2025 8:48 AM, MitchAlsup1 wrote:

On Thu, 10 Apr 2025 7:02:41 +0000, Robert Finch wrote:
>

Working on the MMU component tonight.
>
Just realized that it is possible to have only a single hierarchical
page table in the system if base and bound addressing is applied before
translating with the page table. Or to reduce the number of page tables
using the base/bound addressing.
>
Building base/bound registers into the MMU, pondering having multiple
sets of registers to reduce the amount of register swapping. A single
BRAM should be enough for 32 sets of 16 registers. Could store an index
for selecting the set in the process control block. Defaulting set zero
for flat addressing.

>
Base and Bounds is not compatible with the feature/functionality we see
in modern applications; things such as::
>
a) mmap()
b) dynamically linked libraries
c) Address Space Layout Randomization
d) JITTed binaries
>
At least until there are enough base and bounds registers, and when
there
are enough of these, then the B&B MMU smells just like a SW programmable
TLB--and at this point--either go all the way or don't start down that
path.
>
Also note:: at SATA data transfer rates, activating a 20 GB application
takes multiple seconds on the disk drive itself, something that only
suffers a dozen milliseconds with typical paging.

>
You seem the be talking about B&B as the only mechanism.

No,

                                                         In that case,
your criticisms are (mostly) valid.  But if, as I think Robert is taling
about, you have a B&B implementation "on top of" a paging
implementation, most of those problems go away (albeit introducing
others).

I saw that and took that into consideration. Way back in 1980 one could
get away with a single base+bounds per process. My argument above is
that
that time has past mostly due to new things we want applications to do
these days.
Secondarily, once you get a base+bounds for every kind of memory region
you are closing in on the number of PTEs in a minimal TLB. Which is why
I suggested to just use paging under paging (GuestOS vis HyperVisor).
Consider that every open file is mapped into memory areas that allow
for the files to grow (significantly). I just done see how a single
application with 20 open files each of which can grow can use a dew
number of base+bounds registers is any realistic manner.

>
>