CS452 - Real-Time Programming - Fall 2011

Lecture 6 - ARM Architecture

Pubilc Service Annoucements

Context Switch

Kernel Structure

The kernel is just a function called main( ), which runs forever. It looks like this

main( ) {
  initialize( );  // includes starting the first user task
  FOREVER {
    active = schedule( )
    request = activate( active );
    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 activate( active ).

schedule( ) returns the ready task of the highest priority or nil.

• Task states: Ready, Active, Zombie
• Three possible state transitions

  Initial state	Final state	Trigger
  Ready	Active	schedule( )
  Active	Ready	Pass( )
  Active	Zombie	Exit( )

All the interesting stuff inside done by the kernel is hidden 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

Context Switch

The context switch is an examnple of the NOP design pattern, which is extremely widespread in actual code. A common, and relevant, example occurs when we call a function

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}
                         ; fp stands in for all registers except scratch, 
                         ; determined by the registers the function uses
   ...
   ldmia   sp, {..., fp, sp, pc}
                         ; exact inverse of bl, mov and stmdb

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

Software Interrupt

The above code sets up function execution within the context of the calling task. When we want to run code that is in a different context we use the software interrupt instruction

• swi{cond} <immed_24>

What happens when it's 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
   ; the kernel entry point must be in 0x028
   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?
; Retrieve kernel state from kernel stack
; Do kernel work

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 isn't important. Why not?
6. This is not the only way to do a context switch. But remember that every correct implementation of a content switch contains either a software interrupt (swi ) or a hardware interrupt.

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, which uses the NOP design pattern repeatedly to create a context switch step-by-step, with every step testable.

After the Software Interrupt

In the kernel

The order matters

kernel entry:

1. State on entry
   • supervisor mode
   • interrupts off
   • spsr = cpsr_usr
   • arguments in r0-r3
   • caller context in registers r4-r12
   • caller local variables indexed off fp
   • kernel stack pointer in r13
   • address of instruction following swi in r14, i.e., lr_srv = return address
   • 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 in the TD when you're finished

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 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. Save kernel state on kernel stack
2. From TD
   • set spsr_svc = cpsr_usr
   • set lr_svc = pc for execuation in user mode
   • get sp_usr
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.

Making the Stub that Wraps swi

For each kernel primitive there must be a function available in usr code: the kernel's API.

• e.g. int Create( int priority, void ( *code ) ( ) );

What gcc does for you

Before calling Create

1. gcc saves the scratch registers to memory.
2. gcc puts the arguments into the scratch registers, and possibly on the stack.

While calling Create

1. bl to the entry point of Create

While executing Create

1. gcc saves the registers that it thinks will be altered during execution of the function.
   • gcc thinks wrong, because only the assembler knows that swi is in the instruction stream
2. your code gets executed
3. gcc restores the registers it saved, and only those registers.

Exiting from Create

1. mov pc, lr, or equivalent, is executed, returning the execution to the instruction following bl

After calling Create

1. gcc stores register r0, the return value, in the variable, to which the result of Create is assigned.

What the code you write does

1. Moves the arguments from gcc's locations to whatever convention you choose for your kernel
2. Does swi n, where n is the code for Create.
3. Moves the return value from your kernel's conventional location to r0.

Creating a Task

In creating a task you have to do two things

1. Get and initialize resources needed by the task
   • TD
   • memory
2. Make the task look as if it had just entered the kernel
   • it's ready to execute when it's scheduled

Things you need to do

Get an unused TD and memory for its stack

• memory could be associated with TD during initialization
• actually a form of constant time memory allocation
• unless you implement Destroy

Mostly filling in fields in the TD.

1. task id
2. stack pointer
3. SPSR
4. link register
5. parent tid
   • the active task
6. return value
   • dummy
   • different return value for the active task, which goes in its TD
7. state
   • READY
8. install in the ready queues
   • pointers in the TD

Must also initialize the stack

• exactly as if the task had just done a kernel entry
• look carefully at what your kernel exit code will do
• At the end stack pointer must correspond to stack contents
• I initialize the stack pointer to the top of allocated memory
  • my stacks grow down

  then change it as I push stuff onto the stack

  • imitating the context switch code

The Create Function

You also need a int Create( int priority, void (*code) ( ) ) function to call from user tasks.

Although it's no more than a wrapper there are a few problems to solve.

1. Passing arguments
   • On entry the arguments are somewhere, usually r0 & r1
   • You have to put them where the kernel can find them.
   • gcc's function extry code immediately puts them on the stack.
   • In assembly you can find them using the frame pointer.
2. Jumping into the kernel
3. Getting the return value from the kernel and returning it.
   • You find it where the kernel put it
   • gcc's function exit code expects it to be indexed off the frame pointer
     • from where it does into r0

What follows just seems to say the same thing again. But we might as well leave it here because some student might find it useful.

How do we implement the API for user code?

1. This requires a bit of assembly language.
2. In assembly language all arguments & return values are words.
   • usually pointers
   • stored in registers
   • What happens when there are too many arguments?
3. What happens when Create is called?
   • Two arguments
     • stored in r0 and r1
     • which is which?
   • Immediately placed on the stack, referred to by fp
   • Create puts them in the special place you choose
     • r0, r1 ?
   • swi switches context into the kernel.

What happens when Create returns?

• When the kernel is finished manipulating TDs and PQs
  • it knows the tid to be returned
  • it places the tid in the caller's return value in its TD

When the caller is next activated,

• as part of activation the return value is put in your special place, usually r0

user code has to get it and put it in the compiler's special place, r0 for gcc.

Return to:

• Bill Cowan's Fall 2011 CS452 page
• Bill Cowan's CS452 page
• Bill Cowan's teaching page
• Bill Cowan's home page