[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2510072335250.7364@angie.orcam.me.uk>
Date: Wed, 8 Oct 2025 00:43:46 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Olof Johansson <olof@...om.net>
cc: Ben Dooks <ben.dooks@...ethink.co.uk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Paul Walmsley <pjw@...nel.org>, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] RISC-V updates for v6.18-rc1
On Thu, 2 Oct 2025, Olof Johansson wrote:
> > Now we’re starting to see commercial cores on the horizon that will have the
> > ability to be endian configured at run-time. For example, MIPS (the company
> > not the ISA) has announced they will be producing cores with configurable
> > endian (https://mips.com/products/hardware/i8500/).
>
> MIPS has been doing some not so awesome things to the RISC-V architecture
> in the last year or so. They've published patchsets that make it seem
> like that they seem to have taken some old MIPS designs and done the
> bare minimal conversion over to RISC-V, since they need their own weird
> system peripherals and hooks. Again, with the burden for everybody to
> maintain because their hardware engineers couldn't bother to develop a
> full proper RISC-V core.
This is obviously a false image. The most recent MIPS ISAs, such as the
microMIPSr6 or the nanoMIPS architecture, and consequently implementations
were absolutely RISC-V-like, with branch delay slots removed, conditional
moves replaced with conditional selects, floating-point condition codes
removed in favour to setting a general register, PC-relative instructions
added and overall being a variable-length compressed instruction set, up
to the point for some company engineers to become disgruntled with the ISA
"losing the MIPS spirit." So it's not that they can't be bothered to make
a full proper RISC-V core, surely they can.
The thing is based on my experience I'm fairly sure it's all just driven
by company customers, which have their legacy MIPS code base or whatever
and want to switch with minimum effort. And for a hardware company to
support a customer it's obviously easier to tweak hardware rather than
software.
NB I doubt it's about peripherals: dropping a different CPU into an
existing system is nothing new and does not require the ISAs involved to
be remotely similar to each other; cf. VAX vs Alpha for example.
> While I'm not happy with the lack of upstreaming from the (mostly
> Chinese) SoC vendors, and we should be encouraging more of them to
> contribute directly, MIPS seems to be making choices that might have
> long term burden for all of us. So far the slope is slippery on the
> system side, but needing to worry about BE support seems to be stepping
> over the line for me without some obvious clear use cases that make sense.
Whether we're going to accept things dumped onto us is another matter.
There's plenty of code downstream that hasn't made it here, and going back
to my examples, we've never got microMIPSr6 support in Linux even though
it used to live downstream, and attempts continue being made to get this
stuff upstreamed across the board. We may or may not choose to accept
bits that make our life tougher, and there have been precedents across
free software, such as the RS6000/PowerPC GCC backend maintainer refusing
to take changes adding support for the VLE instruction set.
FYI and FWIW,
Maciej
Powered by blists - more mailing lists