Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!umich!srvr1!math.lsa.umich.edu!math.lsa.umich.edu!hyc
From: hyc@math.lsa.umich.edu (Howard Chu)
Newsgroups: comp.sys.atari.st
Subject: Re: Does anybody no anything about UNIX on an Atari ST
Message-ID: <1990Jun6.225653.24296@math.lsa.umich.edu>
Date: 6 Jun 90 22:56:53 GMT
References: <669@hexagon.pkmab.se> <90150.161022SA44@LIVERPOOL.AC.UK> <10060@chaph.usc.edu>
Sender: usenet@math.lsa.umich.edu
Organization: University of Michigan Math Dept., Ann Arbor
Lines: 48

In article <10060@chaph.usc.edu> baffoni@alcor.usc.edu (Juxtaposer) writes:
>In article <90150.161022SA44@LIVERPOOL.AC.UK> SA44@LIVERPOOL.AC.UK (Kevin Maguire) writes:
>>space 128K for big (?) processes). The ST is only limited by memory size.
>>OF course it's nice to have 4M as minix has no virtual memory, but
>
>Disclaimer: I do not claim to know much about the ST architecture but...
>
>
>   I was wondering if there are ANY (preferably transparent) programs out that
>will enable an ST to use its hard-drive as a source of virtual-memory:  As long
>as the software you are using doesn't need to skip all over memory while it is
>running, this sure would be a nice way to give yourself an 8-meg machine (4meg
>chipped + swap 6meg or so [leaving 2meg for system,etc]) or some other exotic
>memory size by utilizing the memory storage most people already have.  Or even 
>give someone with a 1meg-machine 4meg of useable memory.  Of course by using 
>certain replacement policies you can speed up what could be excruciatingly
>slow, but for some programs like word processors, I can't see that it would 
>slow it down that much if most of what is in memory (pages of information) were
>read into the ST in bursts.

This seems to be impossible on a plain ST. A paged virtual memory system
automatically implies page-faults - traps generated by accessing a virtual
page that isn't currently in real memory. First there's no straightforward
way to distinguish a virtual address from a physical address. This is pretty
much essential, that is, you must be able to keep the two distinct. Second,
assuming you have some way of recognizing an access to a virtual address,
and generating a page fault if the corresponding page isn't in physical
memory, you can't reliably restart the instruction that caused the fault to
occur. (This is *really* a problem if you fault while accessing a memory
mapped I/O device, but we'll leave that alone for now...) Before the advent
of the 68010 with VM support on the chip, there were one or two 68000 based
Unix systems on the market. I think Sun & Apollo used custom designed MMUs,
which probably suspended the CPU in lieu of interrupting it. This implies
that the VM management was handled almost entirely in hardware, with no input
from the OS. Another approach was to use two 68000s running in parallel. On
a page fault, one 68000 is suspended, the other traps & does the necessary
VM magic, the suspended processor is resumed, and the 2nd processor re-syncs
at the following instruction.

So... Unless you can add in some whiz-bang hardware, I don't think you can
get away with it. And even if you can, I don't think it'll run very quickly,
but that's probably not important. The main thing is, you can get better 
performance using a chip that was designed to handle VM in the first place.
(68010 on up. 68020 would probably be minimum, though I *think* you can use the
PMMU with the 68010.)
--
  -- Howard Chu @ University of Michigan
  ... the glass is always greener on the side ...