Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site oakhill.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!wjh12!talcott!harvard!seismo!ut-sally!oakhill!davet
From: davet@oakhill.UUCP (Dave Trissel)
Newsgroups: net.micro
Subject: Re: 4->8->16->32->64? bit micros
Message-ID: <280@oakhill.UUCP>
Date: Sun, 16-Dec-84 14:52:50 EST
Article-I.D.: oakhill.280
Posted: Sun Dec 16 14:52:50 1984
Date-Received: Tue, 18-Dec-84 02:16:16 EST
References: 
Reply-To: davet@oakhill.UUCP (Dave Trissel)
Distribution: net
Organization: Motorola Inc. Austin, Tx
Lines: 90

In article <707@ames.UUCP> eugene@ames.UUCP (Eugene Miya) writes:
>
>1) We probably will have 64-bit micros, contrary to what some people
>belived.  I think there are several reasons for this:
>a) ..........

It may seem logical that 64-bit architectures will eventually become dominant
since progressions have gone from 8-bit to 16-bit and then 16-bit to 32-bit.
However, I think the extension to 64-bits will not generally occur.

Technology plays a part, of course.  Ten years ago it would have been
literally impossible to build a 32 bit architecture on a single chip.
Today with 200,000 devices on a chip there could certainly be designed and
built   64-bit implementations. But I think there are other, more important
factors involved in deciding the size of an architecture.

If you look at the early 8-bit architectures all registers were only 8 bits.
Of course an 8 bit address bus only accessed 256 bytes of memory.This quickly
became a limiation and was removed by supplying higher addressing bits with
a so-called "page" register which the programmer would setup whenever he/she
wanted to access a different 256 byte page in the external memory space.

The next improvement was to actually implement one or more 16 bit registers
to assist in larger memory space accesses.  Examples being the Z80 and the
MC6800.  Note, however, that the 16 bit registers were only practically
usefull for addressing purposes.  Neither could do other than very primative
data operations such as increment and decrement by one in the 16-bit regs.
Almost all data manipulations were 8 bits in size and only worked in 8 bit
registers.

Next we find the introduction of chips such as the 8088/8086 which
provide 16-bit registers and operations for not only addresses but
data as well.  In fact that chip family provided a method to access
more than just the 16-bit address space via an enhancement to the
page register scheme called segment registers.

Now, why have 32-bit micro architectures evolved?  Primarily because the
16 bit ones could not efficiently handle 32-bit data and the larger than
64K address space.  The early MC68000 chip allowed a linear addressing range
of 16 Megabytes and provided almost a full range of 32-bit operations.  These
were all due to the fact that it implemented a full set of 32-bit registers
both for data and addresses.

Lets examine now the potential extension to 64 bits.  I would suggest that
the criterian will be the same.  If there are data types (address or data)
which will not effectively operate in a 32-bit register environment then
there will be a push for a larger than 32-bit architecture.

Concerning data types, there is only one I can think of that would merit
more than 32-bits: the floating-point number.  Most architectures which
support floating-point offer both a 32-bit (36-bit or whatever) single
precision along with a 64-bit (or whatever) double precision format.  Clearly
64-bit general purpose registers would be the propper support for a
double format.  Most architectures, however, provide a completely different
set of registers for floating-point operation.  Thus, they need not be the
exact same size as the general purpose data and address registers and can
provide for the larger sizes of the floating data type. Now this may not
be as good as having TRUE general purpose  registers which would allow
floating-point as well as all other operations but it seems to be
adequate enough.

As for addressing more than a 32 bit memory space there are several
alternatives.  One is the 8087/8086 method of segment register extension
to the address.  Another is to support virtual memory which would potentially
allow each user task or process access to its own 4 gigabyte address space.
The one of interest here, however, is the support of a     more-than-32-bit
linear address space which would be ideally implemented with more-than-32-bit
registers, thus providing the push for a 64-bit register architecture.

There are a lot of finer points that can be made in this discussion but I
believe the bottom line boils down to  the requirement of supporting data
or addresses of more than 32-bits in size.  I simply do not find much
interest around for either.  The floating-point users seem quite content
to have thier own unique set of registers for floating-point support.
Likewise, although most system designers are demanding a completely linear
and large addressing space they seem more interested in using virtual memory
facilities or a larger partitioning scheme to oversee the individual 32-bit
spaces involved.

I would think that in the realm of large-scale number crunching you would find
the most interest in a 64-bit architecture.  But I also believe that outside
that area there are not very many applications which require more than a
4 Gigibyte address space that 32-bit registers provide.

It would be interesting to hear other viewpoints on the net, especially from
those that are already using 64-bit (or large) architectures or are
investigating same.

Motorola Semiconductor                           Dave Trissel
Austin, Texas            {ihnp4,seismo,ctvax,seismo}!ut-sally!oakhill!davet