This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001607] Cortex-M4F architectural Floating Point Support


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]