Of modules and commands...

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

Does anyone have any predefined ideas on what we should do
with loadable modules and external libraries (possibly in a
foreign language such as C)?

The existing ETH compilers appear to use a mechanism whereby
a "command" could exist either in an Oberon-2 module or it
could also come from an external library which is loaded by
the OS.  I know there was some discussion about this earlier
and maybe we could formalize this stuff a bit.

I see that the front-end compiler would have to provide some
support to facilitate module loading.  There would have to be
an explicit call to load a Module along with some parameters
such as the SB definition (for garbage collection), pointer
locations, a command list, an import list (to help when
unloading a module), etc.  Of course, the back-end would know
most of this information so the front-end would probably have
to call a back-end procedure which inserts this code at the
head of the module initialization.  Of course, the module
will also have to have a reference count so we would know
when it can be unloaded and an initialized flag which is set
when the module initialization code has been executed.  I
assume the garbage collector would have some finalization
registered for each module object so that the module can
be unloaded and its state could be saved? once it is no longer 
used.

In order to execute a command, we will have to store a list
of commands in the module header together with some sort of
jump table which can be indexed to execute a particular command.

It would be nice to be able to have command arguments like
Oberon/F but that might require some work (ie., a parser would
have to extract arguments, look up values in some sort of
symbol table, and pass them as parameters; maybe constant
parameters wouldn't be so bad).

One other thought about type descriptors: we will also have to
explicitly load any type descriptors for a module in the
initialization code for that module and assign pointers to
those descriptors to static module variables.  The main
reason for having dynamic descriptors (from discussions in
the Oberon system) is to allow a module to be unloaded even
if another module still references a type supplied by that
module.  (Of course there are still problems if trying to
call a type-bound procedure defined in that module or if a
global procedure variable is used which was initialized 
from the unloaded module).

A last concern is about the father/mother (main) module which
gets loaded first.  I'm assuming that this would be the "main"
executable which would be linked together with the loader. Only
the main module and the loader would need to be present in this
executable image -- all other modules would be loaded as required
most likely by the initialization code of the main module.

I'm a bit unclear about how multiple main modules could be loaded
and share loaded modules except possibly through having an OS-defined
library concept supported.  That would mean that each compiled
Oberon-2 module is a library to itself which can be loaded into
the operating system and then becomes available for use by any
main modules.  I'm assuming this is what Sander had in mind
when he wrote about this in another thread.  There still exists
a problem, I think, since libraries typically don't contain any
global data (at least I don't think they do).  So how are the
type-descriptors and commands set up for a library?  Maybe one
procedure in the library could be used to initialize a heap-based
Module/library descriptor which contains the required information.
I'm not sure where this descriptor would be anchored though.

Anyway, enough rambling.  Comments on the above are welcome.

Michael G.