[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Questions about specification and possible implementations
- To: JonL.pa@XEROX.ARPA
- Subject: Questions about specification and possible implementations
- From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
- Date: Fri, 05 Oct 1984 00:43:00 -0000
- Cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA, HEDRICK@RUTGERS.ARPA, Moon@SCRC-RIVERSIDE.ARPA, Rem%IMSSS@SU-SCORE.ARPA
- Sender: WHOLEY@CMU-CS-C.ARPA
Date: Thursday, 4 October 1984 19:01-EDT
From: JonL.pa at XEROX.ARPA
Hmmm, I think this discussion is beating around an important "bush" --
namely *exactly* which of the functions in the Common Lisp spec is it
permissible to open-code in such a way that TRACE, BREAK, ADVISE, etc
will not work?
(DECLARE (NOTINLINE FOO)) is the way to make FOO traceable regardless of what
the compiler might do. All implementations should grok that.
Additionally, there may be other functions for which
TRACE etc cannot work (there are a number of such functions in
Interlisp-D -- QUOTE comes to mind -- and woe betide the poor loser who
accidentally stumbles across one, for his machine will rapidly take a
non-returnable vacation "South")
QUOTE is a special form. The Common Lisp specification of TRACE indicates that
it may be used to trace functions, not macros or special forms. I agree that
tracing macros and special forms can be useful, but restricting TRACE to
functions is an elegant way to avoid that problem. Indeed, there are some
functions that probably can't be traced, but I believe the encapsulation code
can figure out when it's being invoked recursively. Our TRACE endeavors to do
this. Making the encapsulation code be compiled (easy and fun with lexical
closures!) avoids the lossage that can happen when one traces EVAL, for
I see Hedrick's complaint as continuing evidence of the tension in this
community between the special-purpose microcoded machine adherents and
the general-purpose stock hardware men. I'm with Chuck in thinking that
it was a mistake to remove names of functions that are "there only for
compiler optimizations" -- as long as Common Lisp is going to run on
something other than a 3600 or a PERQ, more attention needs to be paid
to these needs. (i.e., when Chuck says "I believe it to be a mistake to
do these optimizations", I take him to mean that either you must compile
a call to the documented function, or else provide a documented name of
the right functionality that the user might put in his source code).
If I were also involved in doing a stock-hardware implementation (which I am),
I don't think I'd decide to do these things differently. I assume you meant
that this quick check could be part of a microcoded instruction. If I
implemented the scheme I outlined in my previous message, I would do so without
introducing any new macroinstruction. I don't think it's worth the microcode.
At one time, all such needs were swept into the bag of "it's only a
compiler optimization, put it in a DECLARE" -- remember the RPG Memorial
Vector Proposal -- but if these "compiler optimizations" are critically
essential to any realistic implementation on stock hardware . . .
Almost all of the "compiler optimizations" that make vector hacking cheap on
stock hardware are very easy to do if the right information is around at the
right time. Declarations are important in Common Lisp on stock hardware; if
you're implementing Common Lisp on stock hardware, your compiler should be
structured so that the information from the declarations is easily accessible
in your code generator and optimizers.
Incidentally, your solution of dynamic testing is similar to many speed
optimizations that compilers sometimes emit (e.g., doing an open-coded
EQ check before actually calling EQUAL), but I'd had to see it applied
to all those "myriads" of functions that took any keyword -- think of
the code-size bloat!
If you're concerned about code size, do (DECLARE (OPTIMIZE SPACE)). I've spent
a great deal of time in the past few weeks staring at assembly code listings,
and I'm pretty sure that such a test on function calls to keywordized functions
would not contribute significantly to code size. There are "myriads" of
functions that take keyword args, but I don't think there are "myriads" of
calls to those functions.