[webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Oliver Hunt]

That would be the ifdef hell we currently deal with. 

One option (that would keep everything building till appropriate people have fixed whatever needs to be fixed) would simply be to disable the JIT for effected platforms everytime something changes that is too difficult for us to blindly fix.  Then people with appropriate hardware and toolchains could make the (probably trivial) changes required to bring them up again.

--Oliver

On Jun 22, 2012, at 11:20 AM, Maciej Stachowiak wrote:

> 
> Is there a way to reduce these costs other than deleting the slower-maintained JITs? For example, could we temporarily freeze the JIT (perhaps the whole JSC engine somehow) at old versions somehow for architectures that may take time to catch up?
> 
> Regards,
> Maciej
> 
> On Jun 22, 2012, at 10:52 AM, Oliver Hunt <oliver at apple.com> wrote:
> 
>> The problem is that as we make changes we end up breaking the SH4, MIPS, ARMvOld builds, which we are ostensibly not allowed to do, and so have to spend significant amounts of time trying to ensure that the builds don't break/start failing horribly, and then having committed the patch[es] we have to spend multiple build bot cycles discovering all the cases that we missed.
>> 
>> This consumes a lot of time that would be better spent working on the higher level portions of the JIT, that benefit all platforms.
>> 
>> --Oliver
>> 
>> On Jun 21, 2012, at 11:44 PM, Zoltan Herczeg wrote:
>> 
>>> Hi Filip,
>>> 
>>> we (Gabor Loki and me) are the maintainers of the traditional ARM port,
>>> and we are willing to fix all issues. Just let us know what we need to do.
>>> You can assign the necessary bug reports to us and we are available in the
>>> #squirrelfish (or #webkit) channel as well.
>>> 
>>> Regards,
>>> Zoltan
>>> 
>>>> Hi all,
>>>> 
>>>> We are actively trying to improve the WebKit JavaScript engine
>>>> (JavaScriptCore), with new debugging, profiling, memory efficiency, and
>>>> performance features.  Because JavaScriptCore is a JIT-based engine, this
>>>> inevitably means doing JIT work, which in turn includes adding new
>>>> instructions to the JIT assemblers and changing the API between the
>>>> assemblers and the JIT.
>>>> 
>>>> Currently, the maintenance situation in the assembler layer is not great.
>>>> We have three well-supported assemblers, X86-32, X86-64, and ARMv7. Then
>>>> we have three assemblers that appear to be on life support: legacy
>>>> (non-THUMB2, pre-v7) ARM, SH4, and MIPS.  It is increasingly painful to
>>>> maintain these three barely-supported assemblers.  None of these
>>>> assemblers has been updated to support the new JIT or interpreter
>>>> infrastructure, and there appears to be no ongoing effort to do so.  That
>>>> means that for progress to be made on X86 and ARMv7, we need to
>>>> increasingly scatter #if ENABLE(...) noise throughout the system to keep
>>>> those other assemblers building.  Neither the active JavaScriptCore
>>>> contributors, nor those running the bots for those hardware platforms,
>>>> appear to have much interest in maintaining those assemblers, other than
>>>> the occasional build fix.
>>>> 
>>>> This is not a good situation to be in.
>>>> 
>>>> So, I am curious: is anyone shipping with the legacy ARM assembler, the
>>>> MIPS assembler, or the SH4 assembler?
>>>> 
>>>> As a secondary question, if you are shipping the legacy ARM assembler, are
>>>> you doing so because you have legacy ARM hardware or because you have not
>>>> had the chance to switch to the new ARM assembler in your codebase?
>>>> 
>>>> -Filip
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>