Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!UOTTAWA.BITNET!451061 From: 451061@UOTTAWA.BITNET (Valentin Pepelea) Newsgroups: comp.sys.amiga.tech Subject: Re: MEMF_PHYSICAL? Message-ID: <8906030123.AA14671@jade.berkeley.edu> Date: 2 Jun 89 20:31:53 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 138 Doug Merritt and I have been having a small sling-shot war over the desirability of of various memory models. I have been contending that a single addressing space is preferable, because it allows tasks to access each other's space, while Doug has been claiming that separate addressing space is preferable due to the protection features thus inherited. But when we are comparing operating systems with different memory models, we have to compare operating systems which offer the same other features. Doug is comparing an operating system with virtual memory, memory protection and separate addressing spaces to an operating system with virtual memory, no memory protection and a single addressing space. That is wrong. We have to compare operating systems which offer both virtual memory and memory protection regardless of memory model. Let me illustrate: Doug Merritt writes in Message-ID: <367@xdos.UUCP> > For real time programming, the performance advantage of shared address > spaces makes them desirable, and hence the single address space model > we have on the Amiga is a blessing. It is a mixed blessing nonetheless, > since any malfunctioning program can bring down the whole machine. You see? Doug is saying that a single program can bring down the whole machine. Obviously he was talking about an operating system without memory protection. > Sometimes this is because it has misused a hardware resource, something > that a protected private address space model (adapted to the Amiga's > demands) would not prevent. Oops, so perhaps he does mean that the OS has memory protection. But now he says that misusing a hardware resource can be fatal to a single address space OS, but not to a separate address space OS. Can you see the reasons why? Can you see that this is implementation dependent? > But most of the time it's simple things, > like not deallocating memory, or overwriting OS structures with a runaway > pointer. These problems simply do not arise on systems with private > address spaces, or even on systems with a single address space but > each task limited to writing in the memory that belongs to it. Whoa! Now he is comparing an operating system which has resource tracking with one which does not. That is ridiculous. It is obvious that when memory protection is implemented on the Amiga, resource tracking will have to be added so that crashing programs may free up the requested resources. In a separate address space operating system, resource tracking has to be implemented too, and it is just as difficult to implement, if not more. So at this point, let me compare AmigaOS 2.0 as I propose it, to that which Doug suggests would be better. Valentin's AmigaOS 2.0: FEATURES: 1. Single addressing space. 2. Virtual memory. 3. Memory protection. 4. Resource tracking. ADVANTAGES: 1. Fast context switches, fast message passing (no space copying) 2. Real-time response. 3. Allows tasks to monitor each other, to read (not write, unless allowed) each other's addressing space, to share code. DISADVANTAGES: 1. Virtual memory fragmentation. 2. Limited total addressing space to 4 Gigabytes. (wow!) 2. Fixed-size stacks. Can be made variable by allowing separate address spaces for stacks from the main body. (A la (ICK) Unix.) 3. Fully compatible with old software. Code with Forbid() & Disable() has to be put in MEMF_LOCKED memory. Doug's operating system: FEATURES: 1. Multiple addressing spaces 2. Virtual memory 3. Memory protection 4. Resource tracking DISADVANTAGES: 1. Slow context switches. Slow message passing. (requires MOVES instrucions) 2. No real-time response. Needs real-time 'extensions' which basically consists in implementing shared physical memory... 3. Does not allow shared code, no shared libraries. Can be 'extended' to allow these. 4. Does not allow programs to monitor each other. Needs special operating system primitives to allow debugging. 5. As compatible with current AmigaOS software as MS-DOS software is. ADVANTAGES: 1. Provides each program with 4 Gigabytes of addressing space. Can be further extended into separate program and data spaces. 2. Layer operating systems on top of each other. Now you can run AmigaOS, Minix Unix, Uselessix and Boringix together *at the same time*. Wow! Always wanted to do that! Now Doug has made a rather funny comment in a previous posting. You have to be careful when analysing the implementation of any of these two memory models: > Another strong disadvantage of a single address space model is that it > has problems regarding addressing. Let's say I run two programs, > say for the purpose of having two copies of the same chess program play > against itself. The Amiga simply relocates each copy to a different > piece of allocated memory (patches each process to address correctly > relative to its load point). But once that's done, each must always reside > in that particular piece of physical memory. This puts a severe restriction > on virtual memory, since each time one of those tasks is run, the same > physical ram must be freed again, which will often mean that whole > processes will *have* to be swapped out, while if private address spaces > were implemented, then we'd be free to put it anywhere in physical ram > we want. > > Thus by asking for both virtual memory and for a single address space, > you end up requiring the swapping that you said was such a bogus feature! His error is pretty easy to catch if you though out how virtual memory is to be implemented. You see, the virtual memory handler on a single address space OS does not care what program is running in what memory. It merely swaps in and out individual pages one-by-one. Full programs never have to be swapped out entirely, just individual pages. This will become more obvious in a couple of weeks. :-) Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: (613) 231-7476 (New!) system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA