SPARC interrupt masking was Re: context switch and interrupts

[Joel Sherrill]

On 01/06/2010 10:28 AM, Gedare Bloom wrote:
> Joel,
>
> Thank you, I think I see where and why I got confused.  I have been
> using the SPARC cpukit as the basis for my port, and it appears to
> always enable interrupts during the restore phase of the context
> switch.  I avoided that choice in my implementation, and now need to
> figure out what is the best thing to do.
>
> I guess the original SPARC port solely relies on the interrupt level
> for masking out interrupts -- the sparc processor has both an
> interrupt enable/disable bit, and a processor interrupt level. Would
> it be better to turn on the interrupt bit in _CPU_Context_Initialize
> while setting the processor interrupt level, or to emulate the SPARC
> port and always enable interrupts and let the interrupt level
> determine whether the processor actually takes one?
>    
I have a simple rule on the SPARC.  Jiri knows best. :-D

There are some subtle issues on the SPARC related to this
topic.  Jiri.. could you help out here?

My gut feeling is to follow the original SPARC32 code.

Thanks.

--joel
> -Gedare
>
> On Mon, Jan 4, 2010 at 7:32 PM, Joel Sherrill<joel.sherrill at oarcorp.com>  wrote:
>    
>> On 01/04/2010 04:41 PM, Gedare Bloom wrote:
>>      
>>> Hi,
>>>
>>> I'm working on a port of RTEMS to the Sparc 64 (with Eugen) using the
>>> existing SPARC port as a basis. Our port is "working", but I have
>>> found that when any RTEMS application begins to run, interrupts are
>>> disabled. After some initial debugging, it appears that interrupts are
>>> turned off explicitly by boot_card and do not appear to be explicitly
>>> turned on.
>>>
>>>
>>>        
>> That is correct.  The interrupt enable/disable/level state
>> is part of the per thread context.  Interrupts should be
>> enabled when you restore the context of the first task
>> since tasks normally run with interrupts enabled.
>>      
>>> Looking at the BSP guide, I noticed this in section 7.3.2 about
>>> boot_card: "RTEMS will context switch to the first application task.
>>> As a side-effect of this context switch, processor interrupts will be
>>> enabled."
>>>
>>> Does this mean that _CPU_Context_switch in cpu_asm.S should always
>>> turn interrupts on, regardless of the processor's state?
>>>
>>>
>>>        
>> No.
>>      
>>> Or is it just that the first context pointed to by Context_Control
>>> *heir on the first context switch has the appropriate processor state
>>> for interrupts to be enabled?  If so, where is that context
>>> initialized so that I can make sure it is correct? The obvious
>>> candidate seems to be _CPU_Context_Initialize, but it only seems to
>>> set an interrupt masking level, not actually change whether interrupts
>>> are enabled or disabled.
>>>
>>>
>>>        
>> Every context switch includes the "processor status register"
>> or whatever it is called.  So interrupt state is switched every
>> task switch.
>>
>> It may not be the architecture you are most familiar with but
>> the m68k is IMO probably the easiest to understand.  There are
>>
>> + a0-a7 (address registers)
>>    - a6 - frame pointer
>>    - a7 - stack pointer
>> + d0-d7 (data registers)
>> + sr - (status register)
>>
>> Three bits in the sr determine the interrupt level and the
>> entire sr is considered part of the per thread context.
>>
>> Also a0/a1/d0/d1 are assumed NOT to be preserved across
>> subroutine calls so are not saved in _CPU_Context_switch
>> but as part of the interrupt context.
>>
>> I hope this helps.  Ask questions.  This is tricky.
>>
>> --joel
>>      
>>> Thanks,
>>> Gedare
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>>>        
>>
>>      


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