Re: pointer elimination in C (Stavros Macrakis)
Wed, 3 Nov 1993 15:59:42 GMT

          From comp.compilers

Related articles
[5 earlier articles]
Re: pointer elimination in C (1993-10-22)
Re: pointer elimination in C (1993-10-22)
Re: pointer elimination in C (1993-10-28)
Re: pointer elimination in C (1993-10-29)
Re: pointer elimination in C rbe@yrloc.ipsa.reuter.COM (1993-11-01)
Re: pointer elimination in C (1993-11-03)
Re: pointer elimination in C (1993-11-03)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Stavros Macrakis)
Keywords: Lisp, optimize
Organization: OSF Research Institute
References: 93-10-032 93-11-027
Date: Wed, 3 Nov 1993 15:59:42 GMT

Robin Popplestone <> writes:
      |> LISP for example, provides almost nothing but pointers -
      |> typically only short integers and possibly short floats will not
      |> be pointers. (Jim McDonald) writes:
      |> Some objects have non-pointers as data: (Ted Dunning) writes:
      |> All of the objects you mention do exist in memory, but when you
      |> actually write lisp code, the values manipulated are pointers to
      |> these objects. (Jim McDonald) writes:

      It depends on what you mean by "values manipulated".... The
      arguments are assumed to be pointers to floats. (For foo to accept
      the floats directly would require restrictions on all the
      callers...) The result is a pointer at a newly created float, for
      the same reason....

This is solvable. I am not up on current Lisp compilation techniques, but
by 1975, the NComplr compiler for MacLisp avoided pointers for full-size
numbers (integers and floats) even on procedure calls, basically by
providing two entry points (invisible to the user) for each procedure. It
also avoided allocating temporary numbers on the heap, allocating them
instead on special stacks, and implementing a sort of pointer hygiene
which guaranteed that they would be reallocated on the heap if their stack
context disappeared.

Code quality was quite good. Fateman published an example in the SIGSAM
newsletter at the time which showed that NComplr was competitive with
native Fortran (actually a bit faster) for a small test case. True, it
was _not_ competitive for larger and less trivial examples, but it was far
better than other Lisps.


Post a followup to this message

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