Re: Sources to port fenv.h to ARM and AARCH64

[Eshan Dhawan]

I went through the FreeBSD and NetBSD sources for implementation
In FreeBSD there is an architecture-specific implementation with different
header file for each architecture it supports .
Whereas in NetBSD there is a single fenv.h defined but each architecture
has its own C file to implement the functions.
Also FreeBSD has soft-float for ARM
So, I think FreeBSD would be a better option.

On Sat, Mar 21, 2020 at 2:37 AM Joel Sherrill  wrote:

>
>
> On Fri, Mar 20, 2020 at 3:33 PM Eshan Dhawan 
> wrote:
>
>> thanks, dr Joel
>>
>> I had gone through the musl-libc library but it doesn't have much
>> architecture specific support for ARM as well as AARCH64
>> It has support for s390x, m68k, powerpc64
>>
>
> This type of evaluation is important.  The architecture may be supported
> in only one implementation or one may be more complete than another.
>
> Ignoring the license requirements of course.
>
>>
>>
>> On Sat, Mar 21, 2020 at 1:32 AM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Fri, Mar 20, 2020 at 2:43 PM Eshan Dhawan 
>>> wrote:
>>>
 What would be the preferred source to port fenv.h to ARM and AARCH64
 its implementation is present in both FreeBSD as well AS NetBSD
 -> ARM
 ---FreeBSD Source
 # https://github.com/freebsd/freebsd/tree/master/lib/msun/arm
 ---NetBSD Source
 # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/arm

 ->AARCH64
 ---FreeBSD Source
 # https://github.com/freebsd/freebsd/tree/master/lib/msun/aarch64
 ---NetBSD Source
 # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/aarch64

>>>
>>> Don't forget MUSL-C Library which has a lot of architectures and
>>> is appropriately licensed.
>>>
>>> https://git.musl-libc.org/cgit/musl/tree/src/fenv
>>>
>>> I think our the order is going to be FreeBSD, NetBSD, then other places.
>>>
>>> The code drops into newlib's libm in a particular way which may require
>>> some refactoring. fenv.h is shared across all ports and machine/fenv.h is
>>> where port code goes. There must be an architecture specific file for
>>> each
>>> method. But the entire implementation could go in one file and the others
>>> be stubs. The i386 does this.
>>>
>>> --joel
>>>


 

 Thanks
 -Eshan
 ___
 devel mailing list
 devel@rtems.org
 http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC 2020 Proposal | Beagle BSP: Add a flattened device tree based initialization

[Niteesh G. S.]

Hello everyone,

I have revised my proposal as per your suggestions.
Please have a look again.
https://docs.google.com/document/d/1V2RitYJOvWOvfow99hPUFB034iw4gb4eSfH8MixHnrk/edit?usp=sharing

Thank you,
Niteesh.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Creation of the Quick Start / Build Your Application section

[Gedare Bloom]

On Fri, Mar 20, 2020 at 5:56 PM William  wrote:
>
> Oh, well that's slightly embarrassing. Before I submitted I tried
> looking for the patch referencing that page and I didn't see anything.
>
> Looking over what you wrote, would it be worth adding either a section
> or a sub-page for building an application manually or with another build
> tool such as GNU Make? Can salvage a bit of the work I did :)
>
Short answer, yes. It is good to show a variety of ways that users can
build their applications.

> On 3/19/2020 18:20, Chris Johns wrote:
> > On 20/3/20 9:05 am, William wrote:
> >> Been sitting on this patch for a while now, figured I should finally 
> >> submit it...
> > Thank you for posting the patch.
> >
> >> About a month ago I saw someone saying that they wanted to have this 
> >> section of
> >> the users guide added in, followed all of the steps of the userguide up to 
> >> the
> >> point just prior and then wrote this.
> > Oh it is a shame this was not posted earlier as I have recently added a 
> > section ..
> >
> > https://docs.rtems.org/branches/master/user/start/app.html
> >
> >> One thing to note, the GDB simulation did not work, I couldn't get it to 
> >> link up
> >> to the SIS simulator (GDB didn't even know what `target sim` meant). 
> >> That's why
> >> I have written on how to use SIS directly. No idea where I could track that
> >> problem down.
> > To run a remote session with gdb you need to add -gdb to the SIS command 
> > line
> > with the executable, start gdb, connect with `target :1234` then load and 
> > run
> > (or continue).
> >
> > Chris
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: riscv BSPs on Spike due to weird RSB side-effect

[Joel Sherrill]

On Fri, Mar 20, 2020 at 7:56 PM Joel Sherrill  wrote:

> Hi
>
> I think something is wrong with the build of spike that ends up with
> a hard-coded path to inside a build tree:
>
> Result: invalidTime: 0:00:01.197748 mimfs_fslink.exe
> =>  run: spike --isa=RV32IAC 
> ./riscv-rtems5/c/rv32iac/testsuites/fstests/mimfs_fslink.exe
> ] Failed to run 
> /home/joel/rtems-cron-5/rtems-source-builder/bare/build/tmp/sb-1001/devel/spike/home/joel/rtems-cron-5/tools/5/bin/dtc:
>  No such file or directory
> ] Child dtb process failed
>
> https://lists.rtems.org/pipermail/build/2020-March/02.html
>
> Does spike work if there isn't this problem?
>
> I can poke at the host exes to see if the dtc path is hard-coded. Otherwise, 
> this seems very strange.
>
>
I can confirm that spike built with the RSB has the hard-coded
path to dtc that is in the temporary RSB build/staging directories.

$ strings spike | grep dtc
/home/joel/rtems-cron-5/rtems-source-builder/bare/build/tmp/sb-1001/devel/spike/home/joel/rtems-cron-5/tools/5/bin/dtc
Failed to run
/home/joel/rtems-cron-5/rtems-source-builder/bare/build/tmp/sb-1001/devel/spike/home/joel/rtems-cron-5/tools/5/bin/dtc:

> Any ideas?
>
> --joel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

riscv BSPs on Spike due to weird RSB side-effect

[Joel Sherrill]

Hi

I think something is wrong with the build of spike that ends up with
a hard-coded path to inside a build tree:

Result: invalidTime: 0:00:01.197748 mimfs_fslink.exe
=>  run: spike --isa=RV32IAC
./riscv-rtems5/c/rv32iac/testsuites/fstests/mimfs_fslink.exe
] Failed to run
/home/joel/rtems-cron-5/rtems-source-builder/bare/build/tmp/sb-1001/devel/spike/home/joel/rtems-cron-5/tools/5/bin/dtc:
No such file or directory
] Child dtb process failed

https://lists.rtems.org/pipermail/build/2020-March/02.html

Does spike work if there isn't this problem?

I can poke at the host exes to see if the dtc path is hard-coded.
Otherwise, this seems very strange.

Any ideas?

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH docs] user/bsps: Remove gdbarmsim

[Joel Sherrill]

I'm really embarrassed it took me three separate tries to catch everything.

I'm also surprised that a BSP that didn't even have a real clock tick and
hadn't work in a couple of years was mentioned in so many places.

Thanks Niteesh for catching this.



On Fri, Mar 20, 2020 at 10:17 AM Gedare Bloom  wrote:

> Hi Niteesh,
>
> Thanks, Joel took care of it, there were a couple other references too.
>
> https://lists.rtems.org/pipermail/vc/2020-March/033721.html
>
> Gedare
>
> On Fri, Mar 20, 2020 at 12:24 AM G S Niteesh Babu 
> wrote:
> >
> > Remove gdbarmsim from list of BSPs in docs. Since, the BSPs has
> > been removed from RTEMS by Joel.
> > ---
> >  user/bsps/arm/gdbarmsim.rst | 8 
> >  1 file changed, 8 deletions(-)
> >  delete mode 100644 user/bsps/arm/gdbarmsim.rst
> >
> > diff --git a/user/bsps/arm/gdbarmsim.rst b/user/bsps/arm/gdbarmsim.rst
> > deleted file mode 100644
> > index 26ea90c..000
> > --- a/user/bsps/arm/gdbarmsim.rst
> > +++ /dev/null
> > @@ -1,8 +0,0 @@
> > -.. SPDX-License-Identifier: CC-BY-SA-4.0
> > -
> > -.. Copyright (C) 2019 TBD
> > -
> > -gdbarmsim
> > -=
> > -
> > -TODO.
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Creation of the Quick Start / Build Your Application section

[William]

Oh, well that's slightly embarrassing. Before I submitted I tried 
looking for the patch referencing that page and I didn't see anything.


