benh at kernel.crashing.org
Sat Jun 8 14:31:08 EST 2013
On Fri, 2013-06-07 at 18:13 -0700, Dan Malek wrote:
> Hi Ben.
> On Jun 7, 2013, at 5:34 PM, Benjamin Herrenschmidt
> <benh at 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
> > … 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
> > 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. :)
More information about the Linuxppc-dev