Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: MMU using base and bound
Date: Thu, 10 Apr 2025 16:46:02 -0400
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <vt9amc$3p3l9$1@dont-email.me>
References: <vt7qei$2f0s7$1@dont-email.me>
 <0f11555bb565a94c2a0bf47c243527c1@www.novabbs.org>
 <vt96as$3efvk$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 10 Apr 2025 22:46:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="48344a9ec57d36f38e8822c813dd850d";
	logging-data="3968681"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18ljcY4r1gVlvLjDGwAQClEOdBHa+8iX+w="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ruQnaJxRmzUtdaTjHbHmy/JZz4U=
Content-Language: en-US
In-Reply-To: <vt96as$3efvk$2@dont-email.me>
Bytes: 3241

On 2025-04-10 3:31 p.m., 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.  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).
> 
> 
> 
Yep, I was talking about extending a TLB based MMU. I am not sure what 
software I will running on it. I wonder if with a small memory system 
having just a single page table might be advantageous. I may want to 
remove the paging / TLB for a small system, it is a good chunk of LUTs 
and BRAMs, but I want to keep the same MMU interface.