Is dynamic user page useful?

[patricksurry]

The doc talks about up as a way to support a multi-user system. Are there any actual use cases or tests (or plans) for that?

It would obviously remove some complexity (size, speed, readability) if up was fixed, and perhaps page-aligned.

At the moment we could even merge everything into zero page: 56 bytes of zp variables, 53 bytes of up variables, leaving 147 bytes for stack and kernel vars.

[SamCoVT]

There are some far future plans for cooperative multitasking, but it's not something I've been working on recently. The idea is that each task would have its own UP space and data stack. The word PAUSE would save the return address, data stack pointer, and UP for this task and replace them with those from the next task in the list before returning. I don't think everything that needs to be in UP has been move there, but most of it has.

Scot and I had also discussed "lightweight" tasks. These would not need a separate data stack. They would be allowed to use the main stack as long as they left it exactly as it was before calling PAUSE to move on to the next task.

One issue with using more ZP is that not all systems have 256 bytes in zero page. Some systems have a window of I/O there for faster/smaller I/O routines.

Having UP be page aligned might be reasonable. I think the plan was for only 256 bytes of UP variables (128 cells). I'd have to look at the words that use it and see what kind of speedup that might offer. I currently like that most parts of Tali can be rearranged to be anywhere in the memory map.

[patricksurry]

OK, makes sense. Mainly checking that it wasn't leftover stuff that was no longer in the plan.

Since the DS is in zp it would need to be copied between tasks. Wth UP as a variable I see that you can each task's local vars in place, but it means access is slower. Given that the user page is small (only 53 bytes) it might be worth the tradeoff of making UP a static value and then copying the user data in/out on each task switch (like COLD does)? This would also make the current single-user mode faster/smaller.

[SamCoVT]

The user variables that exist now are mostly to do with compiling, wordlists, and blocks. A lot of those are only going to be used in interactive mode, or while compiling. The majority won't be touched while running words that are already compiled. We should probably have some discussion about what other things should be moved into the UP variables and which things should be left in zero page and swapped out.

I think a lot of that is going to be based on what limitations we give to tasks. Some examples might include only allowing one task to be interactive (although I personally think it would be super cool to have more than one interactive console on a single 65C02 - the neo6502 system has a keyboard/HDMI console as well as a serial port), or perhaps only one task to use the block support, or perhaps only one task at a time to use the block support with all buffers flushed called before PAUSE.

Some of these things we should also think about if we want to let users write their own ISR in Forth. That requires some extra care as the data stack might be in the middle of being fiddled with when the interrupt happens - it probably requires a separate (small) data stack for the ISR.

PAUSE is likely to be called in loops, so that needs some thinking about as well.

Because this isn't on my immediate roadmap, it doesn't need immediate thought or action. I like to let these kinds of things just rattle around in my head for a while before I make any decisions or start planning action.

[patricksurry]

For those (like me) unfamiliar with multitasking in Forth, I found this article very useful: https://www.bradrodriguez.com/papers/mtasking.html

Sounds like things would be easier if zero-page wasn't fixed, e.g. on a 6809 the direct page could move around with the user.

[SamCoVT]

Agreed. That's why some of the variables live in the user page. Only the UP pointer in zero page has to be updated to switch all of those variables. There's still a bunch of variables in zero page that would need to be swapped during task switching, although some of that can be mitigated with restrictions (such as only allowing one task to do console I/O or forcing all tasks to use the same I/O channel).
Because most of the Forth multitasking systems are cooperative, you can make sure everything is in a reasonable state before you switch tasks. Only IRQ handlers require special care, if you want to write them in Forth, as they can interrupt at any time.