CS452 - Real-Time Programming - Spring 2012

Lecture 6 - Context Switch

Pubilc Service Annoucements

  1. Due date for assignment 1
  2. Partners

Kernel Structure

The kernel is just a function like any other, but which runs forever.

kernel( ) {
  initialize( );  // includes starting the first user task
    request = getNextRequest( );
    handle( request );

Where is the OS?

All the interesting stuff inside done by the kernel is hidden inside getNextRequest.

int getNextRequest( ) {
  active = schedule( ... );
  return activate( active );

What's inside activate( active )?

  1. transfer of control to the active task
  2. execution to completion of the active task
  3. transfer of control back to the kernel
  4. getting the request

The hard part to get right is `transfer of control'

ARM 920T


  1. 16 32-bit registers
  2. Processor modes. In the table below `special' means that the mode has ia separate copy of the registers.
    M[4:0] Mode Registers accessible
    10000 User r0-r15
    10001 FIQ (Fast interrupt processing) r0-r7, r15

    cpsr, spsr_fiq

    10010 IRQ (Interrupt processing) r0-r12, r15

    cpsr, spsr_irq

    10011 Supervisor r0-r12, r15

    cpsr, sprs_svc

    10111 Abort r0-r12, r15

    cpsr, spsr_abt

    11011 Undefined r0-r12, r15

    cpsr, spsr_und

    11111 System r0-r15


  3. Program status register, PSR, which you will find in two places CPSR and SPSR
    Bit Mnemonic Meaning
    31 N Negative
    30 Z Zero
    29 C Carry
    28 V Overflow
    8-27 DNM Does not matter in v4
    7 I Interrupts disabled
    6 F Fast interrupts disabled
    5 T Thumb execution
    4 M4 Five processor mode bits
    3 M3
    2 M2
    1 M1
    0 M0

  4. Exceptions



    Called from

    Mode at




    Reset hardware supervisor 0x00
    Undefined instruction any undefined 0x04
    Software interrupt any supervisor 0x08
    Prefetch abort any abort 0x0c
    Data abort any abort 0x10
    Ordinary interrupt any IRQ 0x18
    Fast interrupt any FIQ 0x1c

    1. You are concerned right now with Reset and Software Interrupt.
    2. The first instruction executed by the CPU after reset is the one at location 0x00000000. Usually it is
          ldr  pc, [pc, #0x18] ; 0xe590f018 is the binary encoding

      which you will normally find in addresses 0x00 to 0x1c. Just executing an instruction, rather than having an address that is specially processed saves transistors, which is good.
      The indirect jump allows the CPU to jump anywhere in the address space.

    3. RedBoot puts entry points of RedBoot into addresses 0x20 to 0x3c.
    4. Note endianness of RedBoot output when examining these locations.
  5. Three data types

Context Switch

Function Call (gcc calling conventions)

; In calling code
                      ; store values of r0-r3
                      ; load arguments into r0-r3
   bl  <entry point>  ; this treats the pc and lr specially
                      ; lr <- pc, pc <- <entry point>
                      ; r0 has the return value
                      ; r1-r3 have useless junk

; In called code
entry point:
   mov     ip, sp
   stmdb   sp!, {fp, ip, lr} ; and usually others, 
                             ; determined by the registers the function uses
   ldmia   sp, {fp, sp, pc} ; and whatever others
                            ; exact inverse of stmdb

Note the role of the index pointer (ip), link register (lr) and stack pointer (sp).

The final instruction could be

   ldmia   sp, {fp, sp, lr}
   mov     pc, lr

The sequence

   bl   junk
   mov   pc, lr

is a NOP.

Software Interrupt

The software interrupt instruction ( SWI{cond} <immed_24> ). What happens when it is executed?

  1. r14_svc <- address of the following instruction. This is where the kernel will return to.
  2. SPSR_svc <- CPSR. This saves the mode, condition codes, etc.
  3. CPSR[0:4] <- 0b10011. Supervisor mode.
  4. CPSR[5] <- 0. ARM (not Thumb) state.
  5. CPSR[7] <- 1. Normal interrupts disabled.
  6. PC <- 0x08

The CPU ignores the 24-bit immediate value, which can be used by the programmer as an argument identifying the system call, for example.

; In calling code
                          ; Store r0-r3
                          ; Put arguments into r0-r3
                          ; 0x08 holds the kernel entry point
   swi  n                 ; n identifies which system call you are calling
                          ; retrieve return value from r0
                          ; r1-r3 have even more useless junk

; In kernel
kernel entry:
; Change to system mode
; Save user state on user stack
; Return to supervisor mode
   ldr    r4, [lr, #-4]    ; gets the request type
; At this point you can get the arguments
; Where are they? Why couldn't you retrieve them earlier?
; Retrieve kernel state from kernel stack
; Do kernel work

The sequence

   swi   n
kernel entry:
   movs   pc, lr

is a NOP.

This NOP depends on a bunch of things being correctly set up, especially the low memory.

For Later in the course

Responding to SWI treats the scratch registers in a special way.

In the third part of the kernel you will implement hardware interrupts.

It seems desirable to have as much code as possible common to hardware and software interrupts.


  1. What is above kernel entry?
  2. If you put swi in a wrapper or stub what happens before and after it?
  3. If the request had arguments, how would you get them into the kernel?

    Hint. How does gcc pass arguments into a function?

  4. It might be important that there are two link registers. Which two link registers? Why?
  5. In practice it is important only for hardware interrupts. Why?


  1. Try this first on paper drawing the stack, registers, etc after each instruction
  2. Try coding in baby steps, which is usually a good idea in assembly language.

Try reading this.

After the Software Interrupt

In the kernel

The order matters

kernel entry:
  1. State on entry
  2. Change to system state
  3. Save the user state
  4. Return to supervisor mode
  5. Get the request into a scratch register
    ldr r3, [lr, #-4]
  6. Retrieve the kernel state, which should not include the scratch registers
  7. Put what you need to in the active task's TD
  8. Some where above you must have picked up the arguments
  9. Return from getNextRequest( active ) and get to work

There is more than one way to do almost everything in this list, and I have chosen this way of describing what is to be done because it's simplest to describe, not because it's necessarily best!.

Before the Software Interrupt

After a while it's time to leave the kernel

  1. Schedule the next task to run
  2. Call GetNextRequest( active )

Inside GetNextRequest

  1. From TD, or the user stack
  2. Save kernel state on kernel stack
  3. Set return value by overwriting r0 on user stack
  4. Switch to system mode
  5. Load registers from user stack
  6. Return to supervisor mode
  7. Let it go
    movs   pc, lr

The instruction after this one is normally the kernel entry.

Return to: