On May 16, 2:05=EF=BF=BDpm, "Stefan Carter" <scarte...@hotmail.com> wrote:
> >> Which is why ZiLOG opted for a different approach for their Z8
> >> microcontroller - a register pointer,
> >Isn't that the same as TI?
>
> In the Z8/eZ8, all registers are/were accumulators - how did the TI handle=

> this?

The same, All registers were in memory, the "pointer" was the address
of the first of 16 registers. Several had special functions but all
were accumulators.

On Wed, 14 May 2008 21:04:27 +0000 (UTC), Andrew Smallshaw
<a...@sdf.lonestar.org> wrote:

>On 2008-05-14, karthikbalaguru <k...@gmail.com> wrote:
>>
>> What could be the best method to achieve zero latency context switch
>> between
>> two processes ?
>
>Two processors, running each process in parallel.  There's _always_
>some latency when performing a context switch.  The absolute minimum
>would be a single clock cycle but that isn't instantaneous.
>Interrupts aren't instant for this very reason.
>
>So, time to modify the question.  What's the maximum latency that
>would be acceptable?  You can work backwards from that.

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

On 2008-05-16, Rene Tschaggelar <n...@none.net> wrote:
>
> By accepting some limitations, there are solutions.
> As example the Sun Sparc has a huge register set of
> 256 registers, of which 32 each are for one process.
> A context switch is as quick as swapping the base
> pointer, basically one operation. The limitation,
> there are only 8 processes like that. There might
> be other architectures that operate like that.
> I have no idea whether they developped any further.

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.

-- 
Andrew Smallshaw
a...@sdf.lonestar.org

Andrew Smallshaw wrote:

> On 2008-05-16, Rene Tschaggelar <n...@none.net> wrote:
> 
>>By accepting some limitations, there are solutions.
>>As example the Sun Sparc has a huge register set of
>>256 registers, of which 32 each are for one process.
>>A context switch is as quick as swapping the base
>>pointer, basically one operation. The limitation,
>>there are only 8 processes like that. There might
>>be other architectures that operate like that.
>>I have no idea whether they developped any further.
> 
> 
> 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

On Tue, 20 May 2008 00:35:00 +0200, Rene Tschaggelar <n...@none.net>
wrote:

>Andrew Smallshaw wrote:
>
>> On 2008-05-16, Rene Tschaggelar <n...@none.net> wrote:
>> 
>>>By accepting some limitations, there are solutions.
>>>As example the Sun Sparc has a huge register set of
>>>256 registers, of which 32 each are for one process.
>>>A context switch is as quick as swapping the base
>>>pointer, basically one operation. The limitation,
>>>there are only 8 processes like that. There might
>>>be other architectures that operate like that.
>>>I have no idea whether they developped any further.
>> 
>> 
>> 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.

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
   

On Sat, 17 May 2008 11:54:13 +0200, Anton Erasmus
<n...@spam.prevent.net> wrote:

>On Wed, 14 May 2008 21:04:27 +0000 (UTC), Andrew Smallshaw
><a...@sdf.lonestar.org> wrote:
>
>>On 2008-05-14, karthikbalaguru <k...@gmail.com> wrote:
>>>
>>> What could be the best method to achieve zero latency context switch
>>> between
>>> two processes ?
>>
>>Two processors, running each process in parallel.  There's _always_
>>some latency when performing a context switch.  The absolute minimum
>>would be a single clock cycle but that isn't instantaneous.
>>Interrupts aren't instant for this very reason.
>>
>>So, time to modify the question.  What's the maximum latency that
>>would be acceptable?  You can work backwards from that.
>
>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

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

On Thu, 22 May 2008 19:47:36 +1000, The Real Andy
<t...@nospam.com> wrote:

>On Sat, 17 May 2008 11:54:13 +0200, Anton Erasmus
><n...@spam.prevent.net> wrote:
>
>>On Wed, 14 May 2008 21:04:27 +0000 (UTC), Andrew Smallshaw
>><a...@sdf.lonestar.org> wrote:
>>
>>>On 2008-05-14, karthikbalaguru <k...@gmail.com> wrote:
>>>>
>>>> What could be the best method to achieve zero latency context switch
>>>> between
>>>> two processes ?
>>>
>>>Two processors, running each process in parallel.  There's _always_
>>>some latency when performing a context switch.  The absolute minimum
>>>would be a single clock cycle but that isn't instantaneous.
>>>Interrupts aren't instant for this very reason.
>>>
>>>So, time to modify the question.  What's the maximum latency that
>>>would be acceptable?  You can work backwards from that.
>>
>>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
>
>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

karthikbalaguru wrote:

> Hi,
>
> What could be the best method to achieve zero latency context switch
> between two processes ?
>

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
http://www.bytecraft.com
w...@bytecraft.com

On Thu, 22 May 2008 21:29:51 +0200, Anton Erasmus
<n...@spam.prevent.net> wrote:

>On Thu, 22 May 2008 19:47:36 +1000, The Real Andy
><t...@nospam.com> wrote:
>
>>On Sat, 17 May 2008 11:54:13 +0200, Anton Erasmus
>><n...@spam.prevent.net> wrote:
>>
>>>On Wed, 14 May 2008 21:04:27 +0000 (UTC), Andrew Smallshaw
>>><a...@sdf.lonestar.org> wrote:
>>>
>>>>On 2008-05-14, karthikbalaguru <k...@gmail.com> wrote:
>>>>>
>>>>> What could be the best method to achieve zero latency context switch
>>>>> between
>>>>> two processes ?
>>>>
>>>>Two processors, running each process in parallel.  There's _always_
>>>>some latency when performing a context switch.  The absolute minimum
>>>>would be a single clock cycle but that isn't instantaneous.
>>>>Interrupts aren't instant for this very reason.
>>>>
>>>>So, time to modify the question.  What's the maximum latency that
>>>>would be acceptable?  You can work backwards from that.
>>>
>>>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
>>
>>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

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