Re: Current state of the `ooc' project?

[Mike Griebling <grieblm@trt.allied.com>]

On March 23, Guy wrote (in part):

> In principle, we expect all modules to be compiled into ELF
> shared-libs (without GAS). A single generic startup executable will be
> used to run programs.  It will accept either a 'command' ala Oberon system or
> a module name whose body will be used as a 'main'.
> One shared lib will need to contain the Run-Time library.
> Provisions will be made for producing standard (monolithic)
> executables as well.

hmmm, this sounds much like what Frank is planning.  Does this require
a background process to hang around in order to manage the modules and
execute any user commands?  Since a number of us will probably want to
do something similar, would it be reasonable to try to make this 'command'/
module manager something which is more-or-less portable to other OSes?

> btw:
> Have any backend writers considered whether any new cpu-specific
> insructions will be added to the GSA as it is refined into machine code?
> At the moment it looks to me like this will have to be done.
> Does anyone have comments on this?

The only instructions I can think of relate to the Sqrt() operation we
discussed earlier.  I've also been thinking about the GETREG, PUTREG
SYSTEM functions.  These functions are of legitimate use when accessing
low-level OS features such as TRAPs and when writing debugger interfaces
which have to pull registers off a stack, yet the current GSA cannot 
represent these operations -- as well, the garbage collector will have
to check the contents of registers for pointers.

What other additions do you see happening?  I haven't looked at the
translation of GSA yet so maybe you are seeing something which should
be incorporated into the GSA.

> Guy

Michael G.