Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!ames!pioneer!lamaster From: lamaster@pioneer.arpa (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: 64 Vs 32 Message-ID: <779@ames.UUCP> Date: Mon, 16-Mar-87 15:58:29 EST Article-I.D.: ames.779 Posted: Mon Mar 16 15:58:29 1987 Date-Received: Tue, 17-Mar-87 03:40:35 EST References: <3810013@nucsrl.UUCP> <1308@ucbcad.berkeley.edu> <205@dumbo.mips.UUCP> Sender: usenet@ames.UUCP Reply-To: lamaster@pioneer.UUCP (Hugh LaMaster) Distribution: na Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 67 Keywords: 64 bit architectures In article <205@dumbo.mips.UUCP> hansen@mips.UUCP (Craig Hansen) writes: : > >I'd be interested in hearing opinions on the necessary sizes of both virtual >and physical address spaces for machines over the next five to ten years, >both per-process and per-system. (Without trying to color the responses, my >personal view is that per-system physical addresses will have to grow beyond >32 bits on high-end machines within five years, and that virtual addresses >(per-process) will have to go beyond 32 bits in the same time frame.) > >Looks like memory is becoming cheap and memory addressing is becoming dear... : First a statement of personal bias: Most of the machines that I have done numerical computing on for the past 15 years have been CDC and Cray; with single precision floating point precision of 60-64 bits. The Cyber 205 has full 32 bit support, but as "half precision". Most of the work that I have done is either engineering and scientific numerical computing, or support of people doing the same. Therefore, I have always seen the world as a 64 bit world for DATA, with 32 bits when you could get by with it and needed it to do a larger problem. It is my experience that 32 bits is not sufficient often enough (for floating point, which is what I usually think about), that 64 bits is a much more natural word size. Actually, I have also used Burroughs 48 bit word machines, and in some respects 48 bits is really the natural single precision word size for many floating point problems. However, it is very inconvenient (for those of us who need to move binary data over a network between machines of different types) not to have the basic word size a power of two, and 64 bits is the next convenient size. It is also my observation that there are already machines being built today for which 32 bits/byte addresses are at the limit. The Cray-2 has 256 MW of 8 byte, 64 bit, words = 2GB, and the next version will have 512 MW. Within 4 years, 4 Mbit memory chips will be commonplace and 16 Mbit may be available, so a machine with 32-128 GB is likely. Therefore, physical memory will probably be beyond the 32 bit limit, even for word addresses, on high end machines, within 5 years. Furthermore, there are plenty of applications for memories this size, so don't assume that no one will know what to do with them if they are available. One machine that I have used which has a very large linear address space is the Cyber 205, which has 48 bit addresses (and 48 bit integers) which fit inside 64 bit words (the other 16 bits is used for something else-vector length). These 48 bit addresses are actually bit addresses (a feature that I wish more machines had - bit vectors are very useful) so the machine is capable of addressing about 2 trillion words per process, enough for the next five years, but maybe not for the next fifteen years. Large linear address spaces are practical and in use today. Finally, there is the internal data path size. On the Crays, this is 64 bits. On the Cyber 205, this is 512 bits (a "super-word"). Some machines with caches use 64-128 bits, even with 32 bit words. So an internal data path size of 64 bits or more is certainly useful. Therefore, for my purposes, I would like to see the next generation of architectures use 64 bits for data and 64(or 63) for (preferably bit, not byte or word) addresses. There shouldn't be any architectural reasons for limiting physical memory size to less than 2**63 bits. The internal data path size should be flexible, 64 bits to 512 bits, depending on the implementation, size of the processor, and cache considerations. Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "In order to promise genuine progress, the acronym RISC should stand for REGULAR (not reduced) instruction set computer." - Wirth ("Any opinions expressed herein are solely the responsibility of the author and do not represent the opinions of NASA or the U.S. Government")