On Tue, 10 Sep 2002, Patrik Stridvall wrote:
While compiling the latest tree, I get this:
[dimi@dimi wine]$ make -s In file included from ../../include/mssip.h:49, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported"
[...]
It seems that gcc or at least a previous versions of GCC didn't support it since somebody (Alexandre?) added a warning in pshpack8.h.
It may have been me. I think at the time it was only meant for gcc, which was the only things you could compile Wine with anyway. The specific version of gcc is 2.95, and but I'm really not sure the situation has changed.
It hasn't. GCC 3.1 has the same problem.
Futhermore Micrsoft C/C++ (or at least later version of it) contrary to the claim of pshpack8.h support it so it wrong at the point at least AFAIK.
Yes, Visual C++ supports alignment 8 which is the problem (so that defined(_MSC_VER) should have been moved elsewhere, just to avoid the warning in fact).
How we can handle such alignment issues in Wine whn compiled with gcc I'm not sure.
Neither am I. I have tested the alignment with various compiler and got the follow result:
- No GNU C compiler not even 3.1 support #pragma pack(8) nor does it support #pragma pack(16). It doesn't even give a warning. - MSVC 6.0 support #pragma pack(8) but not #pragma pack(16) - The Solaris compiler (old version) doesn't even support #pragma pack(4), but then 4 is the default so it doesn't really matter that much (except for a warning). It support #pragma pack(1) and #pragma pack(2) though.
So the conclusion is that only MSVC support #pragma pack(8), nothing else.
I'm totally at loss as to what to do. Not that it currently matters since the data structures isn't currently used but someday somebody will...
PS. I can't understand why GNU C doesn't support it, it can't be that difficult to implement can it? Nether the less that fact that it doesn't warn about it is even worse. That certainly can't be difficult to implement.
Patrik Stridvall ps@leissner.se writes:
I'm totally at loss as to what to do. Not that it currently matters since the data structures isn't currently used but someday somebody will...
Well, we need to add explicit padding in the structures to respect the alignment that MSVC uses. That should only be required at the end of the structures I think, so it's not too bad.
PS. I can't understand why GNU C doesn't support it, it can't be that difficult to implement can it?
Probably because it makes little sense on i386. I guess it might be supported on other CPUs.
Probably because it makes little sense on i386. I guess it might be supported on other CPUs.
Depends, some of the MMX and/or SSE/SSE2 instructions require data to be aligned to >4 byte boundaries.
David
On 10 Sep 2002, Alexandre Julliard wrote: [...]
PS. I can't understand why GNU C doesn't support it, it can't be that difficult to implement can it?
Probably because it makes little sense on i386. I guess it might be supported on other CPUs.
It does make sense on recent x86 processors, i.e. I think on anything from a Pentium and up. the reason is that these processors have a 64bit bus and thus accessing a 64bit value which is not 64bit aligned is slower because it requires two memory accesses.
At least that's what a Byte article claimed when Byt still existed as a magazine. They had found that MSVC's malloc of the time only returned a 32bit aligned pointer which caused a significant performance drop half the time when accessing a big array of doubles. Their workaround was to allocate a bit more and align the pointer themselves.
I'm not entirely sure how this plays over with the recent crop of CPUs that have 128 or even 256bit internal interfaces to their first level cache, and then 32byte cache lines, etc. But a 32byte pragma pack certainly seems excessive :-)
Anyway, that's why 8bytes is the default Visual C++ alignment when placing variables on the stack, retuning mallcated pointers and maybe even structure fields.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.
Patrik Stridvall wrote:
- No GNU C compiler not even 3.1 support #pragma pack(8) nor does it support #pragma pack(16). It doesn't even give a warning.
Well, GCC does support #pragma pack(8) and #pragma pack(16). They just don't do anything on i386, because they don't need to.
What #pragma pack(N) means is: if any structure member would require a default alignment > N according to the normal rules, reduce that alignment to N.
As on i386 no structure member ever requires a default alignment of > 8, #pragma pack(8) never needs to do anything.
You appear to think that #pragma pack(N) should sometimes *increase* some alignment requirement -- but it never does. Under what circumstances do you think it should?
Bye, Ulrich
-
Alexandre Julliard -
David Laight -
Francois Gouget -
Patrik Stridvall -
Ulrich Weigand