Re: Current state of the `ooc' project?

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

> Mike wrote:
> > That should get me to the point where I have a working Oberon-2 compiler
> > on the BeBox.  The next stages will then be to add this back-end to OOC.
> > I'm still kind of waiting as well for someone else to develop an interface
> > between the GSA tree and a typical code generator.
> 
> Is the ETH Oberon-2 compiler OP2 based? If yes, you surely cannot
> reuse its PPC back-end for OOC, as they are based on different
> abstraction levels. OP2's internal structure reflects most of the
> Oberon-2 constructs while OOC is nearly assembler.

Well, I can reuse parts of the low-level back-end which are at the heart
of generating the code.  I obviously won't be using the while, repeat,
and other structures which call the low-level back-end routines.  As a
start, I also won't be doing any fancy register allocations -- just using
the default ETH stuff where registers are allocated as needed during
code generation.  The code sequencing will also be very simple in the
initial compiler -- just using what ETH has done for now.

The main reasons for simplying these things is that they probably won't
give that much extra performance for the amount of effort we put into
them.  The chief benefit to the optimizing compiler will be the higher-
level optimizations which eliminate dead code, recognize common sub-
expressions, hoist code out of loops, and do in-lining.  Some back-end
optimizations will also be useful, especially the peep-hole optimizing
which I will implement for the first OOC back-end.

Of course, I'm leaving open the possibility of doing these things once
the OOC code generator is working on the BeBox.  Probably the most useful
of these will be a general-purpose instruction scheduler which can be
tailored for different PPC machines.

>   The main task for an OP2 back-end is to translate Oberon-2
> statements to machine code patterns, for an OOC back-end to map GSA
> data and control flow onto machine level data and control flow.

You're right.  I would be able to reuse all the stuff at the point
where the actual code patterns are generated.  All the Oberon-2
statement translation stuff will be useless.  Trust me, having even
this amount of reusability will make the back-end MUCH easier to
do (ie., I won't have to determine the best code patterns to add,
multiply, subtract, etc. since ETH has already done this).

>   Btw, what exactly is a `typical code generator'? A `typical code
> generator' for OOC should be one which translates GSA to machine
> code...

Right again.  Once any code generator (even the ANSI-C interface) has
been written, it will be much easier to adopt this generator to any
of the code generators.  Essentially, we could even make a generic
interface which calls routines like "add", "sub", etc. all of which
can be replaced with code for a specific code generator.  It is at
this level that the above ETH compiler code generator is reusable.
 
>   Juergen

Michael G.