Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site oakhill.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!wjh12!talcott!harvard!seismo!ut-sally!oakhill!davet From: davet@oakhill.UUCP (Dave Trissel) Newsgroups: net.micro Subject: Re: 4->8->16->32->64? bit micros Message-ID: <280@oakhill.UUCP> Date: Sun, 16-Dec-84 14:52:50 EST Article-I.D.: oakhill.280 Posted: Sun Dec 16 14:52:50 1984 Date-Received: Tue, 18-Dec-84 02:16:16 EST References:Reply-To: davet@oakhill.UUCP (Dave Trissel) Distribution: net Organization: Motorola Inc. Austin, Tx Lines: 90 In article <707@ames.UUCP> eugene@ames.UUCP (Eugene Miya) writes: > >1) We probably will have 64-bit micros, contrary to what some people >belived. I think there are several reasons for this: >a) .......... It may seem logical that 64-bit architectures will eventually become dominant since progressions have gone from 8-bit to 16-bit and then 16-bit to 32-bit. However, I think the extension to 64-bits will not generally occur. Technology plays a part, of course. Ten years ago it would have been literally impossible to build a 32 bit architecture on a single chip. Today with 200,000 devices on a chip there could certainly be designed and built 64-bit implementations. But I think there are other, more important factors involved in deciding the size of an architecture. If you look at the early 8-bit architectures all registers were only 8 bits. Of course an 8 bit address bus only accessed 256 bytes of memory.This quickly became a limiation and was removed by supplying higher addressing bits with a so-called "page" register which the programmer would setup whenever he/she wanted to access a different 256 byte page in the external memory space. The next improvement was to actually implement one or more 16 bit registers to assist in larger memory space accesses. Examples being the Z80 and the MC6800. Note, however, that the 16 bit registers were only practically usefull for addressing purposes. Neither could do other than very primative data operations such as increment and decrement by one in the 16-bit regs. Almost all data manipulations were 8 bits in size and only worked in 8 bit registers. Next we find the introduction of chips such as the 8088/8086 which provide 16-bit registers and operations for not only addresses but data as well. In fact that chip family provided a method to access more than just the 16-bit address space via an enhancement to the page register scheme called segment registers. Now, why have 32-bit micro architectures evolved? Primarily because the 16 bit ones could not efficiently handle 32-bit data and the larger than 64K address space. The early MC68000 chip allowed a linear addressing range of 16 Megabytes and provided almost a full range of 32-bit operations. These were all due to the fact that it implemented a full set of 32-bit registers both for data and addresses. Lets examine now the potential extension to 64 bits. I would suggest that the criterian will be the same. If there are data types (address or data) which will not effectively operate in a 32-bit register environment then there will be a push for a larger than 32-bit architecture. Concerning data types, there is only one I can think of that would merit more than 32-bits: the floating-point number. Most architectures which support floating-point offer both a 32-bit (36-bit or whatever) single precision along with a 64-bit (or whatever) double precision format. Clearly 64-bit general purpose registers would be the propper support for a double format. Most architectures, however, provide a completely different set of registers for floating-point operation. Thus, they need not be the exact same size as the general purpose data and address registers and can provide for the larger sizes of the floating data type. Now this may not be as good as having TRUE general purpose registers which would allow floating-point as well as all other operations but it seems to be adequate enough. As for addressing more than a 32 bit memory space there are several alternatives. One is the 8087/8086 method of segment register extension to the address. Another is to support virtual memory which would potentially allow each user task or process access to its own 4 gigabyte address space. The one of interest here, however, is the support of a more-than-32-bit linear address space which would be ideally implemented with more-than-32-bit registers, thus providing the push for a 64-bit register architecture. There are a lot of finer points that can be made in this discussion but I believe the bottom line boils down to the requirement of supporting data or addresses of more than 32-bits in size. I simply do not find much interest around for either. The floating-point users seem quite content to have thier own unique set of registers for floating-point support. Likewise, although most system designers are demanding a completely linear and large addressing space they seem more interested in using virtual memory facilities or a larger partitioning scheme to oversee the individual 32-bit spaces involved. I would think that in the realm of large-scale number crunching you would find the most interest in a 64-bit architecture. But I also believe that outside that area there are not very many applications which require more than a 4 Gigibyte address space that 32-bit registers provide. It would be interesting to hear other viewpoints on the net, especially from those that are already using 64-bit (or large) architectures or are investigating same. Motorola Semiconductor Dave Trissel Austin, Texas {ihnp4,seismo,ctvax,seismo}!ut-sally!oakhill!davet