home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!gossip.pyramid.com!olivea!hal.com!darkstar.UCSC.EDU!cats.ucsc.edu!davids
- From: davids@cats.ucsc.edu (Dave Schreiber)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: physical memory protection with MMU
- Keywords: mmu, memory, task
- Message-ID: <1duvk4INN65q@darkstar.UCSC.EDU>
- Date: 13 Nov 92 01:15:48 GMT
- References: <1dtp0rINN9jk@uni-paderborn.de> <1du485INNdbn@uni-paderborn.de> <nn.geht.nicht.die-zweite.121192@uni-paderborn.de>
- Organization: University of California; Santa Cruz
- Lines: 66
- 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)
-