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: Wed, 06 Feb 2013 23:01:57 +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 link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001607
Ilija Kocho <ilijak@siva.com.mk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #1999|0 |1
is obsolete| |
--- Comment #47 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2075
--> http://bugs.ecos.sourceware.org/attachment.cgi?id=2075&action=edit
Alternative Cortex-M4F FPU support with Lazy Stacking 130206
Jifl
I did a backport of the code described in comment 42. The attached code should
patch onto current CVS, but it is for illustration only so many improvements in
CDL and GDB stub refined during our discussion are not implemented.
To start with, there are two aspects of Lazy state saving:
- Context saving during exceptions. As you have noted Cortex-M features a
lazy FPU state saving. I shall call it Lazy Stacking - LS
- Thread Context Switching that is implemented in context.S. I shall call it
Lazy Thread Switching - LTS
The attached code does both LS and LTS, unlike my "official proposal"
(currently attachment 1991) that does LTS exclusively.
First some comparative measurements of thread switching delay:
1. The (proposed) FPU disabling scheme - LTS only (LS-less)
Testing parameters:
Thread switches: 128
Time unit: nanoseconds [ns]
Confidence
Ave Min Max Max-Min Ave Min Samp Function
====== ====== ====== ====== ==== ===== ===== ========
2016 2016 2016 0 100% 100% 127 Thread switch: int-int
2392 2392 2392 0 100% 100% 127 Thread switch: int-fpu
2312 2312 2312 0 100% 100% 127 Thread switch: fpu-int
2688 2688 2688 0 100% 100% 127 Thread switch: fpu-fpu
PASS:<Thread switching OK>
EXIT:<done>
2. Scheme with LS in addition to LTS
Testing parameters:
Thread switches: 128
Time unit: nanoseconds [ns]
Confidence
Ave Min Max Max-Min Ave Min Samp Function
====== ====== ====== ====== ==== ===== ===== ========
2088 2088 2088 0 100% 100% 127 Thread switch: int-int
2432 2432 2432 0 100% 100% 127 Thread switch: int-fpu
2408 2408 2408 0 100% 100% 127 Thread switch: fpu-int
2752 2752 2752 0 100% 100% 127 Thread switch: fpu-fpu
PASS:<Thread switching OK>
EXIT:<done>
As I mentioned in comment 42, itshows that LS-less code provides faster thread
switching. These measurements don't show interrupt processing times, but if you
compare the respective vectors.S files you can deduce that processing of
pendable SVC takes more time for LS code.
We can of course consider trading of processor time for having LS feature, but
I really find FPU usage in ISR academic. I understand and respect that ARM
fellows spent a great effort to provide us with LS but other than that I see no
practical reason to burn CPU cycles for something that very few, if any, would
want to use.
The attached code, also has a flaw that is described in comment 42 point 3. I
have developed a test that I will attach later. In order to fix this issue we
have to put more tests, at least 1 that will add more delay to context
switching.
Considering this, back then I did decide to omit FPU context saving for
exceptions. If there is a demand for FPU arithmetic we can consider it in
future _as option_ but for the time being I would say that we go with my
original proposal (LS-less).
Ilija
--
You are receiving this mail because:
You are on the CC list for the bug.