[fpc-devel] data alignment and int64 (or qword, maybe any singlepiece of size 8 if any)

Пётр Косаревский ppkk at mail.ru
Mon May 15 14:42:36 CEST 2006


> 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).



More information about the fpc-devel mailing list