A possible new port

[Brian Hawley <bhawley@luc.edu>]

Hi all!

I've been talking (OK, typing) to Pieter Muller, the creator of Native Oberon
(a native port of System 3 2.0 to the i386+) about OOC. He would like me to
port OOC to Native Oberon. Native uses OP2 as its compiler now (as of the 
next beta release). I would like to do this port, but I have a few questions
that I need to ask you first.

Can OOC output OP2-style .Sym files, or does it encode extra imformation in 
the existing .Sym's, like inlining or side-effect information? If there is 
extra info, could it be put in a different file or tacked on the end of an
OP2 .Sym or .Obj file?

How far along is the Intel code generator in the Linux port? Some of the code
could be used by both ports. 

Would anyone be interested if I proposed a LIBRARY construct? It would allow
global optimizations to be performed on groups of modules that would be put
together into one .Obj file with one .Sym file. This would be useful for the
Oberon System, where there are no standalone programs, and also for creating
shared libraries on systems that support them, like Unix and Windows.

Does anyone else see the need for a binary GSA intermediate file format? When
we start doing global optimizations memory requirements will go through the
roof. Not everyone has virtual memory, you know. Intermediate files would
also make it possible to pause a computation and restart it later, or do
global optimization on a module-by-module basis. This would allow you to do
really time-intensive optimizations in stages, even as a background task on
systems that support them. I was thinking of that some variant of SDE would
help cut down the space.

Anyone thinking of doing an OMI backend?

Any suggestions would be welcomed!
Brian Hawley
bhawley@luc.edu