Re: Math lib inclusion in BSP
On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan wrote: > Hey all, > > We are developing a new BSP that uses math.h in few of the BSP files. I do May I ask why do you need floating point operations in a kernel? At least, what sort of operations and why not move them upwards. > understand that the math library functions are not part of standard C > library and has to be linked using "-lm". So I include "LD_LIBS += -lm" in > the custom .cgf config file but this doesn't seem to work. I think this has > to be linked in a proper order. Could someone help with this? > > Heres the custom config file: > > include $(RTEMS_ROOT)/make/custom/default.cfg > > RTEMS_CPU = arm > > LD_LIBS += -lm > > CPU_CFLAGS = -march=armv7-m -mthumb > > CFLAGS_OPTIMIZE_V = -O0 -g -mfloat-abi=hard -mfpu=fpv4-sp-d16 > > Thanks and Regards, > Sudarshan > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype:dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Math lib inclusion in BSP
On 2015-09-25 11:06, Daniel Gutson wrote: On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan wrote: Hey all, We are developing a new BSP that uses math.h in few of the BSP files. I do May I ask why do you need floating point operations in a kernel? At least, what sort of operations and why not move them upwards. We are doing floating point operations in one of the device drivers as part of the BSP - to perform buadrate calculation, to be specific, which involes inverse operations and using roundf(). understand that the math library functions are not part of standard C library and has to be linked using "-lm". So I include "LD_LIBS += -lm" in the custom .cgf config file but this doesn't seem to work. I think this has to be linked in a proper order. Could someone help with this? Heres the custom config file: include $(RTEMS_ROOT)/make/custom/default.cfg RTEMS_CPU = arm LD_LIBS += -lm CPU_CFLAGS = -march=armv7-m -mthumb CFLAGS_OPTIMIZE_V = -O0 -g -mfloat-abi=hard -mfpu=fpv4-sp-d16 Thanks and Regards, Sudarshan ___ 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: Math lib inclusion in BSP
El 25/9/2015 13:17, "sudarshan.rajagopalan" escribió: > > On 2015-09-25 11:06, Daniel Gutson wrote: >> >> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan >> wrote: >>> >>> Hey all, >>> >>> We are developing a new BSP that uses math.h in few of the BSP files. I do >> >> >> May I ask why do you need floating point operations in a kernel? At >> least, what sort of operations and why not move them upwards. > > > We are doing floating point operations in one of the device drivers as part of the BSP - to perform buadrate calculation, to be specific, which involes inverse operations and using roundf(). How will you handle fp exceptions? Did you consider using fixed point? > > >> >>> understand that the math library functions are not part of standard C >>> library and has to be linked using "-lm". So I include "LD_LIBS += -lm" in >>> the custom .cgf config file but this doesn't seem to work. I think this has >>> to be linked in a proper order. Could someone help with this? >>> >>> Heres the custom config file: >>> >>> include $(RTEMS_ROOT)/make/custom/default.cfg >>> >>> RTEMS_CPU = arm >>> >>> LD_LIBS += -lm >>> >>> CPU_CFLAGS = -march=armv7-m -mthumb >>> >>> CFLAGS_OPTIMIZE_V = -O0 -g -mfloat-abi=hard -mfpu=fpv4-sp-d16 >>> >>> Thanks and Regards, >>> Sudarshan >>> ___ >>> 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: Math lib inclusion in BSP
On 2015-09-25 01:33, Sebastian Huber wrote: On 24/09/15 21:49, sudarshan.rajagopalan wrote: We are developing a new BSP that uses math.h in few of the BSP files. I do understand that the math library functions are not part of standard C library and has to be linked using "-lm". So I include "LD_LIBS += -lm" in the custom .cgf config file but this doesn't seem to work. I think this has to be linked in a proper order. Could someone help with this? This seems to be a candidate for a FAQ: https://lists.rtems.org/pipermail/devel/2014-October/008322.html This patch would solve the problem: https://lists.rtems.org/pipermail/devel/2014-September/008191.html Is the above patch committed to the master? I applied the above patch to the "bsp_specs" file specific to the BSP processor and it worked, but couldn't find the gcc/config/rtems.h file mentioned. Is the file moved or changed? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Math lib inclusion in BSP
On 2015-09-25 12:21, Daniel Gutson wrote: El 25/9/2015 13:17, "sudarshan.rajagopalan" escribió: > > On 2015-09-25 11:06, Daniel Gutson wrote: >> >> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan >> wrote: >>> >>> Hey all, >>> >>> We are developing a new BSP that uses math.h in few of the BSP files. I do >> >> >> May I ask why do you need floating point operations in a kernel? At >> least, what sort of operations and why not move them upwards. > > > We are doing floating point operations in one of the device drivers as part of the BSP - to perform buadrate calculation, to be specific, which involes inverse operations and using roundf(). How will you handle fp exceptions? Did you consider using fixed point? We haven't implemented any error handling yet. We will do so in our next phase. And I think we decided to use floating-point due to the available FPU hardware support in the processor( ARM Cortex-M4 and M7) to make these operations faster. Are there any concerns that we should be aware of while using floating-point operations in the BSP? > > >> >>> understand that the math library functions are not part of standard C >>> library and has to be linked using "-lm". So I include "LD_LIBS += -lm" in >>> the custom .cgf config file but this doesn't seem to work. I think this has >>> to be linked in a proper order. Could someone help with this? >>> >>> Heres the custom config file: >>> >>> include $(RTEMS_ROOT)/make/custom/default.cfg >>> >>> RTEMS_CPU = arm >>> >>> LD_LIBS += -lm >>> >>> CPU_CFLAGS = -march=armv7-m -mthumb >>> >>> CFLAGS_OPTIMIZE_V = -O0 -g -mfloat-abi=hard -mfpu=fpv4-sp-d16 >>> >>> Thanks and Regards, >>> Sudarshan >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel [1] > > Links: -- [1] http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] score: Fix atomic compare exchange
Sebastian,
Does this need to go on 4.11 / ticket filed?
On Fri, Sep 25, 2015 at 3:51 PM, Sebastian Huber wrote:
> Module:rtems
> Branch:master
> Commit:1f7c5c88ca384baa312a0714c6e93174605418a7
> Changeset:
> http://git.rtems.org/rtems/commit/?id=1f7c5c88ca384baa312a0714c6e93174605418a7
>
> Author:Sebastian Huber
> Date: Fri Sep 25 21:31:00 2015 +0200
>
> score: Fix atomic compare exchange
>
> ---
>
> cpukit/score/cpu/sparc/sparcv8-atomic.c | 8 ++-
> cpukit/score/include/rtems/score/cpustdatomic.h | 18 +--
> testsuites/sptests/spatomic01/init.c| 65
> +++--
> 3 files changed, 70 insertions(+), 21 deletions(-)
>
> diff --git a/cpukit/score/cpu/sparc/sparcv8-atomic.c
> b/cpukit/score/cpu/sparc/sparcv8-atomic.c
> index b1c4f23..2b3bdbc 100644
> --- a/cpukit/score/cpu/sparc/sparcv8-atomic.c
> +++ b/cpukit/score/cpu/sparc/sparcv8-atomic.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2014 embedded brains GmbH. All rights reserved.
> + * Copyright (c) 2014-2015 embedded brains GmbH. All rights reserved.
> *
> * embedded brains GmbH
> * Dornierstr. 4
> @@ -118,12 +118,16 @@ bool __atomic_compare_exchange_4(
> {
>bool equal;
>ISR_Level level;
> + uint32_t actual;
>
>level = _SPARCV8_Acquire_the_one_lock();
>
> - equal = *mem == *expected;
> + actual = *mem;
> + equal = ( actual == *expected );
>if ( equal ) {
> *mem = desired;
> + } else {
> +*expected = actual;
>}
>
>_SPARCV8_Release_the_one_lock( level );
> diff --git a/cpukit/score/include/rtems/score/cpustdatomic.h
> b/cpukit/score/include/rtems/score/cpustdatomic.h
> index 2696e3a..c66dd7e 100644
> --- a/cpukit/score/include/rtems/score/cpustdatomic.h
> +++ b/cpukit/score/include/rtems/score/cpustdatomic.h
> @@ -577,13 +577,17 @@ static inline bool _CPU_atomic_Compare_exchange_uint(
> CPU_atomic_Uint *obj, unsi
> #else
>bool success;
>ISR_Level level;
> + unsigned int actual;
>
>(void) succ;
>(void) fail;
>_ISR_Disable( level );
> - success = *obj == *expected;
> + actual = *obj;
> + success = ( actual == *expected );
>if ( success ) {
> *obj = desired;
> + } else {
> +*expected = actual;
>}
>_ISR_Enable( level );
>
> @@ -600,13 +604,17 @@ static inline bool _CPU_atomic_Compare_exchange_ulong(
> CPU_atomic_Ulong *obj, un
> #else
>bool success;
>ISR_Level level;
> + unsigned long actual;
>
>(void) succ;
>(void) fail;
>_ISR_Disable( level );
> - success = *obj == *expected;
> + actual = *obj;
> + success = ( actual == *expected );
>if ( success ) {
> *obj = desired;
> + } else {
> +*expected = actual;
>}
>_ISR_Enable( level );
>
> @@ -623,13 +631,17 @@ static inline bool _CPU_atomic_Compare_exchange_ptr(
> CPU_atomic_Pointer *obj, vo
> #else
>bool success;
>ISR_Level level;
> + uintptr_t actual;
>
>(void) succ;
>(void) fail;
>_ISR_Disable( level );
> - success = *obj == (uintptr_t) *expected;
> + actual = *obj;
> + success = ( actual == (uintptr_t) *expected );
>if ( success ) {
> *obj = (uintptr_t) desired;
> + } else {
> +*expected = (void *) actual;
>}
>_ISR_Enable( level );
>
> diff --git a/testsuites/sptests/spatomic01/init.c
> b/testsuites/sptests/spatomic01/init.c
> index fbfd071..b90ffd0 100644
> --- a/testsuites/sptests/spatomic01/init.c
> +++ b/testsuites/sptests/spatomic01/init.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2013-2014 embedded brains GmbH. All rights reserved.
> + * Copyright (c) 2013-2015 embedded brains GmbH. All rights reserved.
> *
> * embedded brains GmbH
> * Dornierstr. 4
> @@ -189,24 +189,57 @@ static void
> test_simple_atomic_exchange_body(test_context *ctx)
>
> static void test_simple_atomic_compare_exchange_body(test_context *ctx)
> {
> - unsigned int ia = 8, ib = 4;
> - unsigned int ic;
> - unsigned long a = 2, b = 1;
> - unsigned long c;
> + unsigned int ei;
> + unsigned int vi;
> + unsigned long el;
> + unsigned long vl;
> + bool success;
>
>puts("=== atomic simple compare exchange test case ===");
>
> - _Atomic_Store_uint(&ctx->atomic_int_value, ia, ATOMIC_ORDER_RELAXED);
> - _Atomic_Compare_exchange_uint(&ctx->atomic_int_value, &ia, ib,
> -ATOMIC_ORDER_RELAXED, ATOMIC_ORDER_RELAXED);
> - ic = _Atomic_Load_uint(&ctx->atomic_int_value, ATOMIC_ORDER_RELAXED);
> - rtems_test_assert(ic == ib);
> -
> - _Atomic_Store_ulong(&ctx->atomic_value, a, ATOMIC_ORDER_RELAXED);
> - _Atomic_Compare_exchange_ulong(&ctx->atomic_value, &a, b,
> -ATOMIC_ORDER_RELAXED, ATOMIC_ORDER_RELAXED);
> - c = _Atomic_Load_ulong(&ctx->atomic_value, ATOMIC_ORDER_RELAXED);
> - rtems_test_assert(c == b);
> + _Atomic_Store_uint(&ctx->atomic_int_value, 1, ATOMIC_ORDER_RELAXED);
> + ei = 2;
> + success = _Atomic_Compare_exchange_uint(
> +&ctx->atomic_int_value,
> +&ei,
> +3,
> +ATOMIC_ORDER_RELAXED,
> +ATOMIC_ORDER_RELAXED
> + );
> +
