[Scummvm-devel] Wii & Gamecube (resp. PowerPC) vs. unaligned memory access

Max Horn max at quendi.de
Sun May 8 15:50:12 CEST 2011


Hi folks,

thanks for the valuable comments. To summarize what has been said, and draw some conclusions:

1) besides the unaligned access issues, we maybe aliasing problems with our endian.h macros
2) we have code that works around that in GCC 4.x, but that is only used if "_need_memalign=yes".
3) we do not have similar code for other compilers, including GCC 3.x, clang, MSVC, Intel's, ..
4) detecting whether unaligned access works with our current test code in configure won't work in general.

Regarding 1: We rely on casts that violate aliasing rules in *tons* of places. So besides all else, we may want to recommend to all porters to add -fno-strict-aliasing, or even automatically add that to CXXFLAGS (when using GCC or any other compiler supporting this).
Any reason not to do so?

Regarding 2: It seems that this means we should tweak endian.h, switching the "#if !defined(SCUMM_NEED_ALIGNMENT)" block starting in line 155 with the "#elif defined(__GNUC__) && (__GNUC__ >= 4)" block starting in line 175. Correct? If people agree, I'll do that in my branch.

Regarding 3: According to some googling, the "may_alias" attribute has been around since GCC 3.3 (and "packed" since 2.x). Any reason we restrict this codepath in endian.h to GCC 4.x ?
And out of curiosity, why the trick with the packed struct (a comment in endian.h explaining that would be helpful for future generations, too ;).

Anybody know what the status here is with regards to clang, MSVC, ICC, ... ? 

Regarding 4: I have removed the code test from my branch. Right now, it sets _need_memalign=no for x86, and =yes for everything else.



Bye,
Max



More information about the Scummvm-devel mailing list