[fpc-devel] Stack alignment on i386

[Sven Barth]

Am 22.12.2011 15:57, schrieb Jonas Maebe:
>
> On 22 Dec 2011, at 15:40, Sven Barth wrote:
>
>> i386/Win32 should be adjusted then as well, because I suspect very
>> much that this is the reason for my problems with OpenCV... (on
>> Windows as well as on Linux)
>
>  From what I understand from
> http://msdn.microsoft.com/en-us/library/aa290049(v=vs.71).aspx, a
> function is required to align the stack to 8 or 16 bytes itself if it
> needs better alignment on win32. These links also all say the required
> alignment for win32 is 4 bytes:
> * http://msdn.microsoft.com/en-us/library/k1a8ss06.aspx : Some SSE types
> require eight-byte stack alignment, forcing the compiler to emit dynamic
> stack-alignment code.
> *
> http://old.nabble.com/ATLAS-on-win32,-pthreads,-SSE-and-stack-alignment-p19828585.html
> : in accordance win the Win32 ABI, only guarantees a 4-byte aligned stack
> * http://eigen.tuxfamily.org/dox/TopicWrongStackAlignment.html : this
> assumption can be wrong on Windows, where the stack is only guaranteed
> to have 4-byte alignment
>
> You should probably add the flag -mpreferred-stack-boundary=2 when
> compiling OpenCV for win32 using gcc:
> http://sourceforge.net/tracker/index.php?func=detail&aid=2170667&group_id=23725&atid=379483

While with OpenCV this issue might be solved by recompiling it (which 
I'd yet need to look into, because I'm simply using the provided 
binaries), what should be done about closed source code?

> Also keep in mind that switching to 16 byte aligned stacks for existing
> targets
> a) requires many assembler routines in the RTL to be disabled (or
> rewritten, but that was not done for Darwin/i386, in part because in
> many cases it can use faster libc equivalents anyway)
> b) will probably break quite a bit assembler code from existing
> programs, both written for FPC and for Delphi (unless "nostackframe;" is
> added, the compiler will add stack alignment code to assembler routines
> which may mess up hardcoded offsets or other assumptions)

Somehow this motivates me more to add a "stackalignment" modifier...

Regards,
Sven