sergio masci wrote:

>> sergio masci wrote:
>> 
>>> Having a language and compiler that would generate efficient
>>> multitasking code on both a 628 and Windows XP in a multicore
>>> processor would be a feat. But the hardest part (that of getting it
>>> to work on a 628) is done! Surely you can see that doing the same
>>> for a system with MUCH better resources is trivial in comparison. 
>> 
>> No, I can't see that. Portable, safe and efficient multitasking on a
>> modern multicore system is in no way trivial. It is IMO more complex
>> than multitasking on a 628, by a few magnitudes.
> 
> No Gerhard the fundamental principle is still indentical - you switch
> task contexts. Wheather this means that you need to completely save
> one CPU context and load another OR you arrange for the the task
> contexts to co-exist and simply switch between them is upto the
> implementor. 

This is in the context of the compiler implementing multitasking.
Multitasking is not only about starting threads and maintaining their
state, it's also about synchronization between threads, and do so
efficiently. And many aspects of this depend on the exact situation.

One difference between the 628 and Windows XP or Linux is that the
compiler in the first case does part of what the OS it the other case
does, so the implementations are different. The other is that I have a
somewhat more sophisticated expectation of how multitasking works on a
Windows or Linux PC when compared to a 628.

Also, on a single-core system, an entity that can be manipulated
atomically can be used to synchronize between threads. We do this all
the time on PICs with bits and bytes. It doesn't work this simple way on
a multi-core system; you need additional provisions to synchronize the
corresponding processor cache lines.

Then there's the performance issue. On a single-core system, normal
locks for accessing containers and making sure they are always in a
consistent state are good enough; as long as the code is inside the
container, it's doing useful work, so serializing even read accesses
isn't going to cost me much if anything. However, on a multi-core
system, reader/writer locks may make a lot of sense and speed things up
quite dramatically, as now several readers can read literally /at the
same time/ the container, and the lock is only used to make sure a
writer is always alone in the container.

So there are quite substantial differences in multitasking between a
small bare-metal system and a bigger system with a complete OS on one
hand, and between single-core systems and multi-core systems on the
other hand. If a compiler is to implement multitasking, it needs to take
all this into account. 

I don't know whether it would make sense to use the same functionality
for multitasking keyboard input, display output and measurement on a 628
and for a web server on Linux, but I suspect it wouldn't. 

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