Re: Current state of the `ooc' project?

[Guy Laden <laden@math.tau.ac.il>]

I have had to take a break from ooc for the last 2 months or so. 
However I hope to get back to it towards the middle of April.

I think we (the linux team) understand most of what is required
to translate GSA into ELF executables.
My partner Yuval has written and tested some code for generating
ELF executables.

My schedule is:
. write a bare minimum storage allocator for the GSA.
  this consists of:
  .some code to go over the GSA assigning virtual-register numbers
   or stack-space to all storage locations.
   this effectively gets rid of all phi-nodes, (sometimes inserting
   copies)
   i think i now understand how to do this.
  .specifying the interface to the rest of the register allocator,
   but for now only write an implementation that 'spill' everything
   to memory.
  
. use ToplogicalSort to finish a minimal instruction scheduler
  this gets rid of guards/merge instructions.

. generate code for the rest of the GSA instructions (ie: all
  non phi/guard/merge instructions)

. as a start, all code will be generated to GAS.

In principle, we expect all modules to be compiled into ELF
shared-libs (without GAS). A single generic startup executable will be
used to run programs.  It will accept either a 'command' ala Oberon system or
a module name whose body will be used as a 'main'.
One shared lib will need to contain the Run-Time library.
Provisions will be made for producing standard (monolithic)
executables as well.

btw:
Have any backend writers considered whether any new cpu-specific
insructions will be added to the GSA as it is refined into machine code?
At the moment it looks to me like this will have to be done.
Does anyone have comments on this?

Guy