Find file
Fetching contributors…
Cannot retrieve contributors at this time
131 lines (103 sloc) 3.36 KB
$(P Although D is designed to make it easy to port code between
32 and 64 bit modes, being a systems programming language,
dependencies can creep in. This guide points out what changes
between the two.
$(SECTION2 Versions,
$(P Not all code can be made portable between 32 and 64 bits,
and must be versioned. The following works:
version (X86)
... 32 bit code ...
else version (X86_64)
... 64 bit code ...
static assert("unsupported target")
$(P It is best to write versioning in that manner to give a compile
time error on a new target, rather than guessing in advance what, for example,
a 64 bit ARM target might require.
Experience shows that guesses about how an unfamiliar platform might work
always get it wrong.
Save those decisions for when one is actually working on a 64 bit ARM.
$(SECTION2 Size Changes,
$(P The size of pointers and references will increase from 4
to 8 bytes. The $(TT size_t) alias moves from $(TT uint) to
$(TT ulong), and the $(TT ptrdiff_t) alias moves from $(TT int)
to $(TT long).
$(P The sizes of compound types based on these will also increase.
This includes dynamic arrays, associative arrays, delegates,
and class references.
$(SECTION2 Structs,
$(P The size of the struct and the alignment of its fields
will change, in order to match the C ABI of the equivalent
C struct.
$(SECTION2 Classes,
$(P The size of the class and the alignment of its fields
will change, in order to match the alignment most suitable
for the 64 bit mode, and in order to accommodate the increased
size of pointers and references.
$(SECTION2 printf,
$(P Since $(TT printf) is a C function, it follows C typing rules.
This can have consequences for using them with D types.
$(TR <th rowspan=2>D Type</th> <th colspan=2>printf format</th>)
$(TR $(TH 32 bit) $(TH 64 bit))
$(TR $(TD $(I T)*) $(TD %p) $(TD %p))
$(TR $(TD long) $(TD %lld) $(TD %d))
$(TR $(TD ulong) $(TD %llu) $(TD %u))
$(TR $(TD ptrdiff_t) $(TD %td) $(TD %td))
$(TR $(TD size_t) $(TD %zu) $(TD %zu))
$(P For 32 bit code, it was common to use the $(TT %.*s) format
to print strings. This relied on the 32 bit C ABI interpreting the
components of a dynamic array as separate length and pointer arguments.
64 bit parameter passing is different, and so the length and pointer
should be done explicitly:
string s;
printf("s = '%.*s'\n", s); // 32 bit only
printf("s = '%.*s'\n", s.length, s.ptr); // 32 and 64 bit
$(SECTION2 Inline Assembly,
$(P Naturally, inline assembly for 32 bit code won't work for 64 bit code.
The versioning statements to use are:
version (D_InlineAsm_X86)
... 32 bit assembler ...
version (D_InlineAsm_X86_64)
... 64 bit assembler ...
static assert("unsupported target");
$(P The 64 bit inline assembler uses the syntax found in the Intel
and AMD instruction set references.
$(SECTION2 Variadic Arguments,
$(P How variadic arguments work in 64 bits is radically different from
32 bits. They are not a simple array on the stack. You will need to use
the functions and templates in $(TT std.c.stdarg) to access them.
TITLE=Porting 32 Bit Code to 64 Bits