<div dir="ltr">Hello Eliot,<div><br></div><div>I was thinking a lot about the problem and it is not an easy one.</div><div><br></div><div>I believe it's fine to let a fixed number of registers with a direct mapping from abstract register to concrete register so they can be used for calling convention (smalltalk sends & trampolines). The registers directly mapped are Arg1Reg Arg0Reg ReceiverResultReg TempReg ClassReg SendNumArgsReg FPReg SPReg, and maybe LinkReg and PCReg.</div><div><br></div><div>I think the main issue is how to use efficiently the extra registers. For that I started to build some fancier register allocation. Typically, you can do:</div><div><br></div><div><font face="monospace, monospace">allocateRegNotConflictingWith: regMask </font></div><div><font face="monospace, monospace">"This answers a free register not conflicting with the mask. If a free reg is available, answers it, else scan the sim stack and find the cheapest register to free, free it, answer it."<br></font></div><font face="monospace, monospace"><br class="">allocateRegForStackEntryAt: index notConflictingWith: regMask</font><div><font face="monospace, monospace">"Same think but allocates the register for a simStack entry, index 0 for stack top, if sim stack entry is already in a reg answers the reg."</font><br><div><br></div><div>The implementation uses this method that should be overriden in subclasses of AbstractInstruction:</div><div><font face="monospace, monospace">availableRegisterOrNilFor: liveRegsMask</font><br></div></div><div><br></div><div>For example, in x64, assuming you have in ExtraRegs a list of registers from R8 to R15, you could have:</div><div><font face="monospace, monospace">availableRegisterOrNilFor: liveRegsMask<br></font></div><div><font face="monospace, monospace"> 1 to: NumExtraRegs do: [:i |</font></div><div><font face="monospace, monospace"> (cogit register: (ExtraRegs at: i) isInMask: liveRegsMask) ifFalse:</font></div><div><div><font face="monospace, monospace"><span class="" style="white-space:pre"> </span>[^ExtraRegs at: i] ]</font></div></div><div><font face="monospace, monospace"> ^ super availableRegisterOrNilFor: liveRegsMask</font></div><div><br></div><div>so the register allocation would look up the extra registers before the named ones when possible.</div><div><br></div><div>The main problem then consists in using much more the register allocation API instead of just picking named registers, as I tried to do with stores (for example in genStorePop:RemoteTemp:At:). This is not possible currently because of the calling convention (smalltalk sends and trampolines) which require specific registers at specific places. I believe the smalltalk sends convention should not be changed. However, trampolines that are rarely called but frequent on machine code could be rewritten to pass arguments on stack instead of by registers to be able to use much more register allocation (mustBeBool, contextInstVar, remember, scheduleScavenge, etc.). Another issue is to be able to save register state register state across branches.</div><div><br></div><div>I am just a bit confused by how to handle correctly VarBaseReg.</div><div><br></div><div>Maybe we could talk on skype Eliot.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-06 19:17 GMT+01:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
when I started the Cogit I made the decision to have the notion of abstract registers (ReceiverResultReg, ClassReg, Arg0Reg et al) separate from concrete registers (EAX et al on x86, etc). I used negative indices for abstract and non-negative indices for concrete. But this means the back end has to map from one to the other and with much better register allocation being a priority for Clément and I to deliver in April next year I'm thinking that this was a mistake. After all, the important things are the names, and the relevant back end can simply initialize the abstract registers with the concrete induces and then the napping could go away.<br>
<br>
The only issue I see is that in some circumstances nil is passed to a method expecting an optional abstract register, but nil maps to 0 in C and so would be confused for e.g. EAX, which has the value 0. For this I guess we could use -1, named e.g. NoRegister.<br>
<br>
Before doing this I thought I'd ask y'all to think about the implications and see if we think it makes sense collectively. So over the next few weeks, in working with the code, consider the issue, and I'll prompt you to state your conclusions then.<br>
<br>
_,,,^..^,,,_ (phone)</blockquote></div><br></div>