Re: Use of unaligned load/stores by compilers

The most common issue I've seen regarding the need for unaligned
loads/stores involves the alignment of objects in structures. It
regrettably seems to be common enough for people to assume that
packing of fields is well-defined in C, and to write things like:


      struct {
            char c;
            int i;
    } not_heroic;


and mistakenly assume that this will portably create a structure of 5
bytes (or maybe 3 bytes?) long. When they then read 5 (or 3) bytes
from an I/O device directly into this object, they don't get the
results they expect when they read the values out. Likewise when they
write "sizeof(not_heroic)" bytes to that same I/O device, and all hell
breaks loose.


Over the years, I've had a number of customers insist that our
compilers are buggy because the expensive TCP/IP package they bought,
originally for an X86, doesn't work because our compilers pack the
structure wrong. (Interestingly, at least one of the big TCP/IP
vendors now provides a version of their stuff which works with such
"broken" compilers.)


My experience with adding support for misaligned pointers: not
particularly hard to do, but very inefficient. Every pointer
reference for which analysis or declaration cannot guarantee proper
alignment is subject to significant bloat - effectively loading each
byte, shifting, ORing. For reading a 4-byte value its something like
10 operations. Writes are correspondingly worse. Good candidates for
going out-of-line.


Even in this X86-dominated world, it always surprises me how many
programmers are completely unaware that there is such a thing as
hardware enforced alignment of memory references. <Sigh>


-Reid
[I think this is the 1990s equivalent of the old observation that a
determined programmer can write a Fortran program in any language. -John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.