On 25 Jan 2000, H. Peter Anvin wrote:
> The native fp format on IA32 is "long double" -- 80 bits (10 bytes).
Yes, but this is not relevant here. The 10byte floating point is used in
practice only internally to the FPU. Yes, you can read and store it but
nobody does that, since it's so much slower than a normal float or double
(on Pentium, atleast).
I have understood that on some new x86 CPU (which one?) data should be
aligned at 16 byte boundary. 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. 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].
Is this really not the case anymore? With which Intel CPU? What about AMDs
and other clones? So that I can get the PDF and read myself :)
[1]Even this restriction has been more than enough, since on Pentium a 16
bit data is best aligned _anywhere_ inside 32 bit unit, ie., if you have
an int correctly aligned, you could read a short int containing any two
consecutive bytes in the int, and the short read would be correctly
aligned.
-
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:18 EST