Newsgroups: comp.lang.c
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!ux1.cso.uiuc.edu!phil
From: phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN)
Subject: Re: Garbage (collection, that is...)
Message-ID: <1991May6.225038.8015@ux1.cso.uiuc.edu>
Organization: University of Illinois at Urbana
References: <1991May6.202321.18562@eplrx7.uucp>
Date: Mon, 6 May 1991 22:50:38 GMT
Lines: 30

leipold@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@ux1.cso.uiuc.edu   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/