Build OS features in Software, not Hardware (was Re: New OS idea) (fwd)

Forwarded message:
>From alaric@abwillms.demon.co.uk Mon Dec  2 09:35:20 1996
Path: Kadath.ens.fr!nef.ens.fr!jussieu.fr!math.ohio-state.edu!howland.erols.net!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!dispatch.news.demon.net!demon!abwillms.demon.co.uk
From: alaric@abwillms.demon.co.uk (Alaric B. Williams)
Newsgroups: comp.os.misc,comp.programming,comp.object,comp.sys.powerpc
Subject: Re: Build OS features in Software, not Hardware (was Re: New OS idea)
Date: Sun, 01 Dec 1996 08:30:10 GMT
Lines: 292
Message-ID: <849429011.28136.0@abwillms.demon.co.uk>
References: <AE9B8BD5-9C44D@205.151.119.236> <0mRbd3200YUg0WQxU0@andrew.cmu.edu> <55807l$8ps@aadt.sdt.com> <01bbcc4f$8dc68160$f5a065cc@Phoughton> <0mYrA_200YUd0=m6o0@andrew.cmu.edu> <571ukg$dqd@ns2.borg.com> <0mZ_1A200YUg0_iuI0@andrew.cmu.edu> <32962260.89985021@news.znet.com> <5784sp$stk@ns2.borg.com> <0mazXq200YUd1_E5c0@andrew.cmu.edu> <xgmhgm7vjdc.fsf_-_@Kadath.ens.fr>
NNTP-Posting-Host: abwillms.demon.co.uk
X-NNTP-Posting-Host: abwillms.demon.co.uk
X-Newsreader: Forte Free Agent 1.0.82

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.

I'd phrase it like so: MMUs check software for reliability the
/emperical/ way; let it out to play, on the end of a rope; if it falls
down a hole, we can haul it out.

It's pretty obviously much nicer to analyse it statically before
executing it, so we can say "It will not crash unless my checker is
broken". This approach will detect any crashability, whereas the MMU
approach detects crashability only when it crashes.

And there's nothing wrong with interrupt driven preemption IMHO; it's
an implementation choice. I'm experimenting with inserting frequent
yields at compile time purely because it avoids some of the more
awkward side effects of preemption, such as writing hardware interrupt
handlers! It will bloat the object code with all those possible
yields; they'd better be inlined in the usual NOP case, rather than a
procedure call instruction every time we go through the inner loop!

In the case of a tight loop, certainly, interrupt driven tasking is
faster and smaller. The assembler code for a yielding addition loop
might be:

mov ecx,10000000 or so
mov esi,some_address
xor eax,eax

loop_top:

add eax,[esi]
add esi,4
cmp ElapsedFlag,1
jne continue
push esi
push eax
call Yield
pop eax
pop esi

continue:

dec ecx
jnz loop_top


If we were using interrupts, it would just be:

mov ecx,10000000 or so
mov esi,some_address
xor eax,eax

loop_top:

add eax,[esi]
add esi,4
dec ecx
jnz loop_top

I wonder which one will be faster and smaller!!!!

>Obvious reason: the hardware can only check
>a statically bounded small number of cases (finite expressivity)
>while bugs/attacks come in unboundedly many cases (infinite expressivity).

One way of looking at it...

>   Hardware implementation only slows down the machines

Not necessarily! The 486 can, I seem to remember, perform a push in
one clock cycle. Are you saying that if it didn't check the stack
wasn't overflowing, it could do it in 0? :-)

>and makes software more complicated
>to follow hardware bloatedness,

Trap handlers in the OS don't take up much space, and I don't expect a
runtime compiler to be a small piece of software.

A QNX kernel with hardware memory protection is 8k. An ARGON kernel
with a bytecode compiler in it will probably be more like 200k.

>   I'm confident that using clusters of cheapo MISC chips in parallel,
>programming them with a proof-friendly high-level language
>(like Clean or OCAML, unlike C/C++),
>will appear as the obvious solution,
>all the more when MISC can go farther than anything else in raw speed.

Really? How do they do that? If that stands for Minimal Instruction
Set, then prepare for even more object code bloat if we have to
produce four or so 32-bit instructions for something a 486 could do in
a couple of bytes (AAM comes to mind...)

It could probably execute those four or so instructions in less time
than my 486 can do an AAM, but it still bloats it.

>   Actually I'm even confident that those zillion dollars will eventually
>have been more than what would have been needed to resorb
>hunger in the world, if spent more intelligently.
>   Well, the world's not perfect.

You've noticed that too? :-)

>*My* project is to prove, following the trail shown by Turing himself,
>that the key of better computer systems lies
>not in ever-more bloated hardware,
>but in better software design.
>I'd like the whole system to be built that way,
>but I first need build the development tools.

Hmmm. I would beg to disagree; I interpret that as the RISC-style
argument that we should have real simple hardware being driven by
software. The software has a small set of operations from which it
builds everything else up.

