MOOSE

[Gary D. Duzan]

=>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?

   Perhaps. C or Assembly will certainly do for the kernel itself, but
if we are going to have an object-oriented system, then it would be
nice to have an object-oriented language to implement higher-level
objects and applications. We would need something free, fast, and
portable. GCC 2.3.3 (C, C++, Objective C) meets these requirements, but
C++ isn't that pretty. Does anyone have experience with Objective C? I
would certainly advise against building a language from scratch.
However, if we have the resources, it might make sense to develop a GCC
front-end for an existing object-oriented language in parallel with the
kernel development.

=>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....

   Yep, that's what computers are good for: tedious, boring, tasks that
follow a lot of strict rules. With modern processors, there are more
things to worry about when generating assembly, including things like
instruction ordering and filling branch delay slots. GCC 2.3.3 even has
an option to generate code optimized for a 486 that still runs on a 386.
And when you really do need to access specific instructions, you can
always imbed assembly code in the C.

=>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.

   I tend to agree, but Dennis seems to an assembly-masochist. :-)

=>About part  II, the Kernel - A. General Memory Management

   There are other ways of taking care of this problem. In a virtual
system, one option is to swap in code as needed. Sections of code
that are always used (referred to as the 'Working Set') can be loaded
first. The trick is creating the mechanism to specify the working set.
After the program is done with a section of code, it will eventually
be flushed by an LRU page replacement algorithm.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts