stassen@trwspp.UUCP (09/11/84)
[] I just stumbled across bit fields in K & R. I've seen a lot of C code, and written a lot as well, but have never seen these used. It seems to be a useful feature of the language, yet there *must* be some good reason for not using bit fields... So, if you have the time, I would appreciate a note containing the answers to a short "survey" on bit fields. If there is enough interest, I will post the results - otherwise, I will mail results to anybody who asks for a copy. (1) Have you used bit fields? (a) Why or why not? (b) (If Yes) What have you used them for? (2) Where have you seen them used (in someone else's code)? Thanks for your time if you take it. If you want to flame me, please do so via private mail. ------------------------------------------------------------------------------ The opinions expressed in this document are my own. They are not intended to reflect the views of my employer - TRW - or anyone else. ------------------------------------------------------------------------------ Christian W. Stassen [decvax!trwrb,vortex,ihnp4!vortex]!trwspp!stassen "If we knew what the hell we were doing, then it wouldn't be research."
lcc.barry@UCLA-LOCUS.ARPA (09/18/84)
From: Barry Gold <lcc.barry@UCLA-LOCUS.ARPA> I suspect a lot of people don't use bit fields because, like me, they've been bitten by compilers that turn out awful or even WRONG code for them. The weirdest I ever saw, though, was the Oracle C compiler for the 370, delivered to sdcrdcf's 4331 in September 1982. If you tried initializing an auto structure (prohibited in V7), it wouldn't produce any diagnostics, but would put the generated data into the TEXT section right after the subroutine entry code. This resulted in some INTERESTING program behavior--especially the time the data happened to work out to valid instructions. But, if the structure was defined with bitfields, it would initialize it correctly--by generating the code to initialize each bitfield individually. This was neither fast nor compact, but WAS correct. It also had a code generation problem which is fairly common in naive compilers (I've seen it in JOVIAL, too). Every access to a bitfield was treated as though you were going to do arithmetic on it or assign it to an int; it would be loaded into a register, masked off, and shifted into the low order bit. THIS, even if you only wanted to test a one bit field for zero/non-zero (there's an instruction to do that on the 370). EVEN if the one bit field was in the sign bit! (It could be worse: the JOVIAL I saw masked off bitfields by shifting them to the high order end of the word, then shifting back to the low order end. Never heard of the AND instruction, I guess.) barry gold
qwerty@drutx.UUCP (09/20/84)
We have used bit fields in dealing with hardware interfaces that are mapped into non-byte or non-word segments (ie. a couple of bits here, five bits there kind of things). They have turned out to be very useful. I have also used them as a form of compressed storage where I needed a lot of true/false states - you can get 16/32 to a word. There can be significant time wasted doing this if your underlying hardware does not support bit testing/manipulation.
ron@brl-tgr.ARPA (Ron Natalie <ron>) (09/22/84)
The Oracle C compiler can't even do simple things in C correctly, so I wouldn't hold out for them to be able in doing bit fields. We logged more than one hundred unrelated bugs in that compiler ranging from production of incorrect code, unimplemented things, misparsings, etc... For real fun, declare a variable R12. -Ron
phil@RICE.ARPA (09/22/84)
From: William LeFebvre <phil@RICE.ARPA>
C'mon guys! I'm surprised no one has mentioned this yet. On Berkeley
Unix (which is the only Unix I am familiar with), "ld" uses bit fields all
the time. The structure used to indicate an address that needs
relocation in an object file (a "struct relocation_info") has a bit
field declaration for one of the longs! Look at "/usr/include/a.out.h".
I guess no one out there has ever had to write a relocating loader for
Berkeley Unix.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.arpa>jejones@ea.UUCP (09/26/84)
/***** ea:net.lang.c / sri-arpa!ARPA / 6:38 pm Sep 21, 1984 */ (It could be worse: the JOVIAL I saw masked off bitfields by shifting them to the high order end of the word, then shifting back to the low order end. Never heard of the AND instruction, I guess.) /* ---------- */ Perhaps they wanted to turn them into signed integers? That's what I did when retrieving bit fields (unless they were wanted as unsigned quantities, or for comparison with zero--you pegged it on the needless overhead there) when I wrote a code generator. James Jones
ajrooks@watrose.UUCP (Alan Rooks) (09/27/84)
I have used bitfields in many applications using sets of binary flags. However,
I came across one type of problem in which their use is inconvenient. The
program was a maze generator, and i needed 4 bits for each cell, with bit i
stating whether there was a wall in direction i (i = up, down, left, right).
The problem came up when I had an int (or enum) variable, call it j,
specifying the direction number, and i wanted to check for the wall:
#define UP 0
#define DOWN 1
#define LEFT 2
#define RIGHT 3
switch(j) {
case UP:
iswall = maze[x][y].up;
break;
case DOWN:
iswall = maze[x][y].down;
break;
case LEFT:
iswall = maze[x][y].left;
break;
case RIGHT:
iswall = maze[x][y].right;
break;
}
... when i could do it this way if maze[x][y] was just an int:
iswall = (maze[x][y] & (1 << j)) != 0;
... or even simpler,
#define UP 1
#define DOWN 2
#define LEFT 4
#define RIGHT 8
iswall = (maze[x][y] & j) != 0;
... which is nice and simple. The problem exists because i want to be
able to index my bits, and C bitfields don't give you a way to do that.
Like I said however, i have found them very useful in other applications.
Alan Rooks at the University of Waterloo; ...!utzoo!watmath!watrose!ajrooks