ooc-960207

[acken@informatik.uni-kl.de]

I've uploaded the new sources to cognac.  They include a revised
parser / driver interface that lets the back-end decide on the
granularity of translation.

Frank, could you come up with some numbers regarding the memory usage
of the `translate per proc' scheme?  As I said, the conservative gc
that I use with o2c doesn't allow any precise measurements. 

-- mva


------------------------------------------------------------------------
[This is from backend/ansi-c/doc/oo2c:]

There are three possibilities to handle translation to object code.
The back-end can decide to implement one or all of them.  

--translate proc (default)
  Every procedure is translated as soon as it is parsed.  The GSA code
  is put through the optimizers, converted into object code, and
  then discarded.  This means that not all declarations are known when
  code is generated, and that fixups have to patch references to yet
  undefined objects.  The advantage is (in comparison) low memory
  usage.  

--translate module
  All declarations and code fragments of a module are collected before
  being passed to the optimizers and the code generator.  This means
  that the whole module's data is stored in memory when parsing is
  done, and that memory usage is a function of the module size.  The
  benefit is a that in the code generation phase everything is known
  about the module, which may simplify its task.  But it's unlikely
  that this advantage outweighs the higher memory cost.

--translate program
  The memory hog.  Choosing this setting implies a "make all".  All
  modules that make up the program are parsed and kept in memory.
  Then the optimizers kick in, including global optimizations that
  make use of data that is now available between modules (e.g.   
  nonlocal procedure inlining), and of the knowledge that no
  additional modules will be ever linked to the file (e.g. by using
  the finalized type tree to replace type-bound procedures by direct
  calls).  This setting won't emit any symbol files, and if it
  generates any object files they cannot be linked into other
  programs. 
  Until someone implements a global optimizer, this setting is nothing
  but a complicated way to allocate _lots_ of memory.  It's nice to
  have this as an option to squeeze the last byte out of an finished 
  executable, but it can't be used to during software development, due
  to its huge time and space consumption.  The turn around times
  would be gigantic.  


Implementation outline:
The interface between parser and code generator is somewhat
distributed.  The driver (oo2c), the parser (ParseDecl.Module), and
the code generator (CodeGen) are closely linked.  The module CodeGen
implements the above mentioned translation patterns.

The driver parses the command line and calls ParseDecl.Module, which
in turn depends on three procedures from CodeGen to do the translation.
Except for these three procedures (CreateModule, CompleteProcedure,
and CompleteModule) the back-end can implement the driver / code
generator in any way it wants.  For details see the files
backend/ansi-c/oo2c.Mod and backend/ansi-c/CodeGen.Mod. 


------------------------------------------------------------------------
[ChangeLog Feb 1 upto Feb 7:]

Wed Feb  7 13:39:52 1996  Michael van Acken  <acken@informatik.uni-kl.de>

	* frontend/ParseExpr.Mod (TypeConversion):
	The current value of converted constants wasn't set
	to the new value.

Tue Feb  6 20:23:05 1996  Michael van Acken  <acken@informatik.uni-kl.de>

	* frontend/WriteGSA.Mod:
	Added option to enable assignment hints (--gsa-assign).

	* frontend/Statistics.Mod:
	Extended to count region, instruction, result, and operand objects in
	gregs.

	* frontend/ParseStatm.Mod (AssignToVar):
	Correct nasty bug in propagation of cond gates.
	Setting assignment hints in GSA code is now optional (--gsa-assign).

	(LoopStatement): Initialize $exit with a copy of FALSE instead of
	FALSE itself, otherwise FixupLoopGate will make wrong value
	replacements in nested LOOPs.

	* frontend/ParseDecl.Mod: Adapted to oo2c/CodeGen interface.

	* frontend/Data.Mod:
	Made the `prevXXX' links of all doubly linked lists local.

	* backend/ansi-c/CodeGen.Mod: Initial revision

	* backend/ansi-c/oo2c.Mod: Splitted of module CodeGen.

	* frontend/Data.Mod:
	Marked Region.nextRegion/prevRegion as read-only.  Fixed comment
	regarding Object.level.

Mon Feb  5 12:47:06 1996  Juergen Zimmermann  <jnzimmer@informatik.uni-kl.de>

	* optimizers/Worklist.Mod:
	Made the formerly internal structure `Node' and all procedures dealing
	with it visible for more efficient usage (e.g. iteration) of worklists.

	* optimizers/TopologicalOrder.Mod: Changed dependency scheme.
	All instructions now can determin, which other instructions depend on
	them, so if a instruction is scheduled, only those `depending'
	instruction must be considered as potential new schedulable
	candidates.

Sun Feb  4 14:13:55 1996  Juergen Zimmermann  <jnzimmer@informatik.uni-kl.de>

	* optimizers/TopologicalOrder.Mod:
	Changed `ResolveRegion' to hold a list of all schedulable instructions.
	This way, the `back end' could make a good choice from all of them.