この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "VLIW"
VLIW（英: Very Long Instruction Word、超長命令語）とは、プロセッサの命令セットアーキテクチャ（ISA）の一種類である。
VLIWプロセッサは、その実行ユニットが並列的に一度に実行できる、ロード・ストア・演算・分岐などの命令の複数個から成る、かなり長い命令語によってー単位の命令が構成されており、それをそのまま実行ユニットに投入する（各命令をatom、まとまったものをmoleculeなどと呼ぶこともある）。実行に複数クロック掛かるような命令もあるかもしれないが、そういったものも含めて、タイミング的に全て差し支えなく実行できるようにVLIWの機械語プログラムは書かれていなければならず、依存や順序を解決するような機構をハードウェアでは持たない。一般に、そのようなコードを生成するのはコンパイラの仕事となる。また、どうしても埋められないスロットはNOP(No Operation・何もしない）で埋め、命令語の長さは常に固定長となる。一般にVLIWプロセッサ自身はRISCのコンセプトをより押し進めたような設計であるが、以上のような「複数の機能が詰め込まれた長い固定長の命令」はマイクロプログラム方式における、いわゆる水平型マイクロプログラムを直接外に出したようなもの、といったような感じに近い。なお、「超長命令」の由来は命令語が最低でも（たとえば）128ビットといったように長いものであることからである[1]。
スーパースカラやアウトオブオーダーなどと異なり、命令列はフェッチされたそのまま実行ユニットに投入され、投入された後も並列性の分析などといった必要がない為、ハードウェアコストの低下や動作の高速化が期待される。反面、VLIWの性能を引き出すにはコンパイラが重要である。その意味でRISCよりもさらにソフトウェアに依存する側に寄ったアーキテクチャといえる。
命令セットアーキテクチャではなく、マイクロアーキテクチャを指してVLIWの語が使われることもある。
VLIWの採用例として、サーバ向けとして商品化されたマイクロプロセッサとしては、インテルがHPと開発したIA-64（Itanium）のEPICアーキテクチャがあるが（EPICは修正VLIWアーキテクチャである、などとされることもある）、IA-64については（当初もくろんだようにx86の代替としては）普及はしていない。後述するが、組込み用プロセッサではVLIW風の設計の、複数メーカの複数の製品ファミリが継続している。 VLIWという用語とそのアーキテクチャの概念は、1980年代初期に当時イェール大学のジョシュ・フィッシャー
歴史
とはいえ1980年前後には顕著であった集積回路の集積度の向上と、CGなどといった膨大な計算量が必要な応用からの要請により[2]、似たようなアイディアは他でも独立して考案されており、日本で富田眞治らがQA-1に続き1983年に完成させたQA-2などはVLIWアーキテクチャの先駆であった[3]、と、こんにちでは位置付けられている。
フィッシャーは、ニューヨーク大学の大学院生のとき、トレーススケジューリングというVLIWのコンパイル技術を開発した。VLIWが発明される以前には、機能ユニットをあらかじめソフトウェアでスケジューリングし、命令レベルの並列化をするという考え方は、水平型マイクロコードの開発過程ですでに確立していた。フィッシャーの業績は、一般的なプログラミング言語で書かれたプログラムを、水平型マイクロコードに変換するコンパイラを開発したことにある。フィッシャーの行った研究によって、ワイドイシューなマシン上で良いパフォーマンスを出すためには、基本ブロックの中だけではなく、それを超えて並列性を探す必要があることが分かった。彼は、基本ブロックを超えた並列性を見つけるためのリージョンスケジューリングも開発した。トレーススケジューリングも、そうしたスケジューリングテクニックのひとつである。このスケジューリング技術は、最も起こりそうな基本ブロックの経路を最初にスケジューリングする。そして、次に、二番目に起こりそうな経路をスケジューリングするという風に、最後までスケジューリングしていく。それぞれのスケジューリングを行うとき、投機的な動作を扱うコードも必要に応じて、挿入する。
フィッシャーが行った二つ目の革新的な業績は、ターゲットCPUのアーキテクチャは、コンパイラに向くように設計されるべきで、VLIWのコンパイラとアーキテクチャは、協調設計されなくてはならないと概念を主張したことである。このことは、イェール大学でフィッシャーが浮動小数点システム（英語版）FPS164のようなアーキテクチャ向けのコンパイラを作ることが難しかったという体験に基づいている。FPS164は、複雑な命令体系を持っているため、コード生成で最適な命令スケジューリングを実現するには、複雑なアルゴリズムを必要とした。フィッシャーは、セルフドレイン・パイプライン(self-draining pipelines)・広いマルチポートレジスタファイル・メモリアーキテクチャ（英語版）といったVLIWの設計を特徴付ける原則を開発していった。これらの原則によって、コンパイラが簡単に高速なコードを生成できる。
最初のVLIWコンパイラは、ジョン・エリスの博士論文(指導教授:フィッシャー)で述べられている[4]。 ジョン・ルッテンバーグもまた、スケジューリングに関するある重要なアルゴリズムを開発した。
1984年にイェール大学を離れたフィッシャーは、Multiflow（英語版）というスタートアップ会社を設立した。そのときの共同創立者は、ジョン・オドネルとジョン・ルッテンバーグである。Multiflowは、TRACEシリーズというVLIWのミニコンを生産し、1988年頃に販売開始した。MultiflowのVLIWは、28演算を並列に実行できた。TRACEシステムは、MSI (Medium-Scale Integration) / LSI (Large-Scale Integration) / VLSI (Very Large-Scale Integration)という異なる技術を使って実装された。こうした異なる技術を混ぜることは、あまり評判が良くなく、いずれメモリ以外の部品がひとつのチップ上に実装されるようになる。Multiflowは、少し時代を先取りしすぎていたところがある。しかし、主な半導体会社は、Multiflowの技術の価値を認め、コンパイラやアーキテクチャのライセンスを取得していた。 シリコン技術が進み、より広い実行ユニットが実装できるようになったが、初期のVLIWプロセッサ用にコンパイルされたバイナリプログラムは、より広い実行ユニットをもつプロセッサでは、実行できない。なぜなら、VLIWの命令セットは、そのプロセッサの実行ユニット数に依存していたからである。 Transmetaでは、x86アーキテクチャのCrusoeという実装において、バイナリ・バイナリソフトウェアレイヤ（コードモーフィング）で後方互換性を維持しようとした。Crusoeは、基本的に、実行時にリコンパイル・最適化・x86のオペコードへの変換をCPU内部のマシンコードで行うと言われている。したがって、Crusoeは、内部的にはVLIWプロセッサであるといえる。 インテルのItaniumアーキテクチャでは、もっと一般的な方法で、後方互換性を維持しようとしている。1つの命令は、複数のオペコードを持ち、それぞれのオペコードが、その前のVLIW命令との依存関係を示すビットフィールドが割り当てられている。このビットは、コンパイル時に設定されるので、ハードウェアが依存関係を調べる必要がなくなる。また、こうした依存関係情報を命令列の中に埋め込むことで、実行ユニット数に依存しなくなる。つまり、プロセッサは実行ユニットがもつ分だけ、依存しない命令を並列実行すればよい。 もうひとつのVLIWアーキテクチャの欠点は、常にすべての実行ユニットを使うことができず、NOP命令を実行してしまうということである。これは、そのコード内にたくさんの命令の依存関係が存在する場合に起こる。 ひとつのチップ上にのせることができるトランジスタが増えるにつれて、VLIWのこうした欠点は、あまり重要でなくなってきている。VLIWは、アプリケーションごとにカスタマイズしたプロセッサを使用できる組み込み市場で人気が出てきている。組込み向けVLIWプロセッサは、富士通のFR-V、Pixelworks
後方互換性
主なVLIWプロセッサ
Apollo PRISM（英語版）
Intel i860
Crusoe
Itanium
FR-V
Radeon HDシリーズ (HD 2xxx、HD 3xxx、HD 4xxx、HD 5xxx)
関連項目
CISC