[Bug 1001607] Cortex-M4F architectural Floating Point Support

[bugzilla-daemon@bugs.ecos.sourceware.org]

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

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

--- Comment #63 from Jonathan Larmour <jifl@ecoscentric.com> ---
The only things I've seen is:
- you need to align the thread stacks in fpint_thread_switch.cxx with
CYGBLD_ATTRIB_ALIGN_MAX
- The changelogs for the twr_k70f120m and kinetis variant HALs don't quite
cover all the changes made

But that's it!

(In reply to comment #62)
> 
> I think that for interrupts it would be a waste.
> However this led me to idea to add check ASPEN bit of FPCCR to the
> GDB_STUB_SAVEDREG_FPU_EXCEPTION_SET() so now RedBoot can determine if
> autosave is enabled or disabled in runtime. Single RedBoot image to debug
> LAZY, ALL and NONE. Implemented.

Good catch, I'd missed that that would have been a problem, so fixing it is
even better :).

> There's no problem with using DSP instructions. CDL will allow you to set
> -mcpu=cortex-m4 either manually or provide as default setting by platform

Ah, I'd missed that subtlety in the CDL. The M3 flag is excluded on the basis
of FPU support, the M4 flag is excluded on the basis of CYGHWR_HAL_CORTEXM.
Yes, that's definitely fine then.

> > Also of course as mentioned above, we still need to work out the last few
> > niggles with those kernel tests.
> 
> I hope the tests are clean now. Some of the "features" were inherited from
> original files. My next window for check-in is the upcoming weekend.

I think with the above few changes (stack alignment and changelogs), which are
too minor to re-post here, you can put it all in.

Thanks for all this really good work! It's taken quite a while, but I think
what we now have is a lot better as a result.

Jifl

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