Path: utzoo!attcan!uunet!munnari.oz.au!uokmax!d.cs.okstate.edu!minich From: minich@d.cs.okstate.edu (Robert Minich) Newsgroups: comp.sys.mac.hardware Subject: Re: New Macintosh Strategy Message-ID: <1990Oct31.185243.29169@d.cs.okstate.edu> Date: 31 Oct 90 18:52:43 GMT References: <5494@uqcspe.cs.uq.oz.au> Distribution: comp.sys.mac.hardware Organization: Oklahoma State University Lines: 65 me: | Sorry, but VM does not equal protected memory. You can have neither, | one, or both. Sys 7 will offer only VM... by brendan@batserver.cs.uq.oz.au (Brendan Mahony): | Sorry to hear that. Sounds like a waste of space then. | | In my first year CS course VM did imply protected memory. Every process | has its own (virtual) copy of the full machine address space. The PMU | converts a virtual address to a physical address, be it in main memory | or on disc. The weaker form of memory management was called paged memory | management. I guess I'm not sure what is meant by "paged" as you use/understand it. To me, it means that when a memory access that doesn't land in RAM some "page" (a contiguous block of memory) will be written to disk and the page with the address being accessed will be read into RAM. BM: [VM will aid programmers] Me: [not really] | You miss my point. VM means that programmers do not need to worry about | the size or availability of code segments, or for that matter have | segments at all. This is the reduction of complexity to which I refer. Nothing about VM on the Mac will significantly alter the way programming is currently done. The Mac's idea of "segments" are chunks of code that can be dynamically loaded as they are needed. The technique is to have a jump table with an entry for each routine accessed externally to that segment. If the segment being called is in memory, the table merely jumps to the proper place. If the segment is on disk, the table entry loads in the requested segment from disk. This was very important with 128K to play with but is not very critical now. There is no law that a program MUST use this method only. It just happens that most compilers use it. VM will change nothing about this whole process other than having more memory to keep stuff around in. Also, VM will do zip to fix the stupid scheme where we grant blocks of memory to individual programs. You'll be able to give them bigger blocks but if Memory Hog 3.7 has a 5 meg partition and only happens to be using 100K of it, 5020K of unused memory will be inaccessible to the rest of the system. Apple's implementation of VM will not be able to run out of swap space, unlike UNIX systems where swap space can grow and shrink. There will be a big file somewhere and the size of RAM + swap file = total available memory. So even if you have a 2MB free on disk, if you run out of VM you'll have to reboot to allocate more. Likewise, if you want a maximum of say 10MB with 5MB RAM, you'll have a 5MB swap file on your disk whether you're actually making use of it or just running the finder. As I said before, it would be Real Nice to have the Mac OS rewritten from scratch so these problems could be fixed properly. That would also allow (require?) a rethinking of what sort of globals programs can access. This would make protected memory A LOT easier to implement than figuring out how to do it with the current OS and programming model. At the same time, we could fix things like lack of DMA support, non-preemptive multitasking, etc. This is why I (as in me, not necessarily eveyone and his brother) am very intersted in the NeW NeXT machines, where these fundamental OS issues are better dealt with already. Just my personal views. -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| A fanatic is one who sticks to |=(___)= | minich@d.cs.okstate.edu | his guns -- whether they are | U | - Ackphtth | loaded or not.