[PATCH] sparc: Rename NGMP to GR740 and add configs for UT699, UT700, and GR712RC

Sebastian Huber sebastian.huber at embedded-brains.de
Fri Jul 14 10:01:23 UTC 2017



On 13/07/17 11:21, Daniel Cederman wrote:
> On 2017-07-13 10:43, Sebastian Huber wrote:
>> All the BSPs use -msoft-float. How do we want to address the 
>> soft-float vs. hard-float issue on SPARC? This is a never ending 
>> story so far. Is soft-float really used in the majority of 
>> applications? All the users I talked up to now said they use hard-float.
>>
>> What about enabling SPARC_USE_SAFE_FP_SUPPORT also in uniprocessor 
>> configurations and maybe add a lazy floating point safe as an 
>> optimization?
>>
>>
>
> In RCC we have not taken advantage of the Makefile fragments that are 
> generated for each BSP. Instead we have added custom flags to GCC, 
> such as -qleon2, which adds the correct include and library paths. So 
> the flags in leon3.cfg have only affected the compilation of the 
> kernel, which does not use floats. For the kernel we have a patch to 
> always enable floating-point support, but only use it if a FPU is 
> available, which is detected by probing.

Its not good that you patch RTEMS to get something useful for the users 
of RTEMS on your chips. Why can't you add this probing stuff to RTEMS 
mainline?

>
> So in RCC hard floats have always been used if the hardware supports 
> it, as I understand it. I could revise the patch to remove the 
> -msoft-flag as, as you say, most people would like to use hard floats. 

We should probably

1. remove the -msoft-float,

2. enable SPARC_USE_SAFE_FP_SUPPORT for all configurations (see also 
test case spcontext01), and

3. add a deferred floating-point save for uniprocessor configurations.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the devel mailing list