Re: ABI & alignement: IA32

Code such as
    x=(double*)malloc((N+1)*sizeof(double))
does not fit well into a discussion of compliance with the part of an ABI to
which you refer, since the only data item on a stack is the pointer
  (declared as double *x; )
That entity must be align according to the
standard, and not that to which it points.


The pointer is on the stack, the thing it points to might not be.


In the posted code the area pointed to is allocated dynamically with
malloc. And the compliance reqs do not state that the syntactic
feature
    (double*)
of the larger code
    x=(double*)malloc((N+1)*sizeof(double))
needs to conform to anything.


I would conclude from the brief postings, that the parametric compiler
controls are mediating malloc()'s alignment. If you push the parms to
8-bytes, then all mallocs will be double word aligned (at some cost of
wasted space to mallocs of smaller items, possibly).


But that is distinct from alignment specifically for particular type
data items on the stack. The purpose of the standards is to achieve
some efficiency while getting programs to cooperate successfully.


For an item actually on the stack (and not malloc'ed from the heap) a
disagreement between a caller and the receiving code for the
displacement of the item would infact be a problem. So if the standard
says you can only have 4-byte alignment of 8-byte items, then 8-byte
alignment would not agree.(per data exchanged across a stack).


There is a trade-off. Getting the doubles to at least the 4-byte
boundary is a major improvement over byte or word (2-byte)
alignment. And it cost just a little, where as a standard of 8-byte
boundary alignment would, over the bigger picture be somewhat more
wasteful of stack space (relatively).


The backdrop of this is that if you have a lot of doubles (or long
longs) to manage, they should be in an array, that is they should not
actually be pushed. And the alignment of the array can be mediated
otherwise. The point is that you would not push the array, typically;
but instead just push the pointer to it. So the trade-off of a
4-byte, not so perfect, alignment is fairly good, and not too
wasteful.


The important thing to understand in considering your question about
the ABI is that callers and receivers must agree on the _displacement_
on the stack; as the compiling technologies try to optimize execution
speed.


So if I am not mistaken the answer to your question, "My question is:
does such a requirement implies that a compiler that pads the stack
(or whatever) to get an 8-byte alignment is not ABI compliant " is yes
the 8-byte alignment is _non-compliant_. For inidividual doubles
_pushed_ onto the stack.


But this answer only works if we take the "or whatever" out of the
discussion, and nail everything down.


Note that malloc() is distinctly controllable in compilers. And
although I do not know if GCC can do this fluidly, alignment of items
on your instantiating local stack (the autos) is an issue distinct
from the alignment of items pushed onto the stack for calls.


So to have it all straight in your head you would need a lawyers
comprehension of the three alignment compliances: heap alignment, auto
variable alignment, and inter-procedure stack item alignment.


Best Wishes
Bob Rayhawk
rayhawk@alum.calberkeley.org

Return to the comp.compilers page.
Search the comp.compilers archives again.