Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ncrlnk!ncr-mpd!Chuck.Phillips From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) Newsgroups: comp.arch Subject: Re: 64 bits--why stop there? Message-ID: Date: 30 Aug 90 11:01:02 GMT References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <631@array.UUCP> <225@csinc.UUCP> <1372@svin02.info.win.tue.nl> <41188@mips.mips.COM> Sender: uucp@ncr-mpd.FtCollins Organization: NCR Microelectronics, Ft. Collins, CO Lines: 29 In-reply-to: mash@mips.COM's message of 29 Aug 90 20:36:55 GMT John> However, it is still clear that bit-addressing would break more programs John> than byte-addressing, so all I wanted was for someone to work through John> a complete example to show why it would be A Good Thing on balance. Yes, it would break a _few_ programs. (e.g. incrementing a pointer cast to an int or otherwise directly twiddling pointer bits) Adding a new type C type called "bit" (or boolean or logical etc.) should be orthagonal to existing correctly written C code, except for the added keyword. (void *)s and (char *)s _can maintain the old semantics_ and old correct code need only be recompiled after a character substition, if necessary. I think this would fall under your category "b". John> b) It's faster, cheaper, or smaller, and although it's different, John> its architecture+software make it easy to recompile lots of John> existing code with zero hassle. If implemented in hardware, bit addressing could provide faster bit access (bit read vs. byte read + mask + shift), and (at last!) a syntatically and semantically consistant way to access multi-word bit arrays. I'm _not_ suggesting this be added to ANSI C, but this could become a de facto standard as 64 bit machines become more common. #include -- Chuck Phillips MS440 NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com 2001 Danfield Ct. Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp