🚀 go-pugleaf

In article <1727@dinl.mmc.UUCP> noren@dinl.UUCP (Charles Noren) writes:
>
>Last night at home, reading my TC++ manuals, I came across the good old
>setjmp/longjmp library calls.  I've never used them before because of
>the inherently non-portable and non-structured nature of the calls.
>However, now I am curious about the feasibility of faking a primitive
>"multi-tasking" application in TC++ with setjmp/longjmp.  I know that
>these functions can be used in setting up coroutines, and the manual
>mentions the possibility of several stacks (with appropriate caveats of
>not to use the overlay system).
>
>What I would like to do (on my humble 8088 system with only 640K -- I
>remember the days when I had an 8080 with 48K and felt like a king, but
>I digress) is setup a 4 "process" (maybe more, maybe less) system, where
>each "process" follows the discipline of voluntarily calling a function
>that would save the context (via setjmp) and then executes a scheduler
>which would choose (arbitrary choice, does not matter how for this
>discussion) one of four setjmp contexts in which to perform a longjmp
>to.  Has anyone tried this sort of thing and have any pointers to share?
>I was thinking for having each "process" have its own stack.  I haven't
>RFTM enough to find out how to do this in TC++ (prefer to stay in C/C++,
>but will do some TASM if necessary) or what the dangers are.  I would
>like to implement this in different memory models and would like some
>words of wisdom on what I need to do and look out for.
>


The Setjmp/Longjmp calls in TC (not TC++) have been used to implement
this type of multitasking, in fact it is the basis of Phil Karn's
KA9Q/NOS TCP/IP package.   

Rumor has it, however, that the TC++ setjmp/longjmp are broken,
ie they save the state in the wrong order and therefore it can not
be restored, but it is possible to patch the library to reorder
a few instructions to fix it (I don't have a copy of TC++ to look at).

At the heart of NOS is the non-preemptive multi-tasking kernel,
which maintains ready queues, etc and relies on the tasks to
call pwait to sleep (there is also a mode where the current process
will yield but not wait for an event, functions to wake up other
processes, etc.)

So anyway, setjmp/longjmp as the heart of a multitasker is doable,
although bug fixes might be required.   

(BTW, supposedly the MSC 6.? manual says the Setjmp/Longjmp don't
save enough state to be used for this purpose)

Best of luck,
milton