> Can PowerPC do unaligned accesses or not? We support two kinds of architectures:
unaligned strict alignment In reality, we could write kernel emulators and make every architecture be unaligned. In the worst cases of access, it would be extremely expensive. Making a powerpc act truly unaligned is very expensive. In general, it is much worse than aligning data in application software. There are processors which support a subset of "unaligned access", and kernel support must perform the other cases to complete the picture. For instance, reads will work, but writes won't. And access crossing a page boundary will return half crap, or you end up with atomicity problems. Like we told you before: treat powerpc like a strict alignment architecture. > The reality is that we *do* support unaligned accesses, at least > on the machines people test on. No, we don't. > sthen@ noticed when testing the > proposed port for snappy (Google's fast compression library) that > unaligned accesses work fine and is reluctant to disable them in > the port. No, the subset that is being generated in the code appears fine. Until it does a misaligned write over a page boundary. > I just noticed that archivers/xz also uses unaligned accesses on > powerpc and nobody has complained to me that it breaks. Stop that -- consider powerpc strict alignment. The only unaliged access architectures we run on are: i386, amd64, vax, and m68k. (Note: Even though we call them unaligned architectures, 3 of these 4 architectures have at least one aspect which requires alignement). If machine/endian.h defines __STRICT_ALIGNMENT, you have to consider the architecture strict alignment. In OpenBSD this means that at least one standard type needs to be aligned if it is in a structure. It might be an int, or a long, or a double... > I don't have a problem with disabling unaligned accesses in ports > on powerpc, but without errors we are unlikely to find all of them > and what's the justification then? We don't have support for a "sort of strict aligned, sort of not" middle ground. We could create all sorts of extra cpp symbols to indicate that, but I doubt it would not gain acceptance (or increase understanding). Knowing about strict alignment lets us be more clever in high level software, because we know that the worst case of unaligned memory access is astoundingly expensive on the platform. For instance, on an i386 unaligned read access might be 3-5 times slower and unaligned write access might be 5-9 times slower, but on another architecture those operatins might be a 1000x times slower for the "worst case". So it is better to do the alignment up front, in the application. On powerpc, the kernel will not help you for the worst case. Is that application code you have fine with that? I don't know. I doubt it. Read this: http://www.ibm.com/developerworks/library/pa-dalign/
