lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