mikegonta wrote:
LtG wrote:
mikegonta wrote:
Please
don't pack already "packed" structs.
I think that's pretty bad advice. Even based on your article, if this happens to be on x86 or x86_64 then there's no harm done and
you've clearly marked the need for packing, ...
I should have mentioned that the
advice was for GCC x86/x64. One of the nice things in "C" is the assignment of one
struct to another.
The only
harm is that, GCC for example, will use a complex (and unnecessary)
memmove to ensure that most of the copy loop is aligned
for better performance. Of course, you need some sort of directive (
#define, etc.) to prevent the compiler from optimizing non-aligned
on device structures, However, packing is unnecessary when the on device
struct (for example the exFAT BPB) is already
packed (that is,
all
struct components are on size alignment) GCC will (for example with
-march=i486) simply initialize the 3 required registers and do
a
rep movs.
LtG wrote:
on other platforms the compiler presumably does the right thing to ensure correctness.
On other platforms (ARM, MIPS, etc.)
structs should not be used because of
endedness and RISC optimizations, use
unsigned char arrays instead.
Is it guaranteed that without "packed" the compiler will not add padding? Isn't it implementation specific? Granted most likely no sane current compiler would add padding, but do you want to rely on that?
Even if it were guaranteed, and this is my main point, I'd mark it as packed to explicitly convey my intent. If the compiler is bad and does something stupid then you should fix the compiler.
I guess the question is, why does GCC do a complex and unnecessary "memmove" instead of "rep movs"? Can't you tell the compiler the alignment?
Note, with a proper language (which C adheres to some extent) the compiler is going to assume that it can do what ever it wants with internal stuff and only maintain external stuff in a compliant way. This allows a proper compiler to do optimizations more freely. Here GCC is going to assume the struct is properly aligned, is there a guarantee that it comes that way from some 3rd party (the OS?) always?
As I said, I'd rather do things correctly and fix the issue where it is (GCC), though obviously fixing GCC optimizer might be too difficult in which case I might consider a hack but then I would at least add comments..