[webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Fu, Chao-Ying
fu at mips.com
Fri Jun 22 15:19:00 PDT 2012
Hi Filip,
We will be fine, if the MIPS build isn't ok due to new features or changes.
You can go ahead to check in patches for your targets (even with MIPS JIT disabled).
Ex: Suggested by Oliver
http://lists.webkit.org/pipermail/webkit-dev/2012-June/021267.html
We can catch up to fix. This situation happened more than one time since I worked on MIPS JSC.
When I found out the broken build, I just patched the MIPS assembly support.
It's not a burden for us. Thanks a lot!
Regards,
Chao-ying
> -----Original Message-----
> From: webkit-dev-bounces at lists.webkit.org
> [mailto:webkit-dev-bounces at lists.webkit.org] On Behalf Of Filip Pizlo
> Sent: Friday, June 22, 2012 1:07 PM
> To: Zoltan Herczeg
> Cc: WebKit Development
> Subject: Re: [webkit-dev] SH4, MIPS, and legacy-ARM
> assemblers in JavaScriptCore
>
>
> On Jun 22, 2012, at 12:43 PM, Zoltan Herczeg
> <zherczeg at 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
> <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
> >>>
> >>
> >>
> >
> >
> > _______________________________________________
> > 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
>
More information about the webkit-dev
mailing list