[Lightning] Re: lightning x86 FP patch

[Matthew Flatt]

At Wed, 02 Jan 2008 12:52:48 +0100, Paolo Bonzini wrote:
> 
> > I think the `opr' on the sixth line should be `op':
> > 
> >         : (rd) == (s2) ? jit_fxch((s2), op((rd) == 0 ? (s1) : (rd), 0))  \
> > 
> > because the argument order is not reversed.
> 
> There is a bug, but your patch would break other cases.  This is the 
> right patch to fix it:
> 
> --- orig/lightning/i386/fp-32.h
> +++ mod/lightning/i386/fp-32.h
> @@ -63,7 +63,9 @@
>             ((s2) == 0 ? opr(0, (rd))                    \
>              : (s2) == (s1) ? jit_fxch((rd), op(0, 0))   \
>              : jit_fxch((rd), op((s2), 0)))              \
> -        : (rd) == (s2) ? jit_fxch((s2), opr((rd) == 0 ? (s1) : (rd), 
> 0))       \
> +        : (rd) == (s2) ? jit_fxch((s2), opr((s1), 0))  \
>           : (FLDr (s1), op((s2)+1, 0), FSTPr((rd)+1)))

I see why my fix wasn't enough, but that still doesn't look right to
me. For one, I think it doesn't work for the case that s1 == 0 (which
is the case in my use) because it replaces s1 with s2 before performing
the operation in that case. Also, I still think the argument are not
reversed, so `op' should be used instead of `opr'.

Maybe, then, it should be

        : (rd) == (s2) ? ((s1) == 0 ? op((s1), (s2)) 
                                    : jit_fxch((s2), op((s1), 0))) \

which works for me, but I don't have a test case for s1 != 0 (where
`op' vs. `opr' comes into play).


Meanwhile, I ran into a deeper problem in my application. As I
understand it, the lightning model of FP operations on x86 effectively
ignores the "stack pointer" of the FP register stack, instead treating
the FP registers like an array that happens to have stack-like
operations. The problem is that the processor keeps track of the stack
state; it notices when you use registers that don't correspond to
pushed values, and it notices if the stack is left with extra data. In
my application, leaving the stack in a bad state causes floating-point
operations to go wrong in code *not* generated by the JIT.

What's the right way around this problem? Maybe JIT-generated code can
safely ignore the stackness of the FP registers, as long as it resets
some flags before returning to code that might care?

My needs are modest enough that I could write the code-generating code
as a pun that works either in FP-stack mode or FP-register mode, but I
doubt that it's a good approach for many other uses.

Matthew