Down the design trail...

[Chris Harris]

On Thu, 8 Dec 1994, Francois-Rene Rideau wrote:

> > C is very simple (26 operators), but very 
> > extensible (if you can call libraries that).
> Well, you can't. Compare C's extensibility to FORTH's or LISP's or even ML's,
> and you'll see it ain't. Because C is a first order language; and even the
> standard C preprocessor is a very poor first-level language.
> C is low-level. C is unextensible. C is unsecure. C is not powerful at all.
> C doesn't allow code reuse. C is a static language. C is unamendable.
> C sucks. Don't use C. If some people are masochistic enough to ask for it, let
> them have it.

Well that's fine and nice, but C still has one power that most languages 
can't come close to matching: everyone uses it.

I'd like to stress the importance of having many different langs 
supported by the OS.  We shouldn't be dominated by Self, our own 
language, or whatever, as Next is by objective-c.  Even though we all 
love to hate it, I'd even propose having C++ support, or at least the 
ability to.  We could tweak it up so its nice and dynamic, but it should, 
in theory anyway, be perfectly ok to port C++ to the project....

> > C got from UNIX a bunch of good libraries which made it truly useful,
> > along with development tools, etc.
> TeX or UNIX being written in C adds nothing to C's usefulness: when you
> program in C, the only way to exploit some external program is to fork()
> and exec() it (or system() it).

See the above: strength in numbers.

> > How does this relate to our project?
> 
> > 6.23 Our design should be simple enough to get off the ground
> Any design should !

Quite true, but I propose this rule comes after extensibility.  If we 
create a really simple system now, we'll be sorry later when we come to a 
dead end.

> > 6.24 It should allow easy extensions
> It should allow easily *powerful* extensions.
> This is #1 priority. An OS is the basis for computer work.
> It is useful only as it allows any kind of further work to be done
> easily, directly inside the system, and in perfect symbiosis with
> other work inside the system. If some extension is not possible,
> then people will use another system (be it written on top of the
> actual OS).

I 100% second this.  If the system is extedable enough, it should be easy 
(enough) to add more speed later.

> > 6.25 It has to be able to do anything the core CPU can (C's instructions are 
> > 	actually pretty low-level)
> This is a tricky one, as CPUs evolve rather quick...
> And allowing quick and efficient port of programs means such things are done
> in conjunction with the compiler...

I don't really know what to do here.  This should make choosing a LLL 
quite a problem.  In order to support all features of all CPUs, we'd 
basically have to have the instruction set be RISC and CISC at the same 
time, which isn't very possible.  (Ever looked at a PowerPC spec book?  
It has dang near as many instructions as Intel!  Of course, they justify 
the "RISC" by having each of them do less, but there's still quite a few 
of them.)  Stack-based or some other actual language might seem more 
appropriate, but I agree; it would limit the feature set somewhat.

> > 6.26 It has to run fast
> Not the #1 priority: this depends heavily on compiler technology; and good
> optimizing compilers need time to write (and good assembler code needs even
> more time to write). So don't expect the system to run fast until version
> 34.235.12

100% second on this too.  I'd be curious also to know if our LLL will do 
any on-the-fly optimizations of code.  For example, might it scan a few 
lines, and then determine that the native CPU has one instruction that'll 
do it all at once?  The other option, of course, is the have lots and 
lots of keywords that each represent an instruction the native CPU MIGHT 
have, but that's a bit wasteful.

> > 6.27 It has to be easy to program
> This is the #2 priority to me. And remember that *using* is *programming* (and
> the other way round).

Not exactly sure if I'd call it #2, but somewhere around there.  Still 
more important than speed, IMHO.

> > 6.28 Easy to port to different architectures
> Architectures are not *that* different. Anything you would write for, say,
> an i386, would be very easy to port to anything, unless it relied heavily
> on segments, which it won't, as segments are so slow and costly, and bring
> not much. For a first generic implementation, Let's assume just some 32-bit
> linear addressing and pagination. Further implementations for lesser or
> greater architectures (8, 16, 20, 64 or 128 bits) will come later.

Sounds good from here.

Say, for our paging system, might I wonder if it would make sence to kill 
the swap file idea?  Instead, when a page can't fit in memory any more, 
it is written onto disk, in the correct place in the object/toolbox.  
This way, things are more presistant, and you can theoritically pretend 
to have near-infinate RAM, but it might be a bit slow....

> > What did I forget?  What am I missing the point on?  What am I dead wrong 
> > about?
> It is very important to acknowledge that our system will be expressed in
> some computer language, and that its semantics will thus be limited by that
> of this language. Unix semantics suck, because they are expressed in C;
> there thus can't be any kind of security or intelligent error recovery under
> Unix; there cannot be generic operators, or any second order, or even any
> higher order operators under Unix. C is also a static language, with staticly
> defined types; there can be no secure system evolution under Unix.
> Let us use some higher-order, dynamic language to define our system's
> semantics.

Ok, but let's also not get stuck with a particular language, should our 
needs/wants sudenly change.

One last goal I'd like to insert into the hiarchy somehwere (#3?) is 
reliability.    This is still more important than speed, IMHO.  What good 
is a persistant system if the persistant data is constantly getting 
corrupted?

-Chris