SPARC Floating Point Support Changes

[Gedare Bloom]

To clarify, are you asking if SPARC user applications are manipulating
the FSR in a function without saving it first and restoring it before
returning?

On Fri, May 8, 2015 at 2:48 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> Hello,
>
> we work currently on an optimization for the SPARC floating point support.
> See also:
>
> https://devel.rtems.org/ticket/2270
>
> We implement alternative (1). The floating point status register (FSR) is
> volatile according to the SPARC ABI.
>
> https://lists.rtems.org/pipermail/devel/2015-May/011232.html
>
> We are not sure if this is honoured in the RTEMS applications in general.
> Are there known uses cases which treat the FSR in a thread specific
> non-volatile way? It would be beneficial to rely on a volatile only usage
> since this would lead to a much simpler floating point context save/restore
> code.
>
> --
> 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.
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users