On 10/06/2014 05:29 PM, Andy Lutomirski wrote:
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.
It is FPU *emulation*, of course the performance will suck. We don't
care about performance, we just want it to execute correctly.
David Daney
