Re: FP Kernel test added

[Nick Garnett <nickg at ecoscentric dot com>]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> Nick Garnett wrote:
> > Jonathan Larmour <jifl@eCosCentric.com> writes:
> >
> >>Nick Garnett wrote:
> >>
> >>>//==========================================================================
> >>>// Test calculation.
> >>>//
> >>>// Generates an array of random FP values and then repeatedly applies
> >>>// a calculation to them and checks that the same result is reached
> >>>// each time. The calculation, in the macro CALC, is intended to make
> >>>// maximum use of the FPU registers. However, the i386 compiler
> >>>// doesn't let this expression get very complex before it starts
> >>>// spilling values out to memory.
> >>
> >>Surely it's only a good test once we're sure we've spilled some
> >>:-). Perhaps we should have a few more to cover non-x86 FP too (a
> >>check we haven't screwed up and missed off FP registers for example).
> > Possibly. For that I suspect we would have to go down to using
> > assembler to explicitly fill the FPU with known values and test them.
> > It would be difficult to manufacture expressions that cajoled the
> > compiler into doing that.
> 
> What I mean is that it doesn't matter if you spill as long as the FP
> register set is full. At least GCC only saves some registers when it
> needs to (using fst) rather than an fsave of the entire register
> set. And I'm sure that in general the register set will be kept as
> full as possible.

Sadly that doesn't seem to be the case. I couldn't get it to use more
than three or four FP resisters before it started spilling stuff out
to memory. The current expression uses four registers, which was the
best I could do.

> 
> I did notice this though :-)...
> 
> /home/jlarmour/sourceware/ecos/ecos/packages/kernel/current/tests/fptest.c:
> In function `fptest1':
> /home/jlarmour/sourceware/ecos/ecos/packages/kernel/current/tests/fptest.c:176:
> warning: passing arg 1 of `do_test' from incompatible pointer type
> /home/jlarmour/sourceware/ecos/ecos/packages/kernel/current/tests/fptest.c:
> In function `fptest2':
> /home/jlarmour/sourceware/ecos/ecos/packages/kernel/current/tests/fptest.c:194:
> warning: passing arg 1 of `do_test' from incompatible pointer type
> /home/jlarmour/sourceware/ecos/ecos/packages/kernel/current/tests/fptest.c:
> In function `fptest3':
> /home/jlarmour/sourceware/ecos/ecos/packages/kernel/current/tests/fptest.c:214:
> warning: passing arg 1 of `do_test' from incompatible pointer type
>

Doh! I'm sure that sort of thing used to work.


> A final thing is that even on my speedy PC with hardware FP it takes a
> long time. What about simulators with software floating point? Or in
> fact most targets with software floating point? I think the default
> multiplier should probably be 50 for x86 as a special case (since even
> an embedded x86 device is likely to be a lot slower than an 800MHz
> desktop), 10 for almost everything else and 1 for simulators. OK?

Well, the long run time is necessary. I'm relying on timeslices at
random points in the main loops to mix the threads up and expose any
problems. A shorter runtime means less opportunities for that to
happen.

However, I agree that the runtime will be excessive on some
platforms. We should certainly cut it for simulators. Perhaps the
program itself should print out a warning that it might run for a long
time. After all, we don't have to work under the 30s timeout tyrrany
of the test farm any more :-)

> 
> If so I'll fix the warnings at the same time.

Be my guest.


-- 
Nick Garnett - eCos Kernel Architect
http://www.eCosCentric.com/