Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!decvax!tektronix!uw-beaver!uw-june!entropy!dataio!bright From: bright@dataio.Data-IO.COM (Walter Bright) Newsgroups: comp.lang.c Subject: Re: bit-field pointers / arrays Message-ID: <1223@dataio.Data-IO.COM> Date: Mon, 22-Dec-86 20:37:00 EST Article-I.D.: dataio.1223 Posted: Mon Dec 22 20:37:00 1986 Date-Received: Wed, 24-Dec-86 20:47:59 EST References: <2937@bu-cs.BU.EDU> <321@bms-at.UUCP> <3811@utcsri.UUCP> Reply-To: bright@dataio.UUCP (Walter Bright) Organization: Data I/O - FutureNet Corp., Redmond, WA Lines: 25 In article <3811@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes: >Despite the difficulty, I would prefer that the compiler figures out >when to use [bitfield opcodes] from the mess of shifts and masks, rather than >by adding new types to the language. For one thing, this method >will allow bitfield ops to be used for shifts & masks that were >not specifically intended to operate on bitfields. > >Note that this solution adds several pages of code to the code >generator only on machines with bitfield ops, while the other solution >adds zillions of semantics checks, and other extra stuff *throughout* >the compiler, to the compiler on *all* machines. Hear, hear! (Actually, the compiler I wrote translates all bitfield operations into the appropriate shifts and masks. If I ever build a code generator for a CPU that has bitfield opcodes, I will use them by recognizing trees of shifts and masks.) The same argument applies to the register keyword. Tuning a function with register declarations is non-portable (the code is still portable, but the tuning is not). I think the compiler should stuff variables into registers automagically using some reasonable heuristic (many compilers already do this). Perhaps the XJ311 committee could be persuaded to make the register keyword an obscelescent feature?