Looking over what you wrote, would it be worth adding either a section 
or a sub-page for building an application manually or with another build 
tool such as GNU Make? Can salvage a bit of the work I did :)


On 3/19/2020 18:20, Chris Johns wrote:

On 20/3/20 9:05 am, William wrote:

Been sitting on this patch for a while now, figured I should finally submit 
it...

Thank you for posting the patch.


About a month ago I saw someone saying that they wanted to have this section of
the users guide added in, followed all of the steps of the userguide up to the
point just prior and then wrote this.

Oh it is a shame this was not posted earlier as I have recently added a section 
..

https://docs.rtems.org/branches/master/user/start/app.html


One thing to note, the GDB simulation did not work, I couldn't get it to link up
to the SIS simulator (GDB didn't even know what `target sim` meant). That's why
I have written on how to use SIS directly. No idea where I could track that
problem down.

To run a remote session with gdb you need to add -gdb to the SIS command line
with the executable, start gdb, connect with `target :1234` then load and run
(or continue).

Chris


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Students: Submit Draft Applications

[Gedare Bloom]

PS: And gather your proof documentation to submit :)

On Fri, Mar 20, 2020 at 4:24 PM Gedare Bloom  wrote:
>
> Hello Aspiring Students,
>
> I wanted to let you know that you can submit and revise your
> application including your "Final" proposal as many times as you like
> in the Official website, and that you should do so now and update it
> periodically until the deadline. If you don't submit it then you can't
> get picked. "Final" is not final. :)
>
> Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC Students: Submit Draft Applications

[Gedare Bloom]

Hello Aspiring Students,

I wanted to let you know that you can submit and revise your
application including your "Final" proposal as many times as you like
in the Official website, and that you should do so now and update it
periodically until the deadline. If you don't submit it then you can't
get picked. "Final" is not final. :)

Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libdebugger: Fix ARMv7-M with -O0

[Chris Johns]

> On 20 Mar 2020, at 4:49 pm, Sebastian Huber 
>  wrote:
>> On 20/03/2020 05:15, Chris Johns wrote:
>>> On 19/3/20 7:52 pm, Sebastian Huber wrote:
>>> The ARMv7-M architecture has no CP-15.  The inline assembly for the
>>> CP-15 access leads to assembler errors if compiled with -O0.
>> I would like to understand this one in detail to see why there is cp15 in 
>> the build.
> In ARMv7-M the system registers are memory mapped.
> If I compile a Cortex-M based BSP with -O0, then I get:
> 
BSP?

Chris___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Sources to port fenv.h to ARM and AARCH64

[Joel Sherrill]

On Fri, Mar 20, 2020 at 3:33 PM Eshan Dhawan 
wrote:

> thanks, dr Joel
>
> I had gone through the musl-libc library but it doesn't have much
> architecture specific support for ARM as well as AARCH64
> It has support for s390x, m68k, powerpc64
>

This type of evaluation is important.  The architecture may be supported in
only one implementation or one may be more complete than another.

Ignoring the license requirements of course.

>
>
> On Sat, Mar 21, 2020 at 1:32 AM Joel Sherrill  wrote:
>
>>
>>
>> On Fri, Mar 20, 2020 at 2:43 PM Eshan Dhawan 
>> wrote:
>>
>>> What would be the preferred source to port fenv.h to ARM and AARCH64
>>> its implementation is present in both FreeBSD as well AS NetBSD
>>> -> ARM
>>> ---FreeBSD Source
>>> # https://github.com/freebsd/freebsd/tree/master/lib/msun/arm
>>> ---NetBSD Source
>>> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/arm
>>>
>>> ->AARCH64
>>> ---FreeBSD Source
>>> # https://github.com/freebsd/freebsd/tree/master/lib/msun/aarch64
>>> ---NetBSD Source
>>> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/aarch64
>>>
>>
>> Don't forget MUSL-C Library which has a lot of architectures and
>> is appropriately licensed.
>>
>> https://git.musl-libc.org/cgit/musl/tree/src/fenv
>>
>> I think our the order is going to be FreeBSD, NetBSD, then other places.
>>
>> The code drops into newlib's libm in a particular way which may require
>> some refactoring. fenv.h is shared across all ports and machine/fenv.h is
>> where port code goes. There must be an architecture specific file for each
>> method. But the entire implementation could go in one file and the others
>> be stubs. The i386 does this.
>>
>> --joel
>>
>>>
>>>
>>> 
>>>
>>> Thanks
>>> -Eshan
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Sources to port fenv.h to ARM and AARCH64

[Eshan Dhawan]

Then I will be giving preference to FreeBSD

On Sat, Mar 21, 2020 at 2:03 AM Eshan Dhawan 
wrote:

> thanks, dr Joel
>
> I had gone through the musl-libc library but it doesn't have much
> architecture specific support for ARM as well as AARCH64
> It has support for s390x, m68k, powerpc64
>
>
> On Sat, Mar 21, 2020 at 1:32 AM Joel Sherrill  wrote:
>
>>
>>
>> On Fri, Mar 20, 2020 at 2:43 PM Eshan Dhawan 
>> wrote:
>>
>>> What would be the preferred source to port fenv.h to ARM and AARCH64
>>> its implementation is present in both FreeBSD as well AS NetBSD
>>> -> ARM
>>> ---FreeBSD Source
>>> # https://github.com/freebsd/freebsd/tree/master/lib/msun/arm
>>> ---NetBSD Source
>>> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/arm
>>>
>>> ->AARCH64
>>> ---FreeBSD Source
>>> # https://github.com/freebsd/freebsd/tree/master/lib/msun/aarch64
>>> ---NetBSD Source
>>> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/aarch64
>>>
>>
>> Don't forget MUSL-C Library which has a lot of architectures and
>> is appropriately licensed.
>>
>> https://git.musl-libc.org/cgit/musl/tree/src/fenv
>>
>> I think our the order is going to be FreeBSD, NetBSD, then other places.
>>
>> The code drops into newlib's libm in a particular way which may require
>> some refactoring. fenv.h is shared across all ports and machine/fenv.h is
>> where port code goes. There must be an architecture specific file for each
>> method. But the entire implementation could go in one file and the others
>> be stubs. The i386 does this.
>>
>> --joel
>>
>>>
>>>
>>> 
>>>
>>> Thanks
>>> -Eshan
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Sources to port fenv.h to ARM and AARCH64

[Eshan Dhawan]

thanks, dr Joel

I had gone through the musl-libc library but it doesn't have much
architecture specific support for ARM as well as AARCH64
It has support for s390x, m68k, powerpc64


On Sat, Mar 21, 2020 at 1:32 AM Joel Sherrill  wrote:

>
>
> On Fri, Mar 20, 2020 at 2:43 PM Eshan Dhawan 
> wrote:
>
>> What would be the preferred source to port fenv.h to ARM and AARCH64
>> its implementation is present in both FreeBSD as well AS NetBSD
>> -> ARM
>> ---FreeBSD Source
>> # https://github.com/freebsd/freebsd/tree/master/lib/msun/arm
>> ---NetBSD Source
>> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/arm
>>
>> ->AARCH64
>> ---FreeBSD Source
>> # https://github.com/freebsd/freebsd/tree/master/lib/msun/aarch64
>> ---NetBSD Source
>> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/aarch64
>>
>
> Don't forget MUSL-C Library which has a lot of architectures and
> is appropriately licensed.
>
> https://git.musl-libc.org/cgit/musl/tree/src/fenv
>
> I think our the order is going to be FreeBSD, NetBSD, then other places.
>
> The code drops into newlib's libm in a particular way which may require
> some refactoring. fenv.h is shared across all ports and machine/fenv.h is
> where port code goes. There must be an architecture specific file for each
> method. But the entire implementation could go in one file and the others
> be stubs. The i386 does this.
>
> --joel
>
>>
>>
>> 
>>
>> Thanks
>> -Eshan
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v6] tests for fenv.h functions

[Eshan Dhawan]

On Sat, Mar 21, 2020 at 1:35 AM Joel Sherrill 
wrote:

