Re: A possible new port

[Frank Copeland <fjc@wossname.apana.org.au>]

On Feb 3 Michael van Acken wrote:

> >  From: Brian Hawley <bhawley@luc.edu>
> >
> > 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.

I treat the Oberon System as just another operating system to target. I'm
planning to have my backend produce objects in both the AmigaOS and ETH
formats so that I can support both dynamic loading and static linking.

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

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.

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

I don't support language extensions in general, and it seems to me that
something like this would require a major change to the Oberon System
itself. Both the compiler and the loader expect one module per
symbol|object file. Under AmigaOS creating a library is as simple as
concatenating several object files and telling the linker to search the
result instead of the individual object files. (Actually there are several
kinds of 'library' constructs in AmigaOS and it can get confusing).

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

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.

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.

> Program based compilation is a great memory hog.  If you take the
[various difficulties deleted...]

I understood there was going to an option to compile one procedure at a
time, and discard the data structure after emitting the code. This would go
a long way towards keeping the memory requirements down.

Frank