4 ms·

I remember that back in the early 90s, the DEC Alpha was pretty "weird", as it was one of the first common LP64 unix machines. I fixed so many issues due to si

I remember that back in the early 90s, the DEC Alpha was pretty "weird", as it was one of the first common LP64 unix machines. I fixed so many issues due to sizeof(int) != sizeof(char *) when building open-source packages for DEC OSF/1 in the early 90s.. Later, the alpha was FreeBSD's first 64-bit platform, and when working on the port to alpha, we hit a lot of the same issues in the FreeBSD kernel. As alpha was also FreeBSD's first RISC machine with strict alignment constraints, we also hit a lot of unaligned access issues in the kernel. Ah, those were the days. I now find myself grumbling about having to check to ensure my code is portable to 32-bit platforms.

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 ago
  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.
  - kayamon 8y ago
    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.
    - burfog 8y ago
      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.
      - kayamon 8y ago
        Most of the troubles related to -fstrict-aliasing involve -fstrict-aliasing.
        burfog 8y ago
        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.

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 ago
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.
- kayamon 8y ago
  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.
  - burfog 8y ago
    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.
    - kayamon 8y ago
      Most of the troubles related to -fstrict-aliasing involve -fstrict-aliasing.
      - burfog 8y ago
        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.