On the Explorer, it's not possible to compile a function inline unless it's
source code is around. That is, if function A wants to declare function B
inline, the code will not appear inline unless function A is compiled in the
compilation environment of function B. If function B was loaded from a
compiled file, recompiling function A will not inline function B.
Is there a good reason for this? I assume by this behavior that (on the
Explorer) inlining a function involves a source-level transformation and
recompilation; but it seems to me that it should be possible to just splice
in a code vector, after some trivial disassembly to move the jump pointers.
One way around this problem is to use DEFSUBST instead, but this has a few
problems, being 1: it's not common lisp, 2: Defsubst doesn't spawn a new
lexical environment, encouraging obscure bugs, and 3: the Explorer defsubst
expansion code is a little buggy.
-- Jamie
In article <····@pt.cs.cmu.edu> Jamie Zawinski <···@teak.berkeley.edu> writes:
>On the Explorer, it's not possible to compile a function inline unless it's
>source code is around.
>Is there a good reason for this? I assume by this behavior that (on the
>Explorer) inlining a function involves a source-level transformation and
>recompilation; but it seems to me that it should be possible to just splice
>in a code vector, after some trivial disassembly to move the jump pointers.
I don't claim to have any particular knowledge about the guts of the
Explorer, but I can think of a very good reason why this won't buy you
very much.
Most of the overhead of a function call in compiled code is *not* in
the actual call/return instructions. Instead, it is in moving
arguments to the right places, saving live registers and other state
information on the stack, and the like.
The code vector that you suggest "splicing in" will assume that arguments
live in particular places, that it is OK to overwrite registers, and the
like. Therefore you still have to do all of the shuffling before and
after the spliced-in code. You gain very little and make your code much
bigger. The point of true inlining is to avoid the shuffling entirely.
The inline code for some small functions can be smaller than the code
generated for an out-of-line call to them, for this reason.
-Sandra Loosemore (······@cs.utah.edu)