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
