I have a an issue with gcc and I am looking for help. I am trying to use a library that was designed for a different environment on a RAM constrained cortex-M0 processor. The library itself makes extensive use of structures like the following (details removed to express the problem succinctly): struct { struct { int chan1; int chan2; } dma; int state; } X; By default, this takes up 12 bytes. But the range of possible values for these fields are very small. I would like to change it to the following: struct __attribute__(( packed )) { struct __attribute__(( packed )) { uint8_t chan1:2; uint8_t chan2:2; } dma; uint8_t :1; uint8_t state:3; } X; This structure should only take 1 byte. But it seems gcc is always padding out the dma structure to a full byte, and then placing the state field in a second byte. So my structure winds up with size 2. I have read everything on the net and have not yet found anything which would allow me to tell gcc not to pad the dma structure, or to align it on a nibble boundary. I am stuck with this structure. To change it would require changing it in hundreds of places of C code, and worse, redoing it every single time there was a library code update. This is doubling my RAM usage. If I could find a way to make gcc behave, then we could squeeze into a smaller part. Does anyone have any idea on a way to make the gcc compiler be more accommodating to my constraints? Thank you for any assistance.
Charles Zi wrote: > This structure should only take 1 byte. But it seems gcc is always > padding out the dma structure to a full byte, and then placing the state > field in a second byte. Yes, because it's a separate type. The dma struct is one bit field that must have a size that is a multiple of one byte. That doesn't change just because it is embedded into another structure with bitfield elements. > I have read everything on the net and have not yet found anything which > would allow me to tell gcc not to pad the dma structure, or to align it > on a nibble boundary. I don't think there a way to put bits of multiple bit fields together into one byte. > I am stuck with this structure. To change it would require changing it > in hundreds of places of C code, Then better start now ;-) > and worse, redoing it every single time there was a library code update. Why?
Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.