From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28949 invoked by alias); 28 Jun 2012 07:41:24 -0000 Received: (qmail 28935 invoked by uid 22791); 28 Jun 2012 07:41:21 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 28 Jun 2012 07:41:03 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 900AA2FF0004 for ; Thu, 28 Jun 2012 08:41:02 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWhtZthgHiPI; Thu, 28 Jun 2012 08:41:00 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001607] Cortex-M4F architectural Floating Point Support X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: jifl@ecoscentric.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 28 Jun 2012 07:41:00 -0000 Message-Id: <20120628074100.25A7B2F78001@mail.ecoscentric.com> Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org X-SW-Source: 2012-06/txt/msg00020.txt.bz2 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 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.