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