🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #22356

Re: 64-bit addresses

#22356
From: Wayne Schlitt
Date: Sun, 11 Feb 1990 22:55
94 lines
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!wayne
References: <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