From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3181 invoked by alias); 6 Feb 2013 23:02:15 -0000 Received: (qmail 3172 invoked by uid 22791); 6 Feb 2013 23:02:14 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW 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; Wed, 06 Feb 2013 23:02:08 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 098B2468000E for ; Wed, 6 Feb 2013 23:02:06 +0000 (GMT) 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 p0t-vDPphktp; Wed, 6 Feb 2013 23:02:00 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001607] Cortex-M4F architectural Floating Point Support Date: Wed, 06 Feb 2013 23:02:00 -0000 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: NEEDINFO X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: jifl@ecoscentric.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: attachments.isobsolete Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: 2013-02/txt/msg00012.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001607 Ilija Kocho changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1999|0 |1 is obsolete| | --- Comment #47 from Ilija Kocho --- 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: EXIT: 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: EXIT: 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.