Tiny OS Optimistic Lightweight Interrupt Handler

1
Tiny OS Optimistic Lightweight Interrupt Handler

• Simon Yau (smyau_at_cs), Alan Shieh
  (ashieh_at_hkn.eecs). CS252, CS262A, Fall 200

The Problem
The Proposals

• Tiny OS is an event-based Operating System
  environment for wireless network of deeply
  embedded systems.
• Runs on low-power autonomous sensor nodes. -gt
  Real need to cut power consumption.
• Context switch is the most expensive software
  primitive in Tiny OS -gtReflected in the fact that
  most of the active execution cycles (gt66) are
  spent in RFM (lowest level component) during the
  reception of a packet.
• Want to reduce the number of active cycles
  reduce the RFM components work make interrupts
  more effective.

Optimistic (Lazy) Interrupt Handler

• Most of the time when an interrupt happens, the
  processor is in sleep mode (I.e., no thread is
  running at that time.)
• If no thread is running when an interrupt
  happens, there is no need to save registers.
• Solution set aside a register, set it when the
  processor enters sleep mode. In the beginning of
  interrupts, check the flag and skip the saving
  and restoring of registers if the flag is set.

//pseudo code Void __interrupt__ ()(naked)
if (wasSleeping) wasSleeping FALSE
naked_interrupt() else
clothed_interrupt() Void
naked_interrupt()(naked) // does work...
asm (reti) Void clothed_interrupt()(signal)
naked_interrupt()
Software simulated register window

• TinyOS and application software typically uses
  about half of the available registers
• Some registers can be reserved for interrupt
  handling
• AVR has an asymmetric register set with some
  registers that are more general than others. Each
  resource pool must be partitioned separately to
  generate good code
• Two variants of AVR compiler, each with own
  modified gcc backend to disallow use of certain
  registers
• Registers used by other mode are marked as
  unspillable, fixed-use registers
• Each mode has separate calling convention and
  low-level libraries
• Post-compilation filter on interrupt-mode
  compiler
• Interrupt handlers and their callee functions are
  extracted and renamed, then combined with output
  of user-mode compiler
• Still a work in progress (compiled with user
  version gcc and interrupt version gcc, but
  linking is too slow).

• Shared registers
• Stack, Frame, indirect-PC address registers

• User registers
• R8-R15 cannot be used with immediate operands

The Evaluation
Network simulator

• Interrupt registers
• R2-R7 cannot be used for immediate operands

CPU simulator

• Used an existing AVR 8535 simulator.
• Added simulated radio transceiver, LED, photo
  sensors to the simulator to make a simulated
  mote.
• Take the following parameters during the
  reception of one packet (97 bits at 6Kbps, about
  12.5us)
• Number of cycles in sleep mode
• Energy consumed.
• Number of cycles in which interrupts are
  disabled.
• Number of interrupts lost

• Network simulation model
• All motes simulated in lock-step
• At each mote, the radio states of each in-range
  mote is compared to detect reception and
  collisions
• Network state is propagated back into the mote
  simulators
• Measure the number of interrupts that are lost.
• Still work in progress.

Lightweight Interrupt Handler

• With register window, the number of register
  available decreases -gt increased pressure on
  register spills.
• Need interrupt handlers that uses less register.
• Can achieve this by delaying the handling of
  interrupts by posting a thread that fires off the
  event instead of firing it.
• However, there is a catch
• Thread scheduler turned out to be the most
  register-intensive operation, therefore it must
  be re-written in assembly code before the
  lightweight interrupt handler is feasible.
• It actually increases the handling time of events
  by adding thread posting/scheduling overhead and
  waste energy.
• It would also help in cases where the interrupt
  handler wants to use some restricted registers
  which are not accessible to interrupt code.
  (e.g., reserved registers used for
  multiplications)

Conclusions Future work

• We must be very careful when designing the
  interrupt handler. For example, making the
  interrupt handler lightweight actually
  increases the workload of the CPU to a point
  where it will be too busy to take interrupts.
• Investigate the impact of other fast
  context-switch mechanisms (e.g., shadow
  registers) using the simulation environment
• Fully explore the design space of interrupt
  handlers.

Timer_interrupt_thread
Interrupt handler
Interrupt handler
Timing Diagram of Event Propagation
Timing Diagram of Lightweight Event Propagation