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

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1921|0                           |1
        is obsolete|                            |

--- Comment #33 from Ilija Kocho <ilijak@siva.com.mk> 2012-11-06 20:54:04 GMT ---
Created an attachment (id=1979)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1979)
Cortex-M4F Floating Point Support 121106

I think that I got a solution for CFLAGS/LDFLAGS management.

The problem was that, as it occurs to me, if several CDL components manipulate
a string [by means of !is_substr()/is_substr()] they do it in a concurrent
manner. I am not familiar with configtool internal structure but it looked like
race conditions...

Therefore I decided to move all operations in a single CDL that is
CYGBLD_ARCH_CPUFLAGS. Besides working smoothly it also solves the following
problems:
   - Home place for FLAGS related "requires" commands,
   - Extensibility: New flags can be added in future,
   - Maintenance: All FLAGS operation on architectural level is consolidated in
a single CDL.
   - Compatibility: No tackling with FLAGS on platform level. Platform need
only to implement an interface. Look for example in STM 32 patch (untested in
runtime).
   - Simplicity: I hope so :-) 

My ability for testing is limited during this and following week, but from what
I could see it operates as it should.

As I have a feeling that we are approaching our goal I would like to do some
shaping work. One question is where is best place to put the tests. They stem
from kernel tests, should I place them there or under Cortex-M architecture?

So far I only run tests on Kinetis. I would appreciate if somebody tries
STM32F4.

Regards
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.


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