Subject: Re: Lisp in C.
From: rpw3@rpw3.org (Rob Warnock)
Date: Mon, 16 Apr 2007 02:14:05 -0500
Newsgroups: comp.lang.lisp
Message-ID: <aJ6dndBxTfugv77bnZ2dnUVZ_v-tnZ2d@speakeasy.net>
Wolfram Fenske <int2k@gmx.net> wrote:
+---------------
| The basic idea is to build a linked list of all the parameters and
| local variables of a C function that are GC-able objects, and to save
| the head of that linked list in a global variable that the GC knows
| about.  The global variable, called "caml_local_roots", is initialized
| with NULL.  Each C function that deals with GC-able objects has to
| follow this protocol... [snip]
+---------------

The Wheel of Reinvention rolls around once again!! That's *exactly* how
the precise GC for the "Elk" dialect of Scheme did it in the mid-1990's.
A typical piece of C code:

    /* 
     * (make-iota-vector 5) ==> #(0 1 2 3 4)
     */
    Object
    make_iota_vector(int argc, Object argv[])
    {
	unsigned i, n;
	Object retval;
	GC_Node;

	ASSERT(argc >= 1); /* XXX Need to call "error" */
	n = Get_Exact_Unsigned(argv[0]);

        retval = Make_Vector(n, False);
        /* Now we need to protect "retval" from allocations that might be
         * done by the following series of Make_Unsigned_Long()
         */
        GC_Link(retval);
        for (i = 0; i < n; ++i) {
          /* See p.22 of "Build. Ext. Apps. w/ Elk" for why need this temp */
          Object gc_seq_temp = Make_Unsigned(i);
          VECTOR(retval)->data[i] = gc_seq_temp;
        }
        GC_Unlink;
        return retval;
    }

There were also versions of the macros protecting more than one object
[all args to "GC_Link*" have to be variable names of type Object]:

    GC_Node2 & GC_Link2(var1,var2)
    GC_Node3 & GC_Link3(var1,var2,var3)
    GC_Node4 & GC_Link4(var1,var2,var3,var4)
    ...

The "GC_Unlink" worked regardless of the size of "GC_Node*" in use.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607