🚀 go-pugleaf

>  
> 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