G'day all. On Mon, Apr 29, 2002 at 07:57:08AM +0100, Piers Cawley wrote:
> Remember that the caller only has to save the stuff that is important > to it, after all, anything that might be of importance to *its* > callers will already have been saved. If the callee saves then it's > going to be doing belt and braces save/restores on registers that may > be completely irrelevant. That's true, it's a tradeoff. However, I think it's much more likely that complex subs call simpler subs, not the other way around, and when it is the other way around, it's probably less time-critical, and even if it is the other way around and it is time critical, I still think that a small number of caller-save registers is a good idea. > Any half decent compiler, given enough information from the original > source and/or linkage information on precompiled modules will be able > to do the appropriate register saving optimizations at compile > time. It should even be possible to have automagic inlining > happening. Intermodule optimization requires a compiler that's significantly better than "half decent", if only to handle the recompilation dependencies. After all, we don't want existing code to break every time someone does a CPAN upgrade. Of course the ultimate solution is the old MIPS register allocation at link time approach, but I assume that for a dynamic language like Perl this is a bad idea. :-) > Well factored code tends to have plenty of small, trivial > subroutines... And in the case of non trivial subs then the register > saving overhead will be the same whereever it happens. The precise > breakdown will be different, but I claim that the average case will > stay roughly the same. I agree that in the case of non-trivial subs the overhead will be roughly the same. Modern code has lots of trivial subs. I remember reading this somewhere but I can't for the life of me remember where. Until I find a proper reference, I can only point to the large number of callee-save registers currently found in "real world" ABIs. :-) > You've still not shown how you're going to make a first class > continuation when the callee saves. And no, using branch instead of > bsr is *not* a good enough answer, you need to be able to bundle up a > continuation that can be called from anywhere, even after that > continuation is no longer in the current caller chain, which means you > need to be able to restore the register state and continuation chain. I'm in a bit of a hurry at the moment, so I can't do this justice right now, however, just a thought: If you want a continuation that can be called from everywhere, and it has registers to be loaded, don't you really want a closure? (I might be wrong on that; it's been a while since I last read Appel's "Compiling with Continuations".) Cheers, Andrew Bromage
