Re: Current state of the `ooc' project?

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

> > 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?
> 
> On linux at least, this little 'main' is quite simple. Basically,
> it just needs to call Linux system-calls for dynamic loading of
> the module specified on the command-line.
> I dont think it'll be more than perhaps 50 lines.
> Its also pretty much machine specific.
> Unless I am misunderstanding you I dont think theres much to make
> into a portable module. Perhaps for OS's without dynamic loading
> there is more to such a loader.

Maybe I'm misunderstanding what you mean by dynamic loading.  In a typical
scenario, a user types on the command line something like:

    oberon Files.Save somefile.txt

and this would load the Files module if not already loaded and execute
the Save command from that module with the argument somefile.txt.  This
mimics what happens in the Oberon system.  It seems to me that the loader
must have some resident data structure available which tells it which
modules have been loaded and what the commands are for each of the
modules it has available.  This data structure must be permanent so
that the data is persistant across different command invocations.  You're
saying that Linus has all this built into the OS?  I didn't think that
the module concept was known outside Oberon/Modula-2 circles.  Maybe
you could explain how your loading would work with an example.
 
> > 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.
> 
> The 'portable' GSA probably wont ever match a target processor exactly.
> The instruction scheduling and register-allocation would probably require
> a very close match between the intermediate-form they work on and the final
> code.

This was understood from the start.  I think that's why we envisioned a
'peep-hole' optimizer substituting target-level instructions for sequences
of GSA stuff.  (e.g., the PowerPC has a multiply and add instruction so
this peep-hole optimizer would scan the GSA tree for sequences of adds
and multiplies and replace them with the add-multiply instruction).  I
guess this GSA tree pruning operation will have to insert back-end
specific instructions.  

> eg:The 'string-copy', 'zero', 'type-assert', guards/merges  and other
> 'high-level' instructions might have to be changed into processor-specific
> opcodes in order to simplify instruction-scheduling/register-allocation.
> A single-pass over the gsa which emitts object-code might be possible,
> but at the moment I think it'd be simpler to traverse the GSA more
> than once, refining it into machine-code.

If that's the case, there will have to be a GSA-instruction for every
back-end machine instruction.

> For example, one pass to get rid of guards/merges which will insert
> branches(which dont exist in the current GSA). Another to get rid of
> gates (and possibly insert copies). And another to convert all the rest
> of the 'high-level' instructions to (sequences of) machine-code,
> before we go into the register-allocator and instruction scheduler.
> Anyway, I'm not sure about whether all of this is needed, once I start
> working on it I'll know more  - I just thought some of the other 
> backend writers have run into this.

I agree, the guards/merges and other GSA-specific stuff will have to
be replaced with 'real' instructions.  I wonder though whether this
may not be possible while traversing the tree.  In theory, all the
information to process any GSA node is available at the time when
the node is encountered.  Branches may have to back-filled with
offsets, but it should be possible to emit instructions.  I'm going
to attempt to allocate registers while traversing the GSA tree in
a single pass.  The instruction scheduler would also work in parallel
on code which has been emitted into a scheduling buffer prior to finally 
being written to the object file.  In most cases, code sequences are
only going to require registers for holding temporary values and the
'live' scope of most registers will be the current procedure.  Global
registers (from the module scope) would be specially tagged.  Of
course, these variables will only be allowed in registers if they
are internal.  Global data which is readable/writeable outside the
module must be allocated to memory.  I'm still not sure how to handle
the aliasing problem which has been mentioned.  Maybe you have some
more insights.

 
> Guy.
> 

Michael G.