On x86, the size of the instructions are fixed. If you want to access
multiple instructions in the instruction stream, you only need to store
the address of the first one, and can access the others by their relative
address. This saves a little memory.
Example (see JIT::linkCall):
instruction at callLinkInfo->hotPathBegin: points to callee comparison
instruction at
callLinkInfo->hotPathBegin + patchOffsetOpCallCompareToJump:
points to the slow case entry jump
Zoltan
> in jit.h, for example:
> static const int patchOffsetOpCallCompareToJump = 9;
> static const int patchOffsetPutByIdStructure = 7;
> static const int patchOffsetPutByIdPropertyMapOffset = 22;
> static const int patchOffsetGetByIdBranchToSlowCase = 13;
> thanks for help, I'm stucked here now.
> joe
>
>
> --- On Sat, 2/28/09, Gavin Barraclough <barraclo...@apple.com> wrote:
>
>> From: Gavin Barraclough <barraclo...@apple.com>
>> Subject: Re: [webkit-dev] want to port JIT to MIPS - JIT reg usage clean
>> up?
>> To: "WebKit Development" <webkit-dev@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.
>>
>> 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 <last...@yahoo.com>
>> wrote:
>> >
>> >> From: x yz <last...@yahoo.com>
>> >> Subject: Re: [webkit-dev] want to port JIT to MIPS
>> - which calling convention is used here?
>> >> To: webkit-dev@lists.webkit.org, "Zoltan
>> Herczeg" <zherc...@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@lists.webkit.org
>> >>
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> >
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
