from Machine Description to Resource Description

既存のコンパイラではマシン記述をプロセサ機能を記述するために用いていた。マシン記述は命令と動作の対応を示したもので、コストの導出は別のプログラムによってなされることが多い(gccLLVMの場合)。
ところが、skyが行うような最適化はパイプラインスループットに非常に影響される。この場合必要なのはマシン"動作"の記述ではなくてマシン"資源"の記述であり、資源を記述するためのフォーマットが必要になる。
資源は、例えばCellのSPUで言えば、

  • 32Bit floating point ADD/MUL/SUB
  • 32Bit integer ADD/SUB(signed/unsigned)
  • 16Bit(!) integer MUL(signed/unsigned)
  • 32Bit AND/OR/NAND/XOR/...

のように表現される。
例えば、LLVM言語では(SPUには存在する)NANDが無いため、LLVM命令上でのコストのみではNANDが1命令で実行できることを知らないのと同義になる。

ダイナミックプロセサ

悪いことに、現代のx86のようなダイナミックプロセサではリソース記述を書きようが無い。micro-opを正確に把握しているCPUベンダ自身だけが書ける。
要するにskyのアプローチはダイナミックプロセッサではあまり効果的でない*1。今後、物理構造を明確に表現するプログラミングは流行ると思うが、それらのコンパイラダイナミックプロセサに背を向けてしまうかもしれない。
ダイナミックプロセサの生き残る道は、OpenCLのような共通言語に典型的なオペレーションを集約して、広く使われるようにすることだろう。つまり新しい命令セットを更に上にかぶせるという方向性といえる。
CellのSPUのような静的なプロセサで、そのアーキテクチャが公開されていて、かつ普及したプロセサは数が殆ど無い。個人的には、いわゆるアプライアンス製品やモバイル製品向けにはまだ普及の可能性が有ると考えている。
過去に"C言語指向マイコン"というカテゴリが有ったのと同様に、"sky仕様マイコン"、即ち、明確にリソース記述された必要最低限のハードウェアを用いる事が今後重要になってくるように思う。

ダイナミックな命令セット

x86で言うところのuOP->X86命令->Cのような命令セットのオーバーレイは、プログラムの密度の面で通常のRISCに勝てる可能性が有る。現代的なコンピュータはメモリ性能がパフォーマンスのボトルネックになっているのでこの方向性は重要なものといえる。
ダイナミックに命令セットを定義できるコンピュータを作ることが出来ればx86の優位性を手に入れることが出来るかというと、そうでもないことが予想される。
命令セットの定義を、一種のデータ圧縮の問題と考える。
データ圧縮にはよく辞書(codebook)式の圧縮が用いられ、この例えでは、uOPで構成されたプログラムをx86の辞書を用いて圧縮したのがx86のプログラムということになる。
JPEGはこの辞書をデータ中に含めることにしているが、一部の実装は辞書を固定している。MP3のように規格中で辞書が固定されているケースも有る。そして、現代的なCPUも、命令セットという形で辞書を固定している。
果たして、辞書を可変にすることが大きな効果を生むだろうか。

*1:それでも、メモリアクセスのスケジューリングやオペレーションの省略は依然効果はあると考えてはいるが。。