VLIW

スーパースケーラー方式と違い、複雑な命令スケジューリングをコンパイラーなどツール側で行なうので、プロセッサー側でスケジューリング/リソース管理回路を持つ必要がない。

最適化時には同時に実行する命令間に依存関係が生じないようにし、同時に実行可能な命令が無い時はNOP(無効命令:何もしない)を埋めこむ。このように依存関係を最初から排除することで、動的な実行順制御機構を不要としている。

逆に、あらかじめ最適化されていることを前提とするため、最適化ツールの性能により十分な性能を発揮できない場合も多い。理論値の最大性能を発揮させることは現状の殆どのコンパイラーでは不可能であり、結局はハンドコーディング(手作業)が必要となることも少なくない。

単純なVLIW方式では無効命令が多数含まれるためプログラムサイズが大きくなりやすいという欠点があるが、実際の実装では命令のパッキングなどによりコードのサイズ削減などの対策が取られることも多い。

また、命令長が長くなるため命令フェッチに要する時間が長くなる可能性が高く、コンパイラーの最適化性能によっては無駄にNOPが多くなるために命令キャッシュの使用効率が低下する恐れがあるなどの実装上の問題点も多く、様々な対策が取られている。

命令セットそのものに並列機能が含まれるため、プロセッサーが改良され構成(例えば命令実行ユニットの数)が変化してしまうと命令セットも変更する必要があり、将来的に渡ってバイナリの互換を保つことが難しい。

このためVLIWアーキテクチャーは主にマルチメディア向けDSPやグラフィックなど特定用途向けのチップで採用され、汎用チップで使われることは少ない。

但し、バイナリコードの変換機構をハードウェアまたはソフトウェアとして搭載することで、従来のプロセッサーとの互換性を持たせることは可能である。汎用プロセッサーのVLIW採用例としてIntelとHewlett-Packardが開発したIA-64や、Transmetaのx86互換プロセッサーCrusoeなどがあり、いずれもバイナリコードの互換性を実現するためコード変換機構をハードウェアやソフトウェア部分に搭載している。

またVLIWをそのまま使う汎用プロセッサーとしてはPlayStation2で使われている64ビットVLIWのEmotion Engine(に含まれるベクトル演算ユニット(VU))などがある。

AMDのGPUであるRadeonシリーズなども、VLIWのプロセッサーだったが、のちにVLIWをやめてSIMDコアとスカラ演算ユニット構成に変更された。

これは、VLIWは非常に賢いコンパイラーの存在が大前提だったが、コンパイラーの性能は思ったほど向上せず、VLIWプロセッサーの性能の足かせとなったからである。しかしそもそも、コンパイラーが、プログラム実行中のCPUよりも賢い判断をすることは出来ない。CPUは実際のデータを元に動作を予測することができるが、コンパイラーは実際の値を持たないので推論するしかなく、当然推論に失敗することもあるため必ずしも効率的なコードを吐き出さないからである。

VLIWの要求する「非常に賢いコンパイラー」とはすなわち、「入力データ無しにプログラムの結果を予測出来るコンパイラー」であり、そんなものが作れる訳が無いことを考えると、VLIWは最初から方向性を誤ったアーキテクチャーだったということができる。