pcore is a portable core for OSL.
=====

* It provides a multithreading OO environment.
* It is meant to run at least on Linux and SunOS systems
 (OSes I have access to).

* It uses an external thread package for portable threading.
The choosen package was ethreads, by Elan Feingold.
See the ``thread'' subdirectory.

* MOOSE is meant to be a standalone OS; but running over existing OSes, if much
slower, allows us to skip the writing of the I/O layers. You thus trade
efficiency for ease of writing (for the system developper) and portability
(for the potential user).

Please read the README file in the main MOOSE directory.


pcore structure:
===============
The pcore allocates and initialises shared memory and other system resources,
then forks into 2 processes:
* Process (1) is the one that will do blocking system I/O.
* Process (2) is the one that will do the actual computing.

Process (0): Initialization routines
====================================
Processes (0) and (1) have same pid, but are here logically considered
different and may be physically different with future little changes in the
implementation.
* main.c:	First, we parse the command line.
* parseopts.c:	(this is a generic command line parser used by main)
* pcoreipc.c:	Secondly, we init IPC between the two processes.
* forker.c:	Then we fork into 2 processes.

Process (1): System access
==========================
* system.c:	The main loop.
* fileio.c:	Unix file I/O.
* socket.c:	Socket I/O.

Process (2): Main code
======================
   It runs the main running code.
   Its only system or library calls after initialization will be IPC or signal
handling, with the exception of sending debug messages to stderr.
   While the program is developping, it may contain blocking calls, and
especially input from stdin and output to stdout. But actually, it shouldn't.

* runmain.c:	Initializes the objects, according to information from (0).
* arch.c:	processor-dependent routines.
* llobjects.c:	Gives the format of low-level objects in this implementation.
* runloop.c:	Main loop: Object evaluator.
* threads.c:	Object-level threads.
* schedule.c:	Object-level scheduler.
* memory.c:	The memory manager, including the garbage collector.

Threads:
=======
   EThreads was choosen 'cause it is small, provides preemptive multithreading,
has no assembler code inside (but system dependencies), has many good features,
runs on Linux and SunOS, and has a friendly author.
   What about pthreads ? I couldn't find the docs, or even compile it !
   QuickThreads, with preemption added ? I couldn't get it !
   "lwp" didn't seem to provide preemptive multithreading !

* thread/*:	The EThreads package, by Elan Feingold
		(elan@tasha.cheme.cornell.edu,efeingol@rose.cit.cornell.edu)


External code
=============
   We should allow the run-time linking of externally compiled modules
(under some restrictions ?) (see rtlink.c).
   When we know how to run-time link a.out format, we can produce "C" code
for a function, then popen("gcc") to compile it, for code both portable and
efficient.

* rtlink.c:	run-time linking module.
* GOOSE.c:	loading GOOSE modules.
* aout.c:	linking with a.out modules.
* coff.c:	linking with coff modules.
* elf.c:	linking with elf modules.


System Dependencies/Portability:
===============================
see "includes.h".
* We assumed the system has standard Unix-like features.
* We may have used GNU C extensions.
* We assumed we could use SYSV like IPC.
* We assumed we could get 16 MB of memory.
* We assumed chars were more than 8 bits and longs were 4 chars (process (2)).
* We assumed pointers were the same size as long (process (2)).
* We assumed we could have a BSD-like signal stack (interrupts.c).
* We assumed 64 KB was enough for this stack, and 16 KB enough for others.
* We used the EThreads package, that for now only runs on linux, SunOS, Ultrix.
* We assumed byte order was little-endian or big-endian.


Summary of C Files:
==================
Each "C" file comes with its corresponding .h header; headers also include
includes.h for standard library or system calls, and limits.h for the limits
of the implementation.

