Re: multi/tasking/processing

[rideau@xxxxxxxxxxxxxx (Francois-Rene Rideau)]

">" is Eugen Leitl
">>" is me (Francois-Rene Rideau)
">>>" is Eugen Leitl again

>>    Why should the OS be called often ? This is a very Unixish and
>> completely silly idea !
> Each time the network processor or the video or I/O processor
> generates an interrupt. Each time the next task must be switched.
   This is either not often enough to bother, or would be better solved
with specialized circuitry, not software (if you have too many tasks,
use more parallelism or faster hardware).

> Each time we send a message. (The last happens a lot).
   Again, all speed-efficient messages should be (dynamically) inlined.
E.g. integer "+" should be inlined to proper assembly instructions.

> Call it OS, call it whatever. Certain methods, I choose to assotiate
> with the "OS" object (node13.OS.flush_1(objectID)) wind up called
> lots of time.
   Then why dispatch call to them through a kernel ? (Dynamically) link
your code so it calls the right routine.

> Microkernels are too big, nanokernel is the thing.
   Nano- or Micro-, they are the same. The principle of a kernel itself
is deeply broken. What is a kernel ? Just some overhead to dispatch
routines at run-time. It just has no point. Code should be bound whenever
the binding is known, not before (not possible!), not after (and at least,
just once, not once per call).

> And how
> do I send a message to an object transparently? I don't know
> where the object currently is, hence OS.Send(ObjID, msg);
> is the only clean way of sending the message. Actually, as I 
> have already proposed in misc somewhere, a dedicated instruction 
> SEND, interpreting stack contents as a message would be nice.
>[...]
> Of course SEND will need a dedicated circuit. But my name is not Chuck. M.
> and I don't own a silicon foundry. Ask Chuck about hardware OO support,
> let's see what he'll say.
   No ! Certainly not ! OO-in-hardware was tried at the beginning of
the eighties (see intel i832), and led to bloated chips that were
big and slow. Just *the opposite of MISC*. I've thought about it a lot
back in time, and when I evaluated the cost, I understood it was
not feasible. Of course, like you, I regretted the security such
design would have brought, until I discovered formal methods for
programming, which allow you to compile *secure* code in a
strongly specifiable language into *fast* code for efficient
machines.

> Object's data is private. Some object methods are private, some
> public. (Verbatim and threaded methods). I can't know to which
> objects I will be talking to at compile time. How can I compile
> direct method calls without runtime checks?
   Recent studies showed that in a strongly typed language with
bounds checking, most (>95%) run-time checks could be removed
using simple optimization techniques.

> There are many shared methods. Kill, flush, retrieve, relocate, etc.
> which each object must understand. Instead of having stupid redundant
> local jump tables and a dispatcher, the message gets diverted to the 
> according OS methods by a central (preferably hardware) dispatcher, 
> only then branching to local dispatcher. 
>
> Why not?
Because it wastes lots of resource for a job that is best done at
compile-time, or at bind-time in a dynamically partially evaluating
system.

>>> A special object with fixed ID, an instance in each node.
>>    This is better. But then, this definition could fit many an object.
>> If you try to define it as "maximal object common to each node",
> Of course. There is a minimal set of methods bound to each node,
> the bare-bone OS infrastructure. Other methods (gfx, maths, sound,
> etc.) gets loaded/flushed on demand. Of course.
   Then, what method should be "bare-bone" is a completely subjective
matter. People doing lots of graphics or programming a GUI will
require lots of graphics primitives in here; end-users will want
a full-fledge UI included; people in embedded systems will want the least
possible included, etc. There is *no reason* why some people should be
priviledged to the great demise of everyone else, or why the OS should
grow to monstruous sizes in trying to satisfy everybody. Actually,
there are lots of reasons why not, and nobody is satisfied in the end.
Instead, the OS should scale to the user's need.

>> then you get my definition for an OS; but then you should be conscious
>> that if you consider a set of nodes running the same application,
>> this application will thus be part of the OS.
> Let us restrict the OS to housekeeping, ok? An application should
> typically have no idea where an object is and how the messages gets
> routed. An application should rely on the "+" method being available
> for integers right from the start. Etc.
   Why should applications have no idea ? On the contrary, the more we
know, the better we can "optimize" code. Well, of course, there are cases
when you don't know, and you need dynamic evaluation. But why re-link
at each call ? You just need link once per binding.

>>> There is no such thing as a bug-free program. Particulary, a large
>>> bug-free program.
>>    Well, there can be crash-proof programs, using *high-level* crash-proof
>
> You can eliminate e.g. dangling pointers with garbage collection and
> do array index checking. You can introduce trap handling. But
> you still will have buggy software.
   You will _always_ have *buggy* software. My point is you can have
*crash-proof* software, which is quite another thing. So you _don't_
need MMU, user/kernel protection and suches, which are but a lot
of hardware overhead that won't ever buy you crashproofing, but will
waste a lot of resources. Instead (assuming you need crashproof software),
you need high-level programmation tools, with programmable code
transformation tools to obtain *fast* secure programs.

> You can't sample the 
> entire input space and you can't generate a bugless program
> from perfec pieces. All this can reduce the number of bugs
> significantly (at the cost of loosing some power), but not
> eliminate them altogether.
   Yes you can (but you need a lot of investment over existing software).
That's called formal methods for programming and correctness proofs.
It works only when you have a mathematically expressible specification
of what you want your program to do or not to do, and you need to prove
things about your program (and to because it's too hard to get from an
existing program, you need program in a language that makes proofs easy,
and code proofs and programs together).

>> tools, like strongly typed languages, and correction proof software.
> Proofs are worth nothing in the real world.
   They sure are worth as much as run-time checking, and much more than
MMU-based protection, and they apply in much more cases.

>> I'm sure this is the only possible long-term future for the software
>> industry, in the same way as I'm sure MISC is the only possible
>> long-term future for the hardware industry.
> These methods will come, but I essentially think nonalgorithmic
> systems are the only robust ones.
What are you calling "nonalgorithmic systems" ???
AFAIK, all digital computers run algorithms. Are you suggesting going
back to analog computers ?

>> As for debugging, emulators can provide programmable protection much finer
>> than MMU-based debuggers.
> Agreed. But you can't run your software on a software interpreter all the
> time. As you can't ferret out all bugs during debbugging.
   Have you ever heard about compilers ? And again, bug-free *is* possible
if only you have a bug free specification. And if the crash-free part
of the specification is ok, at least you can have crash-free code.
Compiling can select the few right checks to do instead of the many wrong
ones you're doing with hardware protection.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/";