Tyson Richard DOWD
trd at hydra.cs.mu.oz.au
Wed Apr 30 13:35:06 AEST 1997
I'm just throwing ideas around here...
The next step in working on the garbage collector is to get the
representation of stack layouts to be generated. At the moment,
this is what I think is required:
For each continuation label (label that can be returned to)
- address of label
- pointer to proc information (see below)
- vector of live data locations (register, stack, etc)
- vector of live data types (type_infos)
For each proc
- possibly string representation of entry label
- address of entry label
- number of stack slots
- determinism (which stack)
- location of succip on stack
- vector of locations of type parameters
(might also need to know where the hp is stored, if it is).
(NB: With just the per proc information, can implement a stack
For each type parameter (in order, 1,2,3...)
- location of type_info for this parameter
So we need to represent
label names == string
label addresses == Code *
determinism == enumeration
type_infos == usual representation
locations == ???
(mostly an encoding of lval, with
some cases missing).
I'm thinking of removing most of the old implementation of this stuff
(using shape numbers and .garb files), and implementing this in a
similar way to the base_type_* files - collect information as code
generation continues, and use this info to generate the data for each
proc (and its continuation labels) after the code is generated (possibly
after each proc is generated).
Any comments at this stage?
Tyson Dowd #
# Sign on refrigerator:
trd at cs.mu.oz.au # Refrigerate after opening.
http://www.cs.mu.oz.au/~trd # - C. J. Owen.
More information about the developers