[webkit-dev] ARM JIT and related issues

[Toshiyasu Morita]

--- On Wed, 6/17/09, Maciej Stachowiak <mjs at 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 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.

The porting problem IMHO isn't the number of operands. The problem is the JIT design assumes a CISC processor with the following characteristics:

1) call/return instructions which store the return address on the stack as on the x86 processor. If the target processor doesn't do this, then this requires a huge amount of work.

2) The JIT performs relocations in a kludgy way. Some relocations are performed before the code is copied to the final location, and some relocations after. Also, it's not clear which relocations are within a single code block, and which go across code blocks, so the generated code needs to assume the worst case if the target processor has a limited number of bits for relative branches.

3) JIT assumes the call instruction does not need to have the call address loaded into a register, which is the cause of the current bug I'm debugging. The JIT generates code which calls another call instruction directly instead of calling the previous two instructions which loads the call address into the register.

I could go on and on, but you get the idea. Basically, the current JIT design akes a large number of x86/CISC target architecture assumptions.

Toshi




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090616/7ce1d1e6/attachment.html>