[ECOS] Two questions about testing.

[ECOS] Two questions about testing.

[Sergei Organov]

Well, I've implemented FPU support in the PowerPC HAL (using MIPS FPU support
as template). Now I'd like to test it.

1. Are there any tests that will likely to fail if something is broken in the
   HAL FPU? How do you test MIPS FPU support?

2. Is there any tool that helps to automate testing (run multiple tests in
   turn) under Linux? I've taken a look into the 'host' part of anon cvs and
   found the directory 'tools/ecostest', but when I build host tools only
   'ecosconfig' is built, nothing else. Documentation seems to describe only
   Windoze way to run tests. Am I missing something?

Thanks in advance,
Sergei Organov.

Re: [ECOS] Two questions about testing.

[Jonathan Larmour]

Sergei Organov wrote:
> 
> Well, I've implemented FPU support in the PowerPC HAL (using MIPS FPU support
> as template). Now I'd like to test it.
> 
> 1. Are there any tests that will likely to fail if something is broken in the
>    HAL FPU? How do you test MIPS FPU support?

Math library tests? Some stdio tests also use floating-point.

If you wanted to write and contribute some new tests, naturally we'd be
grateful :-).

> 2. Is there any tool that helps to automate testing (run multiple tests in
>    turn) under Linux? I've taken a look into the 'host' part of anon cvs and
>    found the directory 'tools/ecostest', but when I build host tools only
>    'ecosconfig' is built, nothing else. Documentation seems to describe only
>    Windoze way to run tests. Am I missing something?

No, it's currently Windows only right now. But I know we're working on
releasing a Unix version, but we're not there yet.

Simon? Any status on this, or is it still work in progress?

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

[ECOS] Motorola ColdFire 5204

[Robert H. Miller]

Does  Ecos run on the Motorola coldfire 5204?

Thanks
Robert Miller
---------------------------------------------------------------------
Robert H. Miller				Office: (734)764-6573
University of Michigan	Aerospace Engineering	Lab:	(734)764-5740
1320 Beal FXB 2022	Ann Arbor, MI 48109	Fax: 	(734)763-0578

Re: [ECOS] Motorola ColdFire 5204

[Bart Veer]

>>>>> "Robert" == Robert H Miller <rhmiller@engin.umich.edu> writes:

    Robert> Does Ecos run on the Motorola coldfire 5204?

So far nobody has contributed such a port, and there are no immediate
plans for Red Hat to work on it either.

Bart Veer // eCos net maintainer

Re: [ECOS] Two questions about testing.

[Jesper Skov]

>>>>> "Jonathan" == Jonathan Larmour <jlarmour@redhat.co.uk> writes:

Jonathan> Sergei Organov wrote:
>>  Well, I've implemented FPU support in the PowerPC HAL (using MIPS
>> FPU support as template). Now I'd like to test it.
>> 
>> 1. Are there any tests that will likely to fail if something is
>> broken in the HAL FPU? How do you test MIPS FPU support?

Jonathan> Math library tests? Some stdio tests also use
Jonathan> floating-point.

Jonathan> If you wanted to write and contribute some new tests,
Jonathan> naturally we'd be grateful :-).

That would be nice. Specifically, with FPU support we'd want to test
that nothing breaks if multiple threads are sharing the FPU.  Most of
the libm tests only use a single thread, so they wouldn't be exercise
the HAL FPU context switch code very well.

Jesper

Re: [ECOS] Two questions about testing.

[Sergei Organov]

Jesper Skov <jskov@redhat.com> writes:
> >>>>> "Jonathan" == Jonathan Larmour <jlarmour@redhat.co.uk> writes:
> 
[...]
> Jonathan> If you wanted to write and contribute some new tests,
> Jonathan> naturally we'd be grateful :-).
> 
> That would be nice. Specifically, with FPU support we'd want to test
> that nothing breaks if multiple threads are sharing the FPU.  Most of
> the libm tests only use a single thread, so they wouldn't be exercise
> the HAL FPU context switch code very well.

