lidnariq wrote:
Context switches are expensive; when one uses coroutines there's much less state to save and restore. I'd be worried about the overhead overwhelming the benefits...
Hmm, what would a context switch look like here? Something like:
IRQ, save registers, some IRQ upkeep, move stack pointer, restore registers, return from IRQ.
I wonder if bankable WRAM could help here too, you could let the different threads independently use memory that way.
Though, aside from running a multitasking operating system with independent programs that come and go, I don't really understand the use for threads on a 6502. For multi-core systems threads are a very important way to parallelize. On a single core system, they can't do that.
In a game... the first situation that comes to mind is running AI for a chess game, where you want to let that run independently and keep doing user interface updates for the player in the meanwhile. For that, though, you only need one more thread... a single IRQ is already good enough to do that (if not just the NMI by itself).
Threads were also common for things like background loading, or background decompression, but the NES doesn't really have enough RAM for decompression to ever take that long, and its only loading device is the FDS... but again even for this kind of thing a single IRQ is already enough for this case too?
So I'd be quite curious to know of a good use case for it, as I can't think of anything, myself.
Coroutines on the other hand do make a lot of interesting code structures possible, especially for AI, but we're not talking about interrupts anymore with that. Coroutines aren't to be confused with "threads", at least in my understanding of them; it's a very different paradigm.