Ah whoops, misunderstood. Only for i386-linux, not i386-win32 as well.
Would there be benefits to aligning the stack on that platform as well
though?
Gareth aka. Kit
On 16/09/2019 13:32, J. Gareth Moreton wrote:
It's a useful feature as far as hand-written and generated assembly
language is
On Mon, 16 Sep 2019 at 14:58, Ben Grasset wrote:
> On Sun, Sep 15, 2019 at 1:36 PM Florian Klämpfl
> wrote:
>> In r43005 to 43014 I committed a couple of patches so FPC generates
>> stack frames aligned to 16 byte boundaries on i386-linux
>
> Good change! Means, for example, the long-standing is
On Sun, Sep 15, 2019 at 1:36 PM Florian Klämpfl
wrote:
> In r43005 to 43014 I committed a couple of patches so FPC generates
> stack frames aligned to 16 byte boundaries on i386-linux
>
Good change! Means, for example, the long-standing issues with popular
libraries like SDL2 on 32-bit Linux won
It's a useful feature as far as hand-written and generated assembly
language is concerned. The Intel SIMD instruction sets work far better
with aligned memory (e.g. you can use MOVAPS instead of MOVUPS, the
former being faster on older CPUs but triggering a segmentation fault if
the memory is
Am 15.09.19 um 19:35 schrieb Florian Klämpfl:
In r43005 to 43014 I committed a couple of patches so FPC generates
stack frames aligned to 16 byte boundaries on i386-linux (before a call
instruction, esp is dividable by 16). This is done because it seems that
linux library start to depend on thi
In r43005 to 43014 I committed a couple of patches so FPC generates
stack frames aligned to 16 byte boundaries on i386-linux (before a call
instruction, esp is dividable by 16). This is done because it seems that
linux library start to depend on this property gcc ensures for around 20
years. To