Comment by wahern
2 days ago
I'm surprised nobody has put together a cooperative threading C framework using the -fstack-usage (https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#in...) option supported by GCC and clang. With per-function stack usage info, you can statically allocate a stack for a thread according to the entry function, just like async Rust effectively does for determining the size of the future. Context switching can be implemented just like any other scheduling framework (including async Rust executors), where you call the framework's I/O functions, which could just be the normal API if implemented as a drop-in alternative runtime.
Googling I see people attempting to use -fstack-usage and -fcallgraph-info for FreeRTOS, but in an ad hoc manner. It seems there's nothing available that handles things end-to-end, such as generating C source type info to reflect back the computed size of a call graph based on the entry function.
In principle Rust might have a much tighter bound for maximum stack usage, but in an embedded context, especially embedded C, you don't normally stack-allocate large buffers or objects, so the variance between minimum and maximum stack usage of functions should be small. And given Rust's preference for stack allocation, I wouldn't be surprised if a C-based threading framework has similar or even better stack usage.
> I wouldn't be surprised if a C-based threading framework has similar or even better stack usage.
“… better stack usage, if you can keep it”
— Benjamin Franklin