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.hu...@embedded-brains.de
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
