Hi,
only as a small remark: the DOS print spooler (I do not know whether
another ones...) is working on an interrupt basis, as the printer tells
with an IT if the data has been printed, so asks for new data. There is no
time slicing.
Imre


On Sat, 15 May 1999, Graeme Smith wrote:

> I have been working on such a machine....
>
> As near as I can tell the only real benefit an interrupt gives you, is
> the ability to do instantaneous changes in context. You can get much the
> same effect without an interrupt simply by planning your code so that it
> always takes the same amount of time, to execute, for each portion of a
> task you have it do.
>
> Instead of getting instantaneous service, you get essentially, a known
> delay time between the mainline code, and the service routine. If you use
> a cooperative system that leaves the processor in a known state, or
> dedicate some registers to saving the context for each task, you can
> manage less instantaneous but certainly timely effects that would be hard
> to tell from an interrupt.
>
> The absolute minimum multi-tasking system, for such a processor would of
> course be the simple round robin sequencer, which gives each task its own
> time slice. By designating one task as a foreground task, and the other as
> a background task, you can signal the need for a supporting background
> task to be launched from your main application in the foreground.
>
> A perfect example of this, is spooling, which is a background task that
> runs the printer, while the foreground tasks, are ongoing.
>
> Each time the spooling task is called, it sends another small string of
> characters to the printer, then returns control to the main task. The main
> task, runs for a period, and then returns control to the sequencer, which
> can call the spooler, or another background task, such as garbage clean
> up, to take care of the print buffer after the data has been printed.
>
> In such a two task system control passes back and forth between the tasks
> in an oscillating effect, advancing both of them just as easily as one.
>
> The main difference between this and an interrupt driven system, that does
> two tasks at the same time, lies in the design of the code to be packaged
> in standard length snippets, rather than running any code at all, and
> using the interrupt to switch contexts.
>
> Such programs where the coding co-operates, is called co-operative
> multi-tasking rather than standard multi-tasking, and requires a bit more
> sophistication of the programmer, in order to make more efficient.
>
>                                         GREY
>
> GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca
> YMCA Edmonton
>
> Address has changed with little warning!
> (I moved across the hall! :) )
>
> Email will remain constant... at least for now.
>
>
> On Mon, 10 May 1999, Seyler Jean-Yves wrote:
>
> >                 Hello all PICers,
> >
> >         Some time ago, there has been a discussion about multitasking and
> > solutions have been proposed with interrupts ...
> > Does any of you has an idea of a multitask kernel (2 tasks should cover
> > most applications) without usong interrupt facilities in order to be put
> > on a PIC 12C509 for example ?
> >
> > Thanks
> >
>
>