Build OS features in Software, not Hardware (was Re: Ne

[Alaric B. Williams]

On  3 Dec 96 at 16:10, Eric W. Biederman wrote:
> Alaric> Francois-Rene Rideau <rideau@ens.fr> wrote:
> >> I see absolutely NO REASON
> >> why this would have to be done in hardware,
> >> without any software cooperation,
> >> through MMU-based memory protection
> >> and interrupt-driven task preemption.
> 
> Alaric> I'd phrase it like so: MMUs check software for reliability the
> Alaric> /emperical/ way; let it out to play, on the end of a rope; if it falls
> Alaric> down a hole, we can haul it out.
> 
> The real usefulness of MMUs is that they allow paging and memory
> reorganization to be done cheaply.  The fact that they might check
> software reliability is a nice side effect.  This justifies there
> existence.

Ah, yes, I forgot virtual memory. Hardware level paging takes the 
load off of complex software serialisation schemes!

[good case for software task flipping snipped]

I see your point...

> Alaric> Trap handlers in the OS don't take up much space, and I don't expect a
> Alaric> runtime compiler to be a small piece of software.
> 
> Tunes will definentily need a regular compilation facility.  However
> FORTHs regularly include a very simple runtime compiler (not
> especially optimizing), and routinely included in embeded
> environments. 

I mean a compiler that does all the checking for illegal memory accesses and 
other crashmongers!
 
> [snip]
> Alaric> It could probably execute those four or so instructions in less time
> Alaric> than my 486 can do an AAM, but it still bloats it.
> 
> Ah but the compiler on the 486 isn't usually bright enough to use AAM
> so it's hardly an issue.

Ok, perhaps AAM is a bad example, but my general argument is that 
specialised instructions in few bytes can provide amazing 
speed/compactness wins in the cases they come in useful. Smarter 
compilers can detect semantics equivelant to what this instruction 
does more reliably. The choice of truely useful special instructions 
is important, of course! We currently don't need an instruction that 
resolves a series of CAT scan cross sections into a 3D image, 
although such a CPU would be popular with medical visualisation 
systems!
 
> Well thats easy to prove most humans can't program much less in
> assembly.  Usually it's the more the case that compiler generate more
> consistent code quality than most programmers, while programmers at
> any single spot can usually optimize better, though much slower.

Can sometimes optimize better! Not always - especially with large 
pieces of code... indeed, by defintion, if you sat at it long enough, 
you could use the compiler's rules to derive an optimised binary, 
then sit and stare at it until you had a good idea the compiler can't 
- but that's /hard/!
 
> A trouble with trusting compilers too much, especially with high level
> languages is that sometimes they can be so stupid :(  Give me a
> compiler that can optimize bubble sort into mergesort or quicksort
> (with out specific code for that case) and I'll change my mind.  

See my other emission (probably on the Tunes list now) about a 
fundamental theory of computation :-)
 
> What is needed in a language is a combination of what compilers do
> well.  Constant propogation and in general expression simplification
> and optimization.  And allowing people to do what they do well write
> algorithms.  And especially attempt a mechanism that allows those
> algorithms to be applied to mulitple types.

Yup. To rephrase, some goals of language designs:

 - it's easy to convert it into other languages (efficient compilers)
 - it's similar to how we think about the problem or solution thereof
 - it doesn't require the programmer to be unnecessarily specific - 
   inflexible type rules, unnecessary ordering of statements, etc.

> How proving and type safeness or in general assertion proving can be
> put into the above frame work, is a little bit tricky.  However I
> believe a clever use of macros could handle that case.  Also it might
> be wise to have a language with very simple types at the bottom and
> use the macros to build up the frame system.

Yup; a simple basic language makes static analysis systems easier, 
since we can factor out the syntactic sugar!
 
> Nicer syntax should be an added feature that simply compiles to a
> trivial syntax, instead of built into the language.

Uhuh. Like operator overloading:

a+b -> +(a,b)

Then we get on with the compilation of a procedure call.
 
> [snip]
> >> I could also talk about other things that traditional designs do ill,
> >> like building a wall between users and programmers;
> 
> There are still access control issues.  And the administrator/user
> disctinction while it shouldn't be as hard as it is now should
> defininentily be there.

Definitely.

> But I suspect in the long run it will be like
> electronics.  Everyone I know can manipulate basic circutes, plug in
> devices, change light bulbs, and a few other basic things.  But when
> the project gets big it is easier to hire an electrician than to do it
> yourself.

Yup! That's the kind of approach the Self guys seem to be following. 
I mentioned Self in my other email, so I won't put the URL in 
again...
 
> Alaric> (Windows for Early Warning and Defence User's manual P385)
> 
> And she will get so upset when you burn her a hole in the ceiling
> right next to her, and let the rain in....
 
> And your computer just crashed with the error message:
> Windows error: $#&*@!@! No error

;-)

<LI><B>Limited Warranty</B> Macrosoft Corporation cannot accept
any responsobility for geological, ecological, biological,
sociological, political, or nuclear disasters caused by Windows for
Early Warning and Defence. The software is supplied as is, with no
express or implied warranty, and with no guarantee of fitness of
purpose, or sufficient reliability to be placed in a situation to
threaten millions, if not billions, of innocent lives.</LI>

<I>Windows for Early Warning and Defence: What Do You Want To Kill
Today?</I>


ABW
--
Governments are merely protection rackets with good images.

Alaric B. Williams Internet : alaric@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">http://www.abwillms.demon.co.uk/</A>