Saturday, January 7, 2012

Developing a multitasking OS for ARM part 3 1/2

Okay, so last time we looked at what we need to schedule and store top level information about tasks in our fledgling OS. And it was pretty easy to do, because we could do all of it in C. Unfortunately, things are about to get complicated again, because we're about to dive down into assembler again.

Whoopee! I can almost hear the sound of "back" buttons being clicked as I type this.

So. Multitasking. How's that gonna work, then? Largely speaking, there's 2 types of multitasking - preemptive multitasking, where tasks run for a specified amount of time then get forcibly swapped out, and cooperative multitasking, where tasks run until they decide to give some time to someone else. We're going to implement (because there's precious little overhead in doing so) a hybrid where tasks can be "nice" and give time to others, but where the absolute maximum time they get is capped by a preemptive scheduler.

So. Let's look at the sequence of events for a user-triggered task swap. We want the user to use a line of code that looks like this (remember, I'm developing something that runs scheme...)

(task-swap-out)

However, the user's code is running in user mode (remember the ARM processor states), and it can't directly access the task scheduler. This is where software interrupts / SVC calls come in - the user's code *can* use the svc instruction. This, in fact, is the beginning of what is known as a syscall interface, the way that unprivileged user code calls (or causes to happen) kernel functions.

Executing the svc instruction causes the following to happen:

CPSR_usr is transferred to SPSR_svc

PC is stored in LR_svc

Processor switches to SVC mode (SP_usr and LR_usr are now hidden by SP_svc and LR_svc, CPSR is identical except for processor state change)

PC is loaded with the address of the SVC exception handler

At this point, what we need to do is store R0-R12, LR_usr and PC (before entry to svc handler) into the user stack, in a known order, then save the user stack pointer to the task's "housekeeping" information, load the equivalents back in for the next task, and jump out of the handler back to user code. We'll get onto that in a minute.

Preemptive task swapping will be done by using a timer interrupt. Thus, for a preemptive task swap, the situation is quasi-identical, with _svc above replaced by _irq. The only difference is that the PC stored to LR_svc is actually 4 bytes on from where we want to restart, so we need to remember to take that into account.

So. How do we go about saving our information to the user stack? This is made quite easy by the fact the user mode register are identical to the system mode registers. So we need to save the svc/irq mode stuff (LR, SPSR) into the system mode stack, then swap into system mode and save the rest. The first bit is covered by one instruction, which might have been made for the task:

srs (Store Return State) - store LR and SPSR of the current mode onto the stack of a specified mode

Note that the only difference is that the irq handler adjusts the return address (as we want to go back to the interrupted instruction, not the next one).

Given that we are now *always* in system mode, exiting from either handler is identical:

pop{r0, lr}/* restore LR_user and readjust stack */

addsp, sp, r0

pop{r0-r12}/* and other registers */

rfeiasp!/* before returning */

I'll move onto how to implement the guts of the two handlers in the next post. But before we go, here's how we set up a task in "C" land.

Remember, when we switch into a task, we will be pulling a stored process state from the task's stack into the registers, and then restoring the PC and CPSR, also from the task's stack. Setting up a task, then, involves "faking" the preamble of the exception handlers above. Note the use of exit_fn as the value of LR_usr, this is where we go when a task dies, and is used to clean up after task exit, and the use of 'entry' (the address of the task's entry function) as the value of LR_svc/irq, which will be used as the "return" address from the exception handler.

The use of exit_fn means we can schedule "one-shot" tasks (which not all realtime OSs can do). Hooray for us.