[Bug 1001607] Cortex-M4F architectural Floating Point Support

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