Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!ssbell!mcmi!dsndata!wayne From: wayne@dsndata.uucp (Wayne Schlitt) Newsgroups: comp.arch Subject: Re: 64-bit addresses Message-ID: Date: 11 Feb 90 22:55:29 GMT References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <11112@encore.Encore.COM> <753@dgis.dtic.dla.mil> Sender: wayne@dsndata.UUCP Organization: Design Data Lines: 94 In-reply-to: jkrueger@dgis.dtic.dla.mil's message of 11 Feb 90 18:15:13 GMT In article <753@dgis.dtic.dla.mil> jkrueger@dgis.dtic.dla.mil (Jon) writes: > > Are 64 bit spaces being held back by hardware: complexity, fabrication, > critical paths? Or software (what we used to call systems software): > virtual memory operating systems that can give processes 64 bit virtual > spaces at acceptable cost? [ blatant opinion warning ] i believe, and i have been saying it for about 5 years now, that 64 bit computers are not going to be common for a _long_ time to come. (5 years ago when 32 bit micros started to become available a fair number of people were real excited about when the 64 bit micros were going to be here and wondering if they should skip the 32 bit micros and wait for the 64 bit micros. *gack*) of course before you can argue about when 64 bit computers are common, you must first define what a "64 bit computer" is, and what it means to be "common". to me, a computer system has become common when you can buy a usable system for less than $10k. i believe the different parts of the computer will become "64 bit" at different times. the following is a list of the parts that i can think of and blatant guesses about when i expect them to become 64 bit. integer registers (ALU) 20-30 years floating point regs 64 bit now, 128 bit in the next 3-10 years. you will never see more than 128 bits. address registers 10-20 years virtual address space the 386 has a 48 bit virtual address space via segments now, but that's only because it was segmented to begin with. other architectures like the 68k and most risc's will be forced to have segment registers in the next 5-15 years. HPPA (HP's risc) have them now. physical address space 2-5 years for 48 bit, 5-20 for a full 64 bit. data path 64 bit memory paths would be used to fill caches quicker, but you might see harvard style separate 32 bit data and instruction paths coming off chip first. from the software point of view, this is the _least_ noticeable and when it will come around depends on how well chip designers are at getting lots of pins on the chips. instruction path see data path the reason for all of this is simply practicalities. 8 bit cant hold the time of day. 8 bit computers didnt last that long. 16 bits are much better, but lots of numbers go beyond 5 digits and 64k is much too small for program code. 64k isnt too bad for array sizes, but it gets in the way fairly often. 32 bits can hold the income in pennies of 99% of companies in the world. very few programs need more than 4 gigabytes in either code or data. sure you can do things like mapping your 20 gig of disc into memory, but do you _really_ need to? this all gets back to the risc idea of studying what you really need and seeing if the extra stuff will slow you down. although i am not an expert, i would be willing to bet that 64 bit paths, registers and ALU's are going to be _very_ expensive in terms of chip area and speed. you are going to see a lot more benefit from making 32 bit computers faster than by making 64 bit computers. using a regular 32 bit computer you can do 64 bit adds and subtracts quite quickly using two instructions instead of one. 64 bit shifts are a little bit harder depending on your instruction set, but on the 68k it only takes about a dozen instructions. 64 bit multiplies and divides are slow, but hey, they are going to be slow anyway. most of the multiplies are going to be for array indexing anyway and you can get around that via shifts, either explicit or implied. i just dont believe that 64 bit flat address spaces are going to be here any time soon. in order to have a flat 64 bit address space you are going to have to be able to do 64 bit address manipulation, which means 64 bit ALU's and registers. for the few times that you really need 64 bits, you are putting a very large burden on the rest of the system. even now, the 386 is most run in 16 bit mode and people are living with it long after it has become a problem. the reason why they are living with it is because of all the software that can actually run and be useful in 16 bit's (and 20 bits of addressing). just think about how much software there is going to be when 32 bits is starting to run out of steam. ibm mainframes use 32 bits, and have been for 20 years and i dont see too much push for a full 64 bits computer even there. (mainframes do have 64/128 bit data paths and such, but from the software's point of view, that doesnt make any difference). i would love to see some more _fact_ to confirm or refute my arguments. these are mostly gut feelings that i have had for a long time. -wayne