On the one hand the MIPS port introduces a number of complexities in the JITs that would disappear with the port (MIPS atomics are a pain point for me because they are more limited than on our other platforms and need more registers) and I would welcome that.
On the other hand, those changes are more painful to put back in than they are to take out and they're currently a sunk cost anyway, so we had better be sure MIPS is not coming back. I'm not completely sold on that; MIPS is going openish-source (mipsopen.com) and may see a resurgence. Indeed if you asked me to pick between open-source MIPS and RiscV I would probably be most tempted to go for MIPS. That said, somebody would have to support the JITs and the last year or more we've had very few contributions, so I'm generally sympathetic to removal. And on the third hand, it might be easier to re-introduce a MIPS port via Cranelift. --lars On Fri, Apr 12, 2019 at 1:20 PM Jan de Mooij <jdemo...@mozilla.com> wrote: > Hi all, > > The MIPS code for SpiderMonkey's JITs has been broken for a while now and > there has been some discussion about removing it. Even though it was never > a Tier 1 platform, MIPS support still affects code elsewhere in the engine > (things like condition codes for example) and people still spend time > implementing and fixing MIPS code when making platform-specific changes. > Future changes like Cranelift integration likely also require significant > MIPS work. > > Given all this, I'd like to propose removing the MIPS code two weeks from > now. Let me know if you have any questions or concerns. > > Thanks, > Jan > _______________________________________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
