Hi,
this really helps! The two pointers may also help Mips. In Mips dest offset
patches are in two instructions, no constant biase can be used as in X86.
Currently I do check instruction syntax to determine the patch offset.
thanks again!
joe
--- On Wed, 3/4/09, Zoltan Herczeg <zherc...@inf.u-szeged.hu> wrote:
> From: Zoltan Herczeg <zherc...@inf.u-szeged.hu>
> Subject: Re: [webkit-dev] want to port JIT to MIPS - how patchOffset*
> constant determined?
> To: webkit-dev@lists.webkit.org
> Date: Wednesday, March 4, 2009, 3:33 PM
> Hi,
>
> they generate instructions, which size is known in advance.
>
> Think about the following sequence:
> hotPathBegin:
> mov regX, 32bit_const <- 6 bytes (*) (**)
> add regX, regY <- 2 bytes
> jo 32bit_addr <- 5 bytes (*)
>
> * (Note) : these instructions will be modified during
> runtime.
>
> ** (Note) : there is a short form for "mov regX,
> 8bit_const", which length
> is only 3 bytes, but they force the longer version in such
> cases to keep
> the size of the instruction.
>
> As you can see, the address of "jo" is always
> (hotPathBegin + 6 + 2). They
> simply introduce a new constant: patchOffsetXXX = 8, and
> use this constant
> to access the "jo" instruction later.
>
> In ARM we can't rely on such constant, because the
> constant pool can be
> placed after any instruction.
>
> hotPathBegin:
> ldr rX, [pc + const_pool_addr] ; 32 bit const
> [...] <- the const pool can be placed here
> add rX, rX, rY
> [...] <- the const pool can be placed here
> hotPath2:
> ldr pc, [pc + const_pool_addr] ; 32 bit target address
>
> We need to store both pointers (hotPathBegin and hotPath2).
>
> Zoltan
>
> > Zoltan,
> > Thanks for reply, I'm trying to understand your
> example. But,X86
> > instruction size is from 1 to 17bytes, not constant. I
> may misunderstand
> > your comments?
> > Many X86 instruction can have imm32 at the end, thus
> this pointer can be
> > used for patch as well as next address after call.
> Does Arm have similar
> > things? or else you still need to figure out why
> > "patchOffsetOpCallCompareToJump = 9;"? may
> be some instruction lengths
> > relates to the 9?
> > rgds
> > joe
> >
> >
> > --- On Wed, 3/4/09, Zoltan Herczeg
> <zherc...@inf.u-szeged.hu> wrote:
> >
> >> From: Zoltan Herczeg
> <zherc...@inf.u-szeged.hu>
> >> Subject: Re: [webkit-dev] want to port JIT to MIPS
> - how patchOffset*
> >> constant determined?
> >> To: webkit-dev@lists.webkit.org
> >> Date: Wednesday, March 4, 2009, 3:45 AM
> >> 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
> >
> >
> >
> > _______________________________________________
> > 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