Well, I think that's a fine place to start at. Sure, use a RISC CPU.
But there's a wide range of hardware devices that can take the load
off of software. There are chips that can do FFTs in the blink of a
clock tick. If we wrote an FFT application for this RISC chip, it
would contain a loop to do the FFT in terms of teeny operations. How
can the compiler see that an FFT is being done, and make it use the
hardware instead? With Difficulty! If we had FFT instructions in our
virtual instruction set, then on normal CPUs, those would be replaced
with calls to an FFT library. On our megazap FFT-in-hardware system,
they would use the chip!

So, yes, there should be a minimal operation list available. If a
piece of software is being prepared for a system with no stunning
hardware accelerators, then those special operations it uses can be
described in terms of basic ones. A very simple instruction set can be
used to talk to the CPU, but a more expressive format is needed to
represent semantics above the kernel level. The conversion from small,
expressive bytecode to bloated, simple, object code will be nearly
irreversible!

>MISC CPUs are so small that they you could put one per memory chip,
>instead of using levels of cache memory between a one active chip
>and many passive ones.

Reminds me of a design for the "perfect" ARGON workstation - one CPU
per object, each with the RAM that object uses! :-)

>Plus no one says that space/speed critical code (e.g. device drivers)
>should forcibly be written in those languages,
>or that no proof-capable-and-requiring low-level language
>could be provided to the user to write the 1% optimized code/metacode
>when the compiler doesn't get something right.

Hmmm. Modern compilers (such as gcc) can write better assembler than
most humans - except for such chestnuts as C's semantics being too
lightweight; there's no rotate instruction in C, and the compiler
cannot isolate pieces of code that are equivelant to rotates well
enough to use hardware ROT instructions.

A language like Eiffel or maybe Ada is well suited for high and low
level coding.

>people end up with using lots of special-purpose languages
>that communicate unsafely through unstructured text/binary streams.

Yeah :-(

>   This means the end of the need to explicitly generate/parse,
>check/blindly-trust and convert/ignore file formats,
>which eats most CPU time,

But there need to be agreed formats!

Say we have a picture object on our system (A), that stores a picture
as an array of Yu'v' colour triplets. An interface-compatible picture
on system B would use RGB colour. This is because A has a Yu'v'
graphics card, and it wants to be able to directly blit pictures to
it's display buffer. B uses a more standard 24-bit RGB VGA card.

How do we transfer a copy of A's picture to B?

If A and B used the same internal representation of pictures, then we
could transparently transfer that array of integers. But they don't. 

Converting Yu'v' to RGB will induce a loss of information, for a 
start!

>   This means that objects can freely communicate,
>that any service is made universally available
>and programmable/controllable, etc.

Locationally transparent objects, yes.

>Interface note:

>   Instead of generating meaningless code stubs from meaningless interfaces,
>we'd rather generate full interfaces (not stubs) from meaningful code.
>Because properly annotated code is meaningful, this is possible,
>while the inverse isn't.

I take it you're saying that the interface shouldn't be written into
the meat of the code, right? As in we should be dealing with:

class Complex {
   void add(Complex &c);
   void mul(Complex &c);
};

rather than

class Complex {
   void process_command_string(char *text);   
   char *render();
}

The latter class can be communicated to by the user at runtime,
whereas the former class can be communicated to by programmers! The
first case defines no user interface at all, whereas the second case
would force the use of code like:

Complex a,b;
a.process_command_string("Please add to thyself the complex number " +
b.render());

>   Different Interface generators could automatically generate
>interfaces for the MacOS, Windows, X/Motif, X/Xt, X/Athena,
>raw VGA, text graphic or raw terminal lovers/users.
>And why restrict to vision-based interfaces?
>sound-based, touch-based, (smell-based?) interfaces
>could be automatically generated, too.

How do you intend to generalise the definition of interfaces like
that?

In the case of the first Complex class, how can we tell the interface
generator that humans like complex numbers written in "a+ib" format?
We have to think of the case of textual representation to do that. We
would also need to think of voice-interface users too; they may prefer
a shorthand format to saying "Plus Eye" between the two numbers. And
how could the system know that complex numbers can be represented as
cartesian points on an Argand diagram without actually telling it that
(which is, surely, defining a 2D user interface)?

>   Of course, interface generators could be parametrized,
>tweaked, etc, to most suit the users' needs, tastes, and habits.
>   It's easy to give an outer shape once you have the inner meaning;
>it's impossible to guess the inner meaning from the outer shape.

Hmmm.

>   The Tunes project aims at showing that such a system is possible,
>by implementing one as a proof-of-concept.

How will you implement this interface generation thingy?

>http://www.dnai.com/~jfox				MISC technology

Ahah. I'll take a look at that.

>I could also talk about other things that traditional designs do ill,
>like building a wall between users and programmers;

I'd prefer a soft squishy layer to a wall, but I don't think we want
to completely remove the distinction until either everyone is educated
enough to program, or programming becomes so easy (due to natural
language interfaces, "Make me a program that can factorise large
primes"), that there need be no distinction; no need to put in
restraints to stop four year old children playing games on Daddy's
computer from wandering into the living heart of the operating system
and dragging the hard disk into the wastebasket...

>like requiring the user-programmer to explicitly
>implement object persistence when this could be managed orthogonally;

I'd agree with that one, though!

Regards,


ABW
--

"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."

(Windows for Early Warning and Defence User's manual P385)

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