CS452 - Real-Time Programming - Spring 2012

Lecture 8 - Create, Initialization

Pubilc Service Annoucements

1. Due date for assignment 1
2. Victoria Day holiday

Initializing the Kernel

Set up the Hardware

1. busy-wait io
2. low memory
   • Where is the kernel entry?
3. Turn off interrupts in the ICU
   • This should be unnecessary, but what if the previous kernel turned them on?
   • Later you will initialize the ICU differently.

Prepare the Kernel Data Structures

Where is the kernel's stack pointer, right now? What does the stack look like?

• Do you want it there? Would you rather have it somewhere else?
• This is your last chance to change it. (If you decide to change it you might want to keep what you are replacing around. Why?)

The kernel data structures

1. an array of empty ready queues
2. a poimter to the TD of the active task
3. an array of TDs
4. a free list of pointers to free TDs

Prepare the Memory to be Used by Tasks

1. task memory

Create the First User Task

Can run with interrupts turned off for now (belt and braces) but will need to be turned on later.

Reminder. The place where the kernel starts executing has the global name main, which cannot be re-used.

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

Allocate resources

Get an unused TD and unused memory for its stack

• actually a form of constant time memory allocation

Initialize resources

Mostly filling in fields in the TD. Here are the ones that ought to be in the TD.

1. task id
2. priority
3. stack pointer
4. parent tid
   • the active task
5. state
   • READY
6. install in the ready queues
   • pointers in the TD

This looks like six words, which could be squeezed into fewer. (There will be more later.)

• If you are thinking about the cache, how can you make the array of task descriptors so that they are cache-aligned.

Here are the ones that could be in the TD, or could be on the stack.

1. SPSR
2. link register
3. return value

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

Here's something I always do.

• Put distinctive values into registers to start off with, like 00000000, 11111111, 22222222, etc.
• This makes solving pointer misalignment problems easier

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

Other Primitives

These primitives exist mostly so that we, which includes you, can ensure that task creation and scheduling are working when there is not much else implemented.

Tid MyTid( )

Self-explanatory

• Doesn't block, but does reschedule.

A question, to which there is a correct answer, or more specifically, a correct (answer, reason) pair.

• Should the Tid be stored in user space?

Tid MyParentTid( )

Self-explanatory

• Doesn't block, but does reschedule.

Where is the parent Tid, and how does the kernel find it?

void Pass( )

Doesn't block: task calling Pass( ) remains ready to execute.

Does reschedule.

When is Pass( ) a NOP?

void Exit( )

Calling task is removed from all queues, but its resources are not reclaimed or reused.

That is, the task goes into a zombie state, in which it cannot be active or ready, but continues to own all its resources.

How Should Execution Terminate?

Nicely.

When there are no tasks left on the ready queues, it goes back to RedBoot.

• This behaviour changes when hardware interrupts are implemented.

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