Cooperative multitasking is not really multitasking, as a single, poorly-written program can hog the machine simply by not relinquishing control when it should. All versions of Microsoft Windows prior to Windows 95 ran with that model, and were notable for data-mangling crashes (Windows 95, in contrast, merely had annoying crashes). A truly multitasking system will have a means for the kernel to interrupt a process and start a different one without the interrupted process being given an opportunity to put up a fight.


Well, I have been plugging away at this computer stuff for decades. I started back when Tele-Type machines were state-of-the-art communications devices.


Ditto here. I'm always interested in finding new ways to pound nails into lumber. What I don't like to see is failure due to someone not fully grasping the magnitude of the problem they are attempting to address. I've been guilty of that sin several times in the past—it's not a very pleasant experience.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The Macintosh had cooperative multitasking, and wasn't especially crashy.

Certainly less "crashy" than any version of Windows prior to NT5 (aka Windows 2000). However, the MacOS was far from perfect and I recall in the 1990s when I was teaching in a computer lab at the local junior high school that crashes were not entirely infrequent (the register dumps were always interesting to read). Something that seemed to often excite the machine's ire and cause a crash was use of the AppleTalk networking feature.


What you have described is preemptive multitasking. The fact that a timer interrupt can trigger a task switch takes the operating system out of the realm of cooperative multitasking, even in a case where a task may voluntarily relinquish its time quantum. Incidentally, a process running under UNIX or Linux can voluntarily relinquish control by calling the kernel sleep() API before its time quantum has expired.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Perfect is the enemy of good.

You can have a fun and useful system without MMU and with cooperative multitasking, especially if you're the only person using it. If a task misbehaves, just hit the reset button and fix it. Let's not discourage people who actually take the effort in creating something.

> Let's not discourage people who actually take the effort in creating something.
Quite so.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I like the idea of a cooperative "scheduler" and a preemptive "executioner". I am reminded of the "watchdog" interrupt facility in some small systems.

Mike B.

Perfect could as well be a driving force to let good advance to better

You are fully right - having a multitasking or multithreading OS available is a big step ahead and opens a new quality for a programmer to achieve his or her aims. I devoutly hope that Hugh isn't getting discouraged by this discussion!

If (due to my limited Forth knowledge) I understand Hugh's idea correctly he figured out a neat way to do a sort of "soft task switching" by selecting a frequently used primitive to check whether time is up and then do a switch with minimum housekeeping efforts. Additionally he assist this switchover by some new instructions, accelerating things even more. This looks to me as a very nifty variant of a switchover and perhaps a really new one as well!

BTW: thinking about a bulletproof multitasking does not mean cooperative MT is useless - cooperative MT could be used within a task as well - I think this is commonly called multithreading.

The W65C265 has a dedicated timer to serve as a watchdog. And the W65C265 as well as the W65C816 have an ABORT-facility that can be used to implement a MMU - there is quite a bunch of additional logic necessary, but who cares

I'm a fan of true multi-tasking. Kernels with true multi-tasking don't need to be large and complex. There are several multi-tasking software kernels that are only a few kb in size. I wonder how efficient a co-operative multi-tasker is. With all the checking for task switches seems like it would be less efficient than pre-emptive.

MMU's can vary from really simple to very complex. Simply switching memory banks by holding a bank number in a register can go a long ways towards providing protection of one task from another. Using a typical 512k ram could provide enough memory for 16, 32kb tasks.

_________________
http://www.finitron.ca

I agree. I think "true" multi-tasking is easier than cooperative multi-tasking. But the latter has advantages when communication between tasks have a prominent role. There you can simply share a common buffer. True multi-tasking would not allow that. There either the OS has to provide some sort of mailbox services (which I like) or a somewhat more powerful MMU is required that allow to access multiple regions which may then overlap with other tasks (never heard of such usage).

(OT: Things are going to become really weird when there is more than one CPU running simultaneously... )

I don't need memory-management hardware, or a supervisor mode, or any of that other stuff that Unix machines have. I'm not expecting the 65VM02 to be a multi-user system. Even if it had been in the C64, it would have still been a single-user system --- but it would have allowed for doing tasks in the background --- it would have been better than MS-DOS with all of those TSRs that were obviously a kludge.


I don't see a problem with "labor-intensive" I/O devices. The IRQ and NMI can interrupt the low-priority ISRs. I/O that needs to serviced frequently will not have to wait on the multi-tasking OS. Also, the low-priority MIRQ interrupts don't have to wait for a task-switch, so they are pretty fast too. They can't interrupt each other though, so if you have more than one pending, some of them will have to wait. They are written in assembly-language though, so they should conclude quite quickly, so there isn't much of a wait. It is possible for them to be written in Forth, but I said that this is not recommended because of the speed issue.

