No subject

[Francois-Rene Rideau]

>> unless it relied heavily
>> on segments, which it won't, as segments are so slow and costly, and bring
>> not much.

> I'm curious why you say segments are costly and slow?  And if you don't 
> use segments, how do you isolate processes from each other without using
> the built in mechanisms provided by the CPU (in this case 386), and still 
> be quick?
I meant using segments as the basis of protection mechanism: this would mean
every memory pointer manipulation would involve a system call for the modifier
and a segment loading for the reader. All this is *quite quite* costly and
slow. Moreover, it allows only contiguous memory. I say: no ! Either have
programs proved secure, or isolate them from the system.

Segments will no more be used in our i386 system than they are in Linux,
OS/2 or any such OS. They'll be there just to allow the system to exist on the
hardware. (that *requires* a GDT) but not *anything* more. Not only wouldn't
that be compatible with other hardware, but it would be slow, and unpowerful.


>> Unix semantics suck, because they are expressed in C;
>> there thus can't be any kind of security or intelligent error recovery
>> under Unix;
> 
> Not true, it is a poor craftsman that blames his tools.
> 
  It is a poorer craftman even, who believes he can do as well with his stone
tools and curved boards as an engineer of the computer ages with his laser-
precise tools.
  Under Unix, you *can't* build a crash-proof persistent system, but by
accessing directly an uncached device (if it exists), that is if you rewrite
the logical disk access layer (which is not using Unix, but developping a
new tool). You can't have real-time response, but by using select() and
signals, and *hoping* nothing wrong will happen. Anything you can't do simply
with C, you can't do with Unix. Any higher-order operator is just impossible
under Unix (but not under systems built on top of Unix).



> There are advantages to writing as much as possible in the highest OO 
> language, points which I do not have to argue here.  But in the mean time 
> we need to work on some low-level implementational stuff, and since 
> machine and next up assembly are not as easy to work in as C, I advocate 
> C to write our bootstrap stuff in.  It is very portable, I have an 
> excellent development environment (Borland C++ 4.0), and we are not 
> anywhere near having a spec for our HLL.  We can always rewrite it later 
> in the HLL (or LLL).

I propose using assembly (on POSIX systems, that's indeed C; but on PCs,
that's i386 assembly, not BC++) to implement the LLL. Then, use the LLL to
implement the HLL. C/asm will only be for device drivers.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
MOOSE project member. OSL developper.                     |   |   /
Dreams about The Universal (Distributed) Database.       --- --- //
Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE   /|\ /|\ //
Phone: 033 1 42026735                                    /|\ /|\ /