[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Interrupt control



  I'm having a bit of trouble understanding the way the
rtems_interrupt_disable macro works.  This is in the M68K
world, so perhaps what I'm questioning doesn't apply to
other CPU's.

  In the RTEMS C User's Guide, the notes say this directive
"modifies the level parameter".  According to the disassembler,
it looks like this:

00005c28 <rtems_interrupt_disable>:
    5c28:       40c0            movew %sr,%d0
    5c2a:       007c 0700       oriw #1792,%sr
    5c2e:       4e75            rts

  Well that certainly doesn't do anything to affect memory,
although you could get a snapshot of the entire status register
(SR) from the returned value.  The way this directive is used,
however, the returned value in %d0 isn't used, at least not in
the eight or ten source files I checked.

  What concerns me more is the way rtems_interrupt_enable
is invoked, typically a few source lines after
rtems_interrupt_disable.  An example, taken from
"rtems-4.0.0/c/src/lib/libbsp/unix/posix/clock/clock.c":

      rtems_interrupt_disable( isrlevel );
       (void) set_vector( args->buffer, Clock_driver_vector, 1 );
      rtems_interrupt_enable( isrlevel );

  Looking at the output from disassembler again:

00005c32 <rtems_interrupt_enable>:
    5c32:       202f 0004       movel %sp@(4),%d0
    5c36:       46c0            movew %d0,%sr
    5c38:       4e75            rts

  There's two things here that just don't sit right with me.  First,
isrlevel is never assigned by the calling function.  Since .bss is
zeroed at run time, its value is predictable, but I'm old and stodgy
enough to be nervous when I see this kind of code.  The other concern
is that the movew instruction at 0x5c36 above clears the entire
status register, which puts the CPU in user mode.  This results in
the use of a different stack pointer and privilege level, neither of
which is obvious nor necessarily desired.

  Is this not really a problem for some reason which escapes me?
Is the M68K implementation of rtems_interrupt_disable not truly
correct, but not wrong enough to cause problems?  I'm having
trouble getting an interrupt source working on my boards, and
my debugging efforts have pointed me to this, but I see other
interrupt-driven tasks working, so it can't be totally broken.

  I'm confused.

				-- Mike Collins --