[webkit-dev] ARM JIT and related issues

[Maciej Stachowiak]

On Jun 16, 2009, at 5:52 PM, Toshiyasu Morita wrote:

> --- 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.

The issues you raise don't seem to have stopped either of the ARM  
ports so they do not seem like fundamental issues.

  - Maciej

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