Re: Fixing MIPS delay slot emulation weakness?

On Sun, Dec 16, 2018 at 10:13 AM Rich Felker <[email protected]> wrote:
>
> On Sun, Dec 16, 2018 at 01:50:13PM +0000, Maciej W. Rozycki wrote:
> > On Sat, 15 Dec 2018, Rich Felker wrote:
> >
> >
> >  It doesn't help that information about that is scattered across many
> > documents.  You can check for the NODS flag in the opcodes library from
> > binutils though, which is almost 100% accurate, except for the SYNC
> > instructions, for semantic reasons (i.e. they are allowed, but we don't
> > want GAS to reorder them).  Most of the disallowed stuff is in the
> > microMIPS instruction set, due to encodings that execute as hardware
> > macros.
>
> I think it suffices to emulate what compilers generate in delay slots,
> which should be fairly minimal and stable. At the very least we could
> enumerate everything GCC and LLVM already emit there, and get them to
> upstream a policy of not adding new insns as fpu-delay-slot-allowed.
> If someone is writing asm by hand to do ridiculous things in the delay
> slot with random ISA extensions, they shouldn't expect it to work.
>

I feel like I have to ask: the real thing preventing emulation is that
new nonstandard instructions might get used in FPU delay slots on
non-FPU-supporting hardware?  This seems utterly nuts.  If you're
using custom ISA extensions, why on Earth are you also using emulated
floating point instructions?  You're targetting a specific known CPU
if you do this, so you should use only instructions that actually work
on that CPU.