From mint-bounce@lists.fishpool.fi Thu Dec 8 08:48:09 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: [MiNT] virtual address spaces From: Evan Langlois To: mint@fishpool.com Content-Type: text/plain Date: Thu, 08 Dec 2005 01:40:31 -0600 Message-Id: <1134027631.19887.45.camel@taro.coolrunningconcepts.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Evan@CoolRunningConcepts.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=2.1 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, RCVD_IN_SORBS X-Spam-Level: ** 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.