From mint-bounce@lists.fishpool.fi Fri Dec 9 12:40:47 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <43996C64.90005@highlandsun.com> Date: Fri, 09 Dec 2005 03:37:08 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051203 SeaMonkey/1.5a MIME-Version: 1.0 To: Evan Langlois Cc: mint@fishpool.com Subject: Re: [MiNT] virtual address spaces References: <1134027631.19887.45.camel@taro.coolrunningconcepts.com> In-Reply-To: <1134027631.19887.45.camel@taro.coolrunningconcepts.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: hyc@highlandsun.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=-1.0 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: Evan Langlois wrote: > 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 Yes, a +/- 32K limit on short offsets. Of course 68020 and up also supports long offsets. > 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. This has been done before, for other chip architectures. The gcc support for MIPS has the notion of a .smalldata segment, for example, which is used to store small variables. And all platforms use tables of function pointers to implement shared libraries. I don't see any reason to treat the heap specially. Pointers are still just pointers. The only thing that needs special treatment are direct address references. > 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. Servicing a Bus Error exception here is needlessly slow. You can handle this the same way as lazy resolution in other systems - set the pointer to point to the system's dynamic loader, so it will do the lookup as needed. > > 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. It will not be as robust since you won't be using the MMU's memory protection features, but it will in fact be more efficient most of the time since short offset base-relative addressing modes are the most efficient on the 68K architecture. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/