Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Hi, Just wanted to note, that there is a working MIPS buildslave again: http://build.webkit.org/buildslaves/mips-1 It only does builds, no tests yet, we are working on that. Thank you everyone for your help! Unfortunately, the MIPS build is still red, because the following patch was not yet accepted to trunk (we bounced off of the commit bot the first time because the patch was malformed, but the current one should be fine now): https://bugs.webkit.org/show_bug.cgi?id=97243 We also have a MIPS DFG and LLINT implementation which passes the JSC testsuite and common benchmark suits (sunspider, v8). We are working on cleaning them up for submission. Best Regards, Gergely On Fri, Sep 14, 2012 at 3:01 AM, Gergely Kis gerg...@homejinni.com wrote: Hi, Submitted the patch for enabling the MIPS slave in build.webkit.org. https://bugs.webkit.org/show_bug.cgi?id=96713 Who should I send the buildbot password for the slave? Thanks, Gergely On Thu, Aug 30, 2012 at 9:52 AM, Holger Freyther ze...@selfish.orgwrote: On 08/30/2012 12:10 AM, Gergely Kis wrote: Would this be acceptable for you? sure, an actively and publicly maintained MIPS build would be great. We have some documentation on how to setup a build slave in the wiki[1] and the slave configuration files are maintained in SVN[2]. The configuration file changes follow the normal WebKit contribution procedure. holger [1] http://trac.webkit.org/wiki/BuildBot [2] http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Hi, Submitted the patch for enabling the MIPS slave in build.webkit.org. https://bugs.webkit.org/show_bug.cgi?id=96713 Who should I send the buildbot password for the slave? Thanks, Gergely On Thu, Aug 30, 2012 at 9:52 AM, Holger Freyther ze...@selfish.org wrote: On 08/30/2012 12:10 AM, Gergely Kis wrote: Would this be acceptable for you? sure, an actively and publicly maintained MIPS build would be great. We have some documentation on how to setup a build slave in the wiki[1] and the slave configuration files are maintained in SVN[2]. The configuration file changes follow the normal WebKit contribution procedure. holger [1] http://trac.webkit.org/wiki/BuildBot [2] http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
On 08/30/2012 12:10 AM, Gergely Kis wrote: Would this be acceptable for you? sure, an actively and publicly maintained MIPS build would be great. We have some documentation on how to setup a build slave in the wiki[1] and the slave configuration files are maintained in SVN[2]. The configuration file changes follow the normal WebKit contribution procedure. holger [1] http://trac.webkit.org/wiki/BuildBot [2] http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Hi All, I'd like to inquire about the future of MIPS and SH4 assemblers. A long time ago we had buildbots for MIPS and SH4 platforms (hosted by Holger). But their last builds were at 29th June, machine were stopped, bots were removed from build.webkit.org (2 months before!). Is there anyone interested in maintaining MIPS and SH4 buildbots (and probably EWS bots) to catch build failures early? Gábor is working on fixing https://bugs.webkit.org/show_bug.cgi?id=79040 and it seems the fix will affect all assemblers. But I don't think if it is a good idea to try to fix MIPS and SH4 assemblers blindly without EWS and buildbots. And who knows if MIPS and SH4 builds work now or not? br, Ossy Filip Pizlo írta: 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/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Hi All, We are working on updating WebKit MIPS support. In particular we have a work in progress LLINT and DFG implementation for MIPS. We already have results (mozilla testsuite, sunspider and v8 benchmarks run reasonably well), but there are still some bugs that need to be fixed before we can submit this work. Regarding https://bugs.webkit.org/show_bug.cgi?id=79040, feel free to contact us if you need help with the MIPS specific bits. Regarding the MIPS buildbots: I will check internally if we can host a MIPS build slave (possibly including different boards) for the webkit project, and get back to you. Best Regards, Gergely On Wed, Aug 29, 2012 at 12:35 PM, Osztrogonac Csaba o...@inf.u-szeged.huwrote: Hi All, I'd like to inquire about the future of MIPS and SH4 assemblers. A long time ago we had buildbots for MIPS and SH4 platforms (hosted by Holger). But their last builds were at 29th June, machine were stopped, bots were removed from build.webkit.org (2 months before!). Is there anyone interested in maintaining MIPS and SH4 buildbots (and probably EWS bots) to catch build failures early? Gábor is working on fixing https://bugs.webkit.org/show_**bug.cgi?id=79040https://bugs.webkit.org/show_bug.cgi?id=79040and it seems the fix will affect all assemblers. But I don't think if it is a good idea to try to fix MIPS and SH4 assemblers blindly without EWS and buildbots. And who knows if MIPS and SH4 builds work now or not? br, Ossy Filip Pizlo írta: 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/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Hi All, Before a MIPS buildbot is ready, you can go ahead to change the assembler or any parts of code. We (MIPS) will test new code and submit patches that are required to fix the MIPS JSC build. Don't need to worry about breaking the MIPS build. (I have a cron job that checks out code and builds JSC on a native MIPS Linux every night.) This is the current process that we use, I think. Thanks a lot! Regards, Chao-ying -Original Message- From: Osztrogonac Csaba [mailto:o...@inf.u-szeged.hu] Sent: Wednesday, August 29, 2012 3:35 AM To: WebKit Development Cc: Holger Hans Peter Freyther; Frederic Lepied; Fu, Chao-Ying; Thouraya ANDOLSI Subject: Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore Hi All, I'd like to inquire about the future of MIPS and SH4 assemblers. A long time ago we had buildbots for MIPS and SH4 platforms (hosted by Holger). But their last builds were at 29th June, machine were stopped, bots were removed from build.webkit.org (2 months before!). Is there anyone interested in maintaining MIPS and SH4 buildbots (and probably EWS bots) to catch build failures early? Gábor is working on fixing https://bugs.webkit.org/show_bug.cgi?id=79040 and it seems the fix will affect all assemblers. But I don't think if it is a good idea to try to fix MIPS and SH4 assemblers blindly without EWS and buildbots. And who knows if MIPS and SH4 builds work now or not? br, Ossy Filip Pizlo írta: 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/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
On Wed, Aug 29, 2012 at 12:35:04PM +0200, Osztrogonac Csaba wrote: Hi All, Hi, my two cents. I failed to engage companies building/using the respective architectures and I think the best way forward is to remove them. I am happy to prepare a patch for that. holger PS: Using the proper sender address for webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Hi Holger, We happily and actively maintain the MIPS port for JSC, and will set up new MIPS buildbot soon. If there are other things that we can help, please let us know. Thanks a lot! Regards, Chao-ying -Original Message- From: Holger Hans Peter Freyther [mailto:ze...@selfish.org] Sent: Wednesday, August 29, 2012 12:56 PM To: Osztrogonac Csaba Cc: WebKit Development; Frederic Lepied; Fu, Chao-Ying; Thouraya ANDOLSI Subject: Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore On Wed, Aug 29, 2012 at 12:35:04PM +0200, Osztrogonac Csaba wrote: Hi All, Hi, my two cents. I failed to engage companies building/using the respective architectures and I think the best way forward is to remove them. I am happy to prepare a patch for that. holger PS: Using the proper sender address for webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
On Wed, Aug 29, 2012 at 05:58:10PM +, Fu, Chao-Ying wrote: Hi All, Before a MIPS buildbot is ready, you can go ahead to change the assembler or any parts of code. We (MIPS) will test new code and submit patches that are required to fix the MIPS JSC build. Don't need to worry about breaking the MIPS build. (I have a cron job that checks out code and builds JSC on a native MIPS Linux every night.) This is the current process that we use, I think. Thanks a lot! Hi, more pennies. That is not how the other stakeholders develop inside the WebKit project. There is little to no value for this community if you test behind closed doors. E.g. how can members of this community know that a lack of communication is the lack of issues and not you being reassigned to something else? holger ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
On Wed, Aug 29, 2012 at 05:58:10PM +, Fu, Chao-Ying wrote: Hi All, Before a MIPS buildbot is ready, you can go ahead to change the assembler or any parts of code. We (MIPS) will test new code and submit patches that are required to fix the MIPS JSC build. Don't need to worry about breaking the MIPS build. (I have a cron job that checks out code and builds JSC on a native MIPS Linux every night.) This is the current process that we use, I think. Thanks a lot! Hi, more pennies. That is not how the other stakeholders develop inside the WebKit project. There is little to no value for this community if you test behind closed doors. E.g. how can members of this community know that a lack of communication is the lack of issues and not you being reassigned to something else? holger Sure. Will having new MIPS buildbot help to solve this concern? If yes, then you should not worry because we promise to help on buildbot. Thanks! Regards, Chao-ying ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
On Wed, Aug 29, 2012 at 11:34 PM, Fu, Chao-Ying f...@mips.com wrote: On Wed, Aug 29, 2012 at 05:58:10PM +, Fu, Chao-Ying wrote: Hi All, Before a MIPS buildbot is ready, you can go ahead to change the assembler or any parts of code. We (MIPS) will test new code and submit patches that are required to fix the MIPS JSC build. Don't need to worry about breaking the MIPS build. (I have a cron job that checks out code and builds JSC on a native MIPS Linux every night.) This is the current process that we use, I think. Thanks a lot! Hi, more pennies. That is not how the other stakeholders develop inside the WebKit project. There is little to no value for this community if you test behind closed doors. E.g. how can members of this community know that a lack of communication is the lack of issues and not you being reassigned to something else? holger Sure. Will having new MIPS buildbot help to solve this concern? If yes, then you should not worry because we promise to help on buildbot. Thanks! Regards, Chao-ying Hi Holger, We are working together with MIPS to update and maintain the MIPS port of Webkit. We are setting up a buildbot slave to be integrated with build.webkit.org. First, it will use qemu emulation to run the on-target tests. However, this is only a temporary measure until we get at least one board dedicated to this purpose, then our slave will also execute tests on actual hardware. It is our current plan to have the initial qemu-only slave set up by next week. Should we contact you directly or someone else to get the slave integrated with build.webkit.org? Would this be acceptable for you? Best Regards, Gergely ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
The ARM support for DFG-JIT is finished, and the patch is ready to review at bug 90198. Regards, Zoltan On the topic of JIT support, the baseline JIT's role is increasingly only to serve only to gather profiling data for the DFG JIT, and if you want high performance JavaScript on your platform you need to have the DFG JIT enabled. As the purpose of the two JITs becomes increasingly coupled it may grow difficult to support the baseline JIT alone without the DFG JIT (we already have a maze of ifdefs for the two JITs, two interpreters, assembler support, value profiling support, etc), so any platforms that want to continue to keep a JIT enabled should probably look into supporting the DFG JIT sooner rather than later. cheers, G. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Good for me. Thanks for helping us. This will help to the buildbot maintainers as well, since if a patch cause a break where all of our names are CC'ed, they can just disable the JIT until the fix is landed. I think the several ports of JSC is something we should be proud of and I hope we can keep them in the future. Regards, Zoltan Ah, sorry, I misunderstood! What about having a convention that assembly port maintainers are CC'd on bugs that require new assembler support? This will give you probably 10 hours heads up before the patch lands. -F On Jun 22, 2012, at 9:29 PM, Zoltan Herczeg zherc...@webkit.org wrote: I don't want adding instructions to SH4, MIPS, and legacy ARM to be a blocker for JSC work. I didn't say you have to wait. I just said you should notify us that something is coming which will break the build. Regards, Zoltan ___ 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
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
On the topic of JIT support, the baseline JIT's role is increasingly only to serve only to gather profiling data for the DFG JIT, and if you want high performance JavaScript on your platform you need to have the DFG JIT enabled. As the purpose of the two JITs becomes increasingly coupled it may grow difficult to support the baseline JIT alone without the DFG JIT (we already have a maze of ifdefs for the two JITs, two interpreters, assembler support, value profiling support, etc), so any platforms that want to continue to keep a JIT enabled should probably look into supporting the DFG JIT sooner rather than later. cheers, G. On Jun 23, 2012, at 7:12 AM, Zoltan Herczeg wrote: Good for me. Thanks for helping us. This will help to the buildbot maintainers as well, since if a patch cause a break where all of our names are CC'ed, they can just disable the JIT until the fix is landed. I think the several ports of JSC is something we should be proud of and I hope we can keep them in the future. Regards, Zoltan Ah, sorry, I misunderstood! What about having a convention that assembly port maintainers are CC'd on bugs that require new assembler support? This will give you probably 10 hours heads up before the patch lands. -F On Jun 22, 2012, at 9:29 PM, Zoltan Herczeg zherc...@webkit.org wrote: I don't want adding instructions to SH4, MIPS, and legacy ARM to be a blocker for JSC work. I didn't say you have to wait. I just said you should notify us that something is coming which will break the build. Regards, Zoltan ___ 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
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
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
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Hi, We (STMicroelectronics) are the maintainer of SH4 port. We would like to continue maintaining it. Could you please let me know what we need to do ? and feel free to assign for me any bug related to SH4. Regards, Thouraya. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
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
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
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
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
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
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
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? 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
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
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
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
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-boun...@lists.webkit.org [mailto:webkit-dev-boun...@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 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
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
I don't want adding instructions to SH4, MIPS, and legacy ARM to be a blocker for JSC work. I didn't say you have to wait. I just said you should notify us that something is coming which will break the build. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Ah, sorry, I misunderstood! What about having a convention that assembly port maintainers are CC'd on bugs that require new assembler support? This will give you probably 10 hours heads up before the patch lands. -F On Jun 22, 2012, at 9:29 PM, Zoltan Herczeg zherc...@webkit.org wrote: I don't want adding instructions to SH4, MIPS, and legacy ARM to be a blocker for JSC work. I didn't say you have to wait. I just said you should notify us that something is coming which will break the build. Regards, Zoltan ___ 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
