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.
On 2015-11-16 11:27, Sebastian Huber wrote:
On 16/11/15 11:06, Daniel Cederman wrote:
@@ -202,6 +193,13 @@ try_update_is_executing:
! The next load is in a delay slot, which is all right
#endif
+ ld [%o1 + PSR_OFFSET], %g1 ! g1 = heir psr
+ andn %g1, SPARC_PSR_CWP_MASK, %g1 ! g1 = heir psr w/o cwp
+ or %g1, %g3, %g1 ! g1 = heir psr with cwp
+ or %g1, SPARC_PSR_ET_MASK, %g1 ! g1 = heir psr traps
enabled
Do we really need the "or %g1, SPARC_PSR_ET_MASK, %g1"? I think we
should simply use the value of the saved PSR and omit this step.
+ mov %g1, %psr ! restore status
register and
+ ! **** ENABLE TRAPS ****
+
ld [%o1 + G5_OFFSET], %g5 ! restore the global
registers
ld [%o1 + G7_OFFSET], %g7
--
Daniel Cederman
Software Engineer
Cobham Gaisler
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
