[jira] [Commented] (MYNEWT-746) Sim - Floating point calculations sometimes incorrect

["Christopher Collins (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MYNEWT-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078496#comment-16078496 ] 

Christopher Collins commented on MYNEWT-746:
--------------------------------------------

Suggestion: look at how the Linux kernel saves and restores its floating point state during context switch.

> Sim - Floating point calculations sometimes incorrect
> -----------------------------------------------------
>
>                 Key: MYNEWT-746
>                 URL: https://issues.apache.org/jira/browse/MYNEWT-746
>             Project: Mynewt
>          Issue Type: Bug
>      Security Level: Public(Viewable by anyone) 
>            Reporter: Christopher Collins
>            Assignee: Christopher Collins
>              Labels: doc
>             Fix For: v1_1_0_rel
>
>
> *Note: this problem does not occur in OS X; it has only been seen in Linux.*
> In sim, some floating point calculations yield wildly incorrect results (usually 0 or NaN).  The cause appears to be that the floating point registers are not restored when longjmp() is called.  If subsequent code tries to use an intermediate value stored in a floating point register, the result is indeterminate.
> There is a gcc / clang compiler option which mostly solves this problem: *-ffloat-store*:
> {quote}
> -ffloat-store
>     Do not store floating point variables in registers, and inhibit other options that might change whether a floating point value is taken from a register or memory.
>     This option prevents undesirable excess precision on machines such as the 68000 where the floating registers (of the 68881) keep more precision than a double is supposed to have. Similarly for the x86 architecture. For most programs, the excess precision does only good, but a few programs rely on the precise definition of IEEE floating point. Use -ffloat-store for such programs, after modifying them to store all pertinent intermediate computations into variables. 
> {quote}
> The problems disappeared when I started using this option.  However, it seems there is still the occasional miscalculation, as a test failure just occurred due to an incorrect floating point value.  In this case, assigning {{18.0}} to an int yielded the value {{-2147483648}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)