Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



If 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.


You think a chip will be a financial success based on whether it supports unaligned reads?

Almost zero software out there actually needs unaligned reads.


Yes.

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.


Most of the troubles related to -fstrict-aliasing involve -fstrict-aliasing.


If 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: