Article View: net.micro.atari16
Article #1463Re: 68000 Memory Managment
From: Eric Black
Date: Fri, 29 Aug 1986 18:16
Date: Fri, 29 Aug 1986 18:16
55 lines
3655 bytes
3655 bytes
In article <510@elmgate.UUCP> jdg@elmgate.UUCP (Jeff Gortatowsky) writes:
>In article <64@mit-prep.ARPA>, tmb@mit-prep.ARPA (Thomas M. Breuel) writes:
>> However, an MMU has other uses besides paging, e.g. to protect processes
>> from one another, to help utilise memory more efficiently, and
>> to allow swapping and process duplication (a la fork(1); you can't
>> implement fork(1), in general, on the 68000 without an MMU).
>>
>> I consider it a grave mistake not to have included even a rudimentary kind
>> of address remapping on the Amiga; even just an adder on the address lines
>> of the 68000 would have simplified the system software and allowed some
>> kind of swapping to be hacked.
>>
>> Thomas.
>
>I understand your first paragraph completely. But you lost me on the second.
>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? I guess it be
>nice to learn from you what type of paging you could implement with just an
>adder, etc. Enlighten me. Mail if you must. Post if it seems of general
>interest to all 68000 based machines.
Just recently there was a fair amount of discussion in net.micro.amiga
about the difficulties of making shareable code. One of the biggest
difficulties is generating code which can use distinct parts of memory
for data for each of the processes/tasks/threads/whatever sharing the
one copy of the code. There are ways of doing this for the 68K, but
unfortunately none of the compilers currently available for the Amiga
do this well, if at all. Protection issues aside, it sure would be
nice to be able to compile & link my program so that it uses a data
segment starting at some particular address which gets mapped by
something MMU-like to the address of a memory block allocated by the
OS when I start to run the program.
And hey, I could do that for the code, too, and keep executable images
on the disk as a memory image, instead of a "hunk" file, so that
loading the program consists of allocating memory, reading from
the disk into memory, setting the memory map correctly, and going.
The hunk scheme used by the Amiga results in the CPU having to touch
everything when loading a program, even if you had a hard disk with
fast DMA.
There are real advantages to be had from a simple address mapping
scheme. Protection is nice, especially on a multitasking machine,
but is a separate issue. Demand paging, implying the ability to
restart an instruction which faulted, is yet another separate issue.
--
Eric Black "Garbage In, Gospel Out"
UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric
>>>> after Sept 1: <<<<
{sun,pyramid,hplabs,amdcad}!cti!eric
^^^
Technical Details
Message-ID:
<339@chronon.chronon.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!ut-sally!pyramid!chronon!ericReferences:
<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!ut-sally!pyramid!chronon!eric From: eric@chronon.UUCP (Eric Black) Newsgroups: net.micro.atari16,net.micro.amiga,net.micro.68k Subject: Re: 68000 Memory Managment Message-ID: <339@chronon.chronon.UUCP> Date: Fri, 29-Aug-86 14:16:21 EDT Article-I.D.: chronon.339 Posted: Fri Aug 29 14:16:21 1986 Date-Received: Fri, 29-Aug-86 23:23:15 EDT References: <508@elmgate.UUCP> <64@mit-prep.ARPA> <510@elmgate.UUCP> Reply-To: eric@chronon.UUCP (Eric Black) Organization: (none) Lines: 55 Keywords: 68000 atari amiga 68k mmu