zero latency context switch - The Best Methods !!

The IP3000 from Ubicom can achieve this. One can set up the processor to run up to 8 hardware threads. Each thread can be set up to get an absolute certain percentage of the overall processing power.

Regards Anton Erasmus

I believe what you are referring to here is the Sparc does with function calls. With Sparc you have a large number of general purpose registers - typically over a hundred although it can vary, but only 32 are visible at any given moment in a window that slides up and down as functions are called and return.

The registers are carved up so that the first eight are globals shared among the entire thread. The next eight are shared between the function and its parent, followed by another eight that are private to the function. The final eight are shared between the function and any of its children. The whole arrangement is designed to minimise function call overhead, which can be as low as a single cycle, including the allocation of enough working registers for even reasonably complex functions not to need any space on the stack.

This is actually a pain come a context switch. In this instance all 100+ registers need saving which obviously takes a little time. I believe some Sparc versions actually have fewer registers to speed up context switch times but for general desktop use the larger register is usually a plus, given how much more frequent function calls are than interrupts.

Well, when the registers are changed is matter of compiler concept. What is the difference between a context switch an an interrupt anyway ? At least the option would be there to make it quick.

Rene

While in a pre-emptive kernel, the task switch usually occurs as a result of an interrupt (i.e. a blocked task waiting for a specific interrupt becomes runnable), not all interrupts cause a context switch (e.g. device driver handles individual UART interrupts, but the interrupt might activate the waiting task only after the carriage return is received).

An ordinary (non-context switching) interrupt is not a problem for a Sparc style procedure call register stack architecture, since the interrupt is just an unscheduled function call, which allocates just one more register set below the current local register set.

In a simple pre-emptive kernel, when an interrupt occurs, the registers are saved automatically on the _current_ stack by the hardware. At the end of the interrupt, it is checked if an other higher priority task has become runnable, if not, just perform an ordinary return from interrupt in the current stack.

However, if a task switch is needed, save the current stack pointer to a static storage and the stack pointer from the new task is loaded from an other static location. Since the new task already has the saved registers stored in its stack (as a result of some ancient interrupt+task switch), just performing an ordinary return from interrupt will restore the ancient registers from stack, will complete the task switch.

Trying to implement this with the Sparc style procedure call register stack would be very inefficient, unless of course, you have a procedure call register stack for each potential task, which is not realistic, if the system has hundreds of tasks.

Paul

But that does not garentee that you can switch from one thread to another with zero latency, which BTW, is impossible.

I take "zero" latency in this context to mean as fast as it would have taken to execute the next instruction in the current thread. i.e. if switching from one thread to the next takes just as long as getting to the next instruction, then it is "zero" latency switching.

Regards Anton Erasmus

Karthik

One very specialized solution is in the eTPU engine controller. It is an event driven processor where every event is run to completion. The eTPU is usually configured in pairs with shared execution and RAM space.

The context switch is very fast, the function frame is directly available with no context switch overhead. Two of the processor registers are pre loaded with context switch as well.

Regards

-- Walter Banks Byte Craft Limited Tel. (519) 888-6911

Perhaps your idea of 'zero' is different to mine.