Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!ucsd!ames!pioneer.arc.nasa.gov!lamaster From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: Swizzling (very RISC) instead of 64 bits (was Re: 64 bit addresses) Message-ID: <1991Feb14.020133.24909@news.arc.nasa.gov> Date: 14 Feb 91 02:01:33 GMT References: <1991Feb13.170045.16864@uicbert.eecs.uic.edu> Sender: usenet@news.arc.nasa.gov (USENET Administration) Reply-To: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Organization: NASA Ames Res. Ctr. Mtn Vw CA 94035 Lines: 80 In article <1991Feb13.170045.16864@uicbert.eecs.uic.edu> wilson@uicbert.eecs.uic.edu (Paul Wilson) writes: >I don't know if 64-bit addressing is a good idea in general, and I suspect : : : >anywhere. Going to 64-bit addresses would *double* your memory >requirements. There are much better ways to spend transistors. It's OK. Since you will need more than 32 bits to address the physical memory in your 1998-era personal computer, you haven't lost anything! 1/2 :-) >This scheme *can* support more RAM than the addresses specify, if you >use a kind of page-switched architecture. (A form of bank switching, >page-fault time. (This scheme is a recent development, and wasn't >in the tech report on swizzling that I sent out to a lot of people >who requested it.) [By the way, everybody who asked more than a >week ago -- 75 people! -- should have gotten it by now.] As far as I can tell, from your description, and, from the papers which you sent (thanks!), the maximum size of any particular object is, however, the maximum amount of virtual memory which you can map. This is fine for your applications, apparently, which consist of zillions of little objects, most of which are less than a page in size. But, it isn't fine for my user's applications, which require a few large objects, namely, linearly addressed arrays of 10-20% of the size of whatever physical memory is available. So, once physical memories are, say, > 10GB, you limit the size of the application that I can run artificially. Of course, there are techniques for addressing really large objects, but these always run into an efficiency problem when accessing arrays in multiple directions. (In other words, useless :-) >Even if you can afford 64-bit chips, you may not want them. A 32-bit >chip can probably be made faster, if only by using faster materials MIPSCo claims that it will do 64 bit address generations without penalty. Whether or not this turns into a real hardware product, there are machines in existence which require 3 cycles just to generate a *32* bit address. The penalty for 64 bits will probably be manageable. >I'm not really clear on what the "optimal" hardware address size is, >but I'd bet that for Lisp and Smalltalk, it's *not* 64 bits. For Smalltalk, it could waste some memory, based on your description of memory allocation, compared to the swizzled address scheme. The question to answer is: do you expect *only* a large number of small objects, or, do you need to handle the case of a small number of large objects efficiently, too? The history of computing is littered with the bones of segmented architectures, which could handle the first case just fine, but not the second, by the current standards of their day. Are *you* going to tell your users that they can buy a machine with 128 GBytes of memory, but the biggest array they can use is 4 GBytes? (128 GBytes is what I expect to see on a large machine built out of 64 MBit chips.) I wouldn't want to tell my users that! :-) >Of course, if you want a bunch of bits to specify a huge number of >addresses across a parallel machine, you may want larger addresses; Or, a "huge" number of physical memory addresses in a single machine. :-) What seems huge to one person is just a factor of two increase in resolution in a 3-D model to someone else... ****** P.S.: - Quote of the Day - "By 1995, a common desktop machine will have 1,000 MBytes of main memory, 1,000 SPECmarks of performance, 10,000 MBytes of secondary storage, a 100 MByte network connection, a homogeneous 64-bit address space, wide-area shared memory, and a vastly richer interface environment." John Gage and Bill Joy, Unix Today, Feb. 4, 1991 issue. Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 With Good Mailer: lamaster@george.arc.nasa.gov Phone: 415/604-6117