On Mon, Oct 6, 2014 at 5:28 PM, Andrew Pinski <pinskia@xxxxxxxxx> wrote: > On Mon, Oct 6, 2014 at 5:21 PM, Rich Felker <dalias@xxxxxxxx> wrote: >> On Mon, Oct 06, 2014 at 05:11:38PM -0700, Andrew Pinski wrote: >>> On Mon, Oct 6, 2014 at 5:05 PM, Rich Felker <dalias@xxxxxxxx> wrote: >>> > On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote: >>> >> On 10/06/2014 04:38 PM, Andy Lutomirski wrote: >>> >> >On 10/06/2014 02:58 PM, Rich Felker wrote: >>> >> >>On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote: >>> >> [...] >>> >> >>This is a huge ill-designed mess. >>> >> > >>> >> >Amen. >>> >> > >>> >> >Can the kernel not just emulate the instructions directly? >>> >> >>> >> In theory it could, but since there can be implementation defined >>> >> instructions, there is no way to achieve full instruction set >>> >> coverage for all possible machines. >>> > >>> > Is the issue really implementation-defined instructions with delay >>> > slots? If so it sounds like a made-up issue. They're not going to >>> > occur in real binaries. Certainly a compiler is not going to generate >>> > implementation-defined instructions, and if you're writing the asm by >>> > hand, you just don't put floating point instructions in the delay >>> > slot. >>> >>> It is not the instruction with delay slot but rather the instruction >>> in the delay slot itself. >> >> An instruction in the delay slot for the instruction being emulated? >> How would that arise? Are there floating point instructions with delay >> slots? > > Yes branches. I admit I have no idea what's going here, but I find it hard to believe that having the kernel fix this up for new code is desirable. Unless MIPS can round-trip a trap *very* quickly, performance will be awful for any code that has this problem. --Andy
