Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!lamaster
From: lamaster@ames.arpa (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: More than 32 bits needed where?
Message-ID: <4611@ames.arpa>
Date: 9 Feb 88 19:15:48 GMT
References: <235@unicom.UUCP> <28200089@ccvaxa> <3104@watcgl.waterloo.edu> <4340@ames.arpa> <1333@vaxb.calgary.UUCP>
Reply-To: lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster)
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 57

In article <1333@vaxb.calgary.UUCP> radford@calgary.UUCP (Radford Neal) writes:

>
>Why is everyone assuming that if you want greater than 32 address bits
>you need 64? My guess is that 48 (or maybe even 40) bit addresses will
>be used. If you assume that memory is dominated by such addresses, or


Actually, it is extremely important in a networked world for word sizes
to be a power of two bits long.  As someone who has spent a considerable
amount of time maintaining code to move data between machines of 
various sizes (in my case, DEC and IBM 8 bit byte/32 bit word machines
and CDC 60 bit word machines), and helping users convert data written
on one such machine to another, etc. etc., I can say with complete
conviction:

Word size (or the size of any addressable data) should ALWAYS be a 
power of two.

In addition to making life much easier for those who have to move
binary data between machines (and with NFS, there are a lot more
such people out there), it also makes it much easier to move CODE
between machines.  Yes, I have converted bit-level code from IBM's
to Cyber 170's and back to 8 bit machines again.

Now, theoretically, 48 bit machines are great.  The address size is
very nice and 48 bits is probably perfect for SINGLE PRECISION
floating point (as has been observed by many people, 32 bits is too
small for many f.p. problems), and 96 bits is probably perfect
for double precision.  However, I stand by my previous judgement
that the money you save in memory with a 48 bit word size you will
pay back many times in programming costs. 

>
>Now I can see the flames coming on this one... How increadibly short
>sighted! History shows that we *always* need more address bits... Please
>calculate the amount of memory addressable with 48 bits, then ask whether

>Of course, there are other reasons for wanting long addresses, than just
>access to physical memory. If you want sparse address spaces, typed
>pointers, ring brackets, whatever, more power to you (MULTICS already
>has *72* bit pointers...)

The ability to support sparse address spaces is useful now and will be
even more useful in the future when capability based systems become
commonplace- It is a natural idea to support "objects" using virtual
memory "segments".  With 2**31 segments, each one of which is 2**32
bits or bytes long, it would be very natural to map an object to a
segment and be able to support many segments.  As well as shared virtual
memory without using up all of your precious address space.

As far as I know, the only thing holding back 64 bit word machines
in the micro world is the difficulty of getting enough pins into the chips
with enough chip area left to do something useful.  

The question I have, since the 64 bit alternative seems to controversial, is:
Are there any OTHER reasons for NOT using 64 bits?