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,
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);
+move(ARMRegisters:
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 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 Dat
Hi Gabor,
Thanks for your prompt reply.
> Make sure your assembler does not break ctiVMThrowTrampoline
> and ctiOpThrowNotCaught functions. This approach requires that the
> ctiVMThrowTrampoline fall-backs to ctiOpThrowNotCaught
> after 'bl cti_vm_throw' call. Or you can simply copy the body of
>
Hi Patrick,
Patrick Roland Gansterer wrote:
> I'm trying to enable the JIT for CPU(ARM_TRADITIONAL) && OS(WINCE).
> MSVC supports inline assembler only for X86, so i had to provide a separate
> asm file (i copied the code from the GCC #ifdef with !JSVALUE32_64):
>
> ctiVMThrowTrampoline proc
>
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
>
On Jun 16, 2009, at 5:52 PM, Toshiyasu Morita wrote:
--- On Wed, 6/17/09, Maciej Stachowiak 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 th
--- On Wed, 6/17/09, Maciej Stachowiak 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 want to
> do
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 ho
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 y
> 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. Righ
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. Y
On Jun 11, 2009, at 9:59 AM, Toshiyasu Morita wrote:
--- On Wed, 6/10/09, Gavin Barraclough 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 o
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
http://lists.webkit.
--- On Wed, 6/10/09, Gavin Barraclough 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 a method to ensure
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 discussions,
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 optimize
On Jun 10, 2009, at 1:15 PM, Toshiyasu Morita wrote:
--- On Wed, 6/10/09, Geoffrey Garen 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
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 sign
--- On Wed, 6/10/09, Oliver Hunt 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 lines of sourc
:
From: Geoffrey Garen
Subject: Re: [webkit-dev] arm jit
To: "Oliver Hunt"
Cc: "Toshiyasu Morita" , "WebKit Development"
Date: Wednesday, June 10, 2009, 9:14 PM
> It could be worth trying a stub function that triggers the compilation of the
> function s
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 alway
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
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 theoreti
--- On Wed, 6/10/09, Geoffrey Garen 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.
Consider someth
Umm. IMHO The existing JIT is not well designed, with processor-
specific constants everywhere and "optimizations" such as inlinining
huge blocks of weakly-optimized code instead of making a function
call to properly-optimized code.
These issues make it difficult to both port and maintain.
Gavin Barraclough 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 a port as
> we mov
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 archi
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 whole-hea
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
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 your
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 fir
34 matches
Mail list logo
