where is context switching code in the source?

[VINOD S]

I have downloaded the cocoos source archive. But I couldn't find the core part, ie the context switching code. So how the cpu registers are saved while the task is switching from one to another? :roll:

[peter]

There are no context switching code as in a preemptive OS.
cocoOS is a cooperative OS, meaning each task must actively release the CPU to give other tasks a chance to run. Also, in cocoOS all tasks use the same stack, so there are no need to save the stack pointer when switching task.

Switching task is done by placing a call to a scheduling function e.g. task_wait(). This is in fact a macro that expands into a series of statements which ends with a return statement. Before the return, the current line number is stored in the tcb, task control block, so cocoOS knows where to resume execution next time.

[conurus]

I am very intrigued by this idea. cocoOS is doing something nobody else does (non-preemptive, cooperative multitasking using the coroutine concept). I can see how this can be extremely efficient in terms of RAM (no separate stack required) and maybe time too (no need to save context upon context switching). More or less, we are having the C compiler do all the hard work (through the task switching macros).

I suppose however couldn't do something like this:

Code: Select all

task() {
    do_something();
    call_subroutine();
    do_something();
    call_subroutine();
    do_something();
    call_subroutine();
}

call_subroutine() {
    event_wait();
}


My understanding is a separate stack is needed for each task if nested functions are required, even if task switching is cooperative. Not by any means criticizing the limitation because like I said the world needs to explorer this idea which is useful for many applications and required if you don't have much RAM to spare. But there are other cases where traditional RTOS's may be more applicable or easier to use.

[peter]

Hi,
yes, cocoOS is efficient in terms of RAM and time as you wrote. And as you also points out, it has some limitations, but it will be a perfect choice for some applications. My number one priority was to make it simple to use and configure.

Have you tried it out? Please send me feedback!

/Peter

[conurus]

Thanks for your reply, but I have already decided cocoOS is not what I need.

I was trying to do the classical producer-consumer pattern. I could either
1, use an RTOS, which would consume much precious resource, or
2, rewrite one side as a state machine, which would make the code ugly, unreadable and unmaintainable, or
3, use coroutines.

I have to wait within deep-nested function calls, or else the code will have to be restructured and would look just as ugly as if I have chosen option #2. However, an observation can be made that I don't have to restructure both the consumer and the producer. Only one side needs to be turned into a state machine or a coroutine (with a C-macro based implementation, the two are basically the same thing). So long as one side doesn't need to wait within deep-nested function call like my previous example, it could be turned into a coroutine using C macros. So long story short I don't need the whole OS, but only the macros to implement a coroutine.

I think all of the limitations we see are the limitations of the C language itself, but not that of the coroutine concept. Makes me wonder why we always program in C on microcontrollers. There may be other programming languages better suited for the job.

[SamiKapoor]

C was initially created by Dennis Ritchie in the vicinity of 1969 and 1973 at Bell Labs and used to re-actualize the Unix working framework. It has since turned out to be a standout amongst the most broadly utilized programming dialects ever with C compilers from different merchants accessible for the lion's share of existing PC structures and working frameworks. C has been institutionalized by the American National Standards Institute (ANSI) since 1989 (see ANSI C) and consequently by the International Organization for Standardization (ISO).

Notwithstanding its low-level abilities, the dialect was intended to support cross-stage programming. A norms consistent and movably composed C program can be accumulated for a wide assortment of PC stages and working frameworks with few changes to its source code. The dialect has turned out to be accessible on an extensive variety of stages, from implanted microcontrollers to supercomputers. Unix was one of the principal working framework portions actualized in a dialect other than gathering. Prior occasions incorporate the Multics framework which was composed in and Master Control Program for the Burroughs B5000 written in ALGOL in 1961. In around 1977, Ritchie and Stephen C. Johnson rolled out further improvements to the dialect to encourage conveyability of the Unix working framework. Johnson's Portable C Compiler filled in as the reason for a few usage of C on new stages.