MOOSE

[ANDREASA@dhhalden.no]

Project name..., well I'm quite satisfied with MOOSE at the moment, and I
don't think it is very important to find another name for it at the
moment. That is not, should I say, the crucial part of the development.
Let's be creative, a new name isn't.

I suppose most of you have read the rev. -72 a couple of times by now.

About the language question; Not! I say, it isn't a question. There is no
need for a new language, tell me what reasons there are to build one.
Are there no languages that can fill our needs?
I did some testing the either day. I wrote some asm. code to do a specific
task, then I did the same thing with some C code. I used Borland C(++) and
compiled via assembler. Guess if I was supprised Borland generated better
assembler than me. I have heard rumors that compilers generated better code
than assembler programmers, but I never belived it could be true. In
addition the compiler made use of 386 specific commands in a way I had never
thought of. I'm no assembler guru, have never been, and will probably never
become, but that my code were so much larger....
Listen to what I say, don't overestimate ourselfes. The borland compiler
has had a couple of years on it's neck now, and it doesn't generate the
fastest code either, but anyway it outcoded my code. (I havn't done any
asm.programming for over a year now so...)
Let us use a compiler that has _few_ bugs(!!!), that generates clever code,
and has support for the 386. If you still belive that you are coding much
better than a compiler, compile via assembler, and fix the few unclever
code-parts that has been generated.
That is my advise.


About part D. of the rev. -72, "Design principles".
The OS should, in addition to what Dennis mentions, keep track of the
resources used by any application, so that the system will be able
to unload the resources that are left after an application crash, and thereby
save resources and make the system more fool proof.


About part  II, the Kernel - A. General Memory Management
Dennis mentions something about compiler dependance and memory allocation.
If some of you have been programming Windows, you are familiar with .def
files, definition files. Each program source code has got one of these.
They tells the windows shell what code parts that should be swapped to
disk first.
Imagine a dialog with the user. The user goes through this dialog one or
two times in a month, then there are no need for this code to reside in
memory at all, until the user requests it. Now, an OS could use several
algorithms to make sure that this code part will be put onto disk pretty
fast. Now algorithms are a good thing, but they don't know a thing about
the world, or the program at all, do they. No, but the programmer(s) knows
everything about the use of the program that is worth knowing, doesn't he.
Right. Instead of making smart-dumb algorithms who finds out what code
parts should be unloaded, the programmer marks the code blocks with
priority levels. These levels then makes the desicion data for the unloading
algorithm. After all, the programmer knows best, doesn't he... :->


Have a nice day everyone.

Arff

sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@sofus.dhhalden.no--