Chris Paulson-Ellis wrote:
> I think that the compiler should generate the neccessary code. The programmer has documented that there may be a performance hit by putting align(1){...} in the source. Perhaps another attribute is needed to specify whether you want mis-aligned accesses to blow up or not. Or perhaps an extra 'argument' to the align attribute.

Maybe I only think so for historical reasons, but it seems like if you're going to make it optional it should be a compiler switch or a pragma-type thing. It seems weird at the language level to say "please don't crash" -- maybe that's an argument in favor of such accesses always working, even if slower.

If misaligned reads are defined as safe, there should be a note to non-x86 implementors recommending that possibly-misaligned reads be emulated via function call or extra instructions inline, rather than by trapping the machine exception. If it's defined as safe, it's going to get used fairly often. In reading misaligned data from a file, for example, I can accept the overhead of read emulation, which will be swamped by file access time, but can't accept the overhead of a large number of exceptions.

The more I think about it, on modern processors and in modern applications, there are a lot of performance issues that aren't language defined -- cache sizes and alignments and the like -- and you generally want the code to Just Work even if it's non-optimal. Perhaps potentially-misaligned reads can generate an optional compiler warning, but always work.

-RB