[Vm-dev] Re: Abstract & concrete registers

[Clément Bera]

Hello Eliot,

I was thinking a lot about the problem and it is not an easy one.

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.

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:

allocateRegNotConflictingWith: regMask
"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."

allocateRegForStackEntryAt: index notConflictingWith: regMask
"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."

The implementation uses this method that should be overriden in subclasses
of AbstractInstruction:
availableRegisterOrNilFor: liveRegsMask

For example, in x64, assuming you have in ExtraRegs a list of registers
from R8 to R15, you could have:
availableRegisterOrNilFor: liveRegsMask
    1 to: NumExtraRegs do: [:i |
         (cogit register: (ExtraRegs at: i) isInMask: liveRegsMask) ifFalse:
[^ExtraRegs at: i] ]
    ^ super availableRegisterOrNilFor: liveRegsMask

so the register allocation would look up the extra registers before the
named ones when possible.

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.

I am just a bit confused by how to handle correctly VarBaseReg.

Maybe we could talk on skype Eliot.




2015-12-06 19:17 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:

> Hi All,
>
>     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.
>
> 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.
>
> 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.
>
> _,,,^..^,,,_ (phone)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151206/aa6610d2/attachment-0001.htm