> Suppose you have an array of b. Then, with a size of 12, there would be no
> guarantee that an access to b.ab is aligned. So, the compiler pads the
> record to a multiple of the largest field.
>
> DaniКl
I didn't state that it's useless. It's just unexpected as it is.
The result is the same both with -O3r and -Og switches.
Setting processor to 386 (I don't think that such an alignment helps its
performance) doesn't change the result.
When I read record or something, I use
{$if sizeof(b)<>12}
{$fatal }
{$endif}
so it's not much of a problem (added to {$A1} etc).
1/2/4/8/16 alignment is not required by the processor architecture, it does not
always improve performance too. If needed programmer can control alignment
almost precisely with and {$a##} and {$if}.
Automatic longword alignment in some cases exists too (size of "record a:
longword; b: byte; end;" is 8). It appears even with longint type (as I
remember, it was in early [<5] versions of Turbo Pascal on 8086 or 8088, e.g.
[I know, that FPC does not support <32 width oriented models and absolutely
don't expect it to do it in the future]).
So this feature surely should be documented (at least for easier solving
possible compatibility problems).
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
