Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.os.misc Subject: Re: virtual memory (was Re: NIH class libraries for Turbo C++) Message-ID: <59677@microsoft.UUCP> Date: 10 Dec 90 20:12:33 GMT References: <14440@accuvax.nwu.edu> <15150004@hpdmd48.boi.hp.com> <59300@microsoft.UUCP> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 73 In article khera@thneed.cs.duke.edu (Vick Khera) writes: |In article <59300@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: | | Having used both Unix-style huge linear addresses, and Intel 80x86 | segments, I believe neither has much in common with OOP. In either | one has to copy objects around, or do manual clustering of objects | via heuristics, etc. Maybe one needs hardware based on an | obid+offset, with automatic support of clustering? |you seem to be implying that a segmented architecture is better than a |system that implements virtual memory in a linear address space. No, I was stating that neither traditional segmented architectures nor linear architectures have much in common with the needs of object oriented programming. Maybe people ought to consider CPUs based on the needs of OOP? Yes, I realize there has been abortive attempts at this in the past, which only means the problem is non-trivial. |there is no need to "reverse engineer" all those aspects to get good |performance out of a Unix OS. The OS has the freedom to figure out |which parts of the application are needed and have those in memory, |with the rest loaded in on demand. This also reduces initial startup |time since the whole program doesn't need to be loaded into memory |before it starts to execute. if the program is sufficiently small and |the computer's memory is sufficiently large, the whole program can sit |in memory with no problems or hassles of segments. I agree that traditional flat address spaces works good for traditional program code. So do segmented architectures. They both fall down in terms of object-oriented code, and object store. Flat verses segmented doesn't impact load on demand, memory residency etc. These issues are the same on both architectures. Both architectures have problems if if patterns of code usage or memory usage is not constant and well clustered. |i agree that it is beneficial to cluster objects and code that |reference each other in the same pages to reduce the page faulting in |a virtual memory machine. it is not that crucial, however, since we |don't have to worry about crossing segment boundaries and the OS will |figure out which pages it needs (the working set). Crossing segment boundaries is not an issue since typical object size is much smaller than segment size, and thus objects can simply be placed by memory allocators so as to not cross segment boundaries. The ability to order the addresses of a billion bytes is not terribly important when the size of a typical object is 100 bytes or so. And even within that object, the ability to order the addresses of those 100 bytes is seldom needed. |the only reason Intel sticks with the idea is the amount of investment |they have in it and all those little pee-cee's out there that need |backward software compatibility. though this is an admirable goal, |there comes a point when you just have to cut your losses and go with |a better idea. The Intel 80x86 line has supported flat model "Unix" style programming for some years, in addition to maintaining segmented support for backwards compatibility, so you cannot fault Intel on those grounds. They also support an interesting 16:32 segmented mode that could be used for transparent programming across multiple workspaces, tagged pointers, etc. The fault on these issues is not the Intel hardware, but rather in the software support that lags -- due, as you point out, to the needs of supporting a couple million customers out there with software running in segmented architectures. One might well wonder when some other old CPU architectures will move beyond 0:32 pointers, and in what manner. Will they move to 0:48 or 0:64 pointers, if so, how will they maintain instruction set compatibility? Or will they move to a 16:32 multiple workspace "segmented" architecture? [New CPU designs do not restrict themselves to a 32 bit address space] If you want to fault Intel, do so for the pitifully small number of registers they put in their machines, or the short-comings of their risc CPUs :-)