jwz@spice.cs.cmu.edu (Jamie Zawinski) (11/24/89)
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
sandra%defun.utah.edu@cs.utah.edu (Sandra J Loosemore) (11/24/89)
In article <7077@pt.cs.cmu.edu> Jamie Zawinski <jwz@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 (sandra@cs.utah.edu)