Re: Current state of the `ooc' project?

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

On Mar 22 Juergen wrote:

Sorry for the late reply, I've been taking a break and it sort of
stretched.

> As Michael van Acken sent a TODO list, I'm very much interested in
> what is already done or will be done in the near future.
[...]

> But now for you. As the frontend is there and considered `working',
> I'm very much interested if someone has got some experience in trying
> to write a backend for the GSA code. I myself have no idea how the GSA
> code could be translated to object files (machine language) for a
> specific processor.

All I have had time to do so far is get the frontend working on the Amiga,
compiled by Oberon-A. This is now much improved, and changes I've made to
the Oberon-A run-time system make memory management *much* faster. I can
now do a --make --all that completes in a reasonable time on my fairly slow
system, and which only uses a bit over 1M of heap for the symbol tables.

The next stage for me will be to determine how the GSA code maps to M68k
assembly code, and implement a backend pass to make any necessary
substitutions. The main issue that I can think of at the moment is
converting the three-address GSA code into two-address M68k code.

After that, or perhaps tied in with it, will be implementing a register
allocator. I've got a copy of Preston Briggs' thesis, which seems to be a
pretty definitive explanation of most of the issues involved, and I've also
got the paper by Koblenz(?) mentioned in Brandis' thesis. So far as I can
see, it should be possible to write a register allocator in the same
frontend/backend style used by the compiler itself.

The last bit would be the actual code generator, which should be the
easist. I will probably use a version of WriteGSA initially, that will
write M68K assembly with the corresponding GSA code as comments.

Frank