Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!cornell!batcomputer!rpi!rpi.edu!deven From: deven@rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga.tech Subject: Re: MEMF_PHYSICAL? Message-ID: Date: 28 May 89 07:05:29 GMT References: <8905270516.AA18668@jade.berkeley.edu> Sender: usenet@rpi.edu Organization: RPI Public Access Workstation Lab, Troy NY Lines: 74 In-reply-to: 451061@UOTTAWA.BITNET's message of 26 May 89 21:53:08 GMT In article <8905270516.AA18668@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: Um, what I meant is that since the MMU is to be entirely controlled by the future Exec, then the MMU context and the current task context are the same. That seems a rather unfounded assumption. Yes, it's likely how it might be implemented, just because of C-A's passion for ultimate speed except when scanning directories... But this is not a given. Due to the way Amiga interrupts are managed, it would be rather uncomfortable to play with the MMU for interrupt processing. The rate of interrupt arrivals on real-time operating systems such as the Amiga's can be overwhelming. Trying to load the MMU with the proper root pointer can delay interrupt processing considerable. Thus since the root pointer can not be changed, you better declare your code and variables as MEMF_PUBLIC. Quite so. But impractical as it may be, it remains a possible approach. Not that a simple way to avoid this is to have a translation table that gives full privilege to code running in Supervisor mode, because user tasks are not supposed to go into supervisor mode all by themselves. An option to consider, although it is not what I consider ideal. Less than ideal, but a quick and easy way out... > Arguments can certainly be entertained by both sides, but the fact > remains that Exec was designed using the model of a *single* address > space for all tasks, with any task being able to access the memory of > *any* task. You are mixing up two concepts here. Yes the Exec was designed to use the single address space model. Hoever that does not imply that tasks should be allowed to access each other's memory. The only reason current Minis and Mainframes, give tasks their own address space is because two decades ago, processors could access only a limited amount of ram. (say 64K) Thus for multi-tasking, the computer would swap the entire programs in and out of that same physical space at ever context switch. Even Unix uses this *poor* memory model, indeed it was first develloped for the PDP-11, which had a 64K instruction space and 64K data space. I'm not mixing up the concepts. I mentioned them together, but they're not interdependent. The single address space isn't very important (except when it comes to things like paging executables to a file) but the assumption that all memory is publicly accessible is rather ingrained. The message-passing mechanism assumes it, and it is relied on heavily by all parts of the system for proper operation, and the lack of memory protection is relied on to keep the overhead low, by avoiding copying. The single address space is assumed also, but that would not change by addition of VM. Hence, my statement that VM should be easier to _integrate_ with the system than memory protection... without breaking everything. [The Unix memory model has changed many times.] If they had processors able to access 4 Gigabytes of physical ram, then Unix too would enjoy the superior functionality available in single-addressing space operating systems. "superior functionality"? What is inherently superior about a single address space? > I stand by my statement. I stand by the model of the ideal real-time message-based operating system. Exec is pretty good, but I wouldn't say ideal. Deven -- shadow@[128.113.10.2] Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet Troy, NY 12180-2306 <> "Simple things should be simple and complex things should be possible." - A.K.