bit-field pointers / arrays

[Walter Bright]

In article <3811 at utcsri.UUCP> greg at 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?