Re: Translating *to* Lisp?

Samir Barjoud <samir@mindspring.com>
2 Nov 1999 12:42:10 -0500

          From comp.compilers

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)
| List of all articles for this month |
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


Post a followup to this message

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