Introducing... PUNIX! A Puny UNIX

[drogon]

barnacle wrote:

That sounds vaguely like the original windows 16 message handler, Gordon, except for the ability to force a switch if a task decided to hog the processor.

Neil

I've never used that, so no idea what it is.

It's actually modelled on the Inmos Transputer - which did that in the hardware/microcode. The transputer would run a thread for about 100mS then switch to the next thread at the next jump instruction. Nothing was saved except the stack pointer. A linked list was used to track the threads. Compilers had to "know" that registers would be potentially trashed after a jump, but that was ok as there were only 3 of them which worked like a push/pull stack.

As my system is a bytecode VM, I also chose to use the jump instruction(s) as the task switch point, although in my case, I do save the 3 registers plus 3 others that the virtual cpu uses, but still keep a linked list of tasks. (I call them Imps) In theory a program with no jumps would run forever but that's never going to happen.

I'm also looking at making it more like Tony Hoares Communicating sequential processes model. Channels are means to pass messages between processes e.g. a filing system and a user program, and so on, but also between individual user processes - each of which could be running on a different core. That extends to hardware channels or "links" to use Transputer terminology. The idea being it could be run in a multi cpu or multi-core environment. Not quite there yet as this was a bit of an after thought, but it all fits into the same model.

I have experimented with using a VIA to connect 2 x 65xx systems together (and 65xx to AVR) - hardware works, it's just software. My current development board has a 2-core RISC-V setup so when I have time I'll start to look at bringing up the 2nd core.

If anyone were to do a 2-core '816 system, then it may be adapted but that's never going to happen, but I do have a backplane ready to go for my '816 system that has the capacity to have multiple CPU boards as well as peripherals. (That's probably never going to happen either)

-Gordon

[barnacle]

Yep, same here. Cooperative multitasking _isn't_.

Though apart from the inability to time out a task, there's a lot to be said for the W/dos message handling loop.

Neil

[GlennSmith]

Hi all,
The last few posts set off a few "brain jogs" in my head. In one of my previous lives I was an HP1000 expert, providing systems support as an HP consultant. But that was a long, long time ago, and I realize that I've forgotten all about the RTE (Real-Time Executive) system. Luckily internet forgets a bit less than I do, and I managed to find some of the RTE manuals.
This little excerpt shows why my brain woke-up :

RTE-ProgramManagement.pdf

RTE : Program states and scheduling.

(19.23 KiB) Downloaded 12 times

Extracted from HP manual 92077-90013
At the time, for me, RTE was the best thing since sliced bread - 16-bit architecture, predictable interrupt latency ('real-time' was an exaggeration), multi-user, multi-tasking - all that in, generally, less than 4Mb of memory!
The only real danger that could cause problems was the risk of deadlocks between programs waiting for the same (generally I/O) resources. The scary thing was, back in the 1970's, it worked amazingly well!
As Bill 'n Dave have long passed away, I don't think they'll mind that I reproduce part of the original manual.

P.S. If anyone out there has the QDM/1000 manual from around 1986 - I'd love to have a copy, 'cos I wrote it!

[drogon]

barnacle wrote:

Yep, same here. Cooperative multitasking _isn't_.

I do like the idea of coroutines. Many years back (Early 80s) I did a factory automation project at uni. all based on BBC Micros with Econet - one Beeb at each "station" (cnc mill, lathe, loading/unloading robot, measuring station, etc.) The Beebs sent commands to a little "PLC" (Home designed 6502 - "Arduino" of it's time) which did the actual hardware movements with the Beeb talking to the stations CNC controller.

All the Beeb code was in BCPL and used coroutines extensively - which all coperated and never hogged the system because that was the intention. The 'idle' task ran a little blinker on the screen, so I could visually tell hos "busy" the cpu was (and if something ever locked up!)

But yes, it demanded cooperation from each task... So each task ran as a little state machine. It worked extremely well - given cooperation.

However for many reasons, I decided pre-emptive was the way in my current system - a task should never sit idle and spin, waiting on something, so it can voluntarily pass over - hopefully when I get more subsystems moved to their own processes then waiting on something (like uart, sd card) will do the automatic skip over via the scheduler in a similar way to Unix processes.

(Unix it's not, although I'm finding it hard to get away from all those Unix-isms I've used over the past 46 years...)

-Gordon

[GARTHWILSON]

As I wrote in the "POC VERSION TWO" topic, non-preemptive, cooperative multitasking allows a very fast, efficient context switch, and there's no need to delay interrupts during the context switch.  Rather than letting a problem task bring the whole system to a halt, NMI could be used with a VIA timer, similar to a watchdog timer, and if the timer times out and generates an interrupt, the ISR could take that task out of the rotation and restore the operation of the rest.  The timer times out only if the task stops being coöperative, something that won't ever happen if everything is working properly.  When all is working as intended, the timer keeps getting reset by the beginning of a task before it ever times out (or, maybe even safer, have the timer get reset by the end of the task that's handing control over to the next one—or maybe even both).

Back when I was using Microsoft software, I certainly did my share of yelling at the monitor (it's slightly satisfying you know, when you can't get to Microsoft itself), about all the bugs.  The company was always racing to get the next product out when the schedule said to, regardless of bugs.  I don't want any new features until the bugs in the existing product are fixed.  There's no excuse.  I've used coöperative multitasking in realtime firmware I programmed, for products I designed and they went into service in the field, and I never had any problem.