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: Thu, 28 Jun 2012 08:41:00 +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 #11 from Ilija Kocho <ilijak@siva.com.mk> 2012-06-28 08:40:46 BST ---
Hi Jifl
Here I revisit the CFLAGS
(In reply to comment #10)
> > - Here's a possible outline of a simplification. What do you think?
> > cdl_option CYGHWR_HAL_CORTEXM_FPU_FLAGS {
> > display "FPU build flags"
> > calculated { (CYGHWR_HAL_CORTEXM_FPU ? " -mfloat-abi=hard" : "" ) .
> > (CYGINT_HAL_CORTEXM_FPV4_SP_D16 ? " -mfpu=fpv4-sp-d16" : "" ) }
> > }
> > requires is_substr(CYGBLD_GLOBAL_CFLAGS, CYGHWR_HAL_CORTEXM_FPU_FLAGS )
> > requires is_substr(CYGBLD_GLOBAL_LDFLAGS, CYGHWR_HAL_CORTEXM_FPU_FLAGS )
> > requires { !CYGHWR_HAL_CORTEXM_FPU implies !is_substr(CYGBLD_GLOBAL_CFLAGS,
> > "-mfpu=fpv4-sp-d16") && !is_substr(CYGBLD_GLOBAL_CFLAGS, "-mfloat-abi=hard") }
> > requires { !CYGHWR_HAL_CORTEXM_FPU implies !is_substr(CYGBLD_GLOBAL_LDFLAGS,
> > "-mfpu=fpv4-sp-d16") && !is_substr(CYGBLD_GLOBAL_LDFLAGS, "-mfloat-abi=hard") }
>
> Since you ask me, I would get rid of is_substr(). Something like this:
>
> cdl_option CYGHWR_HAL_CORTEXM_FLOAT_ABI_FLAG {
> flavor data
> no_define
> display "Float ABI flag"
> calculated { CYGHWR_HAL_CORTEXM_FPU ? " -mfloat-abi=hard" : "" }
> }
>
> cdl_option CYGHWR_HAL_CORTEXM_FPU_FLAG {
> flavor data
> no_define
> display "FPU build flags"
> calculated { (CYGHWR_HAL_CORTEXM_FPU && CYGINT_HAL_CORTEXM_FPV4_SP_D16) ?
> " -mfpu=fpv4-sp-d16" : "" }
> }
>
> Ditto for -mcpu=cortex-m3/m4 (CYGHWR_HAL_CORTEXM_CPU_FLAG).
>
> Then we concatenate all these in CYGBLD_GLOBAL_CFLAGS.
>
> cdl_option CYGBLD_GLOBAL_CFLAGS {
> display "Global compiler flags"
> flavor data
> no_define
> default_value { CYGBLD_GLOBAL_WARNFLAGS . CYGHWR_HAL_CORTEXM_CPU_FLAG .
> " -mthumb -g -O2 ffunction-sections -fdata-sections -fno-rtti
> -fno-exceptions" .
> CYGHWR_HAL_CORTEXM_FLOAT_ABI_FLAG . CYGHWR_HAL_CORTEXM_FPU_FLAG }
> }
>
I found out that this requires CYGBLD_GLOBAL_CFLAGS to be *calculated* instead
of *default_value*. I assume that it is not flexible enough so I revoke it.
Regarding your outline it looks nicer than the one I posted in the patch.
However it leaves some unresolved conflicts when I try to change code
generation by clicking the subject controls in configtool.
Actually I came to the construction from the submitted patch after pretty much
experimenting and my criterion was: least clicks that produce unresolved
conflicts. To explain what I mean, here's one example:
1. Create a configuration with "Freescale Kinetis TWR-K70F120M" default
template.
2. Deselect Cortex-M4 code.
Configtool shall report unresolved conflicts. (You can make it easier to
configtool if you deselect Hardware FPU prior to deselecting Cortex-M4). This
is AFAICT the only case that produces unresolved conflict for present CDL
construction. Other combinations that I have tried have more cases. I'm not
much familiar with CDL engine, but from my experience I would say that it is
easier to corner configtool to resolve the conflicts if expressions are
constants (rather than variables).
Cheers
Ilija
--
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.