>
>
> On Fri, Mar 20, 2020 at 2:50 PM Gedare Bloom  wrote:
>
>> On Sun, Mar 8, 2020 at 11:02 AM Eshan Dhawan 
>> wrote:
>> >
>> > I have compiled as well as executed it for RISC V architecture function
>> Fegetround() returns error for all rounding directions other the default
>> "FETONEAREST" I asked about it on devel to which dr Joel told that it is
>> due to soft-float.
>> > So I have added its test case but they won't work on emulators.
>> >
>> There may be some emulator/simulator that simulates hard-float
>> support. You may want to investigate a little bit. That would be
>> helpful for testing purposes.
>>
>
> Jim Wilson of SiFive and long time GCC maintainer told me that about the
> RISC-V
> soft float. It is just the way it is.
>
> If there is a way to know you have soft float, perhaps the libm header
> file could
> do the right thing and not define the constants it doesn't support. That
> is the
> contract on these methods. :)
>
Can you elaborate, please :)

>
> --joel
>
>>
>> >
>> > thanks
>> > -Eshan
>> > On Sun, Mar 8, 2020 at 7:55 PM Gedare Bloom  wrote:
>> >>
>> >> Hi Eshan,
>> >>
>> >> This is looking good. Did you compile it? Execute it?  How was the
>> output?
>> >>
>> >> On Sat, Mar 7, 2020 at 6:51 AM Eshan dhawan 
>> wrote:
>> >> >
>> >> > ---
>> >> >  testsuites/psxtests/psxfenv01/init.c | 89
>> ++--
>> >> >  1 file changed, 71 insertions(+), 18 deletions(-)
>> >> >
>> >> > diff --git a/testsuites/psxtests/psxfenv01/init.c
>> b/testsuites/psxtests/psxfenv01/init.c
>> >> > index cdb0fa596e..6d71463465 100644
>> >> > --- a/testsuites/psxtests/psxfenv01/init.c
>> >> > +++ b/testsuites/psxtests/psxfenv01/init.c
>> >> > @@ -46,11 +46,12 @@
>> >> >  #include 
>> >> >  #include 
>> >> >  #include 
>> >> > +#include 
>> >> >
>> >> >  const char rtems_test_name[] = "PSXFENV 01";
>> >> >
>> >> >  /* forward declarations to avoid warnings */
>> >> > -rtems_task Init(rtems_task_argument ignored);
>> >> > +rtems_task Init( rtems_task_argument ignored );
>> >> >
>> >> >  /* Test Function Begins */
>> >> >  rtems_task Init(rtems_task_argument ignored)
>> >> > @@ -62,28 +63,31 @@ rtems_task Init(rtems_task_argument ignored)
>> >> >
>> >> >/*
>> >> > * 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
>> >> > -   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
>> >> > -   * 'fetestexcept()' functions are supported by the architecture.
>> >> > +   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
>> >> > +   * fetestexcept() functions are supported by the architecture.
>> >> > * Hence their testcases can be wrapped under #ifdef and #endif.
>> >> > */
>> >> >#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
>> >> >  puts( "fesetenv(FE_DFL_ENV)." );
>> >> > -r = fesetenv(FE_DFL_ENV);
>> >> > -if (r)
>> >> > +r = fesetenv ( FE_DFL_ENV );
>> >> > +if ( r ) {
>> >> >printf("fesetenv ==> %d\n", r);
>> >> > -rtems_test_assert( r == 0 );
>> >> > +}
>> >> > +rtems_test_assert ( r == 0 );
>> >> >
>> >> > -/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>> >> > -puts( "feclearexcept(FE_ALL_EXCEPT)." );
>> >> > -r = feclearexcept(FE_ALL_EXCEPT);
>> >> > -if (r)
>> >> > +/* Test feclearexcept() and fetestexcept() in one go. */
>> >> > +puts( "feclearexcept(FE_ALL_EXCEPT)" );
>> >> > +r = feclearexcept ( FE_ALL_EXCEPT );
>> >> > +if ( r ) {
>> >> >printf("feclearexcept ==> 0x%x\n", r);
>> >> > -rtems_test_assert( r == 0 );
>> >> > +}
>> >> > +rtems_test_assert ( r == 0 );
>> >> >
>> >> > -r = fetestexcept( FE_ALL_EXCEPT );
>> >> > -if (r)
>> >> > +r = fetestexcept ( FE_ALL_EXCEPT );
>> >> > +if ( r ) {
>> >> >printf("fetestexcept ==> 0x%x\n", r);
>> >> > -rtems_test_assert( r == 0 );
>> >> > +}
>> >> > +rtems_test_assert ( r == 0 );
>> >> >
>> >> >  /* Test 'FE_DIVBYZERO' */
>> >> >  puts( "Divide by zero and confirm fetestexcept()" );
>> >> > @@ -91,11 +95,60 @@ rtems_task Init(rtems_task_argument ignored)
>> >> >  b = 1.0;
>> >> >  c = b/a;
>> >> >  (void) c;
>> >> > -
>> >> > -fegetexceptflag(,FE_ALL_EXCEPT);
>> >> > -
>> >> > +/* Test fegetexceptflag() and fesetexceptflag() */
>> >> > +r = fegetexceptflag ( , FE_ALL_EXCEPT );
>> >> > +if ( r ) {
>> >> > +  printf("fegetexceptflag ==> 0x%x\n", r);
>> >> > +}
>> >> > +rtems_test_assert ( r == 0 );
>> >> > +
>> >> > +r = fesetexceptflag ( , FE_ALL_EXCEPT );
>> >> > +if ( r ) {
>> >> > +  printf("fesetexceptflag ==> 0x%x\n", r);
>> >> > +}
>> >> > +rtems_test_assert ( r == 0 );
>> >> > +
>> >> > +/* Test for fegetround() and fesetround()
>> >> > + * They have four main macros to be tested separated by ifdef
>> >> > + * Since not all architectures support them
>> >> > + * The test case gets and sets the 

Re: [PATCH v6] tests for fenv.h functions

[Eshan Dhawan]

I will patch that up

On Sat, Mar 21, 2020 at 1:25 AM Aditya Upadhyay  wrote:

> Hi Eshan,
>
> You should look into the RTEMS Coding conventions and rules. I can see
> that some spaces that you inserted after
> rtems_test_assert() were not needed. Please remove these unnecessary
> spaces. For example,
>
> rtems_test_assert ( r == 0 ) ; ===> should be changed to
> rtems_test_assert( r == 0 )
> rtems_test_assert ( fegetround() == FE_DOWNWARD ) ;  ===> same here.
>
> Thanks,
> Aditya Upadhyay
>
> On Sat, Mar 21, 2020 at 12:21 AM Eshan Dhawan 
> wrote:
> >
> >
> >
> > On Sat, Mar 21, 2020 at 12:19 AM Eshan Dhawan 
> wrote:
> >>
> >> Hello Everyone,
> >> I had sent this patch a few days ago to add tests of fenv.h to psxtests.
> >> If you all could look into it and tell if it could be merged or
> requires any more changes.
> >>
> > link to patch :
> https://lists.rtems.org/pipermail/devel/2020-March/058063.html
> >>
> >> thanks,
> >> Eshan Dhawan
> >>
> >>
> >> On Sun, Mar 8, 2020 at 10:32 PM Eshan Dhawan 
> wrote:
> >>>
> >>> I have compiled as well as executed it for RISC V architecture
> function Fegetround() returns error for all rounding directions other the
> default "FETONEAREST" I asked about it on devel to which dr Joel told that
> it is due to soft-float.
> >>> So I have added its test case but they won't work on emulators.
> >>>
> >>>
> >>> thanks
> >>> -Eshan
> >>> On Sun, Mar 8, 2020 at 7:55 PM Gedare Bloom  wrote:
> 
>  Hi Eshan,
> 
>  This is looking good. Did you compile it? Execute it?  How was the
> output?
> 
>  On Sat, Mar 7, 2020 at 6:51 AM Eshan dhawan 
> wrote:
>  >
>  > ---
>  >  testsuites/psxtests/psxfenv01/init.c | 89
> ++--
>  >  1 file changed, 71 insertions(+), 18 deletions(-)
>  >
>  > diff --git a/testsuites/psxtests/psxfenv01/init.c
> b/testsuites/psxtests/psxfenv01/init.c
>  > index cdb0fa596e..6d71463465 100644
>  > --- a/testsuites/psxtests/psxfenv01/init.c
>  > +++ b/testsuites/psxtests/psxfenv01/init.c
>  > @@ -46,11 +46,12 @@
>  >  #include 
>  >  #include 
>  >  #include 
>  > +#include 
>  >
>  >  const char rtems_test_name[] = "PSXFENV 01";
>  >
>  >  /* forward declarations to avoid warnings */
>  > -rtems_task Init(rtems_task_argument ignored);
>  > +rtems_task Init( rtems_task_argument ignored );
>  >
>  >  /* Test Function Begins */
>  >  rtems_task Init(rtems_task_argument ignored)
>  > @@ -62,28 +63,31 @@ rtems_task Init(rtems_task_argument ignored)
>  >
>  >/*
>  > * 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
>  > -   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()'
> and
>  > -   * 'fetestexcept()' functions are supported by the architecture.
>  > +   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
>  > +   * fetestexcept() functions are supported by the architecture.
>  > * Hence their testcases can be wrapped under #ifdef and #endif.
>  > */
>  >#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
>  >  puts( "fesetenv(FE_DFL_ENV)." );
>  > -r = fesetenv(FE_DFL_ENV);
>  > -if (r)
>  > +r = fesetenv ( FE_DFL_ENV );
>  > +if ( r ) {
>  >printf("fesetenv ==> %d\n", r);
>  > -rtems_test_assert( r == 0 );
>  > +}
>  > +rtems_test_assert ( r == 0 );
>  >
>  > -/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>  > -puts( "feclearexcept(FE_ALL_EXCEPT)." );
>  > -r = feclearexcept(FE_ALL_EXCEPT);
>  > -if (r)
>  > +/* Test feclearexcept() and fetestexcept() in one go. */
>  > +puts( "feclearexcept(FE_ALL_EXCEPT)" );
>  > +r = feclearexcept ( FE_ALL_EXCEPT );
>  > +if ( r ) {
>  >printf("feclearexcept ==> 0x%x\n", r);
>  > -rtems_test_assert( r == 0 );
>  > +}
>  > +rtems_test_assert ( r == 0 );
>  >
>  > -r = fetestexcept( FE_ALL_EXCEPT );
>  > -if (r)
>  > +r = fetestexcept ( FE_ALL_EXCEPT );
>  > +if ( r ) {
>  >printf("fetestexcept ==> 0x%x\n", r);
>  > -rtems_test_assert( r == 0 );
>  > +}
>  > +rtems_test_assert ( r == 0 );
>  >
>  >  /* Test 'FE_DIVBYZERO' */
>  >  puts( "Divide by zero and confirm fetestexcept()" );
>  > @@ -91,11 +95,60 @@ rtems_task Init(rtems_task_argument ignored)
>  >  b = 1.0;
>  >  c = b/a;
>  >  (void) c;
>  > -
>  > -fegetexceptflag(,FE_ALL_EXCEPT);
>  > -
>  > +/* Test fegetexceptflag() and fesetexceptflag() */
>  > +r = fegetexceptflag ( , FE_ALL_EXCEPT );
>  > +if ( r ) {
>  > +  printf("fegetexceptflag ==> 0x%x\n", r);
>  > +}
>  > +rtems_test_assert ( r == 0 );
>  > +
>  > +r = fesetexceptflag ( , 

Re: [PATCH v6] tests for fenv.h functions

[Joel Sherrill]

On Fri, Mar 20, 2020 at 2:50 PM Gedare Bloom  wrote:

> On Sun, Mar 8, 2020 at 11:02 AM Eshan Dhawan 
> wrote:
> >
> > I have compiled as well as executed it for RISC V architecture function
> Fegetround() returns error for all rounding directions other the default
> "FETONEAREST" I asked about it on devel to which dr Joel told that it is
> due to soft-float.
> > So I have added its test case but they won't work on emulators.
> >
> There may be some emulator/simulator that simulates hard-float
> support. You may want to investigate a little bit. That would be
> helpful for testing purposes.
>

Jim Wilson of SiFive and long time GCC maintainer told me that about the
RISC-V
soft float. It is just the way it is.

If there is a way to know you have soft float, perhaps the libm header file
could
do the right thing and not define the constants it doesn't support. That is
the
contract on these methods. :)

