PDD03: Responsibility for environment preservation PDD03: PDD03: The caller is responsible for preserving any environment it is interested PDD03: in keeping. This includes any and all registers, lexical scoping and PDD03: scratchpads, opcode libraries, and so forth. PDD03: PDD03: Use of the savetop opcode is recommended if the caller wishes to save PDD03: everything, and the restoretop opcode to restore everything savetop saved. PDD03: This saves off the top 16 of each register type, leaving the bottom 16 PDD03: registers, which generally contain the return values, intact.
The way I read it, paragraph one implies that when you print P5 after calling foo(), you are expecting to get the return value. You didn't save and restore register P5, so you wanted foo() to do something to it. The above docs may be slightly ambiguous. The first paragraph says that you have to save everything. The seconds says that savetop/restoretop commands are there to help the user, by allowing them to take care of registers 16-31, but what about 0-15? Is there an implication that you don't have to save those? Based on the way people are coding IMC, that seems to be the case. Both the old and new register allocator are kind of hands off the first 16 registers. Recall that I was asking about this some time ago, and found that if the allocator tries to use the bottom half first, chaos ensues. Our convention then ... our interpretation of the calling convention, is that we "try to allocate" only the top 16 registers. If more are needed, the new allocator starts from R15, and go on downward. The old one just went up from R0. Note that PDD03 is specifying a dynamic calling convention. Because of this, the register allocator cannot use the convention to find what should be saved, and what it can use. If this were indicated at compile time, the register allocator could keep hands off only the used registers. As it is, we may need to do as you suggest, and leave the bottom 16 registers for parameter passing, and the top 16 for local symbols and register allocation. If so, we will obviously need a better register allocator. One exception to this. If a sub calls no other subs, it can use all 32 registers. Also, P4, S1-S4, N0-N4 seem to be free. ~Bill On Sun, 14 Nov 2004 18:32:50 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > As outlined in the analysis of dumper.t failures with the new register > allocator, we have another problem with current calling or better return > conventions. > > Given this simple program: > > $ cat ret.imc > .sub main @MAIN > P5 = new PerlString > P5 = "ok\n" > foo() > print P5 > .end > .sub foo > .local pmc ok > ok = new PerlString > ok = "bug\n" > .return(ok) > .end > > $ parrot ret.imc > bug > > The usage of the register P5 in main isn't invalid: the register > allocator might have (in a more complex program) just not found any > other free register. And as the main program just calls a function in > void context the register P5 could have been used. > > Defining now that P5 has to be preserved in main, because it's a > possible return result of foo() and therefore may be clobbered by foo() > is meaning, that we have effectively just 16 registers per kind > available for allocation around a function call. > > If the latter is true according to current pdd03 then we are wasting > half of our registers for a very doubtful advantage: being able to pass > return values in R5..R15. > > leo > >
