JavaからJNIでDLLを呼び出せるので、JavaVMで処理に時間がかかりそうな処理をC/C++で開発してみようと思うのは普通だと思うし、どうせならMMXやSSEなどで高速に演算させたいと思うこともある。
GCCには、MMX、SSEなどの命令を呼び出すためのAPI(__builtin_ia32_hogehoge())があるので、これらを使えば、わざわざアセンブラのお世話にならずとも実現することが可能である。ということで、JNIなDLLをSSE命令を使って開発するのであるが、これが一筋縄に行かないようなのである。
SSEには、メモリー上のデーターをアクセスするための命令に128bitアライメントされているデーター用とそうでないもの用の２つがある(MOVAPSとMOVUPSなど）。要するに、128bitアライメントされているほうが高速にアクセスできるということであるが、もし、アライメントがされていないデーターにアクセスすれば、いわゆるソフトウェア割り込みが発生してアプリケーションエラーとなってしまう。
これらのアライメントを前提とする命令を使うには、コード上データーがアライメント上にあることが保証されているなければならないということになる。
普通、C/C++でプログラムするときには、データーがメモリ上どう配置されるかということを気にすることなく、もし、なんだかの制約があるとすれば、コンパイラーが何とかしてくれる（それ用のオプションをつけて実行するとか）ことにしている。
ただし、デフォルトでない特殊なアライメントなどを利用したい場合には、GCCでは__attribute__((aligned(n)))のような属性をつけられる。これは例えば、char data[256] __attribute__((aligned(16))) = {0};のように使うのだが、この例では、このchar配列を128bit(16byte)上に配置するようにしていている。
ただし、このように書けるのはC/C++上での静的な変数に対してであり、動的に得る場合（mallocやnewで生成する領域）では、このような属性では制御できない。ただ、C/C++の場合、ポインターはメモリーアドレスそのものであると考えられるので、ポインターをずらして、合わせてしまうという事が可能である（本質的にはAPI側でなんとかしてほしいところだが）。
このようにすれば、SSEでのアライメントの問題が解決するということにしたいのだが、実際にはそういう訳にはいかない。というのが、本題であったりする。
ここで根が深いのは、基本的にはコンパイラーのオプションや属性の指定で解決されているべきものが、実際にはアライメントされていないということである。
アセンブラ以外でアライメントなどを考慮しなくてはいけないのは、C/C++であるとしてでもおかしな話であると思うが、CPU固有の命令を使おうとしているので、なんだかの特殊な処理が必要であると考えても仕方がないかもしれない。確実に動くコードが書ければ、それはそれで問題ないといえるだろう。
ところで、C/C++で変数といわれるものは２つあり、それはいわゆるstaticで宣言されるものと、関数やブロックのなかで宣言されるいわゆるauto変数といわれるものである。
staticな変数は、モジュールがロードされるときに確保され、その領域はモジュールがなくなるまで存在する。この変数は、その領域のアドレスをどこかに保持し、領域内の相対アドレスをコード内に持って、それを足してアドレスを確定してアクセスする。
ここでアライメントを保持するには、領域の先頭のアドレスをアライメントされるように配置して、相対アドレスもアライメントを保持するように割り当てるようにする。
コンパイラーでオプションや属性で指定するアライメントは、相対アドレスにを指定するものであり、領域のアドレスはモジュールのロードにアライメントされて確保されるので、問題なく使える。
auto変数は、スタックといわれる領域に確保される。これは、関数が呼び出されるときのスタックのアドレス（スタックポインター）を基に相対的に割り当てられる。
autoな変数のアライメントは、staticと同様に相対アドレスは、コンパイラーが割り当てて、スタックは、モジュールのロード後、最初の関数を呼び出すときにアライメントされるように割り当てられるようになっている。その後、呼び出される関数もアライメントするように配置することによって、アライメントを維持するようにしている。
そうすると、staticな変数と同様にauto変数も問題なく動くはずなのだが…。
最初に述べたのだが、DLLでSSEを使うときの問題があるということなのだが、それは、DLLのスタックは、呼ばれる元のモジュールのスタックを引き継いで利用する。これは、C/C++で関数を呼び出すために必要な仕組みである。
もし、C/C++コード上でアライメントが不明であれば、アライメントを前提としない命令を使えばよいのだが、コンパイラーはauto変数に割り当てられたSSE用の変数を、アライメントされているものとして、読み書きするような命令を出力するのである。
ということで、おわかりであると思うが、DLLを呼び出すモジュールがアライメントを維持しないようにスタックを使っている場合、DLLでアライメントを保持するようになっていても、うまく動かないということになるわけである。それは、JNIがJavaVMから呼び出されるときも起きていて、JNIのDLLでSSE命令を使おうとすると、ほとんどうまくいかない（うまくいくのは、SSE用の変数がすべてレジスタ上に配置されたときか、運良くスタックがアライメントされているときだけ）。
どうやら、このことを問題だと思っている人が多く居るらしく、GCCでこれを回避するオプションを作ることが想定されているようだが、まだ実装されていないもよう。ましては、MinGWでの移植にも時間がかかるため、おそらくMinGWのGCC環境では、うまく動くコードをはくコンパイラーはしばらく先になるだろう。
