Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!ames!pioneer.arc.nasa.gov!lamaster From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: 64 bit addresses Message-ID: <1991Feb15.202041.19852@news.arc.nasa.gov> Date: 15 Feb 91 20:20:41 GMT References: <1991Feb13.212041.14368@news.arc.nasa.gov> <1991Feb14.183045.16468@watdragon.waterloo.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: 75 In article <1991Feb14.183045.16468@watdragon.waterloo.edu> tbray@watsol.waterloo.edu (Tim Bray) writes: >lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes: >>mh2f+@andrew.cmu.edu (Mark Hahn) writes: >>>Just think of the added overhead in pointer-linked structures! >>What is the ratio of pointers to other data in typical "small" programs? (The answer provided). >... starting to crunch into 32-bit >boundaries on non-exotic real-world problems, so the extra addressing bits >will be extremely welcome. The price will be a dramatic increase in physical >memory consumption. Mea culpa. My bright-eyed, bushy-tailed optimism punctured by two examples which need the large address space, and, are *very* pointer dense. >Two questions: > o as a software developer currently bruising my head against 32-bit issues, > should I: > (1) bite the bullet and write a segmented scheme which will run > portably (if suboptimally) on 32-bit systems, or : It appears to me that this would benefit from segmentation at some level. > (2) sit tight and wait for rescue-by-recompilation on the R4000 et al? : >>complications. 8 Bytes is just not that precious anymore. Only if you >>have arrays of millions of objects should you compromise on simplicity. > >But we do, sigh, lots of us do. This brings up another idea that has appeared in the past, and, may again. "Segments" (warning, segments mean many different things to different folks) have developed a deservedly bad reputation as a way to *extend* an address space which is *too small*. But, another use of segments is as a way of efficiently providing *compact* access to a nice large address space. This method of access has occasionally been provided. It may be time to explore it again, particularly as it may be a way to provide *efficient* access to tagged/object-oriented/capability/etc type functionality. While I am convinced that segments are no way to extend an address space which is too small, in fact, I think that alternative methods of generating addresses using segment number + offset are, in fact, potentially quite useful. One of the problems that people experience with this is the assumption that segments have to be a fixed, architecture-determined size. In fact, it is possible for segments to be an arbitrary power of two in length, with hardware support. This is a solution, though, which adds hardware to the TLB (and therefore is potentially "expensive"- nobody likes to add real estate to the TLB in single-chip designs). I think you will be able to do this in software with little overhead, as long as you can put limits on both the number of objects and the maximum size of each object. For example, no more than 2^^32 objects of no more than 2^^32 bytes in size. If you can, then the space expansion may be minimal. On the other hand, if you can't place such limits, I think that will pay the price of a full 64 bit address for each object. >Cheers, Tim Bray, Open Text Systems, Waterloo, Ontario Cheers, 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 #include