There will be an upcoming 64 bits Delphi compiler. Embarcadero promised it.

Florian Klämpfl (the FPC's architect) showed a first "Hello world" program for Win64 in March 2006.

This was remarkable since GCC and the binutils didn't even support this target at this time.

In fact, FPC used its Internal linker on Win32 and Win64 platforms, just like Delphi does.

Here are some points on how you could make your code ready to compile under FPC 64 bits, therefore (I hope) under future Delphi 64 bits compiler.

The good news

Under FPC, all common types (like integer, cardinal, etc...) have the same size. They are all 32 bits.

So most of you code don't need to be rewritten.

If you have some assembler

But if you have some asm part in your code, you'll have to write it in pascal.

Use the PUREPASCAL conditional, and always provide a pure pascal version of any asm function. It's therefore a good practice to always code in pascal, then add an optimized asm version only if it's necessary.

Here is one example extracted from our framework:

function IdemPropName(const P1,P2: shortstring): boolean; overload; {$ifdef PUREPASCAL} var i: integer; begin result := false; if P1[0]<>P2[0] then exit; for i := 1 to ord(P1[0]) do if (ord(P1[i]) xor ord(P2[i])) and $DF<>0 then exit; result := true; end; {$else} asm // eax=P1 edx=P2 mov cl,[eax] cmp cl,[edx] jne @z // length differs or cl,cl @1: lea eax,[eax+1] lea edx,[edx+1] jz @ok mov ch,[eax] xor ch,[edx] and ch,$DF // case insensitive compare jne @z dec cl jmp @1 @ok:mov al,1 ret @z: xor eax,eax end; {$endif}

The bad news: Pointers size changed

If you use pointer arithmetic, you should use PtrInt instead of integer to typecast pointers.

See http://wiki.freepascal.org/Multiplatfor … 2.2F64_bit

It's perfectly cross-compiler. We defined these types for working with Delphi and FPC on the same code:

{$ifdef FPC} {$ifdef CPU64} {$define PUREPASCAL} {$endif} {$else} type /// a CPU-dependent unsigned integer type cast of a pointer / register // - used for 64 bits compatibility, native under Free Pascal Compiler PtrUInt = cardinal; /// a CPU-dependent unsigned integer type cast of a pointer of pointer // - used for 64 bits compatibility, native under Free Pascal Compiler PPtrUInt = ^PtrUInt; /// a CPU-dependent signed integer type cast of a pointer / register // - used for 64 bits compatibility, native under Free Pascal Compiler PtrInt = integer; /// a CPU-dependent signed integer type cast of a pointer of pointer // - used for 64 bits compatibility, native under Free Pascal Compiler PPtrInt = ^PtrInt; /// unsigned Int64 doesn't exist under Delphi, but is defined in FPC QWord = Int64; {$endif}

So it's always a good practice to use these PtrInt instead of integer in any pointer arithmetic, just as you should use AnsiString/AnsiChar/PAnsiChar for any ansi content, even on Delphi 7.

And if you use loop variables like for i := 0 to Lines.Count-1, you should better use var i: PtrInt instead of i: integer

Note that there is a CPU64 define set if you're compiling for a 64 bits CPU.

For example, since PtrInt = Int64 in fact, you can test {$ifdef CPU64} to avoid writing a Int64 specific function, if a PtrInt one has already been defined.

We use all these tips in our SQLite3 Client-Server framework.

Hoping and praying

I just hope that EMB will follow the same rules for their future 64 bits compiler.

They will surely release their compiler 5 years later than FPC's... I hope they will follow the FPC way, just as Intel did about 64 bits instructions, against AMD.