[Bug 1001607] Cortex-M4F architectural Floating Point Support

[bugzilla-daemon@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.