On 16/11/15 13:14, Daniel Cederman wrote:
I was unsure if the ET bit was always set or not for newly created
task contexts, or if this was the first place that traps got enabled
for a new task. If it is always set we can remove that instruction.
The PSR is initialized like this (_CPU_Context_Initialize()):
[...]
/*
* Build the PSR for the task. Most everything can be 0 and the
* CWP is corrected during the context switch.
*
* The EF bit determines if the floating point unit is available.
* The FPU is ONLY enabled if the context is associated with an FP
task
* and this SPARC model has an FPU.
*/
sparc_get_psr( tmp_psr );
tmp_psr &= ~SPARC_PSR_PIL_MASK;
tmp_psr |= (new_level << 8) & SPARC_PSR_PIL_MASK;
tmp_psr &= ~SPARC_PSR_EF_MASK; /* disabled by default */
#if (SPARC_HAS_FPU == 1)
/*
* If this bit is not set, then a task gets a fault when it accesses
* a floating point register. This is a nice way to detect floating
* point tasks which are not currently declared as such.
*/
if ( is_fp )
tmp_psr |= SPARC_PSR_EF_MASK;
#endif
the_context->psr = tmp_psr;
[...]
Since traps must be enabled at C level, this should be fine.
Maybe add this to the patch for documentation purposes:
diff --git a/cpukit/score/cpu/sparc/cpu.c b/cpukit/score/cpu/sparc/cpu.c
index 569b6f8..5434355 100644
--- a/cpukit/score/cpu/sparc/cpu.c
+++ b/cpukit/score/cpu/sparc/cpu.c
@@ -356,6 +356,9 @@ void _CPU_Context_Initialize(
tmp_psr |= (new_level << 8) & SPARC_PSR_PIL_MASK;
tmp_psr &= ~SPARC_PSR_EF_MASK; /* disabled by default */
+ /* _CPU_Context_restore_heir() relies on this */
+ _Assert( ( tmp_psr & SPARC_PSR_ET_MASK ) != 0 );
+
#if (SPARC_HAS_FPU == 1)
/*
* If this bit is not set, then a task gets a fault when it accesse
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
