Re: multi/tasking/processing

[rideau@xxxxxxxxxxxxxx (Francois-Rene Rideau)]

">" is Eugen Leitl
">>" is Penio Penev

[About Eugen's proposal for two register banks, one for the OS]
> But at least the OS, which gets called very often, does not need
> to be swapped out.
[...]
> E.g. imagine we are calling OS.SendMessage() all the time (in
> an OO environment, probably the most often used OS call).
> On some machines the opcode would mean CALL OS.SendMessage(),
> on some a dedicated instruction OS.SendMessage(). No need to
> recompile.
   Why should the OS be called often ? This is a very Unixish and
completely silly idea ! If you need faster OS switch, have it switched
to SRAM: if you need fast IO, use a specialized coprocessor, not tight
interrupt driven code; if you need to pass messages quickly, pass them
directly, and to not waste the stupid overhead of a micro-kernel.
[Microkernel are the most stupid thing ever invented: concentrated
overhead without any functionality. "Exokernels" are the solution:
no more kernel at all, but a dynamic linker that links objects directly
one to one another]. A centralized dispatcher is to be used only when
run-time speed is unimportant.

>> How would you define an "OS"?
> The interface between the hardware and the software. An insulating
> layer, providing an consistant surface. Plus resource manager.
   I think this is a bad definition for an OS. I try to give a better
one in the TUNES project.

> 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",
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.

>> If the "OS supervisor task" works 100ns worth at 1ms intervals, would you
>> dedicate half the chip resources to make it work 50ns at 1ms intervals?
> 
> Though 1 ms is probably too long, you are right, here. But how about
> interrupts? OSCalls? Your code will be seething with OSCalls. Every 10 
> opcodes there will be one.
  If you need very fast regular interrupts for something, then you'd better
have a specialized circuit for that task (much like the F21 "coprocessors",
not interrupting your generic ALU. It will cost less chip than a complex
interrupt manager and register bank switcher, and will sure yield far better
results.

>> Reentrancy we need. But why do we need memory protection? A program, that 
>> needs memory protection is a buggy program. I'd rather have a simple
> 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
tools, like strongly typed languages, and correction proof software.
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.

[About MMUs]
MMU take a lot of chip resource for specialized operations of questionable
efficiency. I'm convinced that investing the same chip size in more P32-type
general units and/or fast SRAM yields far better results.
If you want security, use secure tools (strongly typed languages with
bound checks) have it "optimizing" tools if you want efficiency.
As for debugging, emulators can provide programmable protection much finer
than MMU-based debuggers.

--    ,        	                                ,           _ 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/";