Date: Thu, 6 Aug 1998 19:09:48 +1000 (EST) From: "Andrew Reilly" <reilly@zeta.org.au> To: tlambert@primenet.com Cc: tom@uniserve.com, current@FreeBSD.ORG Subject: Spin-type OS issues, was: Re: Heads up on LFS Message-ID: <19980806090948.6680.qmail@gurney.reilly.home> In-Reply-To: <199808060606.XAA22855@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980806090948.6680.qmail>