Neil Cherry wrote:

> It's already here for the desktop and server. But for embedded use is it
> here? I think we'll be seeing more of this but we'll really have to
> change out ways of doing things. Or maybe the embedded world would be
> better off with multi-processor system ...

I think there are already many multi-processor systems in the field. A
mid-sized production line probably has dozens or hundreds of processors
working together. Even here people routinely inquire about how to make two
PICs talk to each other. 

> ... used to work really well for the Gimix Ghost running OS9. It was a
> 6809 running at 4Mhz, it had an processor for the disk, the serial ports
> the parallel port and other things. 

I don't know how many processors are in a typical PC these days, but I'm
sure it's more than one. (Depends a bit on what you call a "processor",
too.)

I think there are at least three rather different aspects to this. One is
the classical multi-process/threading/multi-tasking issue, with semaphores,
queues etc. Another is parallel data-crunching, like with DSPs or for
encryption, often with specialized hardware. Both are pretty mainstream in
the embedded area.

And a third, and that's what seems to be getting into mainstream just now
(but not in embedded), is finding ways to make applications that were not
written for multi-processors run most efficiently on a multi-processor
system. This is something the OS writers are working on, not so much the
application programmers. They of course have to know how to use the OS
features efficiently to make their apps run optimally. But I don't think
that this will become a major issue in the embedded area, because here it's
not about running arbitrary apps on a newer, better system -- the apps
usually are written or adapted specifically to the hardware.

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist