[parisc-linux] glibc 2.3.1 - It's alive! - patches

[Carlos O'Donell]

On Tue, Nov 12, 2002 at 10:44:07AM -0500, John David Anglin wrote:
> > > __asm__ __volatile__ ("fmpy,dbl %1,%%fr0,%0\n\t"
> > > 			/* FIXME: is this a proper trap barrier? */
> > > 			"fcpy,dbl %%fr0,%%fr0" : "=f" (d) : "0"(d));

So really the fix is to spill into a third register or a memory location
in order to:

1) Prevent reordering and subsequent discard of the insn
2) Trigger the trap since the result of the register is needed

> 1) You probably want to clear the T bit at the beginning of the
>    routine.  This will ensure that you get the correct exception
>    when the first one is raised.  The only way to do this without
>    potentially causing a pending trap to trigger is with a double
>    word store to floating-point register 0.  You can't read register
>    0 before the write without potentially triggering a trap, so
>    you need to know what the current state should be.  See page
>    10-5 of the PA2 arch manual.

Okie, lets see if I have this right:

1) Routine starts
2) Clear T by reading fr0 and writing back with T=0
	= All other pending delayed exceptions are nulled
3) Setup an exception to occur based on requirements
	= insn writes to dX
4) Trap barrier
	= insn where dX is copied to dY (dX!=dY)

> 2) A fcpy insn should raise an exception if it depends on the
>    result of a pending trapping insn (the current code doesn't).
>    It would be best to not use register 0 or the source register
>    for the destination register since in theory the processor
>    would then know the operation is a nop.  Then, the insn could
>    be reordered or discarded.  The fcpy insn is nice since it
>    is non-arithmetic and doesn't cause an invalid operation
>    exception when a NaN is copied.  The fcmp insn isn't quite
>    as nice since it will generate an invalid operation when one
>    of the values is a signaling NaN, or if the low-order bit
>    of the condition code is 1 and one of the values is an NaN.

I liked the fcpy specifically for that reason. It doesn't itself cause a
recursive triggering of more delayed exceptions, eventually filling the
exception queue and delivering an exception anyway ;)

c.