[webkit-dev] arm jit

[Zoltan Herczeg]

Hi guys at Apple,

it looks we are in the way of the train. You have plans, we don't know
about them, you have commit rights, we don't, so the tides are against us.
Hints on the mailing lists are scarce, although a year ago someone from
you asked whether others are interested in design discussions, we said
'yes', nothing really changed. Except some simple bugfixes, new patches of
ours do not really get into the mainline (except some of our best ideas
reimplemented by someone else). Partially this is due to the lack of
information and roadmap of JavaScriptCore. That is why I feel the missing
of the real openness.

And here, I have to make a short comment on the non-acceptance of our ARM
JIT implementation. In your mail you mention that you would remain
reluctant to accept a duplicate of the JIT into the tree, rather than a
port of the existing JIT utilizing the MacroAssembler abstraction. Well,
did you check our ARM port? It has been rewritten to conform to the
MacroAssembler interfaces more than a month ago and posted it into the
bugzilla (https://bugs.webkit.org/show_bug.cgi?id=24986).

Anyway, we have updated the MacroAssembler-based ARM port of ours,
uploaded it to the bugzilla, and set the review flag on the patch.

Regards,
Zoltan

> On Jun 9, 2009, at 2:38 PM, Akos Kiss wrote:
>
>> Dear Community,
>>
>> Today, we realized that there is a new ARM JIT port for WebKit.
>> (http://trac.webkit.org/changeset/44514
>> ) Congratulations on getting this working!, great job.
>
> Hi Akos,
>
> Thank you!  Just to clarify, we have just landed a ARMv7 architecture
> (thumb2) JIT backend into ToT.  I say ARMv7 to distinguish this port
> from the ARM application instruction set found in the ARMv6
> architecture and earlier (as I believe would be a common understanding
> of the term ARM, and and which I believe your port targets).  Thumb2
> in ARMv7 is, of course, a very different instruction set to the
> traditional 32-bit instructions found in ARM – with completely
> different machine encodings, and significantly different capabilities
> (e.g. two operand versus three operand instructions, sizes of
> immediate operands, and options for instruction predication).  For the
> JIT to be able to run on both ARM and ARMv7 platforms, it needs to be
> ported to both architectures – in much the same way the the JIT is
> ported to both the x86 and x86-64 platforms.
>
> Obviously there is a great deal of similarity on the surface between
> ARM and ARMv7, but in terms of the JIT implementation that may well
> only be true above the level of the MacroAssembler interface.  There
> may be some limited opportunities to share code within the Assembler
> classes (register numbering enums, and possibly types describing
> immediate operands), but since the assembler is primarily concerned
> with formatting machine instructions, and since the instruction
> encodings are different, it seems likely the bulk of the code will
> have to remain separate.  Again, the differences in instruction
> selection options available on the two architectures will likely make
> it hard to share code within the MacroAssember (different numbers of
> operands to many common instructions, and the options when working
> with large immediate values particularly spring to mind).  We would
> certainly want to share code and avoid any duplication where ever it
> makes sense to do so.
>
>> I cannot conceal how disappointed I am, as is the whole team at
>> Szeged.
>
> I am very sorry to hear this.  If you look at the patches that landed
> into ToT there were very few changes made outside of the new assembler
> classes which, for the reasons described above, I think are highly
> unlikely to have much in common on the two platforms.  The changes
> that have been made to common code outside of the assemblers should
> only help in removing x86 dependencies and assumptions that had
> existed in the code. I strongly urge you to review the changes that
> have been made, as I hope and believe you will find that they will
> assist the team in integrating your ARM port.
>
>> Of course, we've felt that you were reluctant to accept our
>> implementation.
>
> We were (and remain) reluctant to accept a duplicate of the JIT into
> the tree, rather than a port of the existing JIT utilizing the
> MacroAssembler abstraction.  We are concerned that it would be
> extremely difficult to continue to maintain such a port as we move the
> JIT technology forwards.  Beyond that, they key barrier to the ARM JIT
> being accepted into WebKit is that there simply haven't been any
> patches put forwards for us to review!  (I'm sorry, I'm aware you have
> provided a link to an external git repository, but I'm afraid we
> really can't seek through version control systems to find changes to
> review – we do need contributors to attach patches to bugs, and we
> need a review flag setting to indicate when the contributor believes
> their patch is ready.  If there is any uncertainty as to the
> procedure, please see http://webkit.org/coding/contributing.html .)
>
>> - Are you still looking for patches, bug reports, feature requests,
>> etc., or is it all in vain - you will get everything done in house?
>
> Yes!   Please do so, this is only way your changes will get into the
> tree.
>
>> - Should we ask for credits in the new files, as it was done by you
>> when we first published our JIT implementation? I'm quite sure that
>> we can state the same argument: "a number of the new files appear to
>> have taken large chunks of logic from existing jit files".
>
> The new files were derived from their x86 counterparts, with reference
> to the ARMv7 manuals.  As such the existing copyright notifications
> within the files from which they were derived have been retained.
>
> (Apologies for the slow reply, we have a busy week with WWDC on!)
>
> cheers,
> G.
>
>
>>
>> Best regards,
>> Akos
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>