Well, maybe I'll make one after I figure out why 'asin' test halts half its
way as soon as I build all with -mhard-float flag :-( Hopefully it just causes
floating point exception at some value from the test vector, and the exception 
isn't yet handled properly.

I think the test for HAL FPU support should run 3 threads at the same
priority level that are time-sliced. Two of these threads should perform
floating point computations, and one should not use floating point (to test
not yet implemented lazy FPU context switches). I also think this test belongs 
to 'hal/common' set.

Any comments?

Sergei.

Re: [ECOS] Two questions about testing.

[Jonathan Larmour]

Sergei Organov wrote:
> 
> I think the test for HAL FPU support should run 3 threads at the same
> priority level that are time-sliced. Two of these threads should perform
> floating point computations, and one should not use floating point (to test
> not yet implemented lazy FPU context switches). I also think this test belongs
> to 'hal/common' set.
> 
> Any comments?

A test involving kernel threads should live in kernel/, even though the
functionality being tested is in the HAL. If you put it in hal/common you'd
still have to make it conditional on CYGPKG_KERNEL anyway.

Also, while not an absolute requirement, if you could avoid using libm
functions that would be good so the test can still run if libm is disabled.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Two questions about testing.

[Sergei Organov]

Jonathan Larmour <jlarmour@redhat.co.uk> writes:
> Sergei Organov wrote:
> > 
> > I think the test for HAL FPU support should run 3 threads at the same
> > priority level that are time-sliced. Two of these threads should perform
> > floating point computations, and one should not use floating point (to test
> > not yet implemented lazy FPU context switches). I also think this test belongs
> > to 'hal/common' set.
> > 
> > Any comments?
> 
> A test involving kernel threads should live in kernel/, even though the
> functionality being tested is in the HAL. If you put it in hal/common you'd
> still have to make it conditional on CYGPKG_KERNEL anyway.

Ok, got it.

> 
> Also, while not an absolute requirement, if you could avoid using libm
> functions that would be good so the test can still run if libm is disabled.

I believe trivial FPU operations like +,-,*,/ would be enough, so nothing from
math library will be involved. As far as I remember, even if target doesn't
support '*' or '/', the support code resides in the "libgcc.a"

Sergei.

Re: [ECOS] Two questions about testing.

[Jonathan Larmour]

Sergei Organov wrote:
> 
> > Also, while not an absolute requirement, if you could avoid using libm
> > functions that would be good so the test can still run if libm is disabled.
> 
> I believe trivial FPU operations like +,-,*,/ would be enough, so nothing from
> math library will be involved. As far as I remember, even if target doesn't
> support '*' or '/', the support code resides in the "libgcc.a"

Yep. Another thing I just thought of is that it would be good (if you have
time) to write your test for each of the types float, double and long
double - all should work in gcc.

The only caveat is, of course, not to rely on the format :-). e.g. on some
targets double's are 32-bits (yes, really. Some HW manufacturers should be
shot for specifying ABIs like that).

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Two questions about testing.

[Sergei Organov]

Jonathan Larmour <jlarmour@redhat.co.uk> writes:

> Sergei Organov wrote:
> > 
> > > Also, while not an absolute requirement, if you could avoid using libm
> > > functions that would be good so the test can still run if libm is disabled.
> > 
> > I believe trivial FPU operations like +,-,*,/ would be enough, so nothing from
> > math library will be involved. As far as I remember, even if target doesn't
> > support '*' or '/', the support code resides in the "libgcc.a"
> 
> Yep. Another thing I just thought of is that it would be good (if you have
> time) to write your test for each of the types float, double and long
> double - all should work in gcc.

I believe writing tests for all of types takes almost the same time as
writing for single type. If you know that you need to do it for multiple types
before you start writing ;-) BTW, do I need to write tests in C? 

> 
> The only caveat is, of course, not to rely on the format :-). e.g. on some
> targets double's are 32-bits (yes, really. Some HW manufacturers should be
> shot for specifying ABIs like that).

Thanks, I know. Have seen it in newlib's libm sources ;-)

Sergei.

Re: [ECOS] Two questions about testing.

[Jonathan Larmour]

Sergei Organov wrote:
> 
> BTW, do I need to write tests in C?

Do you mean, versus C++? Then no, it doesn't matter. If you mean versus
assembler, then it would be nice if that could be avoided.... or perhaps
there could be a generic portion written in C that would work on all
targets, as well as architecture-specific additional checks.

But I'd have thought that a good enough test case which would guarantee
lots of int and float register spilling would be good enough to churn the
FP state.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] Two questions about testing.

[Sergei Organov]

Jonathan Larmour <jlarmour@redhat.co.uk> writes:

> Sergei Organov wrote:
> > 
> > BTW, do I need to write tests in C?
> 
> Do you mean, versus C++? Then no, it doesn't matter. If you mean versus
> assembler, then it would be nice if that could be avoided.... or perhaps
> there could be a generic portion written in C that would work on all
> targets, as well as architecture-specific additional checks.

Sure I meant C++, I'm not brave enough yet (or already) to write tests in
assembler :-) When you told about multiple types first thing that came to my
mind was templates. Well, actually it's not that important.

Sergei.