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

[bugzilla-daemon at webkit.org]

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


akiss at inf.u-szeged.hu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |akiss at inf.u-szeged.hu




------- Comment #4 from akiss at inf.u-szeged.hu  2009-04-02 03:10 PDT -------
(In reply to comment #3)

Hi Oliver,

Now, I try to present our view on the issue. There were two main modules of JSC
we had to modify, the assembler and the JIT.


To the assembler, we added two new files:

ARMAssembler.h: This contains only C++ functions that deal with the ARM
instruction set. This code is ours for sure.

MacroAsseblerARM.h: This contains a simple class wrapping pointers. Here, we
could not reuse the AbstractMacroAssembler for ARM since it is quite
x86-focused.


In the jit module, there are 7 new files:

CommonJIT.h: This file contains platform-specific macros that are required
because of the differences in the x86 and ARM JITs.

ARMCompiler{.h,.cpp}: Basically, this is where the generated machine code
instructions are stored. In your implementation, this functionality is
implemented in the AssemblerBuffer. However, we go further than simply storing
the instructions. We maintain a constant pool and post-optimize branches.
Moreover, because of the pecularities of ARM, labels and branches are built and
stored in a different manner than done for x86. The x86 jit has no element of
similar functionality.

ARMJIT{.h,.cpp}: This converts byte code to machine instructions. The
high-level approach is similar to that used in x86, but this is defined/fixed
by the interface we had to implement. We did not want to diverge from that.
However, on the low-level, the logic of the implementation is ARM-specific. The
x86 JIT was not reusable at that level. Where we do resemble that code is the
name of the functions.

ARMJITStubFunctions.cpp: This is our own idea. x86 JIT contains nothing alike.

ARMJITPropertyAccess.cpp: This is the place where you might be right. This code
resembles the most to the origial JITPropertyAccess. This contains the least
ARM-specific optimizations. Here, we are ready to add Apple copyrights.


Additionally, we added an extra file into wtf as well:

WTF/Tape.h: This is an auxiliary data structure. Idea and implementation is
ours alone.


Basically, I do not think that implementing an interface implies copyrights on
the implementation for the owner of the interface, do you? So, now you see our
perspective. May I ask you to point our where you do not agree with our
explanations above?


Regards,
Akos, Gabor, and Zoltan


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