Bill Coffman <[EMAIL PROTECTED]> wrote: [ pdd03 ]
> 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 nasty thing of a function call is: i = foo() # fine P5 returned vs. foo() # P5 clobbered by foo (but you can replace P5 with P15 too, or every register R5..R15) > The above docs may be slightly ambiguous. The first paragraph says > that you have to save everything. Not quite. You have to save everything that should be preserved, i.e. everything you reuse later. > ... 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? Well, that's obsolete and needs rewording. We changed from a scheme, where the register saving is done by opcodes to a scheme where the system preserves registers (as well as lexicals and such, which were already saved by switching contexts). By providing a new register frame for the called sub, basically all registers are preserved. The exceptions are unused return values like in the above example, which are actively returned by the framwork, when the subroutine indicates the presence of return values. > 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. Yes, exactly. And that's just because of unused returns. > ... 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. We need to refine the calling conventions. Reserving 16 registers of all four kinds just for likely one return value is super-inefficient. > ~Bill leo
