Multiple processes on 8086... how?
Julien System Oster
Hello.
I have a question for one thing which won't let me sleep :)
How does Minix implement Multitasking on 8086 systems? This CPU doesn't have
any memory management (a translation lookahead buffer, for example) and won't
let you do any context switching.
How the hell can you then achieve multiple processes running simultaneously on
this CPU? And signals, how are they implemented?
--
Gruß, Julien Oster
e-Mail: sys...@sysadm.cc
Julien System Oster
Martijn van Buul
> How does Minix implement Multitasking on 8086 systems? This CPU doesn't have
> any memory management (a translation lookahead buffer, for example) and won't
> let you do any context switching.
management'.
Virtual memory, lookaheadbuffers and even protected modes are not necissary
for multitasking. Granted, they make life better, but that's no reason why
you couldn't have a multitasking system. I've once written a taskswitcher
for a Commodore 64 (with it's 8-bit 6510 microprocessor). Needless to say
that it's terribly slow, but it worked, as long as programs followed
certain guidelines (which, unfortunately, included 'Don't make any
kernal calls!', because the kernal wasn't re-entrant.)
--
Fight Spam! Join CAUCE! == http://www.cauce.org/
Martijn van Buul, mart...@mud.stack.nl, tij...@outerspace.imaginary.com
Pienjo on #c-64 and #dohd (when I'm in the mood)
Tijntje@OuterSpace - 131.155.141.166 3333
Mykhaylo M. Mythrofanov
>
> Hello.
Same. :)
> I have a question for one thing which won't let me sleep :)
Yes you are sleep :))) (by cartoon about Simsons.) :)
> How does Minix implement Multitasking on 8086 systems? This CPU doesn't have
> any memory management (a translation lookahead buffer, for example) and won't
> let you do any context switching.
1. Yes 8086 have no much features which require by modern OS,
but for many task you can apply a OS under such processor.
Yes crash of one application can crash all work,
I afraid that is possible to write virus for Minix with 8086.
You can compile short POSIX-compatible application,
and run few such application under Minix with 8086.
And you can't touch some hardware from application,
or no you can't toch any hardware, but it theoretical possible.
2. Is not enough for serious UNIX-server,
but it enough for simple personal
computer. Or for very simple server.
3. And other point of view.
Tradition of using UNIX for some people
who use big UNIX-machines using DOS is not agreeable,
best solution for them is using UNIX-emulator,
especial for programmers.
4. (I think that Bill Gay ts-s-s tred to did multitasking
OS like Minix with M?-DOS from version 3 but he not did it.)
5. I know way how did it all OS's features on any CPU,
in software way. Not software emulation of virtual machine,
I tall about real performance.
>
> How the hell can you then achieve multiple processes running simultaneously on
> this CPU? And signals, how are they implemented?
>
> --
> Gruъ, Julien Oster
>
> e-Mail: sys...@sysadm.cc
>
Mykhaylo M. Mythrofanov
24-Nov-98 12:07 you wrote:
> It occurred to me that Julien "System" Oster wrote in comp.os.minix:
> > How does Minix implement Multitasking on 8086 systems? This CPU doesn't have
> > any memory management (a translation lookahead buffer, for example) and won't
> > let you do any context switching.
> I assume that you mean virtual memory when you're talking about 'memory
> management'.
>
> Virtual memory, lookaheadbuffers and even protected modes are not necissary
> for multitasking. Granted, they make life better, but that's no reason why
> you couldn't have a multitasking system. I've once written a taskswitcher
> for a Commodore 64 (with it's 8-bit 6510 microprocessor).
You are a monster (I hope you true understand it, but remember
English is not my native, if something wrong - sorry.)
On MCS6510 ?
So, how you did it ?
It must bee next:
You reserv a memory for swap which is not used by both applications,
and swap applications in memory between "swap area" and
work area, and give processor resource to application in
work area for beat of time and .... "again and again" (by Doors)
Isn't it ?
I do not know architecture of that computer but afraid
that on monitor you saw something strange in that moment.
Good bye.
Martijn van Buul
> You are a monster (I hope you true understand it, but remember
> English is not my native, if something wrong - sorry.)
>
> On MCS6510 ?
> So, how you did it ?
I used a timed non-maskable interrupt to do the context switch. The
real problem is the fact that the processor stack of a 6510 is
fixed in the $0100 to $01ff area. This leaves only 256 bytes of
stack, which is not enough to share between different processes. So,
I had to copy the contents of the stack at each context switch. Terribly
slow.
> It must bee next:
> You reserv a memory for swap which is not used by both applications,
> and swap applications in memory between "swap area" and
> work area, and give processor resource to application in
> work area for beat of time and .... "again and again" (by Doors)
I didn't use any memory swapping at all, except for the stack. At an
NMI, the processor pushes PC and processor flags to the stack. If you
push the other registers to the stack, copy the contents of the stack
and save the stackpointer somewhere, you can resume this 'task' at any
time. So, basicly, all my taskswitcher did was
<push registers>
<copy stack>
<store stacpointer>
<copy stack from next job>
<restore stackpointer>
<pop registers>
<return from interrupt>
It didn't have anything like a priority queue or nifty things like that.
If memory serves me right, I even used BRK (forced interrupt) as a
software context switch.
> Isn't it ?
> I do not know architecture of that computer but afraid
> that on monitor you saw something strange in that moment.
Euhm.. Like I said earlier, those tasks couldn't use the original
Kernal at all. I stopped with the project after I got a couple
of completely useless programs running (One changing the border colour,
one chaning the screan colour, one displaying a keepalive counter, and
one doing basic I/O to the screen and keyboard). It has been done before
on that machine, and I didn't feel like rewriting the whole kernal
myself. More or less a "Let's see if I could have done that myself"-kind
of approach ;)