On Wed, 17 Nov 2004 14:14:18 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > I've now (locally here) extended Bill Coffman's register allocator by > one subroutine that actually decides to use non-volatiles or volatiles > according to pdd03. All variables that are live around a subroutine call > are e.g. allocated from R16..R31.
Interesting. I'd like to see it. Regarding pdd03, I am still not clear how it should be interpreted. The current pdd03, as well as the previous one, both seem to indicate that registers 0-15 are likely to be overwritten, and anyone making a call, should save those registers if they still want them. The issue with PIR Code, is that the author won't know which of their symbols are mapping to registers about to be killed. So, as previously discussed, those registers will have to be hands off for the register allocator. That is essentially how the old and new alloctor have been working. But this doesn't have to always be the case. * If the subroutine being allocated is a leaf (with no sub calls), then all registers should be available. * Registers P4, S1-S4, N0-N4 are free for allocation, regardless. * It seems like it would be simple enough to provide a "compiler hint", to let the allocator know if the subs it calls are using the parrot convention or not, or how many of the R5-R15 it will need. >From this hint, a bit mask saying which registers are available could be constructed. This can then be used as part of a static analysis, and can be incorporated into the unit data structure, or passed as a separate parameter to imc_reg_alloc(). I wouldn't think this last idea would be considered a change to the calling convention, but rather as an optional optimization prototype. Not part of pasm. Dan, would something like this be allowed? ~Bill
