This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001607] Cortex-M4F architectural Floating Point Support


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 <ilijak@siva.com.mk> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]