Hi,
the dateProtoFuncGetTimezoneOffset does not use the argList argument,
while functionPrint does. Perhaps passing this argument is still not yet
WinCE compatible. ArgList contains a pointer to the arguments (JSValue
pointers), and the length of the arguments. This structure is 8 bytes on
32 bit
Hi Patrick,
hm, I feel I found something. Please have a look at
JavaScriptCore/jit/JITOpcodes.cpp : privateCompileCTIMachineTrampolines.
The second one, when JSVALUE32_64 is disabled. If JIT_OPTIMIZE_NATIVE_CALL
is enabled, a specialized code is generated to call native builtin
functions (like
Hi,
many thanks! It works already when I disable OPTIMIZE_NATIVE_CALL (other 3
OPTIMIZE are turned on). I think you're right with the ABI problem. Maybe you
can help me with it too: Here are the instruction dumps with and without the
OPTIMIZE_NATIVE_CALL:
Hi,
I did some further investigation today.
I did a quick hack in the privateCompileCTIMachineTrampolines to get the same
maybe correct register values like without OPTIMIZE_NATIVE_CALL.
move(callFrameRegister, regT0);
+move(ARMRegisters::r2, ARMRegisters::r3);
+
Hi,
I'm trying to enable the JIT for CPU(ARM_TRADITIONAL) OS(WINCE).
It already passes the RegExp-Tests with ENABLE_YARR_JIT. If i set all
ENABLE_JIT_OPTIMIZE_* to 0 it won't compile.
MSVC supports inline assembler only for X86, so i had to provide a separate
asm file (i copied the code from
Hi,
1) The armv7 port is separate from the armv6 work, and uses the thumb2
instruction set. Both ports are (I hope!) useful.
We hope it as well.
2) We would have liked to let the community know about the arm v7 port
sooner. Unfortunately, we were not at liberty to disclose it until the
I'm not sure if there are any remaining disputes about the Nitro ports
to armv6 and armv7. But just to make sure everyone is on the same
page, I would like to clarify a few things:
1) The armv7 port is separate from the armv6 work, and uses the thumb2
instruction set. Both ports are (I
--- On Wed, 6/17/09, Maciej Stachowiak m...@apple.com wrote:
5)
Gavin has been a strong proponent of using MacroAssembler as the
primary CPU
abstraction layer, and that approach has worked reasonably
well so far. However,
it seems at least to me that CPUs with very
different instruction sets may
On Jun 16, 2009, at 5:52 PM, Toshiyasu Morita wrote:
--- On Wed, 6/17/09, Maciej Stachowiak m...@apple.com wrote:
5) Gavin has been a strong proponent of using MacroAssembler as the
primary CPU
abstraction layer, and that approach has worked reasonably well so
far. However,
it seems at
Hi guys at Apple,
it looks we are in the way of the train. You have plans, we don't know
about them, you have commit rights, we don't, so the tides are against us.
Hints on the mailing lists are scarce, although a year ago someone from
you asked whether others are interested in design
--- On Wed, 6/10/09, Gavin Barraclough barraclo...@apple.com wrote:
If you consider calling a JS function with too few arguments as being
akin to =
invoking a C++ method with some defaulted parameters
not-provided, then it is
also the responsibility of code generated for
the call to such
Can the arity check be performed at compile time as in C++?
C++ can perform arity checks at compile time because C++ uses early
binding. JavaScript uses late binding.
Geoff___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Jun 11, 2009, at 9:59 AM, Toshiyasu Morita wrote:
--- On Wed, 6/10/09, Gavin Barraclough barraclo...@apple.com wrote:
If you consider calling a JS function with too few arguments as
being akin to =
invoking a C++ method with some defaulted parameters not-provided,
then it is
also
it looks we are in the way of the train. You have plans, we don't know
about them, you have commit rights, we don't, so the tides are
against us.
If you're interested in review or commit rights, they're granted based
on a track record of good work, good judgement, and good
collaboration.
If you're interested in review or commit rights, they're granted based
on a track record of good work, good judgement, and good
collaboration. You can read more about the policy here:
http://webkit.org/coding/commit-review-policy.html
.
Please work on your collaboration skills. Right now,
And here, I have to make a short comment on the non-acceptance of
our ARM
JIT implementation. In your mail you mention that you would remain
reluctant to accept a duplicate of the JIT into the tree, rather
than a
port of the existing JIT utilizing the MacroAssembler abstraction.
Well,
did
Gavin Barraclough barraclo...@apple.com wrote:
We were (and remain) reluctant to accept a duplicate of the JIT into
the tree, rather than a port of the existing JIT utilizing the
MacroAssembler abstraction. We are
concerned that it would be
extremely difficult to continue to maintain such
--- On Wed, 6/10/09, Geoffrey Garen gga...@apple.com wrote:
I'm having a hard time understanding from your comment what optimization
changes you think are appropriate, but if you can produce a patch that
implements
your idea, and shows a benefit on a benchmark, I'd be happy
to review it.
This expands out to 95 inline instructions on the MIPS for just the
slow case alone, of which 3 are functions calls to other functions.
So this probably requires thousands of clock cycles to execute.
IMHO it doesn't make sense to inline op_call because:
You've made some interesting
It would be an interesting experiment to compile functions at
creation time instead of call time, and see if things got faster.
I'd love to hear your results, if you try it.
I doubt that eager compilation would be a good strategy for the web,
though, since web pages tend to load very large
It could be worth trying a stub function that triggers the
compilation of the function should it not be present, but i'm not
sure what that would really save as we still need the arity checks
inline
A design that I like is a stub function that triggers compilation (so
the caller can
...@apple.com wrote:
From: Geoffrey Garen gga...@apple.com
Subject: Re: [webkit-dev] arm jit
To: Oliver Hunt oli...@apple.com
Cc: Toshiyasu Morita tm_web...@yahoo.com, WebKit Development
webkit-dev@lists.webkit.org
Date: Wednesday, June 10, 2009, 9:14 PM
It could be worth trying a stub function
--- On Wed, 6/10/09, Oliver Hunt oli...@apple.com wrote:
I doubt that eager compilation would be a good strategy
for the web, though,
since web pages tend to load very large libraries
of functions, while only calling a
small percentage of those functions.
Turbo C compiled about 10,000
The issue is that it compiling 5000 lines of libraries (possibly more)
results in a significant amount of memory use, that's why we don't
compile -- i don't believe there was a significant cpu time
performance win (if any at all) from delaying function compilation.
There was however a
On Jun 10, 2009, at 1:15 PM, Toshiyasu Morita wrote:
--- On Wed, 6/10/09, Geoffrey Garen gga...@apple.com wrote:
I'm having a hard time understanding from your comment what
optimization changes you think are appropriate, but if you can
produce a patch that implements
your idea, and shows
Toshiyasu,
On Jun 10, 2009, at 2:24 PM, Toshiyasu Morita wrote:
Why does the arity check need to be in the caller, and not the callee?
The majority of call sites always call to the same callee, and we can
optimize these cases for calling that same function repeatedly.
Within the
Dear Community,
Today, we realized that there is a new ARM JIT port for WebKit.
(http://trac.webkit.org/changeset/44514) Congratulations on getting this
working!, great job.
I cannot conceal how disappointed I am, as is the whole team at Szeged. It was
months ago, when we presented you our
Hi Akos.
Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514
) Congratulations on getting this working!, great job.
Thanks.
I cannot conceal how disappointed I am, as is the whole team at
Szeged.
I'm sorry to hear that. I understand
On Tuesday 09 June 2009 23:38:43 Akos Kiss wrote:
Dear Community,
Today, we realized that there is a new ARM JIT port for WebKit.
(http://trac.webkit.org/changeset/44514) Congratulations on getting this
working!, great job.
I cannot conceal how disappointed I am, as is the whole team at
Hi there,
I would also say that is it pretty understanding that Apple does not
share information about working on a ARM JIT targeting thumb2,
especially as this can be used to foresee the hardware of future
iPhone models. Something they are probably not interesting in
revealing.
I agree
On Jun 9, 2009, at 2:38 PM, Akos Kiss wrote:
Dear Community,
Today, we realized that there is a new ARM JIT port for WebKit. (http://trac.webkit.org/changeset/44514
) Congratulations on getting this working!, great job.
Hi Akos,
Thank you! Just to clarify, we have just landed a ARMv7
31 matches
Mail list logo
