From: SourceForge.net <no...@so...> - 2011-07-07 06:55:57
|
Feature Requests item #3354045, was opened at 2011-07-05 03:39 Message generated for change (Settings changed) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3354045&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: BsAtHome (bsathome) Assigned to: Nobody/Anonymous (nobody) >Summary: Dense packing of bitfields Initial Comment: The sizeof a structure with uint32_t bitfields yields the wrong size; see example. $ sdcc-sdcc --version SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0 #6037 (Jul 5 2011) (Linux) The 3.0.0 version is build from Fedora 15 repo backported to F13. Version 2.9.0 has same error. Commandline used: $ sdcc-sdcc -mpic16 -ppic18f66j65 --obanksel=2 --pstack-model=small --fomit-frame-pointer -I. -I /usr/share/sdcc/non-free/include/pic16 -c -o t.o t.c -- Start code (t.c) --- #include <stdint.h> #include <pic18fregs.h> struct __test_t { union { struct { uint32_t a:12; uint32_t b:9; uint32_t c:3; uint32_t d:8; }; uint32_t all; }; } var; uint8_t x, y; void bla(void) { x = sizeof(var); y = sizeof(var.all); } --- End code --- The assembly generated yields: _bla: ; .line 20; t.c x = sizeof(var); MOVLW 0x05 BANKSEL _x MOVWF _x, B ; .line 21; t.c y = sizeof(var.all); MOVLW 0x04 BANKSEL _y MOVWF _y, B RETURN The sizeof the structure __test_t is 5 instead of 4, which does not play well with complex aligned structures. -- Greetings Bertho ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2011-07-07 08:55 Message: Moving to feature requests, since this is apparently not a bug. Weshould discuss this further before deciding on implementing though, since there is a data size vs. code size and speed trade-off here. Philipp P.S.: You shouldn't use uint16_t for bitfields, as it's not required by the standard, and could fail on systems where uint16_t is not typedefed to unsigned int. AFAIK the only bitfield types required by the standard are bool, unsigned int, signed int. Plain int will work, too, but is not guaranted to be signed when used for bitfields. ---------------------------------------------------------------------- Comment By: BsAtHome (bsathome) Date: 2011-07-05 15:46 Message: The standard C99 6.7.2.1#10 says nothing about bytes, but about storage units. Although the standard leaves room for interpretation here, it would seem to be logical (read: other compilers seem to do so) to use the storage size of the primary type, which is 32bit in the example. I submit that there is some ambiguity involved here whether to use the platform's native size or the size of the used type. As you already mention errors in large bit-fields, I found out the hard way that a related problem exists for uint16_t bit-fields, where the content is screwed up. So, for now I'm dropping the bit-fields and revert to ugly defines. I'd love to see the compiler to make large bit-fields work, because it makes life much more easy in implementing protocol stacks (doing TCP/IP right now). Anyway, thanks for the pointers and a speedy reply. -- Greetings Bertho ---------------------------------------------------------------------- Comment By: wek (wek_) Date: 2011-07-05 14:36 Message: Strictly speaking, this is not a bug. As per C99 6.7.2.1#10, the compiler is free to move a bitfield into next byte if it won't fit into the remaining bits of a byte, and that's what happens here between .a and .b. For the particular case of PIC16 target, there might be a fix available, see the following post: http://sourceforge.net/mailarchive/message.php?msg_id=12702824 ... although I don't know whether this will actually work - my sdcc version 3.0.2 #6517 says: "SDCC pic16 port error: the port currently does not support *reading* bitfields of size >=8. Instead of generating wrong code, bailing out..." --- I've just submitted a related feature request, https://sourceforge.net/tracker/?func=detail&aid=3354256&group_id=599&atid=350599 Jan Waclawek ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3354045&group_id=599 |