Related articles |
---|
Translating *to* Lisp? xenophon@irtnog.org (Matthew Economou) (1999-10-27) |
Re: Translating *to* Lisp? max@gac.edu (Max Hailperin) (1999-10-28) |
Re: Translating *to* Lisp? tkb@access.mountain.net (1999-10-28) |
Re: Translating *to* Lisp? ppaatt@aol.com (1999-10-31) |
Re: Translating *to* Lisp? rsalz@shore.net (1999-10-31) |
Re: Translating *to* Lisp? xenophon@irtnog.org (Matthew Economou) (1999-11-02) |
Re: Translating *to* Lisp? samir@mindspring.com (Samir Barjoud) (1999-11-02) |
Re: Translating *to* Lisp? notbob@tessellation.com (1999-11-09) |
Re: Translating *to* Lisp? kst@cts.com (Keith Thompson) (1999-11-16) |
From: | Samir Barjoud <samir@mindspring.com> |
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 <xenophon@irtnog.org> writes:
> >>>>> "RS" == Rich Salz <rsalz@shore.net> 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
remainder:
- `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.
http://x44.deja.com/getdoc.xp?AN=472255245&CONTEXT=941551529.1788018711&hitnum=0
: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"}.
http://x44.deja.com/getdoc.xp?AN=518491046.5&CONTEXT=941551529.1788018711&hitnum=4
: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
samir@mindspring.com
Return to the
comp.compilers page.
Search the
comp.compilers archives again.