Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: 64 bits, but for what?
Summary: An instruction need not fill a word
Message-ID: <2430@l.cc.purdue.edu>
Date: 15 Aug 90 14:41:39 GMT
References: <1990Aug11.203944.10478@nlm.nih.gov> <1990Aug13.065744.13208@Neon.Stanford.EDU>
Distribution: na
Organization: Purdue University Statistics Department
Lines: 26

In article <1990Aug13.065744.13208@Neon.Stanford.EDU>, andy@Theory.Stanford.EDU (Andy Freeman) writes:
> In article <1990Aug11.203944.10478@nlm.nih.gov> states@tech.nlm.nih.gov () writes:
> >Let's assume that John Mashey is correct (he usually is :-) and that we
> >will soon see full 64-bit microprocessors.  You need 64-bits for alot
> >of floating point, something more than 32-bits would be nice for
> >adressing, sticking with factors of 2 in word size has advantages
> 
> 64 bit addresses, registers (and "natural" sizes for ints and floats)
> are one thing, but should the instructions grow to 64 bits at the same
> time?  How about the program counter?  (How fast are programs growing
> and how big are they now?)

The idea that an instruction must be as long as a word has been rejected
by many hardware manufacturers in the past.  The IBM 360 had 16, 32, and
48 bit instructions, but 32-bit words.  The CDC 6x00 had 15 and 30 bit
instructions (a few 60 bit ones), but all 30-bit instructions had an 18
bit address, and words were 60 bits.  The CRAYs have essentially 16 and
32 bit instructions, but 64 bit words.  The VAXen have k byte instructions,
where k has a huge range, including k=1.

There are advantages in having different sized relative addresses, but they
should not be as bad as some of the paged machines, such as the 8086.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)