Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbatt!ihnp4!ptsfa!styx!ames!oliveb!sun!cuba!mmp
From: mmp@cuba.UUCP
Newsgroups: comp.arch
Subject: Re: 64 Vs 32
Message-ID: <18035@sun.uucp>
Date: Tue, 5-May-87 07:28:11 EDT
Article-I.D.: sun.18035
Posted: Tue May  5 07:28:11 1987
Date-Received: Thu, 7-May-87 01:12:13 EDT
References: <3810013@nucsrl.UUCP> <28200016@ccvaxa> <1316@ames.UUCP> <751@instable.UUCP>
Sender: news@sun.uucp
Lines: 32
Summary: linear addressing versus base+offset addressing

In article <751@instable.UUCP>, amos@instable.UUCP (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!
>
If you replace 32 for 64, and 16 for 32 in the argument above,
you would be very close to the argument that Zilog put up for
years to justify their going with a base+offset addressing
scheme, rather than the linear addressing scheme that the
MC68000 designers chose.

In case you haven't noticed: Zilog lost.  They lost the argument
(they've since incorporated 32-bit addresses into their
architecture), and they lost the market opportunity (they were
first with a working 16/32 micro, which was also incorporated in
the first non-DEC Unix machine, the Onyx something-or-other and
later in a couple of Plexus models).

You have to be very careful in optimizing the important thing
and not the "obvious" thing.


____________________________________________________
* Matt Perez *   sun!cuba!mmp  (415) 691-7544
DISCLAIMER: beisbole has bean bery, bery guud too me