jca@pnet01.cts.com (John C. Archambeau) (06/15/89)
I recently was on bugs.nosc.mil looking for the problems that I saw in the
file 'subjects' dealihng with ST and the Minix system call fork.
Unfortunately, the only message in the archives on bugs.nosc.mil with that
subject header wasn't about the problems with ST Minix and memory management,
but rather about implementing swapping.
I have heard from a somewhat questionable grapevine that ST Minix has a
problem with forking processes and the problem is attributed to the Blitter
and/or the fact the ST doesn't use a typical MC680x0 MMU, but Atari's custom
chip set. Were these problems corrected (if they existed) or just swept under
the metaphorical rug?
What I want to know is the following;
1. Are there problems with ST Minix memory management (i.e. fork/exec)?
2. What are the exact differences between IBM and ST Minix on a memory
management level?
/*--------------------------------------------------------------------------*
* That's not an operating system, this is an operating system!
*--------------------------------------------------------------------------*
* UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
* APRA: crash!pnet01!jca@nosc.mil
* INET: jca@pnet01.cts.com
*--------------------------------------------------------------------------*/
#include <disclaimer.h>hcj@lzaz.ATT.COM (HC Johnson) (06/15/89)
> > I have heard from a somewhat questionable grapevine that ST Minix has a > problem with forking processes and the problem is attributed to the Blitter > and/or the fact the ST doesn't use a typical MC680x0 MMU, but Atari's custom > chip set. Were these problems corrected (if they existed) or just swept under > the metaphorical rug? > > What I want to know is the following; > > 1. Are there problems with ST Minix memory management (i.e. fork/exec)? > 2. What are the exact differences between IBM and ST Minix on a memory > management level? Your grapevine is twisted! On the ST the 68000 chip each process can address all of memory. A UNIX(r) style fork means making a clone of the parent, and calling it the child. Minix handles this for the ST. As the Atari does not have Virtual memory (misnamed MMU), the OS has to copy the data for parent and child so the the currently running process gets its same address space. That is, think of a process, A in memory area m1. When it forks, the child ,B, is in memory area m2, BUT can only run if copied back into m1. When the OS schedules B, it switches the memory between m1 and m2. then m1 contains the child, which can run, and m2 contains the parent, which cannot run. The Intel xxx86 chips have virtual memory build in (called segments). No MMU. Since each process starts at 0, forking just requires making a copy of the parent. There are now two processes that can run as easily as any other. BOTH systems lack memory protection. Most people think MMU implies Virtual memory and memory protection. These are separable features. Minix (ST and PC) have survived quite will without memory protection; and the current Minix implementation shows that Virtual memory is not a requirement either. (but it does speed things up.). Finally, If a blitter was used to copy in the active parent/child, this would become even faster on the ST. Howard C. Johnson ATT Bell Labs att!lzaz!hcj hcj@lzaz.att.com
exiphm@eutrc3.UUCP (h.munk) (06/16/89)
In article <632@lzaz.ATT.COM>, hcj@lzaz.ATT.COM (HC Johnson) writes: > The Intel xxx86 chips have virtual memory build in (called segments). No MMU. ^^^^^^ Oh yes, they do! But it's on the chip. However, even with that setup, it does cost a little overhead. Harm Munk Institute ITP-TUE/TNO Eindhoven The Netherlands #include <standard/disclaimer.t>
kbad@atari.UUCP (Ken Badertscher) (06/17/89)
In article <632@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes: | Finally, If a blitter was used to copy in the active parent/child, this | would become even faster on the ST. Not necessarily. Depending on how much context needs to be switched, the overhead of setting up the hardware blit could actually slow the process of context switching. Be wary of the tendency to treat the BLiTTER as a panacea for speed problems. The 68000, when treated right, can be quite speedy. The Atari BLiTTER was designed primarily to aid with graphics processing. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>