From owner-freebsd-current Thu Aug 6 13:01:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA15239 for freebsd-current-outgoing; Thu, 6 Aug 1998 13:01:26 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15202 for ; Thu, 6 Aug 1998 13:01:05 -0700 (PDT) (envelope-from reilly@zeta.org.au) Received: from zeta.org.au (d4.syd2.zeta.org.au [203.26.11.4]) by godzilla.zeta.org.au (8.8.7/8.8.7) with ESMTP id GAA08612 for ; Fri, 7 Aug 1998 06:00:42 +1000 Received: (qmail 6681 invoked by uid 1000); 6 Aug 1998 09:09:48 -0000 Message-ID: <19980806090948.6680.qmail@gurney.reilly.home> From: "Andrew Reilly" Date: Thu, 6 Aug 1998 19:09:48 +1000 (EST) Subject: Spin-type OS issues, was: Re: Heads up on LFS To: tlambert@primenet.com cc: tom@uniserve.com, current@FreeBSD.ORG In-Reply-To: <199808060606.XAA22855@usr09.primenet.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My apologies for starting a language discussion. That was not my intention. I just thought that I would point out that I thought the interesting thing about Spin was not that it was written in Modula-3, but rather that the designers were trying to avoid the overhead of process-to-kernel virtual address translation by keeping both the kernel, the extensions, and the user processes in the one address space. (Yes, just like MacOS and Win3.1...) It seemed to me that they were trying to do this _safely_ by pushing the checks that prevent processes from diddling with data that didn't belong to them into the system compiler, resolved at compile time, rather than using the more traditional approach of physically segregating the address spaces. Obviously, forcing the use of a particular compiler for an otherwise niche language is going to limit the practical usefulness: no-one is likely to re-write perl or vi in Modula-3, for example.[1] My point was that some other attempts to use a uniform virtual address space have been attempted, with some hardware support in the form of read-only or no-access regions of the memory map. This still requires that you change protection maps on user/kernel boundary transitions, but a) you still avoid the need to walk tables to convert pointer arguments from one domain to the other. b) The hardware memory protection can be designed to make this more efficient, by associating process IDs (or a mapped working subset of same) with the protection mappings. I believe that the ARM MMU in the Newton was something like this, and that the memory hardware in AS400 systems has much the same effect. (Don't SPARC MMUs have a process ID in the context too?) None of that is particularly relevant to FreeBSD (at least until we try a port to "odd" platforms like those), but it is interesting to see how other folk are approaching OS design. [1] I suppose you could write a "safe C" compiler that nominally did range checking on all pointer references, and prevented access to regions that weren't explicitly passed to you by the operating system. That means that the compiler would have to have intimate knowledge of sbrk and mmap, and would have to work very hard to optimise away most of those checks. Does anyone know if such a compiler has been built? How about the "C on JVM" efforts? -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message