[webkit-dev] ARM JIT and related issues

[Zoltan Herczeg]

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
> iPhone 3G S announcement. We try to let the community know what we're
> up to and drop code into the public tree as soon as we can, but
> sometimes we are limited by confidentiality constraints.

Corporate secrets are corporate secrects, that is understandable.

> 3) We'd definitely like to have a port for pre-v7 ARM in the main
> WebKit tree. I think everyone made this clear.

That is great!

> 4) I think it would be good to see if more code and ideas can be
> shared between the two ARM ports. They were made independently, and
> originally in different ways, so let's see what exchange can happen.

Right now the macro-assembler based ARM port is an x86 emulator. It
translates x86 instructions into ARM instruction sequences (usually 1-5
instructions are enough). As ARMv7 port mostly does it, but thumb2 is much
closer to x86 than a RISC architecture (Thumb2 looks like a CISC operation
mode).

> 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 things differently at a
> higher level. x86 is a 2-operand instruction set with optional memory
> operands, and it seems to me a 3-operand load-store architecture might
> want to do things in a different way to get good performance. Making
> them go through a common assembler interface may not work. Ultimately,
> however, the proof is in the performance results. If doing things a
> different way delivers better performance, that is more important than
> maximizing code sharing or architectural purity. That has always been
> the WebKit way.

In case of the ARM-port we have a native implementation and a
MacroAssembler based implementation, and we have already posted
comparisons between them to the bugzilla. Furthermore, we performed some
tests on our XScale simulator, and the native jit'ed code executes 5-40%
less instructions. However, the gain is smaller on the total runtime,
since the jit'ed code takes only a fragment of the total runtime.

Although native jit is faster, we are happy with MacroAssembler as well.

> 6) It seems like the intent with the Szeged arm port and the plan for
> getting it in the tree wasn't clear to all parties involved. For me
> personally, it wasn't clear that there was an intent to contribute it,
> or perhaps even an expectation that we'd just pick it up from the
> external repository where it was developed. Things would have been
> more clear if patches were submitted for review earlier.

We know that such big patches requries several refactoring phases before
they go to mainline, that is why we thought it is a good idea to create a
branch on Staikos where you can take a look at them before we flooded the
WebKit bugzilla with patches.

> 7) It seems like people said some intemperate things during the
> earlier discussion. It also seems like these remarks were based partly
> on misunderstanding. I hope everyone has gotten past that, and that we
> are all ready to work together productively.

True. I feel the communication between us improved a lot. However, I am
still thinking how can we involve others as well. I am pretty sure not
only us are interested in the design decisions we discuss in bugzilla.
Perhaps squirellfish-dev would be a good place for such discussions.

> 8) A number patches from the folks working at University of Szeged
> have been landed. But it seems to me like there has also been a fair
> amount of abandoned work and working at cross purposes. I feel like
> the people working on JavaScript at U of Szeged are not entirely in
> sync with the main JavaScriptCore hackers. You guys have done a lot of
> great work, and I'd like to explore what we can do to get more in sync
> on design direction. Does anyone have suggestions on this front?

Again, this is true. We have no idea what is the general direction of
JavaScriptCore. We can only see landed patches, and predict the ongoing
and future works based on them. However, landed patches are completed
works, and it is usually too late for any contributions when they are
landed. It would be good to discuss things before a work started,
especially design changes, which affects all-ports.

We feel the design dicussions - such it was about ifdefs - would greatly
improve the cooperation between all parties since everybody can feel as a
part of the community.

Thanks,
Zoltan