[M3commit] CVS Update: cm3

[Rodney M. Bates]

Jay K wrote:
--snip--

> 
> 
(Tony)>> Hmm. Do we know what Pascal/Ada/D and friends do in this instance?
> 
> 
> Good point. I don't know.
> Could be they let gcc use its regular trampolines.
> Which has advantages and disadvantages. But I don't know.
> (advantages: leaves the work/maintanence to mainline gcc, more interopable with C; disadvantages:
> doesn't work on all platforms, is slower (mprotect on some platforms) and faster (no need
> to check for the marker)).
> But I don't know.
> I'd be in favor of transforming this away in the frontend, or maybe in parse.c.
> It does require more or less dataflow analysis to see which locals/parameters ared used by nested functions,
> which is probably easy to make a safe guess at, but then difficult to make an optimized guess at.
> i.e. you'd end up reserving space for and storing locals/parameters that are then not used.
> 

tree-nested.c in gcc now does this.  There is extensive tree-rewriting as a result.  Local variables
and parameters that are accessed nonlocally (i.e., from within a more deeply-nested procedure) are
collected into a record, which is then placed as a local variable.  It can be accessed by two different
static links, located in different places.  I forget all the details.  I understood it once.

There are a _lot_ of multiple copies of things, duplicate copies of parameters passed by value,
duplicate pointers to things passed by reference, etc.  I think there can even be three copies
of these things.  It all leads to activation record expansion and extra code executed in prologs
and in accessing things.

The apparent reason is that it greatly simplifies the compile-time interaction among nested
procedures, nonlocal access, and inlining.  The generated record of nonlocally-accessed stuff
doesn't have to be known to be located inside any particular activation record, and with
inlining, it may not be.  Or something like that.

Note that this is all about ordinary nonlocal accesses from nested procedures, which use
neither trampolines nor closures.  The latter are only used when creating and using
parameters of procedure type, whose runtime values can sometimes be nested procedures.
This is largely independent of static links, etc.  The trampolines/closures are only a
way of storing static link values in formals of procedure type.  Where the values come from
before they are stored and where they go and how they are used after they are extracted
is independent.

For static links themselves, the runtime model is the same for C and Modula-3 code.

> 
>  - Jay