ooc-960612

[acken@informatik.uni-kl.de]

Hi all.

Cognac is up again, and I've placed a copy of the current ooc sources
there.  This time the patches are quite large: 119K (norcs) and 133K
(rcs).  

This update fixes some inconsistencies in Opcode.Mod and also some
bugs.  Here is a list of the most significant changes, for a detailed
list see the ChangeLog below:

o new instructions access-local and update-local; they are used when
  accessing resp. updating a local _structured_ variable; see file
  frontend/doc/AccessLocal for an explanation why these instructions
  are necessary 
o results of call instructions that reflect the modification of a
  variable parameter get a location based on the actual parameter, 
  not the formal one
o access/update-nonlocal takes the variable's address as second
  parameter; the same holds for `zero'
o under certain conditions the value of $mem is added as parameter to
  trap-xxx instructions; otherwise a code sequence like 
    "Out.String("X"); HALT(1)" 
  might produce no output, since the side-effects of Out.String aren't
  used later on and the output is discarded as dead code 



oo2c
----

There has been significant progress on the ANSI-C back-end, although
major parts are still missing and some parts are very preliminary
(like the allocator).  I managed to get the basic o2c libs compiled,
although I haven't tested them in depth.  The largest program compiled
and run(!) successfully is the simple regular expression matcher
backend/ansi-c/Test/RegExpr.Mod (the RegExpr module itself is buggy,
but this is another topic).  Since this module has lots of arrays,
record, recursion, and nested procedures I consider this to be a major
success.  

Now I'll start adding the missing parts to oo2c: module and type
descriptors, NEW and friends, type test stuff, and type-bound
procedures.  Finally I'll replace the stupid allocator with one that
uses hierarchical graph coloring.

I can't possibly say when oo2c is matured so far that it can serve as
a drop-in replacement for o2c.  While the general layout of the
back-end stands, lots of simple things still have to be added.  If all
holes are patched, then running a huge program (e.g. o2c or ood/oo2c)
through the compiler will undoubtly uncover lots of errors, both in
the oo2c back-end and the common front-end :-(.  

So far my experience with translating GSA to an assembler-like
language like C is, that most of the translation is actually quite
simple.  The general layout of the code generation looks like this:

input: optimized GSA code in form of a greg.
1. Low-level optimizations
2. Classification of GSA instructions (do they create output? in which 
   register class do they deposit their results?)
3. Instruction scheduling
4. Register allocation (the C back-end emulates an infinite set of
   registers with local variables) 
5. Generate target code
6. Restoration of the parts of the GSA code that are needed by the
   front-end, but were destroyed by the previous steps
For details take a look at 
  backend/ansi-c/CodeGen.Mod, procedure TranslateGreg. 

Most GSA instructions can be trivially translated to assembler/C.
Only the places where GSA code corresponds to load or store
instructions (in the target code) are not that simple.  It can be
done, though ;-).

-- mva