64ビットWindows環境の開発で注意したいポイント（3/3 ページ）

[C MAGAZINE]

互換性の高さに注意

　64ビットWindows対応のプログラミングといっても「32ビット環境の資産をそのままに64ビット環境への移行を可能にする」という目的のもと、ほとんどのアプリケーションは、たいした手間をかけることなく64ビットネイティブコードにできるようです。実際、通常はポインタサイズが64ビットになったことに注意すれば、まず問題は起きないだろうという印象を受けました。ただし、1つ注意したいのは、構造体のアライメントとパディングの問題です。

　メモリアクセスは「自然境界」にアライメントされるので、同じコードでも32ビットプロセスと64ビットプロセスとでは、パディングの入り方に差が生じてくるケースが考えられます。ここで、32ビット環境と64ビット環境の互換性の高さから、うっかりしていると、32ビットプロセスと64ビットプロセスの間で不適切なデータのやりとりを行ってしまうということも考えられます。たとえば、64ビットプロセスで作成したメモリマップドファイルを32ビットプロセスで何の対策もなしに読み込んでしまうと、両方のプログラムにはコード的な誤りは含まれていないにもかかわらず、正しくデータが受け渡しできないなどのトラブルが発生することも考えられます。明示的にアライメントを指定するなどの対策が必要なケースも出てくるでしょう。

　また、処理の効率化/最適化を考えて、インラインアセンブリを含むコードで記述された資産を持っている方も多いと思いますが、ここでは32ビットCPU用のアセンブリコードがエラーなく実行できてしまうことに問題があります。すなわち、レジスタサイズや数が異なるCPU上で、必要な初期化やデータの準備ができていないまま、見かけ上「問題なく」実行されるため、エラーが出ないにもかかわらず期待した結果にならないということが簡単に起こりうるのです。この点に関しては、コードの検証などのコストを考えると、マイクロソフトが推奨しているようにアセンブリコードをC/C++などのコードに置き換えることで対応するのが得策のようです。ちなみに、現在のところVisual Studio 2005にインラインアセンブリ機能をつける予定はないそうなので、その点からもC/C++コードなどへの移植による対応が必要です。

まとめ

　そのほか、キャッシュを意識した最適化されやすいコードの記述方法など興味深い話をたくさん聞けましたが、誌面が残り少ないことと、それらは今後特別記事などで紹介される可能性が高いので割愛させていただきます。

　ワークショップに参加して受けた個人的な印象としては、最新の技術であると同時にある種の「泥臭さ」が感じられるというところです。ただし、それは洗練されブラックボックス化された環境よりもプログラマの腕を発揮する場の多い魅力的なステージとして映りました。また、同時に懐かしさのようなものを感じたのは、筆者が古い人間だからなのかもしれません。