On Sun, Dec 16, 2018 at 10:13 AM Rich Felker <dalias@xxxxxxxx> 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.
