Processes and Communication

[Francois-Rene Rideau]

(the message I reply to seems not to have been posted to the mailing list, so
if it quoted entirely)
Michael Winnikoff says:
>> 
>> > Why remote or whatever ? That's Microsoft-like name for things: they give
>> > technical names to impress common users, and to show beginner programmers
>> > that a technique much spoken about (because too longly and unjustly left
>> > in the company's previous software) has (at last) been used.
>> 
>> A little unfortunate, however it's a standard name so people kow what you;re
>> talkin g about.
>>
>> > 
>> > >> An invoced method is called a 'thread'.
>> > I think `invoked' should be righter.
>> 
>> I think `righter' should be `more correct' :-)
(oops !)

>> > Hey ! You're interfering with implementation. From external view, the object
>> 
>> Some issues are sufficiently important that you can't abstract 'em.
>> Each process having it's own address space is possible on all MMU equiped
>> systems.
MOOSE should be portable enough to be ported to other architectures than MMU
based, be it older or newer (to be) architectures. Of course, on a non-MMU
computer, you will be forced not to trust code not compiled (or interpreted)
on local host).

>> I am still opposed to having the system based around an interpreter.
>> Sure, it simplifies the solutions to some problems however the efficiency e
>> cost is prohibitive.
I don't think it is prohibitive at all, provided heavy calculus is compiled.
IMHO, you don't need have optimized code to properly run the system: OF COURSE
TIME-CRITICAL ROUTINES MUST BE COMPILED, either system or user routines; but
these can be more easily compiled from low-level code; so we come up with a
LLL standard: the system (and/or the user) chooses when to partly compile or
interpret code. HL routines often gain nothing at compile and may loose
efficiency and genericity, even speed (see my interpreting by RET, more rapid
than any CALL sequence). Whereas interpreting is very cheap in memory,
portable, easy for security, communication, extension. With little redundancy,
LLL programs can be as easily compiled as interpreted, so there's no need to
fear for a specialized code which would fit either compiling or interpretinge
but not both. The interpreter is also a very useful tool for system booting.
Once the system is stable, it's time more to compile. What I mean is we don't
need that much speed NOW.

>> > must cope with its methods. From high level, there are private members
>> > (code or data), but even addressing space should be (IMHO) low-level enough
>> > to be implementation dependant: we must also know that most processors
>> > don't have the same protection scheme as the 386, when they have; so we
>> > should rely on LLL interpreting and compiling to enforce non-interfering
>> > between objects. That means LLL should be `high-level' enough to know
>> > bounded arrays (not like C arrays).
>> > 
>> > >> kernel is reponsible for scheduling objects and providing resources as
>> > >> needed. Each object has a specific protection level which determines
>> > >> how the object's threads may directly modify the system hardware.
>> > To me, the Kernel should only connect objects to resources; the resource
>> > managers provide what they have how they will. Object threads should NOT
>> > modify the hardware anyhow; device drivers are there for that; object
>> > threads should handle neither less nor more than their `local' own members.
>> 
>> Hey -- we're allowing device drivers to be objects -- that should be a  
>> plus :-)
'f course

>> --------------------------------------------------------------------------------
>> Michael Winikoff
>> winikoff@cs.mu.oz.au
>> Computer science honours. University of Melbourne, Australia.
>>