The 65VM02 is designed for hard real-time micro-controllers. It supports a multi-tasking OS though, which is for tasks that don't have to be done on a strict schedule (soft real-time).


The 65VM02 is not Forth-centric.

There are processors, such as the MiniForth/RACE that I worked on previously, that were specifically designed to support Forth. The 65VM02 isn't one of them. There should be no difficulty in writing a C, Pascal, or whatever compiler for the 65VM02 --- the code quality should be comparable to Forth in regard to size and speed.

The 65VM02 supports byte-code with these instructions:

OPA and JVM are used in NEXT. Also, OPA is used in any primitive that has an operand, such as LIT etc.. EXIP is used in CALL and EXECUTE. This should be the same for either C or Forth.

The 65VM02 supports local variables with these instructions:

LLY provides the local-frame address. AAS discards the local-frame from the return-stack. The local-frame is the same in both Forth and C --- this is something that Forth borrowed from C --- the difference is that my Forth supports quotations and HOFs, which C does not support (I don't know why C doesn't support this; that was a failure in the design of C, because this can easily be supported).[/quote]


AFAIK, nobody has downloaded my document and read it. Nobody is actually following the topic.

What you are describing is something I had in an early version, but no longer have.

Previously I had expected to have a T-flag that gets set by the heartbeat timer (either the ISR does this, or it is done by hardware). At NEXT for every primitive (not any particular frequently used primitive), the T-flag is tested and if set a task-switch is done.

I got rid of all that though.

There were problems with that design. Specifically, that accessing some shared resource could only be done inside of a single primitive, which necessarily implied that the code was written in assembly-language. What I have now is the EXA instruction that allows a task to obtain a semaphore. This means that accessing some shared resource can be done in Forth code (or C code or whatever language is being used) --- it doesn't have to be done inside of a single primitive --- the whole point of the 65VM02 is to support high-level languages, so I don't want to force people to use assembly-language for common programming tasks.

I think my design is way beyond the 65c02. I have support for byte-code VM execution which makes a high-level language realistic, I have support for local variables, I have support for semaphores, and I have support for a RAM-disk outside of the 64KB main-bank. The 65c02 lacked support for all of this --- that is why it became obsolete --- it was a very minor upgrade to the 6502; it just wasn't moving forward into the future.

The 65c816 is a much bigger processor than the 65VM02, with 16-bit registers. It doesn't support byte-code VM execution though, so high-level language compilers will typically generate machine-code which is typically quite bloaty. The 65c816 also only has the NMI and IRQ interrupts, the same as the 65c02, so it is pretty weak compared to the 65VM02 that has NMI IRQ MIRQ0 MIRQ1 MIRQ2 MIRQ3 interrupts --- the 65VM02 also allows NMI and IRQ interrupts to interrupt MIRQ ISRs, although the MIRQ interrupts can't interrupt each other's ISRs, so I have a distinction between high-priority and low-priority interrupts.

In the 65VM02 I have the D register that indicates where the direct-page and return-stack are. The D register is always even, so the direct-page will be on an even page and the return-stack will be on the next higher page. By changing D the entire context of a task can be swapped out with that of another task (most tasks use only the direct-page and return-stack for all of their data). This makes for very fast task-switches. The tasks communicate with each other using shared data-structures in the heap (there is 56KB of RAM available in the main-bank, so the heap is pretty big).

The 65VM02 is still an 8-bit processor with 8-bit registers. It is not an upgrade to 16-bit registers like the 65c816. It seems like upgrading from 8-bit to 16-bit registers is obvious. I am dubious that this is a good idea though. To me, the hallmark of the 65c02 was the A X Y and S registers, all 8-bit, and that is what I still have in the 65VM02 (with the addition of the D register that is also 8-bit). This is a small processor! I do have the IP register that is 16-bit, but this is provided to support byte-code VM execution, which is only necessary for high-level languages support.

Having a very few 8-bit registers allows the 65VM02 to have very fast interrupt response time (the IP registers doesn't have to be saved and restored if the ISRs are written in assembly-language, which is the typical case). All in all, I think the 65VM02 is a better design than the MSP430 or STM8 --- those are primarily what it would compete against.

True, but it's better to build a good system first, and perfect it step by step. It's too easy to come up with many great ideas from the start until you're overwhelmed and quit.

Amen. I have spent a large portion of my life struggling with the issues you describe. It is not a pleasant experience.

Mike B.