Article View: comp.arch
Article #22356Re: 64-bit addresses
From: Wayne Schlitt
Date: Sun, 11 Feb 1990 22:55
Date: Sun, 11 Feb 1990 22:55
94 lines
5591 bytes
5591 bytes
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
Technical Details
Message-ID:
<WAYNE.90Feb11165528@dsndata.uucp>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!ssbell!mcmi!dsndata!wayneReferences:
<9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <11112@encore.Encore.COM> <753@dgis.dtic.dla.mil>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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: <WAYNE.90Feb11165528@dsndata.uucp> 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