[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
**DRAFT** issue COMPILED-FUNCTION-REQUIREMENTS, version 2
- To: jonl@lucid.com
- Subject: **DRAFT** issue COMPILED-FUNCTION-REQUIREMENTS, version 2
- From: Eric Benson <eb@lucid.com>
- Date: Wed, 11 Jan 89 08:45:06 pst
- Cc: barmar@Think.COM, cl-compiler@sail.stanford.edu
- In-reply-to: Jon L White's message of Tue, 10 Jan 89 23:24:01 PST <8901110724.AA03410@bhopal>
Date: Tue, 10 Jan 89 23:24:01 PST
From: Jon L White <jonl@lucid.com>
re: MacLisp had a SUBRCALL function, which was
just like FUNCALL but required its first argument to be a compiled
function, and it seems like any Lisp for conventional processors could
make use of such an optimization.
And indeed Lucid Common Lisp has a just such function (and also another
one corresponding to APPLY). These have not been exported to end users
yet, but are solely used in compiler optimizers etc. I'm not exactly sure
how much optimization they provide, but there should be no real obstacle
to making:
(FUNCALL (THE COMPILED-FUNCTION x) ...)
turn into
(FUNCALL-INTERNAL x ...)
at least in low safety modes.
Not quite. Lucid's optimization is for the type PROCEDURE, which is
used for both interpreted and compiled functions. It is equivalent to
the new strict definition of FUNCTION. An interpreted function is
essentially just a compiled closure that calls EVAL. It is only
distinguished by a bit in the header so that COMPILED-FUNCTION-P is
not true of it. The optimized version of FUNCALL eliminates a piece of
code that is equivalent to something like
(UNLESS (PROCEDUREP F)
(SETQ F (COERCE-TO-PROCEDURE F)))