I don't know what we can really do in our tests.

--joel

>
> >
> > thanks
> > -Eshan
> > On Sun, Mar 8, 2020 at 7:55 PM Gedare Bloom  wrote:
> >>
> >> Hi Eshan,
> >>
> >> This is looking good. Did you compile it? Execute it?  How was the
> output?
> >>
> >> On Sat, Mar 7, 2020 at 6:51 AM Eshan dhawan 
> wrote:
> >> >
> >> > ---
> >> >  testsuites/psxtests/psxfenv01/init.c | 89
> ++--
> >> >  1 file changed, 71 insertions(+), 18 deletions(-)
> >> >
> >> > diff --git a/testsuites/psxtests/psxfenv01/init.c
> b/testsuites/psxtests/psxfenv01/init.c
> >> > index cdb0fa596e..6d71463465 100644
> >> > --- a/testsuites/psxtests/psxfenv01/init.c
> >> > +++ b/testsuites/psxtests/psxfenv01/init.c
> >> > @@ -46,11 +46,12 @@
> >> >  #include 
> >> >  #include 
> >> >  #include 
> >> > +#include 
> >> >
> >> >  const char rtems_test_name[] = "PSXFENV 01";
> >> >
> >> >  /* forward declarations to avoid warnings */
> >> > -rtems_task Init(rtems_task_argument ignored);
> >> > +rtems_task Init( rtems_task_argument ignored );
> >> >
> >> >  /* Test Function Begins */
> >> >  rtems_task Init(rtems_task_argument ignored)
> >> > @@ -62,28 +63,31 @@ rtems_task Init(rtems_task_argument ignored)
> >> >
> >> >/*
> >> > * 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
> >> > -   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
> >> > -   * 'fetestexcept()' functions are supported by the architecture.
> >> > +   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
> >> > +   * fetestexcept() functions are supported by the architecture.
> >> > * Hence their testcases can be wrapped under #ifdef and #endif.
> >> > */
> >> >#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
> >> >  puts( "fesetenv(FE_DFL_ENV)." );
> >> > -r = fesetenv(FE_DFL_ENV);
> >> > -if (r)
> >> > +r = fesetenv ( FE_DFL_ENV );
> >> > +if ( r ) {
> >> >printf("fesetenv ==> %d\n", r);
> >> > -rtems_test_assert( r == 0 );
> >> > +}
> >> > +rtems_test_assert ( r == 0 );
> >> >
> >> > -/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
> >> > -puts( "feclearexcept(FE_ALL_EXCEPT)." );
> >> > -r = feclearexcept(FE_ALL_EXCEPT);
> >> > -if (r)
> >> > +/* Test feclearexcept() and fetestexcept() in one go. */
> >> > +puts( "feclearexcept(FE_ALL_EXCEPT)" );
> >> > +r = feclearexcept ( FE_ALL_EXCEPT );
> >> > +if ( r ) {
> >> >printf("feclearexcept ==> 0x%x\n", r);
> >> > -rtems_test_assert( r == 0 );
> >> > +}
> >> > +rtems_test_assert ( r == 0 );
> >> >
> >> > -r = fetestexcept( FE_ALL_EXCEPT );
> >> > -if (r)
> >> > +r = fetestexcept ( FE_ALL_EXCEPT );
> >> > +if ( r ) {
> >> >printf("fetestexcept ==> 0x%x\n", r);
> >> > -rtems_test_assert( r == 0 );
> >> > +}
> >> > +rtems_test_assert ( r == 0 );
> >> >
> >> >  /* Test 'FE_DIVBYZERO' */
> >> >  puts( "Divide by zero and confirm fetestexcept()" );
> >> > @@ -91,11 +95,60 @@ rtems_task Init(rtems_task_argument ignored)
> >> >  b = 1.0;
> >> >  c = b/a;
> >> >  (void) c;
> >> > -
> >> > -fegetexceptflag(,FE_ALL_EXCEPT);
> >> > -
> >> > +/* Test fegetexceptflag() and fesetexceptflag() */
> >> > +r = fegetexceptflag ( , FE_ALL_EXCEPT );
> >> > +if ( r ) {
> >> > +  printf("fegetexceptflag ==> 0x%x\n", r);
> >> > +}
> >> > +rtems_test_assert ( r == 0 );
> >> > +
> >> > +r = fesetexceptflag ( , FE_ALL_EXCEPT );
> >> > +if ( r ) {
> >> > +  printf("fesetexceptflag ==> 0x%x\n", r);
> >> > +}
> >> > +rtems_test_assert ( r == 0 );
> >> > +
> >> > +/* Test for fegetround() and fesetround()
> >> > + * They have four main macros to be tested separated by ifdef
> >> > + * Since not all architectures support them
> >> > + * The test case gets and sets the rounding directions */
> >> > +#ifdef FE_TONEAREST
> >> > +rtems_test_assert ( fegetround() == FE_TONEAREST ) ;
> >> > +#endif
> >> > +#ifdef FE_TOWARDZERO
> >> > +  r = fesetround ( 

Re: Sources to port fenv.h to ARM and AARCH64

[Joel Sherrill]

On Fri, Mar 20, 2020 at 2:43 PM Eshan Dhawan 
wrote:

> What would be the preferred source to port fenv.h to ARM and AARCH64
> its implementation is present in both FreeBSD as well AS NetBSD
> -> ARM
> ---FreeBSD Source
> # https://github.com/freebsd/freebsd/tree/master/lib/msun/arm
> ---NetBSD Source
> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/arm
>
> ->AARCH64
> ---FreeBSD Source
> # https://github.com/freebsd/freebsd/tree/master/lib/msun/aarch64
> ---NetBSD Source
> # https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/aarch64
>

Don't forget MUSL-C Library which has a lot of architectures and
is appropriately licensed.

https://git.musl-libc.org/cgit/musl/tree/src/fenv

I think our the order is going to be FreeBSD, NetBSD, then other places.

The code drops into newlib's libm in a particular way which may require
some refactoring. fenv.h is shared across all ports and machine/fenv.h is
where port code goes. There must be an architecture specific file for each
method. But the entire implementation could go in one file and the others
be stubs. The i386 does this.

--joel

>
>
> 
>
> Thanks
> -Eshan
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v6] tests for fenv.h functions

