Re: ooc-960125 & misc

[acken@informatik.uni-kl.de]

>  From: Guy Laden <laden@math.tau.ac.il>
>  Date: Fri, 26 Jan 1996 00:53:08 +0200 (GMT+0200)
>  
>  > And now something completely different.  The front-end and the GSA
>  > code it emits are fairly stable now, and I don't have any plans to
>  > change the generation of intermediate code.  
>  
>  Have you considered doing the kind of analysis mentioned in
>  the GPM paper 'Type Test Elimination using Typeflow Analysis'?
>  I'm not sure if this optimization can be done on the GSA level
>  or would have to be incorporated into the frontend.

I scanned the paper briefly.  It's possible to implement such a
typeflow analysis.  The front-end emits enough information to do it in
a seperate phase.  Similar to constant propagation, this phase can
also generate error messages if it detects code that can be proven to
fail.  It doesn't have to be part of the front-end.  Will you
implement this optimization?  Please...

>  Its a nice analysis to have because of the added compile-time error
>  checking, though I'm not sure how useful it'd prove to be in practice.
>  If we optimize Type-Tests, perhaps the WITH statement can
>  be implemented more cleanly and we could avoid the pitfall mentioned in
>  the Oakwood Guidelines: The frontend can simply translate WITH statement
>  into type-guards (conceptually this is similar to the way RETURN and EXIT's
>  are handled). I havent looked at the code- how is WITH handled
>  at the moment? 

A WITH is translated like an IF-ELSIF-ELSE sequence, the type guards
provide the code for the IF guards.  There isn't much room to change
the WITH statement without violating the `standard' semantics of the
ETH compilers.
  I _can_ track modifications of guarded variables (I hope this bold
statement won't backfire on me :-), and I'll add a warning if the
guarded variable is modified by a call to a nested procedure.  I'm not
in favor of adding an implicit type guard.

>  
>  > 2) Provide a framework for translation per function (for fast
>  > ...
>  Perhaps this is a good opportunity to split the backends from a
>  common 'driver'. A related issue is cross-compilation.
>  

A common driver isn't such a good idea.  On different platforms you'll
have different command line options and optimization phases (including
back-end specific ones).  It's probably easier to let each back-end
have it's own main module, instead of forcing all back-ends into a
single one.  Although I'd like all back-ends to share a common `look
and feel' as far as possible.
  Cross-compilation isn't much of a problem.  You can, e.g., build the
Amiga compiler on a SUN and use it to produce Amiga code.  You only
have to make sure that the Amiga compiler sees the correct (Amiga)
library modules and doesn't overwrite any SUN code.  Of course this
only works if all system dependencies are hidden by standard lib
modules and no system specific modules are needed to build a foreign
compiler.

>  > 3) Start working on external C interfaces.  I want to all the system
>  ...
>  Is there any frontend support for procedure inlining?

The fe provides enough information for procedure inlining, the
inlining itself happens in a seperate opt phase.

>  Another useful feature at least for some types of programming
>  is 'machine-code procedures' - ie: the procedure has no body, just
>  a string of hex values which are passed directly into the executable.

I intend to provide a hook for the back-end to do such things.
Basically the parsing of `special' procedure bodies will be left to 
the back-end, allowing any form of code definitions.

>  
>  On another issue- since the ooc frontend generates portable GSA,
>  could this be used as the basis for platform independant 'executables'?
>  I gather that the generated GSA is quite big so from that point of view its
>  probably not as good as SDE.

I read the SDE paper some time ago, and I wasn't thrilled.  I don't
think it makes much sense to put the back-end into the module loader.
And since it takes just a second or two to built the intermediate code
that is used for the object files, I don't see much reason to add the
load/store overhead for the ic instead of building native code on the
spot.  
  If you want to store GSA into a file, read it again, and then start
translating, then you're taking a rather long detour.  In short: It's
possible, although I can't say how large the GSA-based `object' files
would become.

--mva