Moose Revision -72

Greetings, Happy Moosers, from the frenchman who wants a new language.

[...]
Here is my reply to the latest news I received from MOOSE (it is a bit long).

"Dr. Hayden" <haydedr@WKUVX1.BITNET> sayz:
> [...]
>  First off, there is a mention of how we're aiming to support the 2-8MB
> RAM PC market, yet we want multi-user support.  8MB, in my estimation,
> seems a little bit small for multiple users.  And, does it seem we
> need multi-user support in the PC arena anyway?

 I agree that we need support multi-user as soon as possible; but we don't
need 8MB for multiple users if they share libraries. Assuming multiple users
essentially use the same programs and features, only user-specific data must
be present twice in (virtual) memory which isn't much in "normal" use.


> Also, should we take into consideration the design of the Motorola chips
> before we begin?  I say this because I know the 386 much better than the
> 680X0s, and I'd like to follow the task and memory management facilites
> provided by the 386 as closely as we can; however, if the two
> architectures differ significantly in those areas (say, if the 680X0s
> don't have any hardware task switching capabilities), then maybe we
> shouldn't use the 386 facilities either.  It seems there may have to be
> a balance struck between the two architectures (unless we just want to
> write it for the 386, then port it later).  My envisionment of Moose is
> that, on the PC end anyway, it will be primarily interrupt driven.  I
> don't think we can do it that way on the 68000 series.  This is a
> fundamental difference, and this alone could cause us to essentially
> have to write two completely different kernels which may not support all
> the same features between them.  The main question I'd like to ask of
> all of us is this: do we expoit the 386 for all it has, or do we look
> for a least common denominator between the two architectures and aim
> for that?
 The problem is very important, and I think everyone of us must have it
in mind; however, I propose another solution: after having agreed on
high-level features (accessible in our standard language; C++ as it seems
to be going to be; something new I'd like), we implement it the best we can
on each machine, using the full power of the processor. But particularities
of processors should NOT be used in the HIGH LEVEL standard.


> Also, our OS will not run on anything less than a 386SX, so is there
> perhaps a similar cutoff in the Motorola chips.  I mean, is there such
> a difference between, say, the 68020 and the 68030, that we should not
> develop for anything less than the 68030?
> And, about Mac support, isn't the user interface part of a Mac OS in
> ROM?

 If we abide by the "standard is high level" principle that I am supporting,
there can be different kernels running on different 680x0's; there can even
be someday a kernel for the 8088 if someone is fool enough to write it. Of
course, we should first concentrate on 386 and 680x0 (x=0,2,3 ?) kernels. As
for Mac support, or more generally support under an existing OS, the only
problem at running Moose (or whatever we call it) as a sub-OS should be
speed, and, firstly this will save development time for early versions, and
finally, once one have seen it run even slow, it will be so good he will want
to run it as main system (or so he should).

> Section E concerns scheduling.  I'd like to see four priority classes.e
> We could have a time-critical class, then perhaps some type of
> class where we could let threads run that need to run before those of
> a user class, such as server maintenance threads and the like, then of
> course a user class, and finally a daemon or idle thread class.  Within
> each priority class we'd have just a simple round-robin dispatching.
> Sound like it will fly?
 HEY, WHAT DO YOU THINK ABOUT THIS:
 My personal opinion is the most important and difficult classes to define
will be the executable code classes. What is bad at ancient languages is
that they each support only one aspect of executable code (imperative
infix, prefix or post-fix notation code as in C, Pascal, or FORTH; functional
notation as in LISP or ML, etc; backtracking as in Prolog; ... ); moreover,
they always create a big gap between code and data, whereas one would like
to do with code the same he can do with data, and vice versa (in C, you
cannot compile small bits of code at execution; neither can you move or
code/decode chunks of code; or analyse it... ) ; finally, very few languages
understand massive multithreading where virtually every item has one or more
threads running or waiting for it. In the other way, data types don't for
the moment include exceptions as is done for code in C++ or CAML, etc; they
don't have as powerful virtual capabilities as methods in OO languages, etc.
 The OOing Kernel should include all these features. To me, it is the most
important in the project; if we just wanted 32 bit multitasking I/O, we else
would have chosen using linux, plus X-Windows for the GUI if needed, or IBM's
half-OS. What can be new is this and just this: standard OOion in the Kernel
(to me, the Kernel isn't the IO routines; just the class manager, including
executable classes and thus multithreading; all other parts of the OS must be
clear with respect to object managing).


> Anyway, I've talked on a low level here, but I think there a some very
> low-level questions such as these that need to be considered early on,
> just as those high-level design considerations.
>
Both low-level and high-level questions must be thought with the other one
in mind. For now, we can define general low-level directives, but we mustn't
start implementing a function without having defined its high-level
features and access.

> Thanks,
> Ross Hayden
> haydedr@wkuvx1.bitnet



Then Gary D. Duzan <duzan@udel.edu> writes (quoting me):

> [...]
>> DOS is directly programmed with 8088 assmebly language; Unix is programmed
>> with C; MacOS is OO styled programmed with Pascal. In every case, the system
>> and the language are thought together, and each adapted to the other.
>>  It will be the same with MOOSE. Whatever language you choose to program
>> with (I mean high-level stuff, not the Kernel, which is bound to be mainly
>> done in assembly), it with shape your system. If you don't choose any
>> language, the default will be assembly, and you'll be as unportable and
>> unimprovable as DOS. If you choose C, you won't do better than U*ix. Perhaps
>> C++ can do better, but it inherits much from C low-level philosophy, and
>> won't give you a clean high-level OO system.
> 
>    True, but what can we do? If we can get a compiler for a good
> object-oriented language that will compile on a number of different
> machine, that would be great, but not, I think, too likely. I suppose
> we could try to get a number of language/compiler design people to whip
> up a language and GCC front-end for us to use if we really wanted to,
> or maybe use an existing language and develop a GCC front-end for it. I
> hate to say it, but C++ looks like the way to go for now. As long as we
> specify the interfaces and abide by them, we should be able to make it
> language-independant. It might be a good idea to develop a Smalltalk
> interface in parallel.

What I propose is making a front end, and have the produced intermediate code
unoptimizedly compiled, or interpreted, or sent to GCC (if we find out how to
do it), or to make a compiler from our high-level language to C (the compiler
will include itself calls to the kernel for multithreading). What would be great
for a later version is that intermediate code be standard itself, so that
recompile of portable applications is quicker and safer, and that the Kernel is
more language independent (even if their is a currently privileged high-level
language); moreover, having a new language will only demand a new front end; and
separate teams can work over front and back ends, meeting only to enhance
intermediate code. Intermediate code must then be a virtual standard, with for
only upward compatibility requirement that an earlier version be compiled to a
later in a time proportional to the size.


Now, Gary quotes Dennis' first specs
>>      As applications grow more and more complex, software designers
>> argue that they require additional resources to support their
>> needs.  Most graphical user interfaces, for example, are quite
>> complicated and require considerable effort on the part of the
>> application programmer to develop software for.  In many ways
>> modern applications do require more resources, but these could be
>> reused and shared among similar applications, significantly
>> reducing the total overhead involved.
>
>   This brings up the question of the general user interface. Do we
> support a character-mode interface? I believe that a GUI (graphical
> shell) should present object methods to the user, so if we do implement
> a character-mode shell, it should have a syntax to reflect the object
> method invocation semantics.
 I believe much of the work can be done in generic text or graphic windozes.
Text is still useful: quick, and available on old terminals.

>    As for the graphics primitives, we should probably start from those
> provided by existing graphics accelerator hardware as a minimal set.
> The video driver should provide these services and advertise any
> additional ones that it can do fast.  However, any objects that use the
> additional services should be ready to ignore or emulate (from the
> minimal set) them in case the video driver doesn't provide them.
No ! The video driver should emulate itself what the hardware does not include;
else what would a video driver be for ?

>>                                          The kernel will be divided
>> into the following logical sections: 
>> 
>>           General Memory Management
>>           Shared Memory Management
>>           Device Memory Management
>>           Memory Transfer (DMA)
>>           System Clock
>>           Object Method Invocation/Interprocess Communication
Hey ! Where did you put the OO Management !? and the multithreading stuff !?
It isn't a small accessory device; it's the central point of what should be
new and great in the OS !

>> F. Data Link Devices
>> G. Network Devices
>> H. Transport and Session Devices
>
>   Do we want to provide intra-machine drivers for these? Should
> they be a standard IPC mechanism?
Of course there should be ! We must have a high-level protocol for IPC;
up to the kernel makers to implement it on each machine.

>   So what language do we write the high-level stuff in? Should it
> matter? Can we make it not matter?
 The greater part of the OS is written in high-level language, the more portable
the OS will be. So we must choose such a language, and choose it well.
 The easiest solution is C++, but C++ is too low-level; so it's ok for Kernel
stuff but it won't fit for really high-level programming the OS.



	 ,
      Fare

(soon to come my high-level specs)