Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!csinc!rpeglar From: rpeglar@csinc.UUCP (Rob Peglar) Newsgroups: comp.arch Subject: Re: 64 bits--why stop there? Summary: Bits and Bytes. Message-ID: <225@csinc.UUCP> Date: 29 Aug 90 14:56:30 GMT References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <631@array.UUCP> Organization: Control Systems, Inc., St. Paul MN Lines: 42 In article <631@array.UUCP>, colin@array.UUCP (Colin Plumb) writes: > In article meissner@osf.org (Michael Meissner) writes: > > IMHO, the 64 bit machine should represent all addresses in bits, not > > bytes (and yes this will probably break those programs which do int > > arithmetic on pointers -- but those are probably in the miniority). > > Before people lynch me, let me explain, that I think that the > > addresses that are not appropriately aligned should trap. > > Strong agreement. There's something fundamentally ugly about byte addressing > when the bit is the "true" least addressible unit. The fact that we've gotten Even stronger agreement. Speaking from experience on such a machine (true bit addresses), one has to deeply consider the relationship between compiler and OS code where byte addressing is taken for granted. sure, the compiler generates the address (bit) of byte n as 0x100 (say) and byte n+1 as 0x108 (for example); the real pain reveals itself in the numerous occasions where either the OS code or an application assumes integer = pointer. you just can't add one to the above example (0x100+1 = 0x101) and assume byte n+1 lives at that address (0x101). this kind of subtlety caused us the most pain in the development cycle. Rob Rob Peglar uunet!csinc!rpeglar -- Rob Peglar Comtrol Corp. 2675 Patton Rd., St. Paul MN 55113 A Control Systems Company (800) 926-6876 ...uunet!csinc!rpeglar