On 12/03/2014 04:52 PM, Leonid Yegoshin wrote:
On 12/03/2014 04:20 PM, David Daney wrote:
On 12/03/2014 03:55 PM, Leonid Yegoshin wrote:
On 12/03/2014 03:44 PM, David Daney wrote:
(...)
Big work
Not really, although by number of lines of code, it is about 3x the
size of your patch, it only touches the existing code in one place. It
only took about 3 days to write, adding full MIPS64 and R6 support
would probably be less than another week of work.
microMIPS I haven't looked at as we don't have anything to test it on.
but it doesn't support customized instructions,
GCC will never put these in the delay slot of a FPU branch, so it is
not needed.
I doubt that it is correct in all situations and with any GCC parameter
combination.
My GCC experts assert that it is true.
Never say never, if it is about toolchain. IMG Arch team was assured
that branch likely are never used and removed it in MIPS R6, but BGEZL
(or so) was a first which I hit then I ran GLIBC.
The fact that the Arch Team designed R6 without bothering to determine
what legacy code does is not relevant to this conversation.
Besides GCC there are LLVM and another JITs.
They don't do it either. But that is not really important. We can
easily emulate faulting instructions if needed.
multiple ASEs,
Same as above. But any instructions that are deemed necessary can
easily be added.
MIPS R6
It is a proof of concept. R6 can easily be added if needed.
Your XOL emulation doesn't handle R6 either, so this is no worse than
your patch in that respect.
You probably didn't research it well. A lot of changes in
arch/mips/kernel/branch.c and and arch/mips/math-emu/cp1emu.c, all of it
related with R6.
I looked at:
commit 3a18ca061311f2f1ee9c44012f89c7436d392117
And I saw no R6 support.
Is it there, or in some other branch that isn't merged?
etc.
GCC will never put trapping instructions in the delay slot either.
It seems like it is not correct and requires a more accurate statement.
FPU instructions may trap, LWL and LWR traps on R6 with RI, etc. Yes,
there are restrictions but basing a kernel on that assumptions is
unsafe. The only safe is HW architecture document.
Finally, there is a manual encoding too.
All we have to support are non-trapping and non-branch/jump
instructions from the ISA manuals that can be executed from userspace
processes. That makes it slightly simpler than complete ISA emulation.
Well, it is still not a replacement of XOL emulation.
For use by the FPU emulator, it is probably good enough
Even close.
I disagree, that is why I took the time to do it.
