Altivec + 16 byte alignment

[Spundun Bhatt]

On Wed, 2003-02-12 at 09:26, Gianni Tedesco wrote:
> On Tue, 2003-02-11 at 22:33, Spundun Bhatt wrote:
> > On Tue, 2003-02-11 at 10:57, Franz Sirl wrote:
> > > At 19:32 11.02.2003, David Edelsohn wrote:
> > > > >>>>> Franz Sirl writes:
> > > >
> > > >Franz> If changing STACK_BOUNDARY doesn't affect binary compatibility, I will
> > > >Franz> submit a patch to set it to 128 in rs6000/linux.h.
> > > >
> > > >         The patch will be wrong and not accepted.
> > > 
> > > Uhm, wrong in which way? Would you mind to explain this a bit?
> 
> I think because the efficient way to do it is for the caller to always
> keep the stack aligned. eg: initial stack pointer is aligned to 16 bytes
> and all functions make sure their stack frames align to 16 also.
> 
> If you have functions with smaller aligned stack and then they call the
> altivec functions then the altivec function would have to look at the
> stack pointer and align it by hand, which would require a conditional
> branch, argh.
> 
Ofcourse you are right. This means that this trick wont work if used in
a library code if the library is used with an older gcc compiler which
doesnt support this bigger alignement. Also wont work if used for
callbacks with the library using the callbacks not suppoirting this
bigger alignement... and may be many other such instances. 
While this does say that there will be a binary incompatibility between
gcc versions... this incompatibility will only be for this wider
alignement issues. This doesnt in *any* way seems to break backward
compatibility. In general whenever a new feature is added to a software,
the new feature is not supposed to work in the older versions but the
backward compatibility needs to be preserved.. right? 
So I think Franz' question is still up in the air.... Unless ofcourse, I
didnt get your point
Thanx 
Spundun
> I guess...
> 
> HTH.