Re: ooc-960125 & misc

[Guy Laden <laden@math.tau.ac.il>]

hi,

> 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.
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? 

> 2) Provide a framework for translation per function (for fast
> translation and low memory impact), per module, or per program (for
> global optimizations).  To achieve this I'll have to change the way
> the parser interacts with the driver.  The current `demonstration'
> compiler driver oo2c works only on a single module.  oo2c will look
> very different when I'm done.

Perhaps this is a good opportunity to split the backends from a
common 'driver'. A related issue is cross-compilation.

> 3) Start working on external C interfaces.  I want to all the system
> flags that are necessary to interface to an arbitrary C library.  C is
> the most popular language around with the highest existing code base,
> so providing easy access to existing code is a most.  The C interface
> will also serve as an example for the implementation of system flags
> (resp. modifiers).  Finally this is also a step in the direction of an
> ANSI-C back-end.

Is there any frontend support for procedure inlining?
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.


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.
Just a crazy  thought... ;-)

Regards,
Guy.