Garbage (collection, that is...)
Phil Howard KA9WGN
phil at ux1.cso.uiuc.edu
Tue May 7 08:50:38 AEST 1991
leipold at eplrx7.uucp (Walt Leipold) writes:
>The stack is gc'd by saving the address of a main-program automatic
>variable, and scanning between there and the address of a current auto
>variable for anything that looks like a Scheme pointer. Registers are
>gc'd by calling setjmp() and then examining the register values saved in
>the jmp_buf structure. As a Portability Paranoid(TM), I find this
>frightening, since (for instance) I don't think that C is even required
>to use a stack to store activation records.
Or at least not a stack implemented as a contiguous array.
The C on IBM 370 seems to work just fine using the saveareas that said
architecture commonly uses. Think of saveareas as a stack whose activation
records are chained together doubly-linked. They can be allocated, but
don't have to be.
>I'm pretty sure that gc'ing off the C stack is non-portable practice. Is
>it *good* practice? In how many current implementations are C activation
>records *not* allocated contiguously on a stack? Should I look elsewhere
>for a Scheme interpreter? (Or am I worrying too much?)
What about systems that can detect a stack overflow and recover by creating
an extension that is non-contiguous (with all the appropriate stuff put in
to make sure you get back when existing).
--
/***************************************************************************\
/ Phil Howard -- KA9WGN -- phil at ux1.cso.uiuc.edu | Guns don't aim guns at \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! /
\***************************************************************************/
More information about the Comp.lang.c
mailing list