[Aditya Upadhyay]

Hi Eshan,

You should look into the RTEMS Coding conventions and rules. I can see
that some spaces that you inserted after
rtems_test_assert() were not needed. Please remove these unnecessary
spaces. For example,

rtems_test_assert ( r == 0 ) ; ===> should be changed to
rtems_test_assert( r == 0 )
rtems_test_assert ( fegetround() == FE_DOWNWARD ) ;  ===> same here.

Thanks,
Aditya Upadhyay

On Sat, Mar 21, 2020 at 12:21 AM Eshan Dhawan  wrote:
>
>
>
> On Sat, Mar 21, 2020 at 12:19 AM Eshan Dhawan  wrote:
>>
>> Hello Everyone,
>> I had sent this patch a few days ago to add tests of fenv.h to psxtests.
>> If you all could look into it and tell if it could be merged or requires any 
>> more changes.
>>
> link to patch : https://lists.rtems.org/pipermail/devel/2020-March/058063.html
>>
>> thanks,
>> Eshan Dhawan
>>
>>
>> On Sun, Mar 8, 2020 at 10:32 PM Eshan Dhawan  wrote:
>>>
>>> I have compiled as well as executed it for RISC V architecture function 
>>> Fegetround() returns error for all rounding directions other the default 
>>> "FETONEAREST" I asked about it on devel to which dr Joel told that it is 
>>> due to soft-float.
>>> So I have added its test case but they won't work on emulators.
>>>
>>>
>>> thanks
>>> -Eshan
>>> On Sun, Mar 8, 2020 at 7:55 PM Gedare Bloom  wrote:

 Hi Eshan,

 This is looking good. Did you compile it? Execute it?  How was the output?

 On Sat, Mar 7, 2020 at 6:51 AM Eshan dhawan  
 wrote:
 >
 > ---
 >  testsuites/psxtests/psxfenv01/init.c | 89 ++--
 >  1 file changed, 71 insertions(+), 18 deletions(-)
 >
 > diff --git a/testsuites/psxtests/psxfenv01/init.c 
 > b/testsuites/psxtests/psxfenv01/init.c
 > index cdb0fa596e..6d71463465 100644
 > --- a/testsuites/psxtests/psxfenv01/init.c
 > +++ b/testsuites/psxtests/psxfenv01/init.c
 > @@ -46,11 +46,12 @@
 >  #include 
 >  #include 
 >  #include 
 > +#include 
 >
 >  const char rtems_test_name[] = "PSXFENV 01";
 >
 >  /* forward declarations to avoid warnings */
 > -rtems_task Init(rtems_task_argument ignored);
 > +rtems_task Init( rtems_task_argument ignored );
 >
 >  /* Test Function Begins */
 >  rtems_task Init(rtems_task_argument ignored)
 > @@ -62,28 +63,31 @@ rtems_task Init(rtems_task_argument ignored)
 >
 >/*
 > * 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
 > -   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
 > -   * 'fetestexcept()' functions are supported by the architecture.
 > +   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
 > +   * fetestexcept() functions are supported by the architecture.
 > * Hence their testcases can be wrapped under #ifdef and #endif.
 > */
 >#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
 >  puts( "fesetenv(FE_DFL_ENV)." );
 > -r = fesetenv(FE_DFL_ENV);
 > -if (r)
 > +r = fesetenv ( FE_DFL_ENV );
 > +if ( r ) {
 >printf("fesetenv ==> %d\n", r);
 > -rtems_test_assert( r == 0 );
 > +}
 > +rtems_test_assert ( r == 0 );
 >
 > -/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
 > -puts( "feclearexcept(FE_ALL_EXCEPT)." );
 > -r = feclearexcept(FE_ALL_EXCEPT);
 > -if (r)
 > +/* Test feclearexcept() and fetestexcept() in one go. */
 > +puts( "feclearexcept(FE_ALL_EXCEPT)" );
 > +r = feclearexcept ( FE_ALL_EXCEPT );
 > +if ( r ) {
 >printf("feclearexcept ==> 0x%x\n", r);
 > -rtems_test_assert( r == 0 );
 > +}
 > +rtems_test_assert ( r == 0 );
 >
 > -r = fetestexcept( FE_ALL_EXCEPT );
 > -if (r)
 > +r = fetestexcept ( FE_ALL_EXCEPT );
 > +if ( r ) {
 >printf("fetestexcept ==> 0x%x\n", r);
 > -rtems_test_assert( r == 0 );
 > +}
 > +rtems_test_assert ( r == 0 );
 >
 >  /* Test 'FE_DIVBYZERO' */
 >  puts( "Divide by zero and confirm fetestexcept()" );
 > @@ -91,11 +95,60 @@ rtems_task Init(rtems_task_argument ignored)
 >  b = 1.0;
 >  c = b/a;
 >  (void) c;
 > -
 > -fegetexceptflag(,FE_ALL_EXCEPT);
 > -
 > +/* Test fegetexceptflag() and fesetexceptflag() */
 > +r = fegetexceptflag ( , FE_ALL_EXCEPT );
 > +if ( r ) {
 > +  printf("fegetexceptflag ==> 0x%x\n", r);
 > +}
 > +rtems_test_assert ( r == 0 );
 > +
 > +r = fesetexceptflag ( , FE_ALL_EXCEPT );
 > +if ( r ) {
 > +  printf("fesetexceptflag ==> 0x%x\n", r);
 > +}
 > +rtems_test_assert ( r == 0 );
 > +
 > +/* Test for fegetround() and fesetround()
 > + * They have four main macros to be tested separated by ifdef
 > + * Since not all architectures 

Re: [PATCH v6] tests for fenv.h functions

[Gedare Bloom]

On Sun, Mar 8, 2020 at 11:02 AM Eshan Dhawan  wrote:
>
> I have compiled as well as executed it for RISC V architecture function 
> Fegetround() returns error for all rounding directions other the default 
> "FETONEAREST" I asked about it on devel to which dr Joel told that it is due 
> to soft-float.
> So I have added its test case but they won't work on emulators.
>
There may be some emulator/simulator that simulates hard-float
support. You may want to investigate a little bit. That would be
helpful for testing purposes.

>
> thanks
> -Eshan
> On Sun, Mar 8, 2020 at 7:55 PM Gedare Bloom  wrote:
>>
>> Hi Eshan,
>>
>> This is looking good. Did you compile it? Execute it?  How was the output?
>>
>> On Sat, Mar 7, 2020 at 6:51 AM Eshan dhawan  wrote:
>> >
>> > ---
>> >  testsuites/psxtests/psxfenv01/init.c | 89 ++--
>> >  1 file changed, 71 insertions(+), 18 deletions(-)
>> >
>> > diff --git a/testsuites/psxtests/psxfenv01/init.c 
>> > b/testsuites/psxtests/psxfenv01/init.c
>> > index cdb0fa596e..6d71463465 100644
>> > --- a/testsuites/psxtests/psxfenv01/init.c
>> > +++ b/testsuites/psxtests/psxfenv01/init.c
>> > @@ -46,11 +46,12 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >
>> >  const char rtems_test_name[] = "PSXFENV 01";
>> >
>> >  /* forward declarations to avoid warnings */
>> > -rtems_task Init(rtems_task_argument ignored);
>> > +rtems_task Init( rtems_task_argument ignored );
>> >
>> >  /* Test Function Begins */
>> >  rtems_task Init(rtems_task_argument ignored)
>> > @@ -62,28 +63,31 @@ rtems_task Init(rtems_task_argument ignored)
>> >
>> >/*
>> > * 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
>> > -   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
>> > -   * 'fetestexcept()' functions are supported by the architecture.
>> > +   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
>> > +   * fetestexcept() functions are supported by the architecture.
>> > * Hence their testcases can be wrapped under #ifdef and #endif.
>> > */
>> >#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
>> >  puts( "fesetenv(FE_DFL_ENV)." );
>> > -r = fesetenv(FE_DFL_ENV);
>> > -if (r)
>> > +r = fesetenv ( FE_DFL_ENV );
>> > +if ( r ) {
>> >printf("fesetenv ==> %d\n", r);
>> > -rtems_test_assert( r == 0 );
>> > +}
>> > +rtems_test_assert ( r == 0 );
>> >
>> > -/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>> > -puts( "feclearexcept(FE_ALL_EXCEPT)." );
>> > -r = feclearexcept(FE_ALL_EXCEPT);
>> > -if (r)
>> > +/* Test feclearexcept() and fetestexcept() in one go. */
>> > +puts( "feclearexcept(FE_ALL_EXCEPT)" );
>> > +r = feclearexcept ( FE_ALL_EXCEPT );
>> > +if ( r ) {
>> >printf("feclearexcept ==> 0x%x\n", r);
>> > -rtems_test_assert( r == 0 );
>> > +}
>> > +rtems_test_assert ( r == 0 );
>> >
>> > -r = fetestexcept( FE_ALL_EXCEPT );
>> > -if (r)
>> > +r = fetestexcept ( FE_ALL_EXCEPT );
>> > +if ( r ) {
>> >printf("fetestexcept ==> 0x%x\n", r);
>> > -rtems_test_assert( r == 0 );
>> > +}
>> > +rtems_test_assert ( r == 0 );
>> >
>> >  /* Test 'FE_DIVBYZERO' */
>> >  puts( "Divide by zero and confirm fetestexcept()" );
>> > @@ -91,11 +95,60 @@ rtems_task Init(rtems_task_argument ignored)
>> >  b = 1.0;
>> >  c = b/a;
>> >  (void) c;
>> > -
>> > -fegetexceptflag(,FE_ALL_EXCEPT);
>> > -
>> > +/* Test fegetexceptflag() and fesetexceptflag() */
>> > +r = fegetexceptflag ( , FE_ALL_EXCEPT );
>> > +if ( r ) {
>> > +  printf("fegetexceptflag ==> 0x%x\n", r);
>> > +}
>> > +rtems_test_assert ( r == 0 );
>> > +
>> > +r = fesetexceptflag ( , FE_ALL_EXCEPT );
>> > +if ( r ) {
>> > +  printf("fesetexceptflag ==> 0x%x\n", r);
>> > +}
>> > +rtems_test_assert ( r == 0 );
>> > +
>> > +/* Test for fegetround() and fesetround()
>> > + * They have four main macros to be tested separated by ifdef
>> > + * Since not all architectures support them
>> > + * The test case gets and sets the rounding directions */
>> > +#ifdef FE_TONEAREST
>> > +rtems_test_assert ( fegetround() == FE_TONEAREST ) ;
>> > +#endif
>> > +#ifdef FE_TOWARDZERO
>> > +  r = fesetround ( FE_TOWARDZERO ) ;
>> > +  if ( r ) {
>> > +  printf("fesetround ==> 0x%x\n", r);
>> > +}
>> > +  rtems_test_assert ( r == 0 ) ;
>> > +  rtems_test_assert ( fegetround() == FE_TOWARDZERO ) ;
>> > +#endif
>> > +#ifdef FE_DOWNWARD
>> > +  r = fesetround ( FE_DOWNWARD );
>> > +  if ( r ) {
>> > +  printf("fesetround ==> 0x%x\n", r);
>> > +}
>> > +  rtems_test_assert ( r == 0 ) ;
>> > +  rtems_test_assert ( fegetround() == FE_DOWNWARD ) ;
>> > +#endif
>> > +#ifdef FE_UPWARD
>> > +  r = fesetround ( FE_UPWARD );
>> > +  if ( r ) {
>> > +  printf("fesetround ==> 0x%x\n", r);
>> > +}
>> > +  rtems_test_assert ( r == 0 ) ;
>> > +  

