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:
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
I doubt that it is correct in all situations and with any GCC parameter
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.
Besides GCC there are LLVM and another JITs.
Same as above. But any instructions that are deemed necessary can
easily be added.
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.
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
I disagree, that is why I took the time to do it.