Re: A possible new port

[acken@informatik.uni-kl.de]

>  From: Frank Copeland <fjc@wossname.apana.org.au>
>  Date: Mon, 5 Feb 96 18:13:50 +1000
>  
>  > The symbol file format is described in ooc/frontend/doc/SymbolFile.ebnf.
>  > ...
>  
>  If the only difference is the IDs, then I would prefer it if they were
>  compatible with OP2. If there is some compelling reason to change them then
>  that is fair enough.

I simplified matters a bit.  No, it's not just the IDs.  I don't know
the OP2 stuff, but I'm pretty sure that changing OOC symbol files into
OP2 would need a major rework of the make stuff and it would prevent
me to put useful additions (like explicit side-effect info, GSA code
for cross module inlining, or a sym file extension mechanism) into the
syms.

>  I'm a bit concerned about the memory issue myself, since I haven't been
>  able to get a VM manager to work on my system. If the RAM requirements get
>  too high it will seriously restrict my potential user base. 2 Meg is quite
>  common on Amigas, and 6 Meg like I have is getting into 'power-user'
>  territory.

I've almost finished the framework for compilation per procedure.  I
can't make any measurements about the memory usage since I have only
the C based conservative gc (which is quite a memory hog itself).  But
even with this gc I need less than half the mem to compile the largest
OOC module.  A decent gc will reduce this number even further.  I hope
to get the new driver / parser interface on cognac by the end of this
week. 

>  One solution that suggests itself is to pair OOC with an OP2-derived
>  compiler. The OP2 compiler could be used for rapid development, and on
>  low-memory systems, while OOC would be used for producing heavily optimised
>  code on systems with sufficient memory to support it. In this scenario it
>  would be a big help if the compilers produced compatible symbol files.

This is bound to fail as soon as you start interfacing with non-Oberon
libraries.  The interface information varies from system to system,
and the two compilers will expect different information from those
interface.  OOC, for example, will need side-effect information in
order to push efficiency of external calls to the limit.  I do hope
that there'll be never a need to have a rapid development compiler
around.  OOC won't be as fast as a single-pass compiler, but it's
compilation speed should never be unbearable.  It's always possible to
identify the slow parts by running profiles and to disable them by a
"speed" option if the need arises.  There not that many possiblities
to reduce memory usage.  I hope that the changed translation process
will fix this problem.

-- mva