Covid Code-In News (20 March 2020)

[Joel Sherrill]

Hi

I hope everyone in the community and their family is staying well and
following the advice of our trusted medical professionals. Personally, we
stepped up social distancing and prepared for "self containment" about a
week ago and now I am working from home. We should remember that being able
to work from home is a lucky privilege others less fortunate do not have.

With GSoC coming up, it is a busy time for RTEMS and I hope the core
developers are doing a good job keeping up keeping up with all the recent
questions and submissions.

For those looking for things to pass time with, Gedare and I have added
some more ideas for small tasks at https://devel.rtems.org/wiki/SmallTasks.
Please know that even though they may be small, they are still important.
Contributions nibbling at the list are appreciated.

Stay healthy, wash your hands, and help your neighbors.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Sources to port fenv.h to ARM and AARCH64

[Eshan Dhawan]

What would be the preferred source to port fenv.h to ARM and AARCH64
its implementation is present in both FreeBSD as well AS NetBSD
-> ARM
---FreeBSD Source
# https://github.com/freebsd/freebsd/tree/master/lib/msun/arm
---NetBSD Source
# https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/arm

->AARCH64
---FreeBSD Source
# https://github.com/freebsd/freebsd/tree/master/lib/msun/aarch64
---NetBSD Source
# https://github.com/NetBSD/src/tree/trunk/lib/libm/arch/aarch64



Thanks
-Eshan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v6] tests for fenv.h functions

[Eshan Dhawan]

On Sat, Mar 21, 2020 at 12:19 AM Eshan Dhawan 
wrote:

> Hello Everyone,
> I had sent this patch a few days ago to add tests of fenv.h to psxtests.
> If you all could look into it and tell if it could be merged or requires
> any more changes.
>
> link to patch :*
https://lists.rtems.org/pipermail/devel/2020-March/058063.html
*

