ooc-960125 & misc

[acken@informatik.uni-kl.de]

Hi.

Yesterdays update was put together in a hurry, and my last minute
bugfix turned to be a bad mistake.  It fixed the translation of
Juergen's tiny test program, but broke almost everything else.  So
here's another update to fix my last bugfix ;-).  It's at the usual
place.


And now something completely different.  The front-end and the GSA
code it emits are fairly stable now, and I don't have any plans to
change the generation of intermediate code.  On the other hand, there
are some things I'd like to improve resp. add in the next 4-6 weeks:

1) Brush up module UndefVar.  It has a severe flaw and it's algorithms
are somewhat chaotic.  I intend to change this.

2) Provide a framework for translation per function (for fast
translation and low memory impact), per module, or per program (for
global optimizations).  To achieve this I'll have to change the way
the parser interacts with the driver.  The current `demonstration'
compiler driver oo2c works only on a single module.  oo2c will look
very different when I'm done.

3) Start working on external C interfaces.  I want to all the system
flags that are necessary to interface to an arbitrary C library.  C is
the most popular language around with the highest existing code base,
so providing easy access to existing code is a most.  The C interface
will also serve as an example for the implementation of system flags
(resp. modifiers).  Finally this is also a step in the direction of an
ANSI-C back-end.

4) Work out a way for moving ooc to 64 bit architectures.  Processor
architectures with 64 bit address space start to appear on the market.
It's not a bad idea to plan ahead for these CPUs.  The problems arise
from Oberon's identification of address values with LONGINT.  I intend
to sketch out a possible porting path, and to prepare the front-end
for this as far as possible (there isn't much I can do, though).

For the not so near future I'm planning to put together a quick-and-
dirty ANSI-C back-end.  It will emit horrible code, directly mapping
GSA to C, but it will allow to test the code generated by the
front-end.  I don't think it's fair to leave the debugging of the
entire front-end to the unfortunate person who comes up with the very
first working native code back-end ;-).  Given time, this q&d back-end
will mature to a more sophisticated version, generating code of
adequate quality (but it will never emit readable code).  Making the C
detour will always make compilation slow, and the resulting executable
will always be slower than what a decent native code back-end could
achieve.  But it will also ensure ooc an incredible availability, even
larger than o2c's.  Availability means lots of potential users.  My
silent hope is that some people out there may come to like the
compiler and see the light of Oberon.  And maybe, just maybe, start
thinking about writing a native code back-end...


I'm sorry that I can't help with the development of the core library
(beyond writing longish mails with lists of unfinished suggestions),
but the above points have priority.  Most of all because I'm in the
best position to implement them.  I hope I find the time to actually
get them done within the next few weeks.

-- mva