Xref: utzoo comp.lang.lisp:2444 comp.sys.ti.explorer:151 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!defun.utah.edu!sandra From: sandra%defun.utah.edu@cs.utah.edu (Sandra J Loosemore) Newsgroups: comp.lang.lisp,comp.sys.ti.explorer Subject: Re: inlining Message-ID: <1989Nov23.135515.1892@hellgate.utah.edu> Date: 23 Nov 89 20:55:15 GMT References: <7077@pt.cs.cmu.edu> Organization: PASS Research Group Lines: 26 In article <7077@pt.cs.cmu.edu> Jamie Zawinski 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)