moratorium

11月初旬にステートマシン型のCPUが動いてから、パイプライン型のCPUの作成に入っています。目標動作クロックは100MHzです。3GHzとか言ってる時代なので100MHzなんて遅ぇ！と思われるかもしれませんが、FPGA上では配線遅延が大きく100MHzで動かそうとすると1stageで32 bit と 32 bitの値同士の足し算をするのもやっとという世界です(10 ns / stage)。

なるべくハードウェアの資源を少なくするために、命令セットのフォーマットを変えたり(命令デコードを高速に行うため)、ソフトウェア側で解決できる問題は出来る限りソフトウェア側で解決したりと、色々苦労しています。

コンパイラは継続して最適化の実装を行っています。現在のところ、レイトレーシングを動かした時に実行される命令の振り分けは以下の様になっています。

総計24.8億Instruction中、約10億InstructionがNOPです(僕らの班ではNOPはADDのSyntax Sugar)。仮想的にCPUシミュレーターで時間を測ると大体consest.sldが28.6秒で終わるぐらいの性能です(内輪向け情報)。こんなにNOPが有る原因としては、主にデータハザードによるものと、ディレイスロットによるものです。

データハザードの方は、FPU命令が３クロックかかってしまう為に起きています。つまりFPU命令は3クロックかかってしまうので、FPU命令の結果を使う命令はその分待つ必要があります。そこにコンパイラが明示的にNOPを入れます。この辺ハードウェアで裁くのが現代CPUの常識なので、将来的にNOPを挟まなくて良いようになるかもしれませんが、例えそうなったとしてもハードウェア内でストールが起きている訳なので、大して性能が上がりません。

ディレイスロットというのは、「branch命令の後で飛んでも飛ばなくても実行される命令列」で、branch命令のすぐ後に挿入されます。 slot数はアーキテクチャによります。branch命令を発行すると制御ハザードが起きるので、その間にも常にパイプライン内で命令を実行させようという意図のものです。MIPSやSPARC等がこの仕組みをもっています。この辺は「Computer Architecture」にも書いてあったはず。Appendix Aか2, 3章辺り?

ディレイスロットを埋めるのはコンパイラの仕事です。具体的にどう埋めるかは、まず命令内で命令の依存グラフを作成します。その情報を元に、ディレイスロットの場所に場所を移動できそうな命令というのを決定してそこに命令を移動させるという事をしています。ただ、上のグラフにも現れているように今のところそんなに埋まっていないし、ソフトウェア側では限界も見えてきたので、ハードウェア側でディレイスロット数を減らす(2個から1個)というアプローチを取る事にしました。

データハザードの方も命令スケジューリングで多少はなんとかなります。コンパイラ側で依存グラフを見てハザードが少なくなるように命令列を有る程度並び替えられます。ただし、完全にハザードを無くすのは不可能です。ソフトウェアで頑張れる所はもちろん有るんですが、さすがに限界も有るので・・・。

ソフトウェアで頑張って１秒縮めても、ハードウェアが良くなれば5秒ぐらい縮む可能性が有ります。ただし、その分回路が複雑になったりするとハードウェアの場合デバッグ＆検証作業が悲惨な事になります。

この辺のバランスが個人的には凄い楽しくて、「ハードウェアが極力シンプルになる方向にもっていけるようにソフトウェア側で無理をする」「ハードウェアではソフトウェアでは無理な最適化だけをやる」というのが良いのかなーというのが今のところの感想です。無理しすぎるとそれはそれで破綻するのですが。後、ハードが完成して安定すると今度はソフトウェア支援の為の機構をプラスして行けるので、また来月辺り状況が変わるのかなーとか。

とまぁ最近はそんな感じの事をやってます。最終的にも対外発表する場も無いので、ブログに書いておくかなーと。