Is the Mips interrupt code flawed?

[Joel Sherrill <joel@OARcorp.com>]

Bruce Robinson wrote:
> To Mips-rtems users,
> 
> I found a knowledge base article on the PMC-Sierra's web site that describes
> using a MIPS system call as the proper way to "atomically" disable
> interrupts. The system call will cause the EXL flag to be set in the status
> register, holding off interrupts while the IE bit is cleared. From my study
> of the MIPS code, it appears that RTEMS disables interrupts by reading the
> status register, adjusting the IP, EXL and IE flags, and then writing the
> value back to the status register. Isn't it possible that an interceding
> interrupt/context switch could result in the status register contents to be
> incorrectly updated?
> 
> Am I missing something?

I don't know for sure since this is so MIPS specific.  The SPARC has to
have a disable/enable system call so this is certainly possible.

 From an atomicity viewpoint, the critical section for _ISR_Disable
does not start until after the SR is written.  As long the ISR code
preserves that register, it is OK.  Consider this sequence:

  + T1 -- read SR
    + ISR -
    + ISR - switch to T2
     .....
    + return to T1 via tail of _ISR_Dispatch
  ?? Is the SR maintained
  + T1 twiddles bits in SR
  + T1 saves SR
   --> critical section begins here

So logically it is not necessarily an error if the ISR and ISR
preemption logic completely preserves the SR.

--joel


> Any feedback would be appreciated!
> 
> Best Regards,
> Bruce Robinson
> 
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985