From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4067 invoked by alias); 17 Dec 2012 14:05:48 -0000 Received: (qmail 4054 invoked by uid 22791); 17 Dec 2012 14:05:47 -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; Mon, 17 Dec 2012 14:05:10 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 07F574680008 for ; Mon, 17 Dec 2012 14:05:09 +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 4hAiHTPpX25U; Mon, 17 Dec 2012 14:05:03 +0000 (GMT) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001607] Cortex-M4F architectural Floating Point Support 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: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 17 Dec 2012 14:05:00 -0000 Message-Id: <20121217140503.1D95E4680002@mail.ecoscentric.com> 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: 2012-12/txt/msg00013.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001607 --- Comment #42 from Ilija Kocho 2012-12-17 14:04:59 GMT --- Created an attachment (id=1999) --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1999) Alternative Cortex-M4F FPU support 121217 (probably outdated). Hi Jifl I will address other issues later. I think this one deserves special explanation - once we have get to it. (In reply to comment #41) > (In reply to comment #40) > But I wonder if we've been missing something here. According to > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0298a/DAFGGBJD.html > the Cortex-M can itself support lazy stacking, and you do enable the relevant > FPCCR bits in hal_init_fpu(). This means that the processor will lazily save > s0-s15 only if needed. We also don't need to worry about s16-s31 as the > procedure call standard means that they will automatically be saved/restored by > the compiler if it generates code which uses them. This should mean that there > is no penalty (except memory) of allowing FPU access in interrupt/exception > handlers. > > I believe the only time we do need to save s16-31 is if this is a ROM monitor > or includes a GDB stub, i.e. if CYGSEM_HAL_DEBUG_FPU is defined (after the fix > we already talked about). > > If you agree with my assessment (I may have missed something!), then I would > even go as far as saying that we could get rid of the _EXC_AUTOSAVE option, > because there probably isn't a reason to do anything else - i.e. we can > effectively have it permanently on. > I have tried this approach, indeed it was my first option, but I have abandoned it. Here I attach what I believe to be the latest iteration. Note: this code saves FPU state during interrupts for LAZY but does not for ALL. Main reasons that I dropped this approach are: 1. Context switching takes more time, compared to submitted one, as now instead of 1 we have 2 (or more - see point 3.) checks: a) Context switch initiated by interrupt/exception (such as tick) - then we need to check FPCCR LSPACT flag; b) Context switch initiated by kernel without interrupt involved (such as yield, priority change, semaphore, etc. Then we check CONTROL register FPCA flag Since we don't know the reason for context switch, or testing for that would take even more time, we must check both flags compared to only one for submitted version. 2. There are also some complexities coming from from variable CPU context length. That requires some additional checks in, for instance pendable VSR, interrupt end VSR, etc. that also takes some (ISR) time. 3. Although this code passes fpinttestf.c (or fptestf.c) there is at least one case unattended: 1. Thread foo uses FPU -> Context switch 2. other threads .... 3. foo gets cpu time but does not use fpu till next context switch. It's context shall be marked FPU less. 4. other threads 5. foo scheduled again, now with lost FPU context! This means that one more check is necessary in hal_thread_switch_context which will add further delay. To sum up, I opted for performance and simplicity. It's true I gave up the possibility of floating point during ISR/VSR in LAZY scheme, but whoever needs floating point within ISR/DSR still has the ALL scheme. Last but not least, my knowledge of eCos kernel context switching is limited to what I have learned during development of FPU support by code inspection and tracing. I can imagine that you have a better insight. 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.