Re: Translating *to* Lisp?

Samir Barjoud <>
2 Nov 1999 12:42:10 -0500

          From comp.compilers

Related articles
Translating *to* Lisp? (Matthew Economou) (1999-10-27)
Re: Translating *to* Lisp? (Max Hailperin) (1999-10-28)
Re: Translating *to* Lisp? (1999-10-28)
Re: Translating *to* Lisp? (1999-10-31)
Re: Translating *to* Lisp? (1999-10-31)
Re: Translating *to* Lisp? (Matthew Economou) (1999-11-02)
Re: Translating *to* Lisp? (Samir Barjoud) (1999-11-02)
Re: Translating *to* Lisp? (1999-11-09)
Re: Translating *to* Lisp? (Keith Thompson) (1999-11-16)
| List of all articles for this month |

From: Samir Barjoud <>
Newsgroups: comp.compilers
Date: 2 Nov 1999 12:42:10 -0500
Organization: MindSpring Enterprises
References: 99-10-128 99-10-185 99-11-009
Keywords: Lisp, GC

Matthew Economou <> writes:

> >>>>> "RS" == Rich Salz <> writes:
> RS> About 10-12 years ago Leor Zolman (unsure of the spelling) had
> RS> a small softare company that sold an ANSI C compiler for
> RS> Symbolic machines.
> Did he publish anything in regards to the implementation? I'd be
> especially interested in finding out how he managed to handle C's
> interactions (e.g. malloc/free, pointer arithmetic) with the garbage
> collector (which is, IIRC, a copying GC as described by Henry Baker).

From what I gather from Chris Torek's postings, the LISP machine
represents pointers as two-part objects - a regular LISP reference to
an array and an offset within that array.

From my knowledge of LISP I can speculate on the design of the

- `malloc' creates an unspecialized array of the size given and
    returns a C pointer (structure described above) to that array.

- `free' marks the array as invalid. References to the freed array
    through any pointer will signal an error. Garbage collection will
    take care of actually freeing the array.

- `sizeof' any object is 1. The reason for this is that an
    unspecialized array can contain objects of any type.

- Pointer arithmetic is just a matter of incrementing/decrementing the
    offset member of the C pointer structure.

- The movement of objects by a copying GC would not have an effect on
    this implementation of C since the array reference member of the C
    structure would be automatically updated after garbage collection.

Here are the postings by Chris Torek and associated snippets.

:Indeed. If it helps any, I can name a machine where the C compiler
:represented pointers as (if I remember right) a three-valued object. The
:Symbolics Lisp Machine's C compiler made them out as: {"base of array to
:which this pointer points", "index within that array", "maximum legal index"}.

:The Symbolics Lisp Machine, a tagged architecture, does not even have
:conventional numeric pointers; it uses the pair <NIL, 0> (basically a
:nonexistent <object, offset> handle) as a C null pointer.
Samir Barjoud

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.