Is there any Guru who knows why interrupts are disabled in IS R?

[Phil Torre]

On Fri, Mar 08, 2002 at 12:27:39PM -0600, Joel Sherrill wrote:
> 
> 
> Leon Pollak wrote:
> > 
> > Hello Gurus,
> >         I shall be very thankful for the explanation of the following
moment:
> >         I look into PPC code file irq_stub.S routine __ISR_handler I see
that
> > all
> > interrupts are disabled almost immediatly. They are reenabled at the end
of
> > the ISR, after the user ISR has finished its processing, almost at the
point
> > of exit from __ISR_handler.
> >         This text contains the comment after the _ISR_NestLevel
incrementing:
> > "From here on out, interrupts can be re-enabled, RTEMS convention says
not".
> >         Can somebody explain me why interrupts must be disabled inside
the
> > user ISR?
> 
> Didn't we answer this a while back?  
> 
> On a CPU family with "good native" interrupt level support RTEMS uses
> that.
> The m68k is an example of that.  RTEMS does not disable interrupts but
> simply leaves them alone and lets higher priority interrupts be dealt
> with by the CPU.
> 
> But the i386 and many PowerPC's have a single interrupt level from 
> the CPU's perspective.  RTEMS does not automatically enable all 
> external interrupts since a PIC would have to be touched and
> generically we don't know about it.  So it is the user's 
> responsibility to deal with that PIC and "reenable" interrupts.

Given that, does anyone have an example of irq_stub.S for MPC860 that *does*
reenable interrupts after nesting?  I'm trying to make mine do that (by
turning
on MSR[EE] right after the comment mentioned above), but this causes my code
to go off in the weeds.  I suspect I'm messing up the switch between task
and
interrupt stacks, but I can't figure out how.

(This is in RTEMS 4.5.0 with old_exception_processing for the 860.  Would a
newer
snapshot with new_exception_processing code fix this?)

-Phil