64-Bit Insider
Volume I, Issue I
The 64-bit Advantage
The computer industry is chang-
ing, and 64-bit technology is the
next, inevitable step. The 64-bit
Insider newsletter will help you
adopt this technology by provid-
ing tips and tricks for a successful
port.
64-bit development and migration
is not as complicated and complex
as the 16-bit to 32-bit transition.
However, as with any new tech-
nology, there are several areas that
require close examination and
consideration. The goal of the 64-
bit Insider newsletter is to identify
potential migration issues and
provide viable, effective solutions
to these issues. With a plethora of
Web sites already focused on 64-
bit technology, the intention of
this newsletter is not to repeat
previously published information.
Instead, it will focus on 64-bit
issues that are somewhat isolated
yet extremely important to under-
stand. It will also connect you to
reports and findings from 64-bit
experts.
Alignment in 64-bit Processors:
Part 1
Understanding Alignment
Alignment refers to where and how data is laid out in mem-
ory. For performance reasons, processors specify rules that
determine valid locations for data. When these rules are bro-
ken, the processor follows one of two paths: it throws an ex-
ception, possibly crashing the application, or it accepts the
unaligned data but runs slower than usual.
The rules change with 64-bit processors, causing the primi-
tive data types and compound data structures inside an appli-
cation to change both in size and shape. Consequently, some
common but nonportable habits of C programmers create
issues when they compile code on 64-bit processors.
Ideally, the compiler would transparently handle any align-
ment issues. And such is the case when programmers write
code that is portable and follows the relevant best practices
of C coding. In this instance, the compiler automatically
takes care of any changes in alignment rules, padding, and
structure sizes so that the associated application works on a
64-bit platform.
64-bit Insider Newsletter
Volume 1, Issue 1
Page 1/4
However, in practice, most programmers take shortcuts, making assumptions about the size
of their data and how it is laid out in memory. Therefore, it is important to compile and test
your application on the 64-bit platform.

Potential 64-bit Alignment Issues

There are several issues that may result from the changes in alignment rules, and that you
might encounter on the 64-bit platform.

• Data structures change size.

Adding extra padding to abide by
new alignment rules may change the
size of a data structure. If you
assume that your data structures are a
specific size, you might allocate
insufficient amounts of memory or
corrupt the memory. Both situations
eventually will cause the application
to crash. Unfortunately, this issue is
difficult to track because the
application may crash long after the
memory corruption occurred.

• Data structures change shape. Adding extra padding also causes data structures to
change shape. Member offsets change, for example, and can also lead to memory cor-
ruption.

• Writing data to memory leaves data unaligned. How you explicitly write data to
memory may no longer be allowed because the target location may leave the data un-
aligned. On Itanium processors, reading data from or writing data to inappropriate lo-
cations will cause your application to crash with a mes-
sage similar to this: “Data alignment fault.”
“... extra padding also
causes data structures to
To help locate and resolve these issues in a more practical
change shape. Member
way, the remaining sections introduce a hypothetical appli-
offsets change, for ex-
cation and associated data structure, and examine a scenario
ample, and can also lead
in which alignment problems, which were not encountered
to memory corruption...”
on a 32-bit platform, occur when the application runs on a
64-bit platform.

Sample application
Consider an application that monitors data coming from a device used in a physics labo-
ratory. This application will receive many bursts of data of varying sizes that should be
stored in a linked list for further processing. Figure 1 shows a structure that might be used
to describe the data bursts that have been detected.

64-bit Insider Newsletter

Volume 1, Issue 1
Page 2/4
typedef struct _mburst
{
int seq_no; // Sequence number for this burst
size_t size; // Size of burst
char* data; // Observed data
_mburst* next; // Pointer to next burst or NULL
} mburst;

Figure 1: 32-bit and 64-bit view of the mburst data structure

Alignment Issues: Hard-Coding Structure

Sizes
As you can see in Figure 1, the 64-bit version of the
mburst object is larger than the 32-bit version. This
is because the size of the pointers and padding
within the structure has increased to keep the
members of the structure properly aligned. Thus, the
following code, used to create a single mburst
object, works only on the 32-bit platform:

mburst* create_mburst()
{
mburst* p = (mburst*) malloc(16);
p->seq_no = -1;
p->size = 0;
p->data = NULL;
p->next = NULL;
return p;
}

Because the mburst object changes in size (from 16 to 32 bits) on the 64-bit platform,
when this code runs on a 64-bit platform it will work only until you write data into the
allocated memory. At this point, the application may crash immediately, or it may con-
tinue to run for a short time and eventually
crash elsewhere in your code.
“.. the 64-bit version of the mburst
object is larger than the 32-bit
Even attempts to “be smart” by asking the sys-
version. This is because the size of
tem for the size of each member in the structure
the pointers and padding within
(as demonstrated in the following code) will not
the structure has increased to
succeed. This failure occurs because the
keep the members of the structure
solution does not take into account the padding
properly aligned....”
that is added on the 64-bit platform.

Note: malloc() always allocates memory

aligned on 16-byte boundaries on a 32-bit platform.
64-bit Insider Newsletter
Volume 1, Issue 1
Page 3/4
mburst* create_mburst()
{
mburst* p = (mburst*) malloc(sizeof(int)+sizeof(size_t)+
2*sizeof(void*));
p->seq_no = -1;
p->size = 0;
p->data = NULL;
p->next = NULL;
return p;
}

As a general rule, you should not try to outsmart the compiler. Modern compilers are
smart and will get things right more often than you might think. Consequently, to get the
size of a structure, use the sizeof() operator on the structure itself, as shown in the follow-
ing code. The sizeof() operator takes into account all of the padding that has been inserted
into a structure—including the padding that has sometimes been added to the end of a
structure.
mburst* create_mburst()
{ “... As a general rule,
mburst* p = (mburst*) malloc(sizeof(mburst)); you should not try to out-
p->seq_no = -1;
p->size = 0; smart the compiler. Mod-
p->data = NULL; ern compilers are very
p->next = NULL;
return p; smart and will get things
} right more often than you
might think.”
Upcoming Newsletter
The next 64-bit Insider newsletter discusses more align-
ment topics, such as hard-coding structure sizes in C++,
miscalculating offsets, custom layouts, packing, and alignment exceptions.

Recommended Reading
Larry Osterman’s Weblog: Alignment (part 1)
http://blogs.msdn.com/larryosterman/archive/2005/04/07/406252.aspx

Intel article: Data Alignment when Migrating to 64-bit Architecture

http://www.intel.com/cd/ids/developer/asmo-na/eng/170533.htm

Microsoft Visual Studio technical article:

Windows Data Alignment on IPF, x86, and x86-64
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dv_vstechart/html/vcconWindowsDataAlignmentOnIPFX86X86-64.asp

64-bit Insider Newsletter

Volume 1, Issue 1
Page 4/4