Florian has implemented a fix recently that allows for better memory alignment using $codealign - true though, I do think we need something to guarantee aligned memory from a function akin to GetMem, since one way or another, there is a performance penalty in using dynamic arrays over raw pointers (although it's not too bad).
Regarding the stack, when you first enter a function under x86-64, it is guaranteed to be 8 bytes away from a 16-byte boundary, because the stack is first aligned to a 16-byte boundary (Windows also allocates 32 bytes of shadow space, a multiple of 16), then the return address is pushed to the stack when you first call the function. However, normally the stack is then aligned to a 16-byte boundary, for any variables are put on the stack, because a stack frame is set up which includes pushing RBP to the stack. For Florian's fix though, any local variables are given the correct alignment on the stack, even if the stack is unaligned beforehand. Gareth aka. Kit On Fri 26/01/18 15:41 , "Adriaan van Os" [email protected] sent: > J. Gareth Moreton wrote: > > > Oh right. I see that you've opted to stick with > the $codealign compiler directive. True, no new feature > > should be required, and TM128 shouldn't need to > be redeclared by a third-party programmer. > > > > > In this case, I think this bug/feature report > can be closed now: https://bugs.freepascal.org/view.php? > > id=32780 - unless you want the 'align' suffix. > > > > I think two questions need to be answered, as there is more than just > global variables > > > 1. What is the status of alignment of the stack ? > > 2. I do think we need an alignment option in the FPC memory manager. Or at > least a runtime-function > that gets aligned memory, like > > <http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_ > memalign.html> > > > Regards, > > > > Adriaan van Os > > > > > _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
