Re: [GIT PULL] RISC-V updates for v6.18-rc1

[Paul Walmsley <pjw@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]

On Wed, 8 Oct 2025, Maciej W. Rozycki wrote:

> 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.

Olof is probably referring to support for extensions like Xmipsexectl:

  https://lore.kernel.org/linux-riscv/20250724-p8700-pause-v5-0-a6cbbe1c3412@htecgroup.com/

  https://mips.com/wp-content/uploads/2025/06/P8700_Programmers_Reference_Manual_Rev1.84_5-31-2025.pdf

Xmipsexectl is annoying for at least two reasons:

1. it is a non-conforming RISC-V extension, stepping on existing 
   standardized base RISC-V ISA opcode space; and

2. it brings over new barrier operations straight from the MIPS
   instruction set, rather than just using the standard RISC-V fences

Doing things like this runs additional ecosystem fragmentation risk, which 
impacts all of us, for little apparent gain.  Nevertheless we took these 
patches because their extension includes a custom PAUSE instruction 
variant, and it's understandable that MIPS might have finalized their 
design before Zihintpause.

I hope Xmipsexectl doesn't survive past P8700, and that we never see 
kernel patches to use those leftover MIPS barrier instructions.

>  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.

This one isn't a hypothetical example either; see:

  https://lore.kernel.org/linux-riscv/20250924-riscv-time-mmio-v6-2-9c6158a14b37@htecgroup.com/


- Paul

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv