On Jun 22, 2012, at 12:43 PM, Zoltan Herczeg <zherc...@webkit.org> wrote:
> True, most of the changes are trivial. The problem is that the changes are > usually appear without prior notice. A patch which depends on new macro > assembler instructions, will obviously break the build, and we are not > necessary there to fix it immediately. I think most improvements require > time to finish, so these new instructions are known several days before > the patch is submitted to the bugzilla. If we would know about these new > instructions before the patch appears, we could prepare the macro > assembler to handle them. Would it be possible to share us these new > requirements before such patches appear? I don't want adding instructions to SH4, MIPS, and legacy ARM to be a blocker for JSC work. -F > > Regards, > Zoltan > >> 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 <oli...@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@lists.webkit.org >>>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> webkit-dev mailing list >>>>> webkit-dev@lists.webkit.org >>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org >>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev