Pulsar(Delphi x64)情報

Stack OverflowのHow should I prepare my 32-bit Delphi programs for an eventual 64-bit compiler?(来るべき64bitコンパイラに備えて、32bit Delphiのプログラムでどのような準備をしておくべきでしょうか？)という質問に対してBarry Kellyさんが非常に興味深い回答をしています。

てきとうな要約:

• 注意書き: Barry KellyさんはEmbarcaderoに勤務していますが、Embarcaderoを代表した回答ではなく、また64bit版Delphiはこうあるべきであるという仮定に基づいたものであり、設計上異なる選択が行われることになるかもしれません。
• NativeIntとNativeUIntというプラットフォームにより32bitまたは64bitとなる整数型が用意される。これ以外の整数型はターゲットプラットフォームによりサイズが変化することはない。
• TComponent.Tagのように整数とポインタをキャストして使用するようなものはNativeInt/NativeUIntに置き換えられる。
• NativeInt/NativeUIntはポインタとの相互変換を必要とする場合以外には使用するべきではない。これ以外の整数型の変数は従来通りのサイズのものでよい。参照やTHandle、HWNDのようなものだけにNativeInt/NativeUIntを使う。
• 文字列や動的配列の(ヘッダデータのような)内部の詳細を当てにしてはいけない。
• (RTLの)APIは可能な限り32bitと64bitの間で維持する、というのが原則になる。たとえばTListの最大要素数もMaxInt div SizeOf(Pointer)のままになる。
• (RTLの)APIを64bitで拡張する場合、別のfunction/method/propertyでアクセスするようにする。たとえばLength()はそのままで、LongLength()を用意する、というように。
• これに関連してサイズを縮小する方向の変換(64bitの戻値を32bit整数の変数に代入するような)に関するエラーチェックを強化する。
• おそらく動的配列は64bitのインデックスをサポートする。
• おそらく文字列は32bitでインデックスが制限される。実際に文字列が4GBを超える状況を想定できないため。
• ほぼ確実にビルトインアセンブラ(BASM)はサポートされないが、オブジェクトファイル(.obj)のリンクはサポートされる。

おそらくNativeInt/NativeUIntはINT_PTR/UINT_PTR(Windows Data Types)のまともな名前バージョンです(INT_PTR/UINT_PTRはそのネーミングセンスのなさで有名)。またPulsar(64bit Delphi)でBASMがサポートされない件はフォーラムのDelphi x64 and no build-in ASM = troublesでも話題になりましたが、PulsarにBASMを間に合わせるのは困難だ、という話でした。

元ねたはNick HodgesさんのFlotsam and Jetsam #15。