There are significant constraints that are being imposed on other parts of
the codebase to support this extra architecture branch. From the
perspective of a production spidermonkey build, it often lags behind in
feature support, correctness, and bugfixes. It imposes API requirements on
the masm, and requires work whenever there are cross-system patches (e.g.
changing the boxing format as in:
With the current design, every additional CPU architecture imposes a cost
on all the other implementations (mostly due to API changes needed, and
convoluted expression of concepts shared across all of them). The ideal
way to move forward with MIPS would be to shift development towards a
general code-generator backend that can support multiple architectures.
To the longsoon stakeholders: would there be openness to considering
contributing a MIPS codegen implementation to CraneLift (
https://github.com/CraneStation/cranelift)? The team is interesting to
eventually transitioning to a single codegen backend. It's not on the
immediate roadmap due to priority, but we intend on moving in that
direction as opportunity allows. If we can find some common path on the
roadmap that allows us to reduce the independent maintenance burden of the
architecture, we can manage support for this architecture much better.
On Mon, Apr 15, 2019 at 5:15 AM wrote:
> Hi all
> I am in charge of browser development in Loongson technology. In the past,
> we have done a lot of work based on Firefox and SpiderMonkey for our
> customers and contributed a lot of code in these communities. Our company
> is willing to invest more resources to maintain the MIPS branch, including
> SpiderMonkey and Firefox. My colleague YuYin（firstname.lastname@example.org） and Qiao
> Pengchen(email@example.com) are willing to maintain MIPS
> branch. We hope that the MIPS branch of SpiderMonkey'Jit will not be
> removed from the main branch.
> dev-tech-js-engine-internals mailing list