[fpc-pascal] Memory alignment with FPC

[Jonas Maebe]

On 11 Oct 2012, at 13:59, dhkblaszyk at zeelandnet.nl wrote:

> I did some performance tests on win32 and it appears that
> both packed and unpacked objects and records all show exactly the same
> performance. Writing the individual variables in a record or object to
> file takes about 5.5 times longer than writing them at once. If  
> someone
> wants my test app to run it on other platforms please let me know  
> then I
> can post the code. I will do more testing later on mac and linux32.  
> I'm
> interested how win64 and linux64 behave in this respect. So if someone
> has these architectures please let me know.

As mentioned before, it not only depends on the platform, but also on  
the contents of the object/record. E.g., a badly misaligned double  
will generally give much worse performance even on Intel.

> This makes me wonder if
> choosing a proper value for $PACKRECORDS could make my file readable
> safely on all platforms, only needing to convert the endianess if
> applicable. This would not force me to do manual padding in my  
> structs.
> Say I use a value of 16 would that cover all ABI's FPC currently
> supports?

Yes.

> Jonas: do you have an overview of the alignment on all
> architectures that FPC supports?

The information is not just architecture-specific, but also OS- 
specific (e.g. the alignment of int64 is 4 on Darwin/i386, but 8 on  
all other i386 platforms). This is defined in the platform ABI  
documents (application binary interface).

> Perhaps you could pinpoint where in the
> compiler this is handled? If appreciated I could make a patch to  
> include
> this info in the documentation in the future.

It's a combination of tdef.alignment (and its overridden methods in  
compiler/symdef.pas), tdef.structalignment (idem) and the varalign  
information in compiler/systems/i_*.pas. And the latter information in  
turn can be overridden by the programmer with -Oa switch and the  
{$codealign ...} directive, or is sometimes also adjusted by us when  
e.g. new data types are introduced, when bugs are found or when  
support for a new ABI is added that has different requirements (some  
OSes support multiple ABIs).

I don't think documenting it in our manual is a good idea. It's not  
something people should depend on beyond what the official platform  
ABIs say, and those documents are maintained separately from our  
manual (and unfortunately seldom have stable URLs that can be referred  
to).


Jonas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20121011/0833aa73/attachment.html>