home .. forth .. misc mail list archive ..

Re: multi/tasking/processing


On Wed, 16 Aug 1995, Eugen Leitl wrote:

> I was not proposing multiple register files or stacks, only two
> sets, not even symmetrical (OS stack being much more shallow).
> If these two banks are on chip, they need not to be swapped out
> to main store. 

If there are two banks and three tasks, they need to.

[ ... ]

> But still I am of the oppinion that having zero-latency context
> switch between two tasks (possibly, protecting the address space
> of one task) is valuable. A lot of program code is OS call code.

How would you define an "OS"?

> The OS is a very special task, requiring dedicated resources.

It is not special at all in general. It is very special in particular in 
the U*X world.

> The OS can be implemented as a VM with zero context switch.
> The OS supervisor task gets called very often particularly in
> realtime machines. 

If the "OS supervisor task" works 100ns worth at 1ms intervals, would you 
dedicate half the chip resources to make it work 50ns at 1ms intervals?

> tens to hundreds of separate monotask nodes on single chip, a reentrant 
> multitasking OS with memory protection is a must. 

Reentrancy we need. But why do we need memory protection? A program, that 
needs memory protection is a buggy program. I'd rather have a simple 
system, that I understand in full and am amble to debug, than a MMU ten 
times the size of the processor, that adds complexity without helping me 
kill bugs.

> What if the task is much too small, shall we waste the
> rest of local node memory resources?

The solution is to make the nodes respectively smaller (and cheaper, and
more). But we are not there with the technology yet :-( We need better
dynamical allocation schemes of on-chip resources. Not very likely with
the silicon (semiconductor) technology. 

But while we are at the silicon level now, we need to experiment with
concepts and identify our needs better. As we write finer and
finer-grained masspar apps, we will learn what (hardware/software/wetware)
we need to solve bigger problems in adequate time (and budget). 

--
Penio Penev <Penev@venezia.Rockefeller.edu> 1-212-327-7423