From: Will Hartung
Subject: Lisp compilers and function redefinition.
Date:
Message-ID: <vfr750E0IKH1.1Ks@netcom.com>
Okay, we have Compiler/Interpreter thread raging away, we had the CLOS
efficiency with a taste of RISC architecture, and now the redfinition
of symbols thread.
So it's getting me to wonder, being Compiler Ignorant, how, precisely,
implementations are pulling this off?
(defun (foo x)
(+ x 1))
(defun (fum y)
(+ (foo y) 1))
(defun (foo x)
(* x x))
Now, it is clear to me what "fum" will return after it is called:
(fum 5)
26
But if you are working with a compiled environment, how is the "foo"
call represented?
Does the compiler hunt down every reference to "foo" in the image and
change it? or does it compile in an indirect jump through the symbol
named "foo", so that "fum"s code doesn't change.
And if the latter is true, is EVERY function call implemented that
way? To handle such redfinition "just in case"? And if THAT is the
case, doesn't that throw the instruction caches on the modern
processors for a loop during jump predictions and what not?
I'm just curious how the compilers pull it off is all.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
From: Len Charest
Subject: Re: Lisp compilers and function redefinition.
Date:
Message-ID: <32826D9B.DDC@cogent.net>
Will Hartung wrote:
> Does the compiler hunt down every reference to "foo" in the image and
> change it?
No.
> or does it compile in an indirect jump through the symbol
> named "foo", so that "fum"s code doesn't change.
Yes.
> And if the latter is true, is EVERY function call implemented that
> way?
Yes.
> To handle such redfinition "just in case"?
Not merely. A Lisp symbol is a generic container. It may "hold"
(be bound to) any data type at any given moment during program
execution. It just so happens that a Common Lisp symbol may have
TWO bindings simultaneously -- one for function calls and one for
all other evaluation contexts.
--
Len Charest
System Administrator
Cogent Software, Inc.