4 ms·
Alignment is one of those interesting things, because x86 doesn't care so much about it... And everyone starts out assuming everything is x86. Meanwhile, ARM d
by octorian 8y ago
Alignment is one of those interesting things, because x86 doesn't care so much about it... And everyone starts out assuming everything is x86.
Meanwhile, ARM does care about alignment, and its now the most popular architecture for anything that's "not a PC".
My first experience with this was writing some smartphone code that died with a SIGBUS when trying to make a function call, where the reason was totally non-obvious from simply looking at the code.
- burfog 8y agoIf you are accessing RAM, modern ARM chips don't care about alignment. A couple decades ago, sure, ARM was different. Had it stayed that way, ARM would not be so popular today.
- kayamon 8y agoYou think a chip will be a financial success based on whether it supports unaligned reads? Almost zero software out there actually needs unaligned reads.
- burfog 8y agoYes. Most of the troubles related to -fstrict-aliasing involve unaligned reads. All sorts of file formats, TIFF for example, are most easily handled with unaligned reads.
- kayamon 8y agoMost of the troubles related to -fstrict-aliasing involve -fstrict-aliasing.
- burfog 8y agoIf the processor supports unaligned reads, sure, you could say that, though it still technically violates the C standard. Otherwise, no. A typical issue would have code like this: foo = * (bar * )baz; // baz is a char pointer into a binary blob, and bar is a type that needs alignment If the data were all properly aligned, then most likely there would be no desire to write such code. The correct types would be used. Aside from gcc abusively optimizing, the above works fine on x86, PowerPC, and modern ARM. It does not work on older ARM. That sort of code is everywhere.