Re: A possible new port

[acken@informatik.uni-kl.de]

>  From: 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.

Sigh.  There is this damned Oberon System again.  OOC hasn't a single
working back-end yet, and already resources are diverted to serve
foreign projects ;-).  I'd prefer to see a working version of OOC
Linux ix86 back-end before anyone starts suggesting to port it.

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

The symbol file format is described in ooc/frontend/doc/SymbolFile.ebnf.
The symbol table data structure is _very_ similar to OP2, but the
object and structure ids will differ.  Inlining and side-effects
are not part of the sf, but this may change in the future.  To answer
the last question: you can use any symbol file format you want, just
replace the file SymbolTable.Mod.

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

I don't support this as a language extension, but I wouldn't mind if
an external tool would implement this.  

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

Program based compilation is a great memory hog.  If you take the
current compiler sources and run them through oo2c without freeing a
single allocated block, you'll end up with a >25MB process.  There is
another problem with intermediate files, though.  We are talking about
a data structure that is essentially a cyclic graph.  While it is
quite easy to dump/restore the whole structure (ie, GSA plus symbol
table plus odds and ends), it is somewhat more difficult to store and
load only parts of it (or even discard parts of it).  While GSA gregs
are selfcontained with respect to GSA instructions, references to the
symbol table (ie, object, structs, and constants) are spread all over
the GSA code.  To dump and restore these wild links is problematic.

>  Anyone thinking of doing an OMI backend?

Don't get carried away... 

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

-- mva