Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!pacbell.com!pacbell!rtech!ingres!llama!daveb
From: daveb@llama.Ingres.COM (here kitty, kitty...)
Newsgroups: comp.arch
Subject: Re: 64 bits, but for what?
Message-ID: <1990Aug13.165618.9547@ingres.Ingres.COM>
Date: 13 Aug 90 16:56:18 GMT
References: <1990Aug11.203944.10478@nlm.nih.gov> <1990Aug13.065744.13208@Neon.Stanford.EDU>
Reply-To: daveb@llama.Ingres.COM (here kitty, kitty...)
Distribution: na
Organization: Ingres Corporation, Alameda, CA
Lines: 22

andy@Theory.Stanford.EDU (Andy Freeman) writes:
>
>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?)
>
>-andy

I'll leave the 32 vs 64 bit instruction argument for other zealots.  

Once you have a 64 bit data address space, you clearly want a 64 bit PC. 
The main reason for 64 bit data addresses (in this discussion) was
handling large data sets by completley merging the i/o with the VM
system.  The natural way to load code in this model is also to map them
somewhere into the address space (with appropriate access controls) and
point the PC at the right place.  A 32 bit PC would complicate that a
lot.

-dB
"Bottom of the 4th, Cooper pitching"	- tibetan baseball
David Brower:  daveb@rtech^H^H^H^H^Hingres.comd