Greetings! I'm in the process of trying to engineer passive list
support in GCL's compiler, to dovetail with the automatic source
function inlining available in CVS.
As many know, many standard lisp functions require &rest arguments,
which are quite slow in a system like GCL which passes arguments on a
C stack. This can be mitigated somewhat by consing the list on the C
stack, as GCL does, but it remains less than optimal. Worse, once
consed, arguments must be boxed if unboxed, and preserving type
information becomes more challenging (cons types, etc.) These
problems are related to eliminating tail recursive calls invoked via
apply, which I am also trying to support.
Still, it would appear ideal to be able to store all optimization
information in the function source itself, accessible in the running
image, rather than in a separate suite of failities like compiler
macros, optimization strings on the plist, etc. So I'm trying to live
with the &rest, but allow the compiler to eliminate the call to list
if the &rest variable is only accessed passively, i.e. via car and the
like. This is similar to GCL's current support (in cvs) for passive
variable reference and elimination, when the binding is known to be an
atomic type.
This is likely a problem which has already been solved somewhere. If
anyone knows of references, please let me know.
Take care,
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
From: Daniel Weinreb
Subject: Re: Compiler support for passive list references
Date:
Message-ID: <V_89j.5781$c82.1423@trnddc01>
Camm Maguire wrote:
> Greetings! I'm in the process of trying to engineer passive list
> support in GCL's compiler, to dovetail with the automatic source
> function inlining available in CVS.
>
> As many know, many standard lisp functions require &rest arguments,
> which are quite slow in a system like GCL which passes arguments on a
> C stack. This can be mitigated somewhat by consing the list on the C
> stack, as GCL does, but it remains less than optimal. Worse, once
> consed, arguments must be boxed if unboxed, and preserving type
> information becomes more challenging (cons types, etc.) These
> problems are related to eliminating tail recursive calls invoked via
> apply, which I am also trying to support.
>
> Still, it would appear ideal to be able to store all optimization
> information in the function source itself, accessible in the running
> image, rather than in a separate suite of failities like compiler
> macros, optimization strings on the plist, etc. So I'm trying to live
> with the &rest, but allow the compiler to eliminate the call to list
> if the &rest variable is only accessed passively, i.e. via car and the
> like. This is similar to GCL's current support (in cvs) for passive
> variable reference and elimination, when the binding is known to be an
> atomic type.
>
> This is likely a problem which has already been solved somewhere. If
> anyone knows of references, please let me know.
>
> Take care,
Yeah, it's hard. In the Lisp machine, for a long time, if you
took a list that was the value of an &rest argument and tried
to use it longer than the lifetime of the function, it just
didn't work and you were in real trouble. I think this was
fixed later but it's hard to remember whether, let alone how,
it was done. I wish I could be of more help.
Daniel Weinreb <···@alum.mit.edu> wrote:
+---------------
| Camm Maguire wrote:
| > As many know, many standard lisp functions require &rest arguments,
| > which are quite slow in a system like GCL which passes arguments on a
| > C stack. ... So I'm trying to live with the &rest, but allow
| > the compiler to eliminate the call to list if the &rest variable
| > is only accessed passively, i.e. via car and the like.
...
| Yeah, it's hard. In the Lisp machine, for a long time, if you
| took a list that was the value of an &rest argument and tried
| to use it longer than the lifetime of the function, it just
| didn't work and you were in real trouble. I think this was
| fixed later but it's hard to remember whether, let alone how,
| it was done.
+---------------
AFAICT, CLHS allows holding onto a &REST parameter's value after
the callee's return... BUT, that might be dangerous anyway due
to the following:
http://alu.org/HyperSpec/Body/sec_3-4-1-3.html
3.4.1.3 A specifier for a rest parameter
...
The value of a rest parameter is permitted, but not required,
to share structure with the last argument to APPLY.
and:
http://alu.org/HyperSpec/Body/fun_apply.html
Function APPLY
...
When the function receives its arguments via &REST, it is
permissible (but not required) for the implementation to bind
the rest parameter to an object that shares structure with the
last argument to APPLY. Because a function can neither detect
whether it was called via APPLY nor whether (if so) the last
argument to APPLY was a constant, conforming programs must
neither rely on the list structure of a rest list to be freshly
consed, nor modify that list structure.
So one must still be careful with it.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607