[webkit-dev] want to port JIT to MIPS - JIT reg usage clean up?
x yz
lastguy at yahoo.com
Fri Feb 27 22:38:47 PST 2009
Gavin,
Thanks for correct me, see my comments below with >>:
--- On Sat, 2/28/09, Gavin Barraclough <barraclough at apple.com> wrote:
> From: Gavin Barraclough <barraclough at apple.com>
> Subject: Re: [webkit-dev] want to port JIT to MIPS - JIT reg usage clean up?
> To: "WebKit Development" <webkit-dev at lists.webkit.org>
> Date: Saturday, February 28, 2009, 12:19 PM
> On Feb 27, 2009, at 4:55 PM, x yz wrote:
>
> > The regTx seems to be working registers here, yet
> their definition are regparm(3) registers for function
> arugments. Such usage would cause conflict on other
> platforms. May I suggest that we use individual defined set
> of regs for func i/o argument and working?
>
> First up, I think you're getting slightly confused
> about regparm(3). This is not used anywhere in the JS
> language JIT, only in WREC. In some configurations of the
> JIT we use fastcall semantics on x86... but none of this is
> really relevant to MIPS. Just ignore all this. Stick to
> the default MIPS ABI for stub functions.
>
>>You are absolutely right, I used to see WREC has postfix for regparm(3) and comments on using fastcall or so, yet I'm confused by so many calling conventions and especially messed up today.
>>For exmaple, how could I know which calling convention the following function uses?
static JSObject* resizePropertyStorage(JSObject* baseObject, int32_t oldSize, int32_t newSize)
{
baseObject->allocatePropertyStorage(oldSize, newSize);
return baseObject;
}
>
> Reading between the lines, I'm guessing your concern
> here is that in setting up arguments for a JIT stub call you
> may trample the JIT's temporary registers? If so, I
> think you need to look at the argument passing more closely.
> The mechanisms to pass arguments to stub functions pass all
> arguments in memory – typically passing a single pointer
> to the stub functions, which can be used to retrieve the
> arguments. This pointer argument can be set up immediately
> prior to the call, so it does not interfere with the regT?
> temporaries. We follow this pattern on x86-64, where the
> ABI is typically to pass arguments in registers. You cannot
> trivially change the way this works, since the argument
> pointer is used for other purposes too (e.g. retrieving the
> arguments passed into the JIT code from within the stubs).
>
> We strongly prefer small, simple, incremental changes. A
> patch that tried to both port the JIT to a new platform and
> to introduce a new argument passing interface to the JIT
> stub functions sounds unlikely to get anywhere (a patch
> porting the JIT to a new platform is on its own very likely
> to be too much more than we'd want to land in one
> chunk). I'd suggest that a port would be wise to
> engineer it's initial solution to fit one of the
> existing argument passing mechanisms (these are selected by
> JIT_STUB_ARGUMENT_* switches, to help find the relevant
> code). (Alternatively, you're welcome to attempt to
> port x86-64 to make use of an in-register argument passing
> solution, which could be hugely useful. With this landed
> first and separately, a port could then build on top of
> this.)
>
>> Mips calling conventions always passes 1st four in regs and others in stack from left to right. Thus I need to change argument passing.
>
> As a more direct answer to your question, you could
> endeavour to make the set of hardware registers used as JIT
> temporaries non-overlapping with ABI function argument
> registers on MIPS, but this is unlikely to be a general
> solution to anything for all platforms, due to limited
> register availability on some architectures.
>
>> Thanks this would work.
> > we would put all these definition in a file named
> regMap.h, then we can remove all "X86::" from
> other JIT files.
>
> I don't think we'll be keen on taking preemptive
> changes so far ahead in preparation of a port. The first
> logical step in porting to a new platform is still to start
> with WREC, and this requires no changes in the JIT
> directory. Any refactoring of the existing JIT would make
> more sense more directly prior to work in that area.
>
>>I'm waiting for a partner to complete tool chain, that's why I paused wrec and work on JIT.
>>I don't ask for logical change on X86 code for porting, but sth like "#define" to remap registers. One reg can have multiple names like what we see in current code:
static const RegisterID returnValueRegister = X86::eax;
static const RegisterID cachedResultRegister = X86::eax;
static const RegisterID regT0 = X86::eax;
>>In this way the X86:eax can exist in just one regMap.h file. For Mips the above may be:
static const RegisterID returnValueRegister = MIPS::$v0;
static const RegisterID cachedResultRegister = MIPS::$s1;
static const RegisterID regT0 = MIPS:$a0;
>>The key is one name one usage. Currently I'll use same MIPS reg for above lines rather than 3 different one as I'm not sure any inter-usage in X86 code, or X86 uses one name for multiple purpose.
>>If I don't use remapping, then I need another set of source files for Mips JIT. It may have flexibility yet sync to X86 code change would cost more in future. Which way are you prefer?
rgds
joe
> cheers,
> G.
>
> >
> > I'd apperciate if sb can do it or help me to do
> it.
> > rgds
> > joe
> >
> >
> >
> >
> > --- On Sat, 2/28/09, x yz <lastguy at yahoo.com>
> wrote:
> >
> >> From: x yz <lastguy at yahoo.com>
> >> Subject: Re: [webkit-dev] want to port JIT to MIPS
> - which calling convention is used here?
> >> To: webkit-dev at lists.webkit.org, "Zoltan
> Herczeg" <zherczeg at inf.u-szeged.hu>
> >> Date: Saturday, February 28, 2009, 7:40 AM
> >> Hi,
> >> Thanks for your help in advance:)
> >> in JITPropertyAccess.cpp:
> >> if
> (transitionWillNeedStorageRealloc(oldStructure,
> >> newStructure)) {
> >> pop(X86::ebx); ///pop return address,
> why? for
> >> exception?
> >> #if PLATFORM(X86_64) ///which convention is
> this?
> >>
> >>
> move(Imm32(newStructure->propertyStorageCapacity()),
> >> regT1); //edx
> >>
> >>
> move(Imm32(oldStructure->propertyStorageCapacity()),
> >> X86::esi);
> >> move(regT0, X86::edi);
> >> callTarget = call();
> >> #else ///__cdecl, yet how
> can I know
> >> resizePropertyStorage() use __cdecl?
> >>
> >>
> push(Imm32(newStructure->propertyStorageCapacity()));
> >>
> >>
> push(Imm32(oldStructure->propertyStorageCapacity()));
> >> push(regT0);
> >> callTarget = call();
> >> addPtr(Imm32(3 * sizeof(void*)), X86::esp);
> >> ///clean stack
> >> #endif
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> webkit-dev mailing list
> >> webkit-dev at lists.webkit.org
> >>
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> >
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
More information about the webkit-dev
mailing list