If you have feature requests, this is the place to post them. Please note your idea may already be something we have already discussed and decided against, or something we are working on privately, and we cannot be held responsible for any similarities in such instance. Whilst we cannot respond to every suggestion, your idea will be read and responded to where possible. Thank you for your input!
The example you show splits the stack into 16 stacks of 16 bytes each. Very limiting.
Because you only have a 256 byte stack and cannot relocate it, multitasking is very hard on a 6502. You either need to split the stack which limits number of tasks and limits task size or you need to copy the stack on context switches which is slow.
There is a project which does preemptive multitasking on a C128 but only because the C128 MMU can relocate the stack anywhere in the memory map.
mgkaiser wrote: ↑Thu Dec 07, 2023 5:18 am
Because you only have a 256 byte stack and cannot relocate it, multitasking is very hard on a 6502. You either need to split the stack which limits number of tasks and limits task size or you need to copy the stack on context switches which is slow.
One of the best changes on the 65C816 was making the stack pointer 16-bit. This allowed the Apple IIGS to give each running program its own stack.
With the 65C02 I don't see multitasking as very practical, although I suppose the X16 is clocked at a high enough speed to make copying the stack on context switches not too horrible.
mgkaiser wrote: ↑Thu Dec 07, 2023 5:18 am
Because you only have a 256 byte stack and cannot relocate it, multitasking is very hard on a 6502. You either need to split the stack which limits number of tasks and limits task size or you need to copy the stack on context switches which is slow.
One of the best changes on the 65C816 was making the stack pointer 16-bit. This allowed the Apple IIGS to give each running program its own stack.
With the 65C02 I don't see multitasking as very practical, although I suppose the X16 is clocked at a high enough speed to make copying the stack on context switches not too horrible.
It does depend on what kind of muti-tasking you are doing. For example, if you have two threads of cooperative tasks plus a watchdog, 120 bytes is ample stack for each cooperative task round robin thread and 16 ample for the watchdog. Also, whatever hardware stack space you allocate to a task in a pre-emptive multi-tasking system, the tasks are not required to use the $0100 page S index stack as a data stack ... you can use addr,X indexed stacks, and of course that can be located in the HighRAM window if you wish, which gives flexibility for a number of tasks with parsimonious use of the S indexed stack.
Agreed and I nearly always use a software stack for parameters. But you have no choice on the call stack. JSR is going to push its return onto the processor stack. So are interrupts..
I'm actually working on cooperative multitasking, which doesn't really care about the stack. This is really just a framework to hook multiple dynamically loaded modules into a common state machine.