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

[Daniël Mantione]

Op Mon, 15 May 2006, schreef ???? ???????????:

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

This is true, an 32-bit processor has no advantage of 64-bit alignment of 
64-bit value, so it is open to discussion wether the compiler should 
really do this for 64-bit values.

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

If you read or write records, please declare them packed to disable 
alignment, so you don't need these ugly tricks.

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

Exactly. In the general case, it does improve performance, so the default 
setting is okay. If alignment is for one reason or another unwanted, the 
programmer can use preprocessor directives or declare the record 
packed and align manually.

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

Yes, if the longword is the largest type in the record (size 4), the 
record is padded to a multiple of 4.

> So this feature surely should be documented (at least for easier solving possible compatibility problems).

I agree.

Daniël