Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!pioneer!lamaster
From: lamaster@pioneer.UUCP
Newsgroups: comp.arch
Subject: Re: 64 Vs 32
Message-ID: <1347@ames.UUCP>
Date: Wed, 22-Apr-87 19:27:38 EST
Article-I.D.: ames.1347
Posted: Wed Apr 22 19:27:38 1987
Date-Received: Fri, 24-Apr-87 04:14:30 EST
References: <3810013@nucsrl.UUCP> <28200016@ccvaxa> <1316@ames.UUCP> <1071@osiris.UUCP> <751@instable.UUCP>
Sender: usenet@ames.UUCP
Reply-To: lamaster@ames-pioneer.arpa (Hugh LaMaster)
Distribution: world
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 60

In article <751@instable.UUCP> amos%nsta@nsc.com (Amos Shapir) writes:

>To increase  flexibility, processors that  can access 64  bits of
>addressing will  probably do it  the old fashioned way:  by using
>one word (32  bits) as a base address, and  another as an offset.
>There's no point  in dragging all 64  bits everywhere, especially
>since  processing   is  usually   localized  among   clusters  of
>addresses.
>
>Also  keep  in  mind  that  future processors  will  have  to  be
>compatible with older programs -  the programs we are writing now
>on 32-bit address machines!
>-- 


I disagree with this completely.  If you need more than 32 bits, you need real
linear addressing on the more than 32 bits.  I take the history of attempts at
such extensions as my evidence: the PDP-11 was probably the most successful of
these extended architectures, but even it increased the usable address size
only modestly.  This style of extending the addresses is also used on the
80386, but people seem to be underwhelmed. 

The installed customer base argument could always be used to justify never
changing the architecture.  If we took it seriously, all current machines
would be upwards compatible with the IBM 650.  Only IBM really has the kind of
customer base that will accept half a loaf for the sake of upward
compatibility.  

The real question is: when will enough customers need this capability that you
can afford to build a product to meet their needs?  Once you decide when that
is, you need a product ready or you will never be able to get your share of
the market.  

I argue that we will need more than 32 bits within 4 years on
minis/mainframes.  Since within 4 years micros should be able to support a
mainframe architecture, I would argue that you should be planning a 64 bit
micro-to-mainframe architecture now, so that you can begin implementation 3
years from now.  

One might argue that at least one more generation of specifically
microprocessor architectures will be necessary before microprocessors 
can support mainframe architectures.  However, I understand from friends that
that there may indeed be machines out there with half a million gates.  If
true, it is enough gates to implement a mainframe, or even a supercomputer.

If you plan the next micro architecture a little more ambitiously,
you will be able to address customer needs further into the future without
either kludge extensions or yet another architecture switch.


  Hugh LaMaster, m/s 233-9,  UUCP {seismo,topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

"In order to promise genuine progress, the acronym RISC should stand 
for REGULAR (not reduced) instruction set computer." - Wirth

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")