On Wed, 24 Jan 2001, you wrote:
> Justin Carlson wrote:
> >
> > On Wed, 24 Jan 2001, Pete Popov wrote:
> > > This simple test fails on a Nevada (5231) cpu:
> > >
> > > int main()
> > > {
> > > float x1,x2,x3;
> > >
> > > x1 = 7.5;
> > > x2 = 2.0;
> > > x3 = x1/x2;
> > > printf("x3 = %f\n", x3);
> > > }
> > >
> >
> > Ummm...care to tell *how* it fails?
>
> Here it is:
>
> sh-2.03# ./fl
> x3 = 0.000000
>
>
> I'm running a test9 based kernel, but the same kernel compiled for my
> Indigo2 produces the right result.
Hmmm...the only thing here that should involve kernel support is the lazy FPU
register saving. I'm not terribly familiar with that portion of the kernel,
but it should take an unimplemented instruction trap on the first fpu op, set
up a flag for saving FP state on context switches, enable the FPU, then let the
program run. From what I *have* seen of that code, it's shared between many
processors; doesn't seem like a likely candidate for such a simple problem.
If you compile that code snippet and optimize it with gcc, you actually won't
invoke any fpu ops, as gcc is smart enough to precalculate the result, and
just load that before jumping to printf().
How are you compiling the code? And are you compiling it the same way on both
platforms? Do you have fpu emulation enabled on a kernel that doesn't need it?
These are the potential problems that jump to mind...
-Justin
