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 <[email protected]> wrote:
From: x yz <[email protected]>
Subject: Re: [webkit-dev] want to port JIT to MIPS - which calling
convention is used here?
To: [email protected], "Zoltan Herczeg" <[email protected]
>
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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
