Data alignment of 64 bit Windows in terms of driver development

I found this on MSDN:

On 32-bit Windows platforms, the operating system automatically fixes kernel-mode memory alignment faults and makes them invisible to the application. It does this for the calling process and any descendant processes. This feature, which often dramatically reduces performance, has not been implemented in 64-bit Windows. Thus, if your 32-bit driver contains misalignment bugs, you will need to fix them when porting to 64-bit Windows.

I'm somewhat frightened by this. Can anyone show me an example of the misalignment bug?

EDIT: I basically know the concept of alignment and its reason. I just want to figure out the diffrence b开发者_Go百科etween win32 and win64 in terms of "automatical fix" on alignment and the impact on my driver.

Consider the following structure, where a and c are 32-bit words and b is a byte.

|-----------a-----------|--b--|-----------c-----------|
|     :     :     :     :     :     :     :     |     :

If you allocate this structure on a 64-bit boundary, then a and b will both be aligned correctly, but c will not, since it crosses a 64-bit word boundary. In fact, it is impossible to layout this structure without pushing either a or c over such a boundary.

In practice, compilers will usually take a definition like this:

struct {
    int a;
    char b;
    int c;
};

and arrange it like so:

|-----------a-----------|--b--|     padding     |-----------c-----------|
|     :     :     :     :     :     :     :     |     :     :     :     :

So that none of the values crosses an alignment boundary. But in driver programming, structures often have to be packed (i.e., no padding) in order to match over-the-wire or on-disk data structure formats. That's when you can get into strife unless you unpack across word boundaries by hand.

I don't have an example to hand but the problem is quite simple to explain - you can only access 64 bit data on 64 bit boundaries. Where data is 32 bit (or smaller) aligned you cannot access this reliably as 64 bit values because every second value will not be on a 64 bit boundary and this access will generate an exception.

WIntel machines are very tolerant of these faults but most other architectures, like ARM, throw exceptions on all alignment problems so all pointer casts are viewed with extreme suspicion. Being careful, very careful, is the only way forward and using static analysis tools like Lint and Klocwork help a lot.

Quote this document in case someone has the same concern:

If the processor tries to read or write improperly aligned data, an alignment fault can occur. On x86 hardware, the alignment faults are invisible to the user. The hardware fixes the fault as described in the previous paragraph. On x64 hardware, alignment faults are disabled by default and the hardware similarly fixes the fault. On the Intel Itanium architecture, however, if an alignment fault occurs while 64-bit kernel-mode code is running, the hardware raises an exception. (For user-mode code, this is a default setting that an individual application can change, although disabling alignment faults on the Itanium can severely degrade performance.)