Re: pointer elimination in C

Robin Popplestone <pop@dcs.gla.ac.uk> writes:
      |> LISP for example, provides almost nothing but pointers -
      |> typically only short integers and possibly short floats will not
      |> be pointers.


mcdonald@kestrel.edu (Jim McDonald) writes:
      |> Some objects have non-pointers as data:


ted@crl.nmsu.edu (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.


mcdonald@kestrel.edu (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.


-s
--

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