This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
[Bug 1001607] Cortex-M4F architectural Floating Point Support
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-patches at ecos dot sourceware dot org
- Date: Wed, 8 Aug 2012 19:01:15 +0100
- Subject: [Bug 1001607] Cortex-M4F architectural Floating Point Support
- Auto-submitted: auto-generated
- References: <bug-1001607-104@http.bugs.ecos.sourceware.org/>
Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001607
--- Comment #20 from Jonathan Larmour <jifl@ecoscentric.com> 2012-08-08 19:01:08 BST ---
Hi Ilija,
(In reply to comment #18)
> (In reply to comment #16)
> >the part we are making temporary is the bit that says:
> > requires { ("CYGHWR_HAL_CORTEXM == "M4") implies
> > is_substr(!is_substr(CYGBLD_GLOBAL_CFLAGS, "-mcpu=cortex-m3") &&
> > is_substr(CYGBLD_GLOBAL_CFLAGS, " -mcpu=cortex-m4 ") }
> > which instead we will comment out for now until we are happy with gcc 4.6.3.
> >
>
> I agree about CYGOPT_HAL_CORTEXM4_CODE removal, but I think that making
> -mcpu=cortex-m4 mandatory for M4 is too inflexible. With present CDL it is
> possible to edit CYGBLD_GLOBAL_CFLAGS and change -mcpu. And somebody will want
> to try M4 with cortex-m3 code.
True enough, then we simply leave that 'requires' out forever rather than
temporarily :-).
> Therefore I think that the idea about CYGBLD_ARCH_XFLAGS is good. It will
> provide -mcpu= default value which can later be edited. This will require us
> to touch some platform CDL files but we only have to deal with M4 devices with
> FPU and they are few (though we can see if we want to "canonize" other
> platforms).
Yes, better to do it now than later.
> > All the M3-based platform HALs will have their CFLAGS default to
> > -mcpu=cortex-m3, and the M4 HALs will have -mcpu=cortex-m4 -mfloat-abi=hard
> > -mfpu=fpv4-sp-d16.
>
> FAOD, there are cortex-m4 devices without FPU as well.
Sure, I just meant for our current TWR-K70 and STM3240G platforms.
> We can apply following changes to CYGHWR_HAL_FPV4_SP_D16 [snip]
> + requires { is_substr(CYGBLD_GLOBAL_CFLAGS, " -mcpu=cortexm4
> -mfloat-abi=hard -mfpu=fpv4-sp-d16") }
> + requires { !is_substr(CYGBLD_GLOBAL_CFLAGS, "-mcpu=cortexm3") }
> + requires { is_substr(CYGBLD_GLOBAL_LDFLAGS, " -mcpu=cortexm4
> -mfloat-abi=hard -mfpu=fpv4-sp-d16") }
> + requires { !is_substr(CYGBLD_GLOBAL_LDFLAGS, "-mcpu=cortexm3") }
Along with what was in the old "anti-flags" proposal to cover when it's
disabled, that looks good.
[snip]
> > 5) I think CYGHWR_HAL_FPV4_SP_D16 can live under the CYGHWR_HAL_CORTEXM_FPU
> > component.
>
> CYGHWR_HAL_FPV4_SP_D16 is a FPU instance. As you say in future there may be
> others. Do we want them under CYGHWR_HAL_CORTEXM_FPU?
Yes since they will all be active_if CYGHWR_HAL_CORTEXM_FPU anyway, they may as
well just live under.
> > 6) A general comment as something which can be done last thing before check-in,
> > and I know it's only a cosmetic thing, but contents of options are a little
> > more readable if things are aligned. For example: [snip]
>
> There are other places like this. My intention is to check them when we came
> close to commit.
Great, I'm just being paranoid then :-).
Jifl
--
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.