Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Removing the MIPS back-end

74 views
Skip to first unread message

Jan de Mooij

unread,
Apr 12, 2019, 7:20:51 AM4/12/19
to r...@hev.cc, dragan.ml...@rt-rk.com, yuyi...@loongson.cn, JS Internals list
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

Lars Hansen

unread,
Apr 12, 2019, 8:25:29 AM4/12/19
to Jan de Mooij, Rui Wang, Dragan Mladjenovic, yuyi...@loongson.cn, JS Internals list
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
> _______________________________________________
> dev-tech-js-engine-internals mailing list
> dev-tech-js-en...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
>

xwa...@gmail.com

unread,
Apr 15, 2019, 4:58:44 AM4/15/19
to
Hi,

We use Firefox extensively so we really do not want the mips port will be removed. we will fix the error soon and want maintain mips port in the future.

I come from Loongson Technology company in China, Loongson is a company which designs general processors based on mips. The market is focused on China at present. Loongson's official website: http://loongson.cn/index_en.html. The core products of loongson are general processors, so the core software such as firefox are very important for loongson.

Last years, imgtec used to maintain the MIPS port, we mainly cooperate with them to contribute code, and now we only provide firefox52 in our os, so we did not do enough work with spidermonkey inbound branch, but now I think we can do some more in spidermonkey.


thank you.

pfge...@gmail.com

unread,
Apr 15, 2019, 5:14:22 AM4/15/19
to
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(xwa...@gmail.com) and Qiao Pengchen(qiaopen...@loongson.cn) are willing to maintain MIPS branch. We hope that the MIPS branch of SpiderMonkey'Jit will not be removed from the main branch.

Thanks
fei

Kannan Vijayan

unread,
Apr 15, 2019, 12:09:30 PM4/15/19
to pfge...@gmail.com, JS Internals list
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:
https://bugzilla.mozilla.org/show_bug.cgi?id=1401624).

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.

Regards.
Kannan

pfge...@gmail.com

unread,
Apr 16, 2019, 5:05:43 AM4/16/19
to
In the past, the mips port of many open source project including SpiderMonkey and firefox ware maintained by imgtec team. They had done a lot of work and done well. We mainly cooperated with them to do it. In the following work, we will gradually assume the responsibility of the open source community(mips port)including SpiderMonkey and firefox.The bugs will be fixed soon.
Cranelift is a very meaningful project and we will arrange engineers to submit to the mips port as soon as possible. Maybe mipe64el port at first.

Thanks
fei

在 2019年4月16日星期二 UTC+8上午12:09:30,Kannan Vijayan写道:

Mary Rose de Vega

unread,
Apr 16, 2019, 5:36:36 AM4/16/19
to
you really need me
0 new messages