「VLIW」の版間の差分
m 追記・リンク変更等、細部の編集 |
|||
(32人の利用者による、間の47版が非表示) | |||
1行目: | 1行目: | ||
{{出典の明記|date=2011年12月}} |
|||
[[Image:Vliwpipeline.png|thumb|300px|VLIWの[[パイプライン |
[[Image:Vliwpipeline.png|thumb|300px|VLIWの一例の、[[命令パイプライン|パイプライン]]の概念図。4個の並列に動作するEXモジュールを持ち、1ワードあたり4命令を並列に実行する。]] |
||
'''VLIW'''とは'''Very Long Instruction Word'''('''超長命令語''')の略で、[[マイクロプロセッサ]]の内部構造の一つである。ロード、ストア、演算、分岐などの命令 (atom) 複数個からなる命令語 (molecule) を構成してそれを一度に実行する。それぞれの命令は依存関係を持たないことが[[コンパイラ]]レベルで保証される。また依存性を除去できない場合はNOPを補い、常に決まった数の命令がパイプラインに投入される([[RISC]]に類似の[[パイプライン処理|パイプライン]]戦略)。「超長命令」の由来は命令語が通常128[[ビット]]などの長い固定長を持つことによる。 |
|||
'''VLIW'''({{lang-en-short|Very Long Instruction Word}}、超長命令語)とは、[[プロセッサ]]の[[命令セット]]アーキテクチャ(ISA)の一種類である。 |
|||
VLIWプロセッサは、その[[実行ユニット]]が並列的に一度に実行できる、ロード・ストア・演算・分岐などの命令の複数個から成る、かなり長い命令語によってー単位の命令が構成されており、それをそのまま実行ユニットに投入する(各命令をatom、まとまったものをmoleculeなどと呼ぶこともある)。実行に複数クロック掛かるような命令もあるかもしれないが、そういったものも含めて、タイミング的に全て差し支えなく実行できるようにVLIWの[[機械語]]プログラムは書かれていなければならず、依存や順序を解決するような機構をハードウェアでは持たない。一般に、そのようなコードを生成するのは[[コンパイラ]]の仕事となる。また、どうしても埋められないスロットはNOP(No Operation・何もしない)で埋め、命令語の長さは常に固定長となる。一般にVLIWプロセッサ自身はRISCのコンセプトをより押し進めたような設計であるが、以上のような「複数の機能が詰め込まれた長い固定長の命令」は[[マイクロプログラム方式]]における、いわゆる水平型マイクロプログラムを直接外に出したようなもの、といったような感じに近い。なお、「超長命令」の由来は命令語が最低でも(たとえば)128ビットといったように長いものであることからである<ref>[[:en:Very_long_instruction_word#Design]]のページでは少なくとも 64 ビットと記載されている。</ref>。 |
|||
⚫ | |||
⚫ | |||
命令セットアーキテクチャではなく、[[マイクロアーキテクチャ]]を指してVLIWの語が使われることもある。 |
|||
VLIWの採用例として、サーバ向けとして商品化された[[マイクロプロセッサ]]としては、インテルがHPと開発した[[IA-64]]([[Itanium]])の[[EPICアーキテクチャ]]があるが(EPICは修正VLIWアーキテクチャである、などとされることもある)、IA-64については(当初もくろんだようにx86の代替としては)普及はしていない。後述するが、組込み用プロセッサではVLIW風の設計の、複数メーカの複数の製品ファミリが継続している。 |
|||
== 歴史 == |
|||
''VLIW''という用語とそのアーキテクチャの概念は、1980年代初期に当時[[イェール大学]]の{{仮リンク|ジョシュ・フィッシャー|en|Josh Fisher}}によって考案された。 |
|||
とはいえ1980年前後には顕著であった[[集積回路]]の集積度の向上と、CGなどといった膨大な計算量が必要な応用からの要請により<ref>1980年代前半に作られたCG用並列計算システムのひとつに、日本で作られた LINKS-1(http://museum.ipsj.or.jp/computer/other/0013.html )がある。</ref>、似たようなアイディアは他でも独立して考案されており、日本で富田眞治らがQA-1に続き1983年に完成させたQA-2などはVLIWアーキテクチャの先駆であった<ref>http://museum.ipsj.or.jp/computer/other/0010.html</ref>、と、こんにちでは位置付けられている。 |
|||
フィッシャーは、[[ニューヨーク大学]]の大学院生のとき、[[トレーススケジューリング]]というVLIWのコンパイル技術を開発した。VLIWが発明される以前には、機能ユニットをあらかじめソフトウェアでスケジューリングし、命令レベルの並列化をするという考え方は、[[マイクロプログラム方式|水平型マイクロコード]]の開発過程ですでに確立していた。フィッシャーの業績は、一般的なプログラミング言語で書かれたプログラムを、水平型マイクロコードに変換するコンパイラを開発したことにある。フィッシャーの行った研究によって、ワイドイシューなマシン上で良いパフォーマンスを出すためには、[[基本ブロック]]の中だけではなく、それを超えて並列性を探す必要があることが分かった。彼は、基本ブロックを超えた並列性を見つけるための[[リージョンスケジューリング]]も開発した。[[トレーススケジューリング]]も、そうしたスケジューリングテクニックのひとつである。このスケジューリング技術は、最も起こりそうな基本ブロックの経路を最初にスケジューリングする。そして、次に、二番目に起こりそうな経路をスケジューリングするという風に、最後までスケジューリングしていく。それぞれのスケジューリングを行うとき、投機的な動作を扱うコードも必要に応じて、挿入する。 |
|||
フィッシャーが行った二つ目の革新的な業績は、ターゲットCPUのアーキテクチャは、コンパイラに向くように設計されるべきで、VLIWのコンパイラとアーキテクチャは、協調設計されなくてはならないと概念を主張したことである。このことは、イェール大学でフィッシャーが{{仮リンク|浮動小数点システム|en|Floating Point Systems}}FPS164のようなアーキテクチャ向けのコンパイラを作ることが難しかったという体験に基づいている。FPS164は、複雑な命令体系を持っているため、コード生成で最適な[[命令スケジューリング]]を実現するには、複雑なアルゴリズムを必要とした。フィッシャーは、[[セルフドレイン・パイプライン]](self-draining pipelines)・広いマルチポート[[レジスタファイル]]・{{仮リンク|メモリアーキテクチャ|en|Memory architecture}}といったVLIWの設計を特徴付ける原則を開発していった。これらの原則によって、コンパイラが簡単に高速なコードを生成できる。 |
|||
最初のVLIWコンパイラは、ジョン・エリスの博士論文(指導教授:フィッシャー)で述べられている<ref name="acmaward">[http://www.acm.org/awards/dd_citation/1985.html ACM Award]{{リンク切れ|date=2011年12月}}, [[Association for Computing Machinery|ACM]], [[1985年]]</ref>。 ジョン・ルッテンバーグもまた、スケジューリングに関するある重要なアルゴリズムを開発した。 |
|||
1984年にイェール大学を離れたフィッシャーは、{{仮リンク|Multiflow|en|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]]の[http://www.pixelworks.com/ BSP15/16]、[[STマイクロエレクトロニクス|STMicroelectronics]]の{{仮リンク|ST231|en|ST231}}、[[NXPセミコンダクターズ|NXP]]の{{仮リンク|TriMedia|en|TriMedia (mediaprocessor)}}<ref>[http://www.nxp.com/products/nexperia/home/products/media_processors/index.html Trimedia]</ref>、CEVAの{{仮リンク|CEVA-X DSP|en|CEVA-X DSP}}、 |
|||
Improv Systemsの{{仮リンク|Jazz DSP|en|Jazz DSP}}、[http://www.siliconhive.com Silicon Hive]など、多くのメーカーが開発し発売している。また、テキサス・インスツルメンツのC6xxxファミリーの{{仮リンク|TMS320|en|TMS320}} DSPもVLIWということになる。 |
|||
== 主なVLIWプロセッサ == |
== 主なVLIWプロセッサ == |
||
* {{仮リンク|Apollo PRISM|en|Apollo PRISM}} |
|||
* [[Intel i860]] |
|||
* [[Crusoe]] |
* [[Crusoe]] |
||
* [[Emotion Engine]] |
|||
* [[Itanium]] |
* [[Itanium]] |
||
* [[ |
* [[FR-V]] |
||
* [[Radeon]] HDシリーズ (HD 2xxx、HD 3xxx、HD 4xxx、HD 5xxx) |
|||
==関連項目== |
== 関連項目 == |
||
* [[CISC]] |
* [[CISC]] |
||
* [[EPICアーキテクチャ]] |
* [[EPICアーキテクチャ]] |
||
* [[IA-64]] |
|||
== 脚注 == |
|||
⚫ | |||
{{脚注ヘルプ}} |
|||
===出典=== |
|||
[[de:Very Long Instruction Word]] |
|||
{{Reflist}} |
|||
[[en:Very long instruction word]] |
|||
{{CPU technologies}} |
|||
[[eo:VLIW]] |
|||
{{Computer-stub}} |
|||
[[es:VLIW]] |
|||
{{DEFAULTSORT:へりいろんくいんすとらくしよんわあす}} |
|||
[[fi:VLIW]] |
|||
[[Category:VLIWコンピューティング|*]] |
|||
[[fr:Processeur VLIW]] |
|||
⚫ | |||
[[it:Very long instruction word]] |
|||
[[Category:命令処理]] |
|||
[[pl:VLIW]] |
|||
[[Category:命令セットアーキテクチャ]] |
|||
[[ru:VLIW]] |
|||
[[Category:1980年代]] |
2024年6月9日 (日) 08:11時点における最新版
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のBSP15/16、STMicroelectronicsのST231、NXPのTriMedia[5]、CEVAのCEVA-X DSP、 Improv SystemsのJazz DSP、Silicon Hiveなど、多くのメーカーが開発し発売している。また、テキサス・インスツルメンツのC6xxxファミリーのTMS320 DSPもVLIWということになる。
主なVLIWプロセッサ
[編集]- Apollo PRISM
- Intel i860
- Crusoe
- Itanium
- FR-V
- Radeon HDシリーズ (HD 2xxx、HD 3xxx、HD 4xxx、HD 5xxx)
関連項目
[編集]脚注
[編集]出典
[編集]- ^ en:Very_long_instruction_word#Designのページでは少なくとも 64 ビットと記載されている。
- ^ 1980年代前半に作られたCG用並列計算システムのひとつに、日本で作られた LINKS-1(http://museum.ipsj.or.jp/computer/other/0013.html )がある。
- ^ http://museum.ipsj.or.jp/computer/other/0010.html
- ^ ACM Award[リンク切れ], ACM, 1985年
- ^ Trimedia