| ??? 08/07/08 20:58 Read: times |
#157304 - I agree, too Responding to: ???'s previous message |
Per said:
But when you talk about C51 code, the problem with cooperative multitasking isn't just that each task needs to have it's own stack.
The traditional use of shared global variables for parameter passing and local variables based on call tree analysis will also be affected. In a cooperative system, each task may have multiple calls to inform that a task switch is possible. And these calls need not be located in the outermost function, but may for example be placed in delay() calls etc. This produces a very complex call tree - the problem is similar to a program that makes heavy use of function pointers. You're right, of course, if there's a C compiler involved. In fact, I think the problem is actually worse than you describe. I would guess that in some cases, the generated call tree would be not just complex, but possibly just plain wrong because the compiler would not be aware of the "calls" that the scheduler was effectively making at run time. But this problem isn't so much a problem with the 8051 architecture itself as it is with the way that C has been implemented on it. That's not an indictment of the C compilers by any means. When you think about it, due to its limited stack, the 8051 isn't really a very good architecture for running C programs in the first place! But we do it anyway, I guess because the advance of technology is a largely evolutionary process where some of the less viable variations take a while--and sometimes a long while--to become extinct. I happen to have a lovely multitasker, written in C, for the 8051. But it's nasty in a couple of respects directly related to what we're talking about here. One is that it is highly compiler dependent in a couple of places. The other is that it won't work if the compiler is allowed to allocate local variables based on the call tree as it normally would. This discussion has made me think about the difficulty and also the usefulness of implementing something similar in assembly language, for use in applications also written in assembly language. On the one hand, such an exercise would avoid the C-related problems we've mentioned. But on the other hand, it seems that applications large and complex enough to need a multitasker might also be large and complex enough that you wouldn't want to do them in assembly language in the first place. Something to think about, anyway. -- Russ |
