-
Code: [Select]
#include <stdio.h>
typedef struct
{
unsigned long aadata; /* 4 byte */
unsigned char aasign; /* 1 byte */
unsigned char aasign2; /* 1 byte */
} my_t;
my_t my;
void my_size()
{
printf("size=%lu byte\n", sizeof(my_t));
printf("size=%lu byte\n", sizeof(my));
}
int main()
{
my_size();
return 0;
}Code: [Select]size=8 byte
size=8 byte
4+1+1 = 8
It seems it is aligning by 4 bytes, but it should not be a common default on linux-PC/x86
what is happening ? -
This can differ from compiler to compiler, but a guess is this: my.aadata is aligned on 4-byte boundaries because it is 4 bytes long. If you were to create an array of my_t, this would require two bytes of padding to be added to the struct to maintain this alignment for subsequent array elements, so it is added. In other words, the struct is padded to a multiple of the alignment of its most coarsely aligned member.
-
The compiler is adding some padding so the struct aligns at suitable boundaries. Otherwise you could end up with inefficient memory accesses.
There may be a compiler switch to prevent this behavior. -
Code: [Select]
#include <stdio.h>
#pragma pack(push)
#pragma pack(1)
typedef struct
{
unsigned long aadata; /* 4 byte */
unsigned char aasign; /* 1 byte */
unsigned char aasign2; /* 1 byte */
} my_t;
#pragma pack(pop)
my_t my;
void my_size()
{
printf("size=%lu byte\n", sizeof(my_t));
printf("size=%lu byte\n", sizeof(my));
}
int main()
{
my_size();
return 0;
}Code: [Select]size=8 byte
size=8 byte
4+1+1 = 8
It seems it is aligning by 4 bytes, but it should not be a common default on linux-PC/x86
what is happening ?
Try with the lines I added, it's an alignment thing.
Edit: maybe stdio includes a header that sets the packing to 4, or it might be the default packing of the compiler.
Edit2: but you might want to leave it as 4 and live with it, data fetching is more efficient at the processor's default alignment. -
By the way, this behavior is quite common, normal and expected. But it may perhaps be considered a "trap for young players".
-
understood
i am using these gcc version on my x86 laptop, they both have the same behavior
[1] i686-pc-linux-gnu-4.1.2 *
[2] i686-pc-linux-gnu-4.4.5
also tested on arm/le machine with
[1] armv5tel-softfloat-linux-gnueabi-4.1.2 *
[2] armv5tel-softfloat-linux-gnueabi-4.3.4
what is the switch to avoid padding ? -
what is the switch to avoid padding ?
Read the documentation?
BTW, unless you are mapping to hardware addresses, you don't want to avoid padding. The compiler knows what it is doing. -
"trap for young players".
i was expecting something like in an embedded metal bare profiled toolchain with a linker file which forces alignment
MIPS has a bad reaction if you access to a data-address which is not good alignment, there are special instructions in MIPS ISA in order to access on misalignment data instead of accessing data with load/store (1) but they are not suggested to be used, btw, never considered on linux machine
(1) which causes a bus exception, so you need an exception routine that fixes the problem, and about that, linux has the properly exception routine code while a bare bone firmware (e.g. the early releases of Yamon) may not have it, so this is the reason why you force a bare bone linker script to be good aligned for the must! -
I guess you missed it on my previous post
#pragma pack(push) // Store current packing.
#pragma pack(1) // change to one byte packing.
typedef struct
{
unsigned long aadata; /* 4 byte */
unsigned char aasign; /* 1 byte */
unsigned char aasign2; /* 1 byte */
} my_t;
#pragma pack(pop) // restore packing to previous setting.
-
mapping to hardware addresses
it's exactly what i am doing, unfortunately, then i got the unexpected behavior, so i isolated the "sizeof" code and i found what it is wrong!
I think i will use a pretty ugly array of uint8_t (of the right size) to short up the story
-
I guess I'm on legacy's ignore list
-
@miguelvp
your pragma hints is perfectly working on both x86 and arm linux machines
thank you
-
I guess I'm not in your ignore list after all
You are welcome. But f you deal with an array of your struct there will be data fetching penalties. Processors pre-fetch data and miss-alignments will stall the pre-fetch queue. for for some structures you might not want to force it to 1 byte alignment.
But for single instance structs there will be no penalty so you are good.
-
Also... if you want any semblance of consistency in variable sizes, DON'T USE PLATFORM DEPENDENT SIZES.
What's "long"? Since the 386 days, "int" was 32 bits, so "long" must be 64. So your struct should actually be 10 bytes (assuming packed).
But what if "char" is Unicode? If it's UTF-16, your struct swells to 12 bytes!
Maybe you copy the interface code to something embedded, like an Arduino. Now "long" is 32 or even 16 bits (I don't know offhand).
Solution: always use (u)intNN_t types (NN = 8, 16, 32, etc.). Your struct should be,
uint32_t aadata;
uint8_t aasign;
uint8_t aasign2;
Now it is guaranteed to always take the same number of bytes (assuming identical packing, of course), and guaranteed to have the same numerical range, on any platform.
(Yes, always writing these types is a pain, but you can typedef a whole lot of things for handy namespacing.)
Tim -
@miguelvp
you are welcome, too
while you was posting i was trying your patch on both machines, x86 and arm, with different gcc versions
umm, so complex CPUs of now a days, that is the price we have to pay
i have also been developing a very simple RISC processor which has no issues like that, no fetching penalties, it's like the first MIPS R2000 but much more simple because it has no pipeline, so it's more like 68000, very pretty to be programmed.
Unfortunately i am now dealing with an hyper complex Atom/x86 and with a pretty XScale-PXA270 arm processor (it's old, but my bos want it for his reasons), and they are both pipelined.
btw, i have fixed the issues with the radio link! Everything is working and i can commit everything out
-
Also... if you want any semblance of consistency in variable sizes, DON'T USE PLATFORM DEPENDENT SIZES.
yes, in my final code i have pretty #include "types.h" in where i defined everything i am using.
i was not expecting this behavior, I have found a bug in my code, then, to be sure it was a gcc problem, i "searched and replaced" my typedefs replacing them with C standard definitions, and to be more sure about the problem i have also removed every other includes (stdio.h and others) to be really really sure it was a padding or something like that.
Thank you guys, the bug has been completely demystified
-
i am using these gcc version on my x86 laptop, they both have the same behavior
[1] i686-pc-linux-gnu-4.1.2 *
[2] i686-pc-linux-gnu-4.4.5
also tested on arm/le machine with
[1] armv5tel-softfloat-linux-gnueabi-4.1.2 *
[2] armv5tel-softfloat-linux-gnueabi-4.3.4
That looks like eselect. O0 -
Consider #include <stdint.h>; it has uint8_t, uint16_t, uint32_t, int8_t etc. defined. It doesn't get much clearer than unsigned/signed + bit width.Also... if you want any semblance of consistency in variable sizes, DON'T USE PLATFORM DEPENDENT SIZES.
yes, in my final code i have pretty #include "types.h" in where i defined everything i am using.
In addition to struct packing; that can be dangerous on some platforms if I'm correct. I believe x86 is pretty forgiving in that it will be slightly slower in accessing memory but will do it.
Some platforms like ARM can choke on packed structs:
http://infocenter.arm.com/help/topic/com.arm.doc.dui0473c/Cihdbfje.htmlQuoteOn some ARM processors, you can enable alignment checking. Non word-aligned 32-bit transfers cause an alignment exception if alignment checking is enabled.
If all your accesses are aligned, you can use the --no_unaligned_access command line option, to avoid linking in any library functions that might have an unaligned option.
Nevertheless you can turn checks off, the hardware will not correct for it and may result in incorrect behavior.
-
understood
You can use something with packed-structs or assign an attribute to the variable using the array declaration. Still I strongly recommend to avoid using packed structs. ARM for example can access a 32 bit value only from addresses dividable by 4. If the compiler isn't sure where a struct is it will divide a 32 bit access into single bytes accesses and build the 32 bit value from that. It will make your code bloated and slow.
i am using these gcc version on my x86 laptop, they both have the same behavior
[1] i686-pc-linux-gnu-4.1.2 *
[2] i686-pc-linux-gnu-4.4.5
also tested on arm/le machine with
[1] armv5tel-softfloat-linux-gnueabi-4.1.2 *
[2] armv5tel-softfloat-linux-gnueabi-4.3.4
what is the switch to avoid padding ? -
You can also design the struct for the platform (unportable code, no, of course not!... ), so, say, using uint32_t for the size number, then a uint32_t for flags which just happens to include the two byte-size things you had, plus either "reserved" (unused) bits, or even part of the next variable, if applicable. This way, instead of, say, checking byte variables (which are compiled as 32 bits anyway) for individual values and flags, you check the same 32 bit variable for more flags. That way, you're handling the same 32 bits as exactly that, 32 bits, and the compiler output follows much more closely from your input -- which helps reduce misunderstandings when inspecting the disassembled output, and misunderstandings between compiler and platform limitations when you do run into weird or unexpected behavior.
Or if it's not random flags, but the bytes are actually numeric, you can byte-slice them into variables at the point of use (which can be in a variable, or an inline expression like "(int8_t)((var & 0x0000ff00) >>
" or whatever), and let the compiler decide how it's going to approach that (32 bit processors often have byte and nibble swapping or selecting instructions). On very advanced processors, you'll even have the luxury of packed (SIMD) instructions, which if you're doing the same actions to all the bytes, can save even more execution time.
The resulting code should still be portable, but will be suboptimal on other platforms. Applying full-width bitmasking operations on uint32_t variables on an 8-bit processor would be simply dreadful. So if you're well and truly designing the code for multi-platform use, maybe you'd add #ifdefs for different cores or WORD sizes or whatever. Which would be a little easier to maintain than separate implementations altogether, but not by much.
Tim -
Nevertheless you can turn checks off, the hardware will not correct for it and may result in incorrect behavior.
An alignment exception doesn't mean incorrect behaviour just that it will incur a performance penalty.
which of course you don't want. But for a single instance like his code there will be no exception since the packing gets restored and other variables will still be aligned, the struct packed as one byte has no internal missalignment either and with or without the packing pragma the two bytes left will be unused either way only difference being that it will report the actual struct size.
-
Quote
What's "long"? Since the 386 days, "int" was 32 bits, so "long" must be 64.
No, "long" is generally 32 bits, unless your compiler makes plain "int" 64 bits.
"long long" is what you want for 64 bits.
The rule is that char ? short ? int ? long ? long long with minimum sizes char = 8bits, short and int = 16 bits, long = 32 bits and long long = 64 bits.
The reason as usual is history. On 16 bit platforms "int" could be 16 or 32 bits and you generally had to say "long" to get 32 bits. Then 32 bit platforms came along and "int"" became 32 bits, long also stuck at 32 bits for compatibility with older software written for long = 32 bits. long long was introduced as the "guaranteed 64 bit" type.QuoteAn alignment exception doesn't mean incorrect behaviour just that it will incur a performance penalty.
On x86 you just get poor performance, on many RISC architectures you get a bus error which can result in your process being terminated with prejudice
-
Depends on the platform, some platforms will halt on an unaligned read(AKA don't do that).Nevertheless you can turn checks off, the hardware will not correct for it and may result in incorrect behavior.
An alignment exception doesn't mean incorrect behaviour just that it will incur a performance penalty.
which of course you don't want. But for a single instance like his code there will be no exception since the packing gets restored and other variables will still be aligned, the struct packed as one byte has no internal missalignment either and with or without the packing pragma the two bytes left will be unused either way only difference being that it will report the actual struct size.
It's also worth noting that bitfields have similar undefined issues as the compiler is free to reorder where they are placed. -
Then stay away from MIPS and some ARM chips, problem solved
In any event, the code:Code: [Select]#pragma pack(push) // Store current packing.
#pragma pack(1) // change to one byte packing.
typedef struct
{
unsigned long aadata; /* 4 byte */
unsigned char aasign; /* 1 byte */
unsigned char aasign2; /* 1 byte */
} my_t;
#pragma pack(pop) // restore packing to previous setting.
Wont cause misalignment, if some obscure chip can't handle it, the compiler will surely scream at you.
Instances of my_t will be aligned and everything is well.
But let me know by all means a processor that doesn't support #pragma pack(1)
-
It's also worth noting that bitfields have similar undefined issues as the compiler is free to reorder where they are placed.
Also I would like to know what compiler doesn't support unions of larger data types with bitfield descriptions and why will a bit field of 0 be part of C if the compiler can reorder it and don't force a storage alignment.
Maybe endianness might be confusing to some, but then they have no place in using bitfields in the first place.