Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-unix!ctnews!pyramid!prls!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.arch
Subject: Re: 64 Vs 32
Message-ID: <2120@mmintl.UUCP>
Date: Tue, 28-Apr-87 18:58:31 EDT
Article-I.D.: mmintl.2120
Posted: Tue Apr 28 18:58:31 1987
Date-Received: Sat, 2-May-87 08:14:11 EDT
References: <3810013@nucsrl.UUCP> <28200016@ccvaxa> <1316@ames.UUCP> <1071@osiris.UUCP> <751@instable.UUCP>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Distribution: world
Organization: Multimate International, E. Hartford, CT
Lines: 25

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.

Unfortunately, some of those processors undoubtably will do this.  I am
convinced that there is no *good* way to do this; any scheme for addressing
which uses addresses shorter than the address space size is a horrible
kludge.

>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!

Which is why machines being designed now should have 64 bit addressing as
the architectural limit.  One of the best things IBM did was to use a large
address size in the 360 (at the time, 24 bits was regarded as ridiculously
large) -- this enabled them to go 20 years with the same architecture.

Don't design the architecture for today's hardware.  Design it for next
decade's.

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108