> thanks,
> Eshan Dhawan
>
>
> On Sun, Mar 8, 2020 at 10:32 PM Eshan Dhawan 
> wrote:
>
>> I have compiled as well as executed it for RISC V architecture function
>> Fegetround() returns error for all rounding directions other the default
>> "FETONEAREST" I asked about it on devel to which dr Joel told that it is
>> due to soft-float.
>> So I have added its test case but they won't work on emulators.
>>
>>
>> thanks
>> -Eshan
>> On Sun, Mar 8, 2020 at 7:55 PM Gedare Bloom  wrote:
>>
>>> Hi Eshan,
>>>
>>> This is looking good. Did you compile it? Execute it?  How was the
>>> output?
>>>
>>> On Sat, Mar 7, 2020 at 6:51 AM Eshan dhawan 
>>> wrote:
>>> >
>>> > ---
>>> >  testsuites/psxtests/psxfenv01/init.c | 89 ++--
>>> >  1 file changed, 71 insertions(+), 18 deletions(-)
>>> >
>>> > diff --git a/testsuites/psxtests/psxfenv01/init.c
>>> b/testsuites/psxtests/psxfenv01/init.c
>>> > index cdb0fa596e..6d71463465 100644
>>> > --- a/testsuites/psxtests/psxfenv01/init.c
>>> > +++ b/testsuites/psxtests/psxfenv01/init.c
>>> > @@ -46,11 +46,12 @@
>>> >  #include 
>>> >  #include 
>>> >  #include 
>>> > +#include 
>>> >
>>> >  const char rtems_test_name[] = "PSXFENV 01";
>>> >
>>> >  /* forward declarations to avoid warnings */
>>> > -rtems_task Init(rtems_task_argument ignored);
>>> > +rtems_task Init( rtems_task_argument ignored );
>>> >
>>> >  /* Test Function Begins */
>>> >  rtems_task Init(rtems_task_argument ignored)
>>> > @@ -62,28 +63,31 @@ rtems_task Init(rtems_task_argument ignored)
>>> >
>>> >/*
>>> > * 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
>>> > -   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
>>> > -   * 'fetestexcept()' functions are supported by the architecture.
>>> > +   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
>>> > +   * fetestexcept() functions are supported by the architecture.
>>> > * Hence their testcases can be wrapped under #ifdef and #endif.
>>> > */
>>> >#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
>>> >  puts( "fesetenv(FE_DFL_ENV)." );
>>> > -r = fesetenv(FE_DFL_ENV);
>>> > -if (r)
>>> > +r = fesetenv ( FE_DFL_ENV );
>>> > +if ( r ) {
>>> >printf("fesetenv ==> %d\n", r);
>>> > -rtems_test_assert( r == 0 );
>>> > +}
>>> > +rtems_test_assert ( r == 0 );
>>> >
>>> > -/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>>> > -puts( "feclearexcept(FE_ALL_EXCEPT)." );
>>> > -r = feclearexcept(FE_ALL_EXCEPT);
>>> > -if (r)
>>> > +/* Test feclearexcept() and fetestexcept() in one go. */
>>> > +puts( "feclearexcept(FE_ALL_EXCEPT)" );
>>> > +r = feclearexcept ( FE_ALL_EXCEPT );
>>> > +if ( r ) {
>>> >printf("feclearexcept ==> 0x%x\n", r);
>>> > -rtems_test_assert( r == 0 );
>>> > +}
>>> > +rtems_test_assert ( r == 0 );
>>> >
>>> > -r = fetestexcept( FE_ALL_EXCEPT );
>>> > -if (r)
>>> > +r = fetestexcept ( FE_ALL_EXCEPT );
>>> > +if ( r ) {
>>> >printf("fetestexcept ==> 0x%x\n", r);
>>> > -rtems_test_assert( r == 0 );
>>> > +}
>>> > +rtems_test_assert ( r == 0 );
>>> >
>>> >  /* Test 'FE_DIVBYZERO' */
>>> >  puts( "Divide by zero and confirm fetestexcept()" );
>>> > @@ -91,11 +95,60 @@ rtems_task Init(rtems_task_argument ignored)
>>> >  b = 1.0;
>>> >  c = b/a;
>>> >  (void) c;
>>> > -
>>> > -fegetexceptflag(,FE_ALL_EXCEPT);
>>> > -
>>> > +/* Test fegetexceptflag() and fesetexceptflag() */
>>> > +r = fegetexceptflag ( , FE_ALL_EXCEPT );
>>> > +if ( r ) {
>>> > +  printf("fegetexceptflag ==> 0x%x\n", r);
>>> > +}
>>> > +rtems_test_assert ( r == 0 );
>>> > +
>>> > +r = fesetexceptflag ( , FE_ALL_EXCEPT );
>>> > +if ( r ) {
>>> > +  printf("fesetexceptflag ==> 0x%x\n", r);
>>> > +}
>>> > +rtems_test_assert ( r == 0 );
>>> > +
>>> > +/* Test for fegetround() and fesetround()
>>> > + * They have four main macros to be tested separated by ifdef
>>> > + * Since not all architectures support them
>>> > + * The test case gets and sets the rounding directions */
>>> > +#ifdef FE_TONEAREST
>>> > +rtems_test_assert ( fegetround() == FE_TONEAREST ) ;
>>> > +#endif
>>> > +#ifdef FE_TOWARDZERO
>>> > +  r = fesetround ( FE_TOWARDZERO ) ;
>>> > +  if ( r ) {
>>> > +  printf("fesetround ==> 0x%x\n", r);
>>> > +}
>>> > +  rtems_test_assert ( r == 0 ) ;
>>> > +  rtems_test_assert ( fegetround() == FE_TOWARDZERO ) ;
>>> > +#endif
>>> > +#ifdef FE_DOWNWARD
>>> > +  r = fesetround ( 

Re: [PATCH v6] tests for fenv.h functions

[Eshan Dhawan]

Hello Everyone,
I had sent this patch a few days ago to add tests of fenv.h to psxtests.
If you all could look into it and tell if it could be merged or requires
any more changes.

thanks,
Eshan Dhawan


On Sun, Mar 8, 2020 at 10:32 PM Eshan Dhawan 
wrote:

> I have compiled as well as executed it for RISC V architecture function
> Fegetround() returns error for all rounding directions other the default
> "FETONEAREST" I asked about it on devel to which dr Joel told that it is
> due to soft-float.
> So I have added its test case but they won't work on emulators.
>
>
> thanks
> -Eshan
> On Sun, Mar 8, 2020 at 7:55 PM Gedare Bloom  wrote:
>
>> Hi Eshan,
>>
>> This is looking good. Did you compile it? Execute it?  How was the output?
>>
>> On Sat, Mar 7, 2020 at 6:51 AM Eshan dhawan 
>> wrote:
>> >
>> > ---
>> >  testsuites/psxtests/psxfenv01/init.c | 89 ++--
>> >  1 file changed, 71 insertions(+), 18 deletions(-)
>> >
>> > diff --git a/testsuites/psxtests/psxfenv01/init.c
>> b/testsuites/psxtests/psxfenv01/init.c
>> > index cdb0fa596e..6d71463465 100644
>> > --- a/testsuites/psxtests/psxfenv01/init.c
>> > +++ b/testsuites/psxtests/psxfenv01/init.c
>> > @@ -46,11 +46,12 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >
>> >  const char rtems_test_name[] = "PSXFENV 01";
>> >
>> >  /* forward declarations to avoid warnings */
>> > -rtems_task Init(rtems_task_argument ignored);
>> > +rtems_task Init( rtems_task_argument ignored );
>> >
>> >  /* Test Function Begins */
>> >  rtems_task Init(rtems_task_argument ignored)
>> > @@ -62,28 +63,31 @@ rtems_task Init(rtems_task_argument ignored)
>> >
>> >/*
>> > * 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
>> > -   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
>> > -   * 'fetestexcept()' functions are supported by the architecture.
>> > +   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
>> > +   * fetestexcept() functions are supported by the architecture.
>> > * Hence their testcases can be wrapped under #ifdef and #endif.
>> > */
>> >#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
>> >  puts( "fesetenv(FE_DFL_ENV)." );
>> > -r = fesetenv(FE_DFL_ENV);
>> > -if (r)
>> > +r = fesetenv ( FE_DFL_ENV );
>> > +if ( r ) {
>> >printf("fesetenv ==> %d\n", r);
>> > -rtems_test_assert( r == 0 );
>> > +}
>> > +rtems_test_assert ( r == 0 );
>> >
>> > -/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>> > -puts( "feclearexcept(FE_ALL_EXCEPT)." );
>> > -r = feclearexcept(FE_ALL_EXCEPT);
>> > -if (r)
>> > +/* Test feclearexcept() and fetestexcept() in one go. */
>> > +puts( "feclearexcept(FE_ALL_EXCEPT)" );
>> > +r = feclearexcept ( FE_ALL_EXCEPT );
>> > +if ( r ) {
>> >printf("feclearexcept ==> 0x%x\n", r);
>> > -rtems_test_assert( r == 0 );
>> > +}
>> > +rtems_test_assert ( r == 0 );
>> >
>> > -r = fetestexcept( FE_ALL_EXCEPT );
>> > -if (r)
>> > +r = fetestexcept ( FE_ALL_EXCEPT );
>> > +if ( r ) {
>> >printf("fetestexcept ==> 0x%x\n", r);
>> > -rtems_test_assert( r == 0 );
>> > +}
>> > +rtems_test_assert ( r == 0 );
>> >
>> >  /* Test 'FE_DIVBYZERO' */
>> >  puts( "Divide by zero and confirm fetestexcept()" );
>> > @@ -91,11 +95,60 @@ rtems_task Init(rtems_task_argument ignored)
>> >  b = 1.0;
>> >  c = b/a;
>> >  (void) c;
>> > -
>> > -fegetexceptflag(,FE_ALL_EXCEPT);
>> > -
>> > +/* Test fegetexceptflag() and fesetexceptflag() */
>> > +r = fegetexceptflag ( , FE_ALL_EXCEPT );
>> > +if ( r ) {
>> > +  printf("fegetexceptflag ==> 0x%x\n", r);
>> > +}
>> > +rtems_test_assert ( r == 0 );
>> > +
>> > +r = fesetexceptflag ( , FE_ALL_EXCEPT );
>> > +if ( r ) {
>> > +  printf("fesetexceptflag ==> 0x%x\n", r);
>> > +}
>> > +rtems_test_assert ( r == 0 );
>> > +
>> > +/* Test for fegetround() and fesetround()
>> > + * They have four main macros to be tested separated by ifdef
>> > + * Since not all architectures support them
>> > + * The test case gets and sets the rounding directions */
>> > +#ifdef FE_TONEAREST
>> > +rtems_test_assert ( fegetround() == FE_TONEAREST ) ;
>> > +#endif
>> > +#ifdef FE_TOWARDZERO
>> > +  r = fesetround ( FE_TOWARDZERO ) ;
>> > +  if ( r ) {
>> > +  printf("fesetround ==> 0x%x\n", r);
>> > +}
>> > +  rtems_test_assert ( r == 0 ) ;
>> > +  rtems_test_assert ( fegetround() == FE_TOWARDZERO ) ;
>> > +#endif
>> > +#ifdef FE_DOWNWARD
>> > +  r = fesetround ( FE_DOWNWARD );
>> > +  if ( r ) {
>> > +  printf("fesetround ==> 0x%x\n", r);
>> > +}
>> > +  rtems_test_assert ( r == 0 ) ;
>> > +  rtems_test_assert ( fegetround() == FE_DOWNWARD ) ;
>> > +#endif
>> > +#ifdef FE_UPWARD
>> > +  r = fesetround ( FE_UPWARD );
>> > +  if ( r ) {
>> > +  printf("fesetround ==> 0x%x\n", r);
>> > +}
>> > +  

AW: AW: [PATCH v2 3/3] i386: Port to RTEMS

[Jan.Sommer]

Thank you. That makes sense.
I will prepare a new version.



Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
Gesendet: Freitag, 20. März 2020 12:54
An: Sommer, Jan; devel@rtems.org
Betreff: Re: AW: [PATCH v2 3/3] i386: Port to RTEMS


On 10/03/2020 09:12, jan.som...@dlr.de wrote:

[...]



diff --git a/freebsd/sys/net/iflib.c b/freebsd/sys/net/iflib.c

index 89bc5e79..09282ac7 100644

--- a/freebsd/sys/net/iflib.c

+++ b/freebsd/sys/net/iflib.c

@@ -1031,8 +1031,13 @@ iflib_netmap_txsync(struct netmap_kring *kring, int

flags)

  }

  if (!(ctx->ifc_flags & IFC_NETMAP_TX_IRQ))

  if (kring->nr_hwtail != nm_prev(kring->nr_hwcur, lim)) {

+#ifndef __rtems__

  callout_reset_on(>ift_timer, hz < 2000 ? 1 : hz /

1000,

  iflib_timer, txq, txq->ift_timer.c_cpu);

+#else /* __rtems__ */

+ callout_reset_curcpu(>ift_timer, hz < 2000 ? 1 : hz

/ 1000,

+ iflib_timer, txq);

I am not completely sure about all the side effects of replacing 
callout_reset_on with callout_reset_curcpu, but the struct callout has no 
"c_cpu" member in RTEMS.

If someone has a better idea, please tell me.



I would change the callout_reset_on() macro and don't change the caller.

#ifndef __rtems__
#definecallout_reset_on(c, to_ticks, fn, arg, cpu)\
callout_reset_sbt_on((c), tick_sbt * (to_ticks), 0, (fn), (arg),\
(cpu), C_HARDCLOCK)
#else /* __rtems__ */
#definecallout_reset_on(c, to_ticks, fn, arg, cpu)\
callout_reset_sbt_on((c), tick_sbt * (to_ticks), 0, (fn), (arg),\
-1, C_HARDCLOCK)
#endif /* __rtems__ */
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH docs] user/bsps: Remove gdbarmsim

