[boost] Re: Determining padding

From: Andy Glew (glew_at_[hidden])
Date: 2000-01-19 18:21:22

> We're still making some assumptions:
>   The compiler pads all classes using the same algorithm, meaning: it makes
> each class at least a certain number of bytes (the same number for all
> classes), and does not pad classes that don't need it.  This second
> statement can be tested by (sizeof(empty_known) == sizeof(empty_helper_t2)).
> The first statement cannot be reliably tested, but is reasonable to assume.

Coincidentally, I have been trying to persuade Intel's compiler's to pad
only contextually, violating your first assumption.

("Trying to persuade" here means that I visit the compiler writers (I'm an architect
for Intel in my real life), showing them the performance costs of their
conservative alignment, etc.)

For example, 
        struct a { char a, b, c; }
needs no alignment at all in its own regard. It can stay 3 bytes.

struct aa[100] doesn't need alignment, but calculating array indexes
is simplified if it is rounded up to 4 bytes in size. So, because the assumption
that  (char*)(&aa[i]) ==  (char*)(aa) + i * sizeof(a) is unfortunately widespread,
we have to pad *all* occurrences of aa.  Other languages don't need such
conservative padding, but Gresham's law applies to ABIs...

Overall, this suggests that the rule to use is to round a struct
up to the nearest power of 2, if less than a certain critical value A,
and then to pad to a multiple of A.

Currently the critical alignment value of A is 64 bits.
KNI / SSE strongly encourages it to become 128 bits
- if the compiler ever wants to use the 4x32 bit floating point vectors.
And then there's the usual cache line alignment, at 16 and 32 bytes,
and soon to become 64 bytes.

Overall I suspect padding will *not* be as uniform as you hope.

Legacy ABIs are the biggest thing favouring your simple rule.