From mint-bounce@lists.fishpool.fi Thu Dec 8 09:25:56 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] virtual address spaces From: Mark Duckworth To: Evan Langlois Cc: mint@fishpool.com In-Reply-To: <1134027631.19887.45.camel@taro.coolrunningconcepts.com> References: <1134027631.19887.45.camel@taro.coolrunningconcepts.com> Content-Type: text/plain Date: Thu, 08 Dec 2005 03:21:30 -0500 Message-Id: <1134030090.17643.20.camel@evil.atari-source.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: mduckworth@atari-source.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=4.0 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, RCVD_IN_DSBL, RCVD_IN_NJABL, RCVD_IN_NJABL_PROXY, RCVD_IN_SORBS X-Spam-Level: **** On Thu, 2005-12-08 at 01:40 -0600, Evan Langlois wrote: > Oh, I'm up too late again toying with odd ideas. A virtual address > space for systems with an MMU would provide quite a few improvements in > certain areas of the MiNT kernel. However, no one has yet implemented > such as its quite a large project. I think it may be possible to do so > one piece at a time. > > If we assume that managing the page tables to do this properly is too > difficult at this time, then their must be a fallback case for non-MMU > systems anyways, so we can implement this. I suppose anything from a > 68010 on up could trap bus errors to do virtual memory, but I'm more > concerned with a virtual address space than disk swapping. > > So .. would anyone be willing to discuss methods for implementing the > mmap() call? Once mmap() is implemented, other parts of the system > such as Malloc(), Mxalloc, Pexec(), etc, can be modified to use mmap() > internally. > > The main problem I see is that without an MMU doing shared executables > is really tough since you can't do copy-on-write pages or anything, and > that would be a key benefit to put in place. You can do base relative > addressing, but if I remember there was a 64K limitation for offsets > isn't there? I was thinking with enough compiler support, you could > emulate page tables in software on a module-by-module basis keeping each > module of code under 64K. Jumps within a module should be fine, but > jumps between modules would look up the function to call through a table > which the OS would have to provide to each process. Heap data > (everything not in a register or on the stack) would also have to be > accessed through such tables so the OS can allocate the non-shared data > segments per-process. Modules can be shared and linked at run-time as > long as no function is > 64K. Shared libraries would consist of > multiple modules. > > You could even have the OS "swap-out" functions and data from the table > and replace the table entry for that function with a non-existent > pointer. When a BUS ERROR occurs on that pointer, put the task on a > wait queue, look up that pointer in a table to find the function that > was swapped out, and swap it back in, then start the process at that > function. > > Now ... it could all work, but obviously its not going to be as > efficient and robust as just using the MMU, and you wouldn't need > compiler teaks to generate all the table lookups. However, it may be > doable quicker easier than MMU code and would work on a plain 68000. > I'm just interested in your thoughts at this point. Unfortunately, while I do not have the skills to render proper assistance, I'm a large fan of the simple implementation. For me it seems like there's 3 ways to do things: 1. not at all. Our chosen route. 2. Create a hacked implementation fast. Whatever is implemented should follow proper api's but behind the scenes could be a brutal brutal hack. The method specified above has a hack sound to me but again I DO NOT KNOW ;) 3. Create the absolute proper implementation all at once. Our ideals to follow number 3 I feel lead us to number 1. In my opinion crap is better than nothing. (that's how GIM was born ;) ). Thanks, Mark