[webkit-dev] want to port JIT to MIPS - JIT reg usage clean up?

[Gavin Barraclough]

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.

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.)

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.

> 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.

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