On Fri, 2013-06-07 at 18:13 -0700, Dan Malek wrote: > Hi Ben. > > On Jun 7, 2013, at 5:34 PM, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > > The question is whether this is still relevant ? > > The only answer I could provide is that it's dependent upon the > libraries and how the distributions are built. It's also dependent > upon processors with hardware FP that don't implement all instructions > in hardware (who had that bright idea? :)) If distributions are fully > all soft-fp in user space or all hardware FP, it removes the one > reason that started the whole partial emulation option.
I'm not questioning the relevance of math-emu as a whole, but of the tiny subset which is duplicated in math-emu and softemu8xx, which emulates only load/stores/fmr. If userspace is built with hard FP it is likely to use more than just those handful of instructions... > > … And if the answer is > > yes, > > There are multiple options, but I believe they are solved today. One > is the libraries coded with hardware load/store that are used by > soft-fp, another is hardware FP that doesn't implement all > instructions in hardware (which it seems is the basis of this thread, > although I thought was already solved). Yes, it's indeed the basis of that thread, and yes, I though it was already solved as well but unless I missed something it is not, because the current Program Check handler calls do_mathemu without first flushing the hard FP state into the thread_struct. However it's quite possible (I'll test when I get back to the office) that this it the only fix necessary, which is a one liner, to make CONFIG_MATH_EMULATION work just fine in that case. > The variation here is that in the first case you have to read/write > user space soft-fp stack "registers," while in the latter you > read/write real FP registers. We never do any "user space soft-fp stack registers" handling in the kernel. If we use full math emu (ie, no FP at all in HW), we simply use the normal thread_struct storage of FPRs to store the "virtual" user FP regs used by the emulation. If use space uses full soft-fp (ie, -msoft-float), we should never see any of it in the kernel. > There used to be the third variation where the stack was allocated > and the emulation had to write both places due to compiler function > APIs or optimizations. Of course, then there is the full-up kernel > emulation where hardware is entirely lacking. I don't know anything about that "3rd option", it certainly doesn't have any kernel impact that I can see :-) Full up emulation is of course still there. > > … we still want that "minimum" emulation of load/stores/fmr as an > > option, is there any reason why we can't replace the one in > softemu8xx > > with the existing (and unused) equivalent in do_mathemu ? > > It appears to me that 8xx custom code can be removed. I guess I > should try to boot it up, if anyone even cares these days. :) Thanks, Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
