various subjects [far35]

[Francois-Rene Rideau]

- Blocking/Async IPC:
Why battle about it ? After all Intel x86 and most CPU instruction sets
provide sync IPC and nothing else (usually CALL, INT, TRAP, JSR or such
instruction). That's why the kernel's job usually is building async IPC
from sync instruction set. Sync communication can be done without the
kernel, using standard servers to connect (=process managin device,
memory managing device for sharing memory)
 Now, the system should porvide both synchronous an d asynchronous IPC
as standard, and building one from the other also should be included in
a standard system (meta-)library, so that synchronousness of IPC be
independent from the kernel.

- I've read the QNX papers: well, MicroKernel seems ok, but the question
is where to put object management in such a system. Moreover, we decided
to have dictionaries (name server) local to objects, etc.

Answer is not to put it in the innermost kernel (the "nucleus" as it was
called)
- MicroKernel: message passing between processes.
- Link: library to link any object with any other. Link understands
meta-typing through add-on libraries, and manages translation of
physical types inside indentical meta-types. This translation is done
according to relative trust between objects: an object can trust
another, thus doing less checking and allowing quicker transfer; it can
even allow direct addressing of its address space to another if it
really trust it, etc. Thus the Link module can handle functions as
parameters (what we want, don't we, Andreas ?), and when the function
is executed, it has more or less acess rights over the caller's address
space, according to the caller's confidence.
 The types of links are:
. existence link: forces the system to have the linked object handy
(the presence of a file in a directory is thus considered as an
existence link from the directory to the file).
. connection: the objects now send data each to the other through the
kernel.
For example, when you want to use some library, first build an existence
link to it, then connect to it each time you use it. This use can involve
a sub-connection, etc (but it is a finite process).
In our system, an existence link IS a connection to the object's class.
Or perhaps a connection is an existence link to an object's instance.

Link is an important part of the system, if not the most important part
of it. It is NOT in the nucleus, but it IS in the standard base system.
Link itself should be modular and include a Link kernel, etc.

- Gary, where can we find papers on Ellie ? on Sather ?

- Soon, my next posts about HLL, LLL and MOOSE Bases. Perhaps Dennis
should maintain a list of our naming conventions (=Kernel, Nucleus,
dictionaries, and so on).

- About HLL, my motto is genericity. The HLL we choose must include
maximal support of genericity. This includes grouping objects by
metaclasses i.e. interface, and not inheritance, and accepting types as
parameters and any other object. Types can also be understood as
restrictions upon objects. To illustrate that, I wrote some
generic module in Pascal (more readable than C, as powerful when you
don't use defines and type casting). Well, Pascal is truly horrible
for that, and well shows the limits of C-like languages.
Unfortunately, these modules were in french, so that I must translate
before I publish it (it was a Power 4 game, using a generic module for
games between two players, and another generic module for minimax
algorithm). The modules also showed that some optimizations that had
to be done manually would have to be included in the compiler (i.e.,
eliminating local variables in a recursive function by using global
ones and saving minor changes of the global variable in the stack), and
that memory management would be done if the language did accept multiple
memory zones (in that case, another stack for some kind of data), that
the optimizer could possibly join into the program's main stack (in a
mono-process version), etc.

- So what about that talk or irc around the net ? Mailing is too slow
for this project.

--
      ,						,           _      ~  ^
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
					'		    / .