[Bug 1001607] Cortex-M4F architectural Floating Point Support

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001607

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|stm3240g_eval (ST           |All
                   |STM3240G-EVAL board)        |

--- Comment #49 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #41)
> But I wonder if we've been missing something here. According to
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0298a/
> DAFGGBJD.html the Cortex-M can itself support lazy stacking, and you do
> enable the relevant FPCCR bits in hal_init_fpu(). This means that the
> processor will lazily save s0-s15 only if needed. We also don't need to
> worry about s16-s31 as the procedure call standard means that they will
> automatically be saved/restored by the compiler if it generates code which
> uses them. This should mean that there is no penalty (except memory) of
> allowing FPU access in interrupt/exception handlers.
> 
> I believe the only time we do need to save s16-31 is if this is a ROM
> monitor or includes a GDB stub, i.e. if CYGSEM_HAL_DEBUG_FPU is defined
> (after the fix we already talked about).
> 
> If you agree with my assessment (I may have missed something!), then I would
> even go as far as saying that we could get rid of the _EXC_AUTOSAVE option,
> because there probably isn't a reason to do anything else - i.e. we can
> effectively have it permanently on.

Jifl
I missundersood you, lazy thinking :(. You are right, "ALL", as is, engages
Lazy Stacking indeed so we can drop the CYGARC_CORTEXM_FPU_EXC_AUTOSAVE option.
I am going to submit updated patch later today.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.