Article View: net.micro.atari16
Article #1452Re: 68000 Memory Managment
From: Jeff Lee
Date: Wed, 20 Aug 1986 15:54
Date: Wed, 20 Aug 1986 15:54
35 lines
2696 bytes
2696 bytes
>> The fact that it is difficult to restart an instruction that received
>> a bus fault on the 68000 makes it difficult to implement paging.
>I can see where a MMU that provides protection only would be useful but
>address mapping is still of no use. Not without a 68010, admittedly an
>easy upgrade, but not provided. If you mapped a some address block to
>another would you not HAVE to ensure it was a legal RAM/ROM address? One
>faulty address and your back to GURU type crashes, yes?
Just because you are implementing "paging" does not mean that you must
implement "demand paging". The PDP-11 had memory mapping registers but
did not allow demand paging. Before a process ran you had to ensure that
all the memory they were allowed to access was resident. You could do
the same with a 68000. With a couple of 35ns rams and some address
decoding (to map them into memory) you can implement a similar type of
MMU. For system level access, you bypass the rams and physical and logical
memory are the same. The OS loads the memory mapping rams with the
appropriate address and dispatches the process. While in user mode, the
high order bits are remapped into different physical locations (going
through the MMU rams). You access something that you are not supposed
to and you take a bus error. The OS kicks you in the butt and drops
your process, or gives you a signal with the caveat that you may not
return to where you took the signal. Others have already commented that
with the appropriate code you really can take bus errors for stack accesses
and recover, as long as the access is at the beginning of the routine to
"feel out" the size. This is paging, but the pages must essentially be
preloaded. During another process, there is nothing that prevents just a
portion of your program being swapped out, but it isn't necessary to swap
it all out.
Enjoy...
--
Jeff Lee
CSNet: Jeff @ GATech ARPA: Jeff%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff
Technical Details
Message-ID:
<4374@gatech.CSNET>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!gatech!jeffReferences:
<508@elmgate.UUCP> <64@mit-prep.ARPA> <510@elmgate.UUCP>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!gatech!jeff From: jeff@gatech.CSNET (Jeff Lee) Newsgroups: net.micro.atari16,net.micro.amiga,net.micro.68k Subject: Re: 68000 Memory Managment Message-ID: <4374@gatech.CSNET> Date: Wed, 20-Aug-86 11:54:43 EDT Article-I.D.: gatech.4374 Posted: Wed Aug 20 11:54:43 1986 Date-Received: Thu, 21-Aug-86 04:00:48 EDT References: <508@elmgate.UUCP> <64@mit-prep.ARPA> <510@elmgate.UUCP> Reply-To: jeff@gatech.UUCP (Jeff Lee) Organization: School of Information and Computer Science, Georgia Tech, Atlanta Lines: 35 Keywords: 68000 atari amiga 68k mmu