This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Back-end-supported heap-based frame allocations?


Hi,

I have been studying how to develop a Simula front-end to GCC and am
about to wrap up my thoughts in a thesis. My conclusion is that
activation records have to be allocated on the heap, similar to what
is being done in earlier Simula implementations that I know of.

So far I have let the front-end plan the layout of each procedure's
activation record by building a compound data type representing each
activation record as if it was specified as a nested structure of C
"structs" and "unions". When each structure is laid out (layout_type),
its size is used as parameter to the activation record allocation code
which is inserted as part of the corresponding procedure's prologue.
Accesses to local variables are translated into indirect component
references into this allocated structure (pointed to by a global
variable).

In other words, this approach does not try to convince the back-end to
set the stack or frame pointers to point to the heap-allocated
activation record, but instead inserts MODIFY_EXPRs to ensure that all
live temporaries have a reliable copy residing in it.

It seems obvious to me that this is not an ideal cooperation between
the front-end and the back-end - the front-end duplicates the
back-end's functionality of handling activation records, and the
back-end (unaware of the front-end's notion of activation records) may
still put critical information (like caller-saved registers) on the
global stack, risking clobbering and an unbalanced stack due to
coroutine switches (jumps between concurrent procedure activations).

Hence, from the Simula front-end's perspective the back-end lacks (or
I have not discovered it) a mechanism for letting activation records
reside on the heap and having function prologues and epilogues do the
necessary (de)allocations.

I imagine that such functionality may also be convenient for potential
front-ends of other (more influential) languages.

Personally, I lack the time and competence to undertake such a project
at this time, but I would appreciate comments on how easily this could
be integrated into the current back-end implementation, so that I have
some sensible words to put into my thesis' concluding remarks.


-- 
Sincerely,
Knut Aksel Røysland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]