[Webkit-unassigned] [Bug 24986] ARM JIT port

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=24986





------- Comment #52 from barraclough at apple.com  2009-06-25 02:44 PDT -------
Hi Zoltan, terribly sorry for the slow response, busy week.

It's really great to hear that that you can generalize your constant pool, and
I can buy your argument for keeping it at a lower level.  All sounds good to
me!

As a quick comment on the MacroAssembler syntax, the goal is not necessarily to
stick to x86 syntax, the idea is really that it is generally often much easier
to break down richer semantic operations into a sequence of instructions than
it is to spot sequences of more primitive atoms from a more minimalist
interface that can be combined to form complex operations (which is not to say
that peephole optimizations that can coalesce instructions would not be a
potentially useful thing to have, just that to do so well is hard, and that we
don't want to pass up on an easy opportunity to provide richer semantic
information that a MacroAssembler implementation might be able to make use of).

The syntax of the MacroAssembler is of course very heavily influenced by the
fact that the JIT was first developed on x86, and the fact that the majority of
browsing takes place on x86 platforms would likely seem to be a good reason for
it to continue to have some bearing on the design.  Also, since the goal of the
interface is to be semantically rich (but within reason – we want to stick to
something that is relatively straightforward to generate on all platforms), and
since x86 is of the richer instruction sets we're likely to port the JIT to, it
would seem likely to me that there is a good chance it will continue to look
fairly close to x86 in some aspects.

That said, we are certainly open to reasonable changes that expand the
interface to allow us to take advantage of other architectures.  An obvious
example on ARM would be conditional execution, and I would imagine that we
should be able to find ways that we could allow the MacroAssemblerARM to take
advantage of that without it being overly burdensome for other architectures. 
For example, we could add method to plant a short forwards branch, which could
be linked like a regular Jump/Label on architectures other than ARM.  On ARM
you could omit to plant the branch and inversely predicate instructions until
the branch was linked.  We could potentially make it an interface requirement
that within such a construct certain operations (other branches, 'set'
operations, etc) could not be used, if this were required to make the pattern
useful.

At some point we will likely also want to switch the interface for arithmetic
operations from two operand to three operand, to better support architectures
that can make use of this.  I believe ARMv6 is mostly 2 operand like x86? - in
these cases the MacroAssemblers will need be able to generate a extra move
where the register to contain the result is not the same as one of the
operands.  This may also open up more code generation options on ARM, for
example where an immediate operand to an add must be loaded from a constant
pool, and the result register is not the same as the operand register, it may
be more optimal to load directly into the result register and then add onto
that value.

Hope this all makes sense & helps clarify our thinking!

G.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.