From: davids@cats.ucsc.edu (Dave Schreiber)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: physical memory protection with MMU
Keywords: mmu, memory, task
Date: 13 Nov 92 01:15:48 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: si.ucsc.edu


In article <nn.geht.nicht.die-zweite.121192@uni-paderborn.de> tron@uni-paderborn.de (Matthias Scheler) writes:
>chandler@uni-paderborn.de (Martin Grote) writes:
>
>[stuff deleted]
>
>>However, to focus on my original intention again:
>>- is it impossible / too difficult?
>
>Too difficult, you can't build MMU tables for every 8 bytes of allocated
>memory. If you really would know how a MMU works and how Operating Systems
>with "Memory Protection" work you would know that it is impossible to put
>this in AmigaDOS without loosing 99.9% of the software. It's easy to
>scream for memory protection if you never wrote a program and don't know
>the concept of AmigaOS.

Who says you need an eight byte page size, i.e. why does every memory
allocation need to be treated as a separate page?  You could implement
something like this:
 When a task starts, create two lists of memory:  memory allocated by the
  task and memory in the task's address space ("owned" by the task) but not 
  allocated.
 When the task wants to allocate a memory block of size n, do the following:
    1. Search the owned-but-not-allocated memory list for a block of size n.
    2. If no large enough block exists, allocate the necessary memory
       (rounded up to a multiple of the page size, of course) from the
       system heap, change its protection so that it is owned by the task,
       allocate the amount of memory required by the task, and put the 
       remaining memory in the owned-but-not-allocated list.
 When the task frees a block of memory, check to see if this free results
  in an entire page of memory being freed.  If so, remove that page from 
  the owned-but-not-allocated list, change its protections back to "unowned,"
  and return it to the system heap.  Note that this can be done occasionally
  instead of on every FreeMem() if it turns out to be too expensive an 
  operation to run frequently.

Using this technique will let you keep the 8-byte minimum allocation size
yet work with large (>=4K on the '040) page sizes.

The real problem with memory protection on the Amiga is that it is
possible for one task to share its memory with another without explicitly
telling the OS that the shared memory is in fact shared.  This is a big
nono under a protected OS.  However, it is an exaggeration to say that
99.9% of Amiga programs do this.  Out of the dozens or so I've written
(some PD, most for my own use), I doubt more than one or two share data
with other tasks (aside from those that have ARexx ports;  I sure hope
MinRexx doesn't break under a protected OS :-)).  Also, I suspect that most
of those programs that do share data with other tasks share data with 
child tasks that are created by the original program using CreateTask(),
CreateNewProc();  I'd bet that if, under a version of AmigaDOS with 
protected memory, CreateTask() etc. created threads (i.e. tasks
that exist in the same address space with their creators, and thus which
can share their creators' data), a lot of compatibility issues could be
minimized.  This would require new system calls that the system program
loader could use to create new address spaces, but that wouldn't affect
user programs.

>Matthias Scheler                                         tron@uni-paderborn.de

Note: in the above, "task" is being used in the generic form, not in the
      Amiga-specific form.  Also substitute "protected context" for 
      "address space" if it makes you feel better.


-- 
Dave Schreiber  "Look.  Don't touch."  davids@cats.ucsc.edu (until 6/20/93)