[Gedare Bloom]

Hi Niteesh,

Thanks, Joel took care of it, there were a couple other references too.

https://lists.rtems.org/pipermail/vc/2020-March/033721.html

Gedare

On Fri, Mar 20, 2020 at 12:24 AM G S Niteesh Babu  wrote:
>
> Remove gdbarmsim from list of BSPs in docs. Since, the BSPs has
> been removed from RTEMS by Joel.
> ---
>  user/bsps/arm/gdbarmsim.rst | 8 
>  1 file changed, 8 deletions(-)
>  delete mode 100644 user/bsps/arm/gdbarmsim.rst
>
> diff --git a/user/bsps/arm/gdbarmsim.rst b/user/bsps/arm/gdbarmsim.rst
> deleted file mode 100644
> index 26ea90c..000
> --- a/user/bsps/arm/gdbarmsim.rst
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -.. SPDX-License-Identifier: CC-BY-SA-4.0
> -
> -.. Copyright (C) 2019 TBD
> -
> -gdbarmsim
> -=
> -
> -TODO.
> --
> 2.17.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AW: [PATCH v2 3/3] i386: Port to RTEMS

[Sebastian Huber]

On 10/03/2020 09:12, jan.som...@dlr.de wrote:


[...]


diff --git a/freebsd/sys/net/iflib.c b/freebsd/sys/net/iflib.c
index 89bc5e79..09282ac7 100644
--- a/freebsd/sys/net/iflib.c
+++ b/freebsd/sys/net/iflib.c
@@ -1031,8 +1031,13 @@ iflib_netmap_txsync(struct netmap_kring *kring, int
flags)
}
if (!(ctx->ifc_flags & IFC_NETMAP_TX_IRQ))
if (kring->nr_hwtail != nm_prev(kring->nr_hwcur, lim)) {
+#ifndef __rtems__
callout_reset_on(>ift_timer, hz < 2000 ? 1 : hz /
1000,
iflib_timer, txq, txq->ift_timer.c_cpu);
+#else /* __rtems__ */
+   callout_reset_curcpu(>ift_timer, hz < 2000 ? 1 : hz
/ 1000,
+   iflib_timer, txq);

I am not completely sure about all the side effects of replacing callout_reset_on with 
callout_reset_curcpu, but the struct callout has no "c_cpu" member in RTEMS.
If someone has a better idea, please tell me.


I would change the callout_reset_on() macro and don't change the caller.

#ifndef __rtems__
#define    callout_reset_on(c, to_ticks, fn, arg, cpu) \
    callout_reset_sbt_on((c), tick_sbt * (to_ticks), 0, (fn), (arg),    \
    (cpu), C_HARDCLOCK)
#else /* __rtems__ */
#define    callout_reset_on(c, to_ticks, fn, arg, cpu) \
    callout_reset_sbt_on((c), tick_sbt * (to_ticks), 0, (fn), (arg),    \
    -1, C_HARDCLOCK)
#endif /* __rtems__ */

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 rtems_littlevgl 1/3] waf: Remove unnecessary code.

[Christian Mauderer]

No one objected to these patches so I pushed them.

Best regards

Christian

On 17/03/2020 08:18, Christian Mauderer wrote:
> ---
>  lvgl.py | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/lvgl.py b/lvgl.py
> index 5452ed0..f275287 100644
> --- a/lvgl.py
> +++ b/lvgl.py
> @@ -68,26 +68,17 @@ def build(bld):
>  
>  sources, includes = source_list(bld)
>  includes.append('.')
> -objects = []
>  include_paths = []
>  
>  for source in sources:
> -objects.append(source[:-1] + 'o')
>  source_dir = os.path.dirname(source)
>  if source_dir not in include_paths:
>  include_paths.append(source_dir)
>  
> -bld.objects(target = objects,
> -features = 'c',
> -cflags = '-O2',
> -includes = includes,
> -source = source)
> -
>  bld.stlib(target = 'lvgl',
>features = 'c',
>includes = includes,
> -  source = sources,
> -  use = objects)
> +  source = sources)
>  
>  arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
>  bld.env.RTEMS_ARCH_BSP)
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH docs] user/bsps: Remove gdbarmsim

[G S Niteesh Babu]

Remove gdbarmsim from list of BSPs in docs. Since, the BSPs has
been removed from RTEMS by Joel.
---
 user/bsps/arm/gdbarmsim.rst | 8 
 1 file changed, 8 deletions(-)
 delete mode 100644 user/bsps/arm/gdbarmsim.rst

diff --git a/user/bsps/arm/gdbarmsim.rst b/user/bsps/arm/gdbarmsim.rst
deleted file mode 100644
index 26ea90c..000
--- a/user/bsps/arm/gdbarmsim.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-4.0
-
-.. Copyright (C) 2019 TBD
-
-gdbarmsim
-=
-
-TODO.
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel