Bill Coffman <[EMAIL PROTECTED]> wrote: > Hello All, > I have been hard at work, trying to grok the reg_alloc.c code, and > with some success. My code is assigning registers, so that none are > conflicting (which I double-verify), and I'm getting to the end of > "make".
Wow. > 1) In the existing parrot code, when a register is assigned, it uses > the following code: > int c = (color + MAX_COLOR/2) % MAX_COLOR; > Thus, it seems to prefer to use register #16 and up, first, before it > uses 0-15. This is mistifying to me, since it's not so trivial to > code it this way, Well, some time ago, register allocation started at zero. The split of register frames in upper and lower halfs *plus* the premature optimization to save only the upper half of registers made it necessary to allocate from 16 up. But things are a bit more compilcated. For function calls, we are passing arguments from register x5 ..x15 and I0..I4 plus some more have a special meaning. See docs/ppds/pdd03_calling_conventions for all the details. The same convention is used for function returns. So, if you want that really super efficient, you would allocate registers around function calls directly to that wanted register number, which should be in the SymReg's want_regno. > 2) When function imc_reg_alloc (the main register allocation thingy) > is called, some of the variables have already expressed a preference > as to which register they want. I understand that this can optimize > certain parameter passing, etc. The question that arrises is, what if > two conflicting variables want the same color (reg#)? Obviously, they > don't get their way. But what are the consequences, and what must be > done to fix this. Ah, ok. For each function call registers are moved around to the correct number, if they aren't there. This is done by code in imcc/pcc.c. But the problem still is there that your code really shouldn't assign these registers in a conflicting way. > ... Incidentally, reg > allocation is done on the following subs: > _main __library_dumper_onload _dumper _register_dumper _global_dumper [ ...] Sure. Register allocation code is done per .sub/.end always. So that's fine. But you might start with simpler source code having one or two function calls only. > Maybe someone can point me at something to look at to fix this. I'll > provide the patch if someone would like to play with it. The main problem probably is to follow register usage in calling conventions. BTW: preserving the upper half of registers will be tossed soon. To simulate this behavior in current CVS, you could run the code with -Oc, which should preserve all allocated registers. I don't know, when the indirect register frame patch whill hit CVS, but it should be in a few days. With that in place, you can allocate registers as you like, with the caveat that rules in PDD03 are used. > Thanks to all who made it this far, > Bill Coffman leo
