Saving tasks?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Saving tasks?

karmic
If I were to load two hefty programs in the ROM in different register ranges, say 1-500 and 1000-1500, then add two new registers S and L. Could I use these to switch at any times between these two programs?
S can be used to store the D register value of the last program when I switch, and L can be used to store the value of program counter where the last program was left off. Then I can introduce a switch button very much like the load button to switch between these programs. (The A register and L register can be mux'd)

Since the program counter of the switched from program will be stored in the L register, I only need to find out what program memory register to switch to for the first switch. (Since I'll always know what line of the other program to go back to once I've started switching) this can be resolved by having a small program in the beginning of the ROM that finds out the base address of the second program, putting the first program right below it, and that's it.

This is really not a concrete idea in my head so I apologise for any confusing language.
Reply | Threaded
Open this post in threaded view
|

Re: Saving tasks?

ivant
I'm not sure I understand your idea very well. First of all, what are you trying to accomplish with this? Multitasking? If so, it will enable the switching between just two "threads", right?

Also who will decide when to switch between the programs and how this will be initiated?

I assume that the programs need to be written in a way that they know about each other at least somewhat. Otherwise they can use the same RAM addresses and bug each-other in various ways. If they do know about each other, why not just write them as a single program? If they don't know, how will you solve the RAM problem?
Reply | Threaded
Open this post in threaded view
|

Re: Saving tasks?

ajoshguy
Pretty sure the existing hardware (VM) can already handle this.  You have the ability to jiggle with the return PC on the stack (I just tested it works in the VM simulator)... and we already have Sys.wait for timing, so with just that alone it'd be pretty easy to imagine a small threading library with a tiny kernel bouncing things back and forth between threads when they called Sys.wait, or Sys.yield or whatever.

Each "process" having it's own private stack and RAM[0-16] of course, when you first booted a thread you'd have to relocate it's stack out of the main stack area.

Of course you can only go so far without real interrupts and no memory protection, etc.