Tuukka Toivonen wrote:
> I have understood that on some new x86 CPU (which one?) data should be
> aligned at 16 byte boundary.
Some data. Specifically the SSE vector floating point values, which are
16 bytes long.
> We were talking about stack -- but I can not
> see any reason the same restriction wouldn't apply to all data. And if it
> applies to double -- which is much less than 16 bytes -- I can not see
> either any reason why it wouldn't apply also smaller units of data, like
> float, int or even char (in C terms).
>
> So the conclusion is that if you have a character array
> char data[10];
> it would be beneficial to allocate 160 bytes memory for this to achieve
> greatest speed of execution.
No, that's not correct. It might achieve the greatest execution speed
if you access only one of the characters, and very, very rarely under
special circumstances. Being so rare it wouldn't be worth doing.
n
> And this doesn't quite make sense for me. Always before a data sized n
> (which I assume to be an integer power of 2) has been best aligned at
> n byte boundary[1].
That's the recommendation yes. Except the different recommendations
apply to code alignment.
The reason GCC 2.95 aligns stacks to 16 bytes by default is because of
the 128 bit SSE vector floating point values. Which hardly anyone uses :-)
enjoy,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:19 EST