[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181216181137.GF23599@brightrain.aerifal.cx>
Date: Sun, 16 Dec 2018 13:11:37 -0500
From: Rich Felker <dalias@...c.org>
To: Paul Burton <paul.burton@...s.com>
Cc: Andy Lutomirski <luto@...nel.org>,
Linux MIPS Mailing List <linux-mips@...ux-mips.org>,
LKML <linux-kernel@...r.kernel.org>,
Paul Burton <paul.burton@...tec.com>,
David Daney <david.daney@...ium.com>,
Ralf Baechle <ralf@...ux-mips.org>,
James Hogan <jhogan@...nel.org>
Subject: Re: Fixing MIPS delay slot emulation weakness?
On Sat, Dec 15, 2018 at 09:26:45PM +0000, Paul Burton wrote:
> > The really nice but less compatible fix would be to let processes or
> > even the whole system opt out by promising not to put anything in FPU
> > branch delay slots, of course.
>
> The ultimate fix comes with a switch to the nanoMIPS ISA which has no
> delay slots :)
I don't understand the MIPS position that introducing new ISAs
(including silently-new like r6) and not supporting or deprecating
support for the old one is a solution to anything. If one doesn't care
about the ability to run existing binaries for your platform, one
might as well switch to RISC-V or ARM or whatever. The whole advantage
of an ISA as a "platform" is the ability to run existing software and
use existing tooling (not just compilers; think also JITs, FFI
frameworks, etc), not any particular design advantage the ISA has.
Rich
Powered by blists - more mailing lists