New OS idea

[Francois-Rene Rideau]

> Frare',
(Ahem that's Fare' but I accept the new name you give me)

>>[About memory protection and preemptive multitasking]
>>    If you mean that a hardware-based implementation is required
>> for the above agreed features, I utterly disagree.
>>    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.
>>    Actually, I see ALL REASONS why it CAN'T be done in hardware, only in
>> software!
>
> How do you intend to do index manipulation?
> There is some way to eliminate at compiling time the need for checking it ?
>
Eliminating unneeded bound checks is already
a successfully well-developed practice in modern compilers
for languages with bound checks.
GNU Pascal Compiler, and a hacked version of GCC do that well,
for instance. I guess many Ada compilers do that, too.
I remember having seen courses on detection for unneeded checks
by abstract interpretation.

The more expressive the language is
about how an object's value can be restricted (its static/dynamic "type"),
and the expected behavior in case of overflow,
the better the compiler can collect this information
to eliminate unneeded bound checks,
and safely move needed ones to cheaper places.
   Because Pascal, C and the like ain't very expressive in such ways,
their potential for removing unneeded checks is low;
still, existing technology already eliminates most checks
quite satisfactorily for these languages,
so requiring Tunes programs to be overflow-safe
ain't such a slowing requirement in the long run,
as Tunes will be able of even better check removal.
   And if the Tunes language is reflectively expressive enough,
then hints can be given to the compiler as to when/how to
detect and eliminate unneeded checks.
   The point is that the TUNES compiler will be *guaranteed* never ever
to produce buggy code wrt bound checking,
unless when *explicitly* used in superuser mode,
with according godly privileges.

> It can be to expensive to check the bound of the program area to every
> memory access (ok, I know that this is the dumbest way) or even to check
> that bound on every indexed pointer aritmetic.
>
It occurs that in most programs,
needed bound checks are among
the 99% code that run 1% of the time (=very seldom),
so that most of implicit hardware bound checking is redundant,
while wasting a lot of resources (time, money, space, energy, etc).
   Of course, *assuming the hardware is fixed and
you pay for these resources anyway*,
then it's all the better when you can turn
even a small part of this expensive hardware checking
into something useful,
instead of dumping the waste in the Universe's entropy pool.
   Hence, on MMUish systems, the MMU *should* be used
for such things as detecting overflows,
saving the cost of copying some objects, etc.
It shouldn't generally be used to completely isolate objects from others,
as (meta-)software-based isolation is much more efficient and accurate.

> It couldn't force the language to be so restrictive ?
   How does that restrict the language to have dynamically restrict
to safe programs? What it means is no crash!
What's the use of a crashing program?
   Perhaps you mean that I over-restrict the language *implementation*,
in requiring that it (statically/dynamically) detects bad programs.
Well, hardware memory protection is just a way to detect
a few bad programs while letting a lot of bugs creep away until
you're stabbed in your back at the worst moment.
And it costs much more than software memory protection.
[agreed: that high cost might be paid already anyway -- see above].

Remember:
* a root user can do what he pleases
* explicit isolation/emulation boxes
 can be built "in user mode" to run unsafe software,
 if one thinks that's useful.

Actually, because there's no kernel,
everything is "in user mode".
So what I mean is that
the usual interobject communication meta-standard
isn't based around hardware protection,
though nothing in it prevents hardware-protected implementations;
and of course, nothing prevents safe communication gates
from linking different hardware-protected areas with each other.

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"