context switch and interrupts

[Gedare Bloom]

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?

-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
>>
>
>