[RTEMS Project] #2270: SPARC: Optimized floating-point context handling

[RTEMS trac]

#2270: SPARC: Optimized floating-point context handling
-----------------------------+-----------------------------
 Reporter:  sebastian.huber  |      Owner:  sebastian.huber
     Type:  enhancement      |     Status:  new
 Priority:  normal           |  Milestone:  4.11.1
Component:  cpukit           |    Version:  4.11
 Severity:  normal           |   Keywords:  SPARC
-----------------------------+-----------------------------
 = Benefit =

 Improved average-case performance.  Uni-processor configurations will
 equally benefit in case the deferred floating-point switch is retained.

 = Problem Description =

 The floating-point context switch implementation is suboptimal on
 RTEMS/SPARC.

 == SPARC ABI Considerations ==

 The set of registers of a processor is divided into three groups by the
 application binary interface (ABI)

 * the volatile registers (also known as caller saved),
 * the non-volatile registers (also known as callee saved), and
 * other registers.

 On RTEMS a context switch is performed via a function call
 ({{{_CPU_Context_switch()}}}), thus the context switch must save/restore
 the non-volatile registers.  The interrupt entry/exit must save/restore
 the volatile registers to/from the stack of the interrupted thread.  The
 [http://math-atlas.sourceforge.net/devel/assembly/abi_sysV_sparc.pdf
 SYSTEM V APPLICATION BINARY INTERFACE, SPARC Processor Supplement, Third
 Edition] declares all floating point registers as volatile.

 Currently the floating point context is saved/restored during the context
 switch on SPARC.  The interrupt entry/exit doesn't deal with the floating
 point unit at all.  This makes no sense with respect to the ABI.  This
 seems to be an optimization for uni-processor systems and applications
 with only few floating point threads.

 == No Deferred Floating Point Context Switch on SMP ==

 RTEMS supports the so called deferred floating point context switch.  This
 is an anachronism dating back to times with primitive compilers and
 processors.  Modern compilers on modern processors which provide direct
 register moves to/from floating point registers will use floating point
 and vector units for all sorts of stuff, thus the differentiation between
 floating point and integer context is mostly obsolete.  On SPARC floating
 point registers must be loaded from memory, so it makes no sense to move
 integer variables into floating point registers to reduce register
 pressure.  So SPARC GCC seems to use the floating point unit only for
 floating point operations, so here this model is still valid.  The
 deferred floating point context switch is an optimization for applications
 on which the floating point threads are the minority.  The floating point
 unit is owned by at most one thread and a floating point context switch is
 deferred until a context switch happens to a floating point thread other
 than the owner of floating point unit.  On SPARC interrupts are not
 allowed to use the floating point unit at all on RTEMS.

 WARNING: Currently the floating point unit is not disabled on interrupt
 entry (PSR[EF]).  Thus interrupt handlers using the floating point unit
 may destroy the floating point context of the interrupted thread silently.

 This seemed to work well on RTEMS in the last couple of years although
 from time to time questions pop up on the RTEMS mailing list with respect
 to floating point support on SPARC.  With SMP the situation changed
 though.  In the early times of RTEMS SMP support the deferred floating
 point support has been disabled.

 Lets suppose we want to use deferred floating point context switches on
 SMP.  Consider the following scenario.  An executing thread T owning the
 floating point unit is interrupted and a context switch to a non-floating
 point thread happens.  In this case the floating point context is not
 saved.  Now the thread T resumes execution on another processor (thread
 migration).  How do we get access to its floating point context on the
 other processor?  We would need inter-processor interrupts,
 synchronization, etc. making this way too expensive.

 = Problem Solution =

 To meet the ABI requirements, the floating point context switch must move
 from the context switch to the interrupt entry/exit sequence.  It is only
 necessary to save/restore the floating point context in case a context
 switch is triggered due to interrupt processing.

 On uni-processor configurations it is possible to implement a deferred
 floating point context save/restore here as well.

 To get rid of potentially silent corruptions of the floating point context
 by interrupt handlers, there are three alternative solutions:

 * Clear the PSR[EF] bit at interrupt entry and save/restore the floating
 point context only in case a thread dispatch is necessary,
 * save/restore the floating point context of the interrupted thread at
 interrupt entry/exit, or
 * use a lazy floating point context save, e.g. clear PSR[EF] and reserve
 space for the floating point context on interrupt entry, then save/restore
 the floating point context on demand.

 The second solution would enable interrupt handlers to use floating point
 operations, but increases the interrupt latency.

 The third solution would enable interrupt handlers to use floating point
 operations and may have less impact on the interrupt latency compared to
 the second alternative.  The implementation is a bit more complex.

 In order to test the low-level code, the
 {{{_CPU_Context_volatile_clobber()}}} and {{{_CPU_Context_validate()}}}
 functions should be implemented on SPARC.  The test program ''SPCONTEXT
 1'' uses these functions to test the context switch and interrupt
 entry/exit code.

--
Ticket URL: <http://devel.rtems.org/ticket/2270>
RTEMS Project <http://www.rtems.org/>
RTEMS Project