Member Avatar for Allasso

Hello,

I have observed that when generating assembly code from simple C programs using GCC, the stack is initialized as follows:

pushl   %ebp
movl    %esp,  %ebp
andl    $-16,  %esp

my question concerns the last instruction where -16 is anded with the stack pointer. Am I correct in assuming that this is for proper memory alignment for 32 bit data? If so, then why not -4?

I have also observed that in a simple program I have written that compares data in memory, byte by byte, removing the said instruction significantly slows down the process. If this has to do with memory alignment, then I don't understand why it would have an affect since I am accessing bytes in memory individually anyway.

Thank you,

Allasso

  • 3 Contributors
  • 4 Replies
  • 106 Views
  • 4 Days Discussion Span
  • Latest Post Latest Post by Tight_Coder_Ex

Dani AI

Generated

Short answer: the compiler is rounding the stack pointer down to a 16‑byte boundary so it can rely on 16‑byte alignment for local buffers and optimized code paths. was partly right that locals play a role, and correctly spotted that the instruction is a rounding/mask operation rather than a simple allocation. is also correct that compiler switches affect this behavior.

Why 16 bytes (not 4)? Modern compilers and libc often use vector/SSE code or word-sized moves to speed up loops and library routines (memcmp, memcpy, etc.). Those fast paths work best — and in some cases require — 16‑byte alignment for aligned load/store instructions. A 4‑byte alignment is fine for scalar 32‑bit accesses but won’t let the compiler safely emit aligned vector instructions. Even code that "looks" byte-by-byte can be auto‑vectorized or replaced by a vectorized library call, so removing the alignment forces slower unaligned or scalar fallbacks and produces the slowdown you measured.

How to control and verify:

  • Ask GCC to change its alignment with -mpreferred-stack-boundary=4 (2^4 = 16 bytes) or force per-function realignment with -mstackrealign.
  • Ensure local buffers that must be aligned use __attribute__((aligned(16))) or allocate with posix_memalign.
  • Inspect generated code with gcc -O2 -S file.c or objdump -d and look for vector instructions (aligned vs unaligned variants).

Cautions: the compiler only emits the aligned variants when it can guarantee alignment. Also note ABI differences: x86-64 mandates 16‑byte alignment at call boundaries, so behavior is not identical between 32-bit and 64-bit builds. When tuning, measure with real workloads (perf/valgrind) rather than assuming single changes will always help.

Recommended Answers

All 4 Replies

Member Avatar for Ancient Dragon

Would have to see the C code but most likely the -16 is allocating 16 bytes on the stack for local variables, such as four 4-byte integers.

Edited by Ancient Dragon because: n/a
Member Avatar for Allasso

did you notice that is "and", not "add"? It is zeroing out the four least significant bits in the stack pointer.

Edited by Allasso because: n/a
Member Avatar for Ancient Dragon

Sorry, no I didn't notice that. My error.

Member Avatar for Tight_Coder_Ex

It is different, and yes probably has something to do with alignment, but without seeing code in its entirety and more importantly the switches your passing to GCC it's hard to say why this is happening.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.