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: Tue, 6 Nov 2012 20:54:07 +0000
- 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
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.