andy@Theory.Stanford.EDU (Andy Freeman) (08/13/90)
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?) -andy -- UUCP: {arpa gateways, sun, decwrl, uunet, rutgers}!neon.stanford.edu!andy ARPA: andy@neon.stanford.edu BELLNET: (415) 723-3088
<LEEK@QUCDN.QueensU.CA> (08/13/90)
In article <1990Aug13.065744.13208@Neon.Stanford.EDU>, andy@Theory.Stanford.EDU (Andy Freeman) says: > >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?) > Yes ! Make everything the same size. It makes life a lot easier to operate on the 64-bit registers. Yes ! 64-bit PC. By now everyone should have learnt the mistake that Intel made moving from 8080 to 8086/8088. >-andy >-- >UUCP: {arpa gateways, sun, decwrl, uunet, rutgers}!neon.stanford.edu!andy >ARPA: andy@neon.stanford.edu >BELLNET: (415) 723-3088 K. C. Lee "Make everything big enough to count all the atoms in this Universe." -me (Now if we store a few bits bits per atom...)
daveb@llama.Ingres.COM (here kitty, kitty...) (08/13/90)
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
cik@l.cc.purdue.edu (Herman Rubin) (08/15/90)
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)