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
  FOREVER {
    request = getNextRequest( );
    handle( request );
  }
}

Where is the OS?

• requests come from running user tasks
  • in essence system calls
• one type of request creates a task
  • There needs to be a first task that gets everything going

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
   • `to completion' means until the active task sends a request to the kernel
3. transfer of control back to the kernel
4. getting the request

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

• which we call a context switch
• Programming a context switch requires you to know the processor architecture

ARM 920T

Features

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 cpsr
   10001	FIQ (Fast interrupt processing)	r0-r7, r15 r8_fiq-r14_fiq cpsr, spsr_fiq
   10010	IRQ (Interrupt processing)	r0-r12, r15 r13_irq,r14_irq cpsr, spsr_irq
   10011	Supervisor	r0-r12, r15 r13_svc,r14_svc cpsr, sprs_svc
   10111	Abort	r0-r12, r15 r13_abt,r14_abt cpsr, spsr_abt
   11011	Undefined	r0-r12, r15 r13_und,r14_und cpsr, spsr_und
   11111	System	r0-r15 cpsr

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

   Exception Type	Modes Called from	Mode at Completion	Instruction Address
   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
   • word: 32 bits, word-aligned
   • half-word: 16 bits, half-word-aligned
   • byte: 8 bits

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

• The calling code does not expect them to be preserved.
• They are likely to contain arguments on entry, and the return value on exit.

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

• You will go to IRQ mode, not SVC mode
• You have to restore the scratch registers exactly as you restore all the other registers.

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

Questions:

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?

Suggestions:

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
   • supervisor mode
   • interrupts off
   • spsr_svc = cpsr_usr
   • arguments in r0-r3
   • caller context in registers r4-r12
   • caller local variables indexed off fp
   • kernel stack pointer (sp_svc) in r13
   • address of instruction following swi in r14, i.e., lr_svc = return address = pc_usr
   • kernel entry in r15
2. Change to system state
3. Save the user state
   • on its stack
   • This might include scratch registers (arguments), which you may or may not need later.
   • Put sp_usr in a scratch register, say r2
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
   • You now have the kernel frame pointer
   • You can use it to put stuff in kernel memory
7. Put what you need to in the active task's TD
   • active is indexed off the kernel's frame pointer
   • active is a pointer to the TD of the requester
8. Some where above you must have picked up the arguments
   • must be done after 5. Why?
   • must be done before 9. Why?
9. Return from getNextRequest( active ) and get to work
   • Don't forget to store the return value when you're finished handling the request and before scheduling.

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
   • i.e. get the value of active
2. Call GetNextRequest( active )

Inside GetNextRequest

1. From TD, or the user stack
   • get sp_usr
   • set spsr_svc = cpsr_usr
     • You should understand how this takes us back to user mode.
   • set lr_svc = pc for return to user mode
2. Save kernel state on kernel stack
   • Combined with 6, above this should be a NOP
3. Set return value by overwriting r0 on user stack
4. Switch to system mode
5. Load registers from user stack
   • Combined wi 3 above this should be a NOP
6. Return to supervisor mode
7. Let it go

   movs   pc, lr

The instruction after this one is normally the kernel entry.

Return to:

• Bill Cowan's lecture notes for CS452 in s12
• Bill Cowan's Spring 2012 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page