JP2013504115A - 方法および装置および記録されたキャリア - Google Patents

Abstract

プログラマブルプロセッサが処理する命令のサブセット用の命令コンパクションスキームをそれぞれ生成する方法は、ａ）プログラマブルプロセッサで実行するソフトウェアを表す少なくとも１つの入力コードのサンプルを受信する段階であって、入力コードは第１の命令セットを定義する複数の命令を含む段階（Ｓ１）と、ｂ）除去する命令セットを空として初期化する段階（Ｓ３）と、ｃ）第１の命令セットの最もコンパクトな表現を決定する段階（Ｓ４）と、ｄ）最もコンパクトな表現のサイズを閾値と比較する段階（Ｓ５）と、ｅ）サイズが閾値より大きい場合、ステップｅ１からｅ３を実行する段階と、ｆ）段階ｂから段階ｆを繰り返す段階であって、第１の命令セットは、除去する命令セットから形成される段階（Ｓ９、Ｓ１０）とを備え、ステップｅ１からｅ３は、ｅ１）第１の命令セットのどの命令の符号化コストが最も高いかを判断する段階（Ｓ６）と、ｅ２）第１の命令セットから、最も高い符号化コストを持つ命令を除去する段階（Ｓ７）と、ｅ３）命令を除去する命令セットに追加する段階（Ｓ８）とである。
【選択図】図４

Description

本発明は、一式の命令コンパクションスキームを生成する方法に係る。

本発明はさらに、このように生成された一式の命令コンパクションスキームによりプログラムをコンパククト化する方法に係る。

本発明はさらに、これら方法を実行する用途に適するようプログラミングされた装置に係る。

本発明はさらに、装置にこれら方法のうち１以上を実行させるプログラムを含む記録キャリアに関する。

本発明はまたさらに、上述した、コンパクト化されたプログラムを実行することのできるプログラム可能プロセッサに係る。

米国特許出願公開第２００２／０４２９０９号明細書は、対応する命令セットからの命令を実行するアーキテクチャリソースを有する処理アーキテクチャで利用するプログラム命令シーケンスを生成するコンパイル方法を記載している。

公知のコンパイル方法では、第１の種類の命令ステートメントと第２の種類の命令ステートメントとを少なくとも含む複数のソースコード命令ステートメントを含むソースファイルが入力される。この方法では、第１の命令セットと第２の命令セットとを少なくとも選択する。第２の命令セットは、第１の命令セットがサポートするアーキテクチャリソースサブセットのみをサポートするよう設計されたコンパクトな命令セットである。それぞれ異なるサイズの少なくとも２つの命令セットを利用することにより、オペレーションおよびレジスタを符号化するためにコンパクトコード内に必要となるビット数が少なくなることから、コンパイラは、処理された平均コード長を低減させることができる。

公知の方法では、コンパイラは、ソースコードのタイプがタイム・クリティカルなコードか、管理コードかを検知する。管理コードとして分類されたコードを第１の命令セットで表し、コンパクトな命令セットおよびタイム・クリティカルなコードを第２の命令セットで表す。それぞれ異なるサイズの少なくとも２つの命令セットを利用することにより、オペレーションおよびレジスタを符号化するためにコンパクトコード内に必要となるビット数が少なくなることから、コンパイラは、処理された平均コード長を低減させることができる。

公知のコンパイラの欠点は、タイム・クリティカルコードおよび管理コードの識別ができないと、第１および第２の命令セットの割り当てができないことにある。

本発明の１つの目的は、より一般的な状況においても１以上の命令セットを生成することができる方法を提供することである。

本発明の第１態様では、プログラマブルプロセッサが処理する命令のサブセット用の命令コンパクションスキームをそれぞれ生成する方法は、ａ）プログラマブルプロセッサで実行するソフトウェアを表す少なくとも１つの入力コードのサンプルを受信する段階であって、入力コードは第１の命令セットを定義する複数の命令を含む段階（Ｓ１）と、ｂ）除去する命令セットを空として初期化する段階（Ｓ３）と、ｃ）第１の命令セットの最もコンパクトな表現を決定する段階（Ｓ４）と、ｄ）最もコンパクトな表現のサイズを閾値と比較する段階（Ｓ５）と、ｅ）サイズが閾値より大きい場合、ステップｅ１からｅ３を実行する段階と、ｆ）段階ｂから段階ｆを繰り返す段階であって、第１の命令セットは、除去する命令セットから形成される段階（Ｓ９、Ｓ１０）とを備え、ステップｅ１からｅ３は、ｅ１）第１の命令セットのどの命令の符号化コストが最も高いかを判断する段階（Ｓ６）と、ｅ２）第１の命令セットから、最も高い符号化コストを持つ命令を除去する段階（Ｓ７）と、ｅ３）命令を除去する命令セットに追加する段階（Ｓ８）とである。

公知の方法とは違って、この第１態様による方法は、汎用性に優れる。この方法によると、大幅に相互に対応している命令を共通のグループに分類することができて効果的である。符号化コストの高い、標準から外れた（deviating）命令は、別個のグループを形成するよう選択する。このプロセスを繰り返す。

一部の命令については、最もコンパクトな表現は、元の（コンパクト化されていないもの：uncompacted）表現であろう。ここでいう元の表現とは、「完全なビュー」とも称する。

命令コンパクションスキームの数および各命令コンパクションスキームで要求される圧縮は、固定されていてもよいし、複数の命令の中の異なる命令数、および、要求されている最小の圧縮率を示す閾値を考慮に入れた計算により自動決定されてもよい。一実施形態では、命令コンパクションスキームの数および各命令コンパクションスキームについての圧縮を、ユーザに決めさせ、ユーザがコンパクションプロセスの制御権をとり、どの仕様が最良の結果を出すかを試すようにしている。

この方法の一実施形態では、命令は、個々にコンパクト化された複数の命令フィールドを含む。個々の命令フィールドをコンパクト化することで、命令全体をコンパクト化する場合よりも大きな圧縮が得られる。２つの命令が特定の命令フィールドで同じ値を有しているが、その他の点では異なっている場合には、この命令フィールドの値は共通コードでコンパクト化して、命令全体のコンパクションには異なるコードを用いる。命令フィールドに関する情報は、プロセッサ記述ファイルから得ることが好ましい。コンパクションスキームは、プログラマブルプロセッサの一定のビューに対応している。プロセッサビューは、プロセッサのリソースのサブセットのみが利用可能なシリコンハイブコンパイラの対象として定義されている。プロセッサのリソースに関する情報は、プロセッサ記述ファイルから得られる。

本実施形態の１つの変形例では、個々にコンパクト化される複数の命令フィールドは、少なくともオペコード、書き込みポートのインデックスを示すフィールド、および、読み出しポートのインデックスを示すフィールドを含む。これらフィールドをコンパクトにすることで、コードサイズが、より低減される。加えて、結果ポート（バス）を示すフィールド、書き込みポート選択を示すフィールド、および、即値（immediate value）を含むフィールドも個々にコンパクトにすることができる。

一実施形態では、それぞれ異なるサブセットのための命令コンパクションスキーム同士が、互いに異なるコードワード幅を有しており、これらサブセットの少なくとも１つが最小コードワード幅を有している。サブセットが互いに異なるサイズを有することができる場合には、一部のサブセットを、より小さいコードワードでコンパクトにして、符号化スペースを節約することができる。一部のサブセットは、互いに異なるコンパクションスキームを有することができるが、互いに同じサイズを有するコードワードにより符号化される。

一実施形態では、各サブセットのコンパクションスキームのコードワードサイズが、１×最小コードワード幅以上の整数である。こうすることで命令の読み出しが簡単になる。命令の一部はコンパクションされないままとすることができる。これら命令の長さは、コンパクト化されていてもいなくてもよい命令をそこからフェッチしてくる命令メモリの幅に等しくてよいが、これより小さくてもよい。好適には、命令は、命令メモリの幅以下として、命令フェッチ時間を短く保つとよい。

一実施形態では、互いに異なるサブセットを、互いに異なる方法でコンパクト化する。例えば、第１のビューに従ってコンパクト化される命令は、コンパイル時間プログラマブルレジスタを利用するテーブルルックアップ・デコンパクション（拡張）を利用することができ、第２のビューに従ってコンパクト化される命令は、ハードワイヤルックアップテーブルを利用するテーブルルックアップを利用することができる。サブセットのうちの少なくとも１つが可変長コードにコンパクト化されると好適である。可変長コード（ＶＬＣ）を命令のサブセットのみに適用することで、そのサブセットの命令については高い圧縮係数が得られるという利点が一方ではあり、他方では、コード量が多くなりすぎず、このサブセット内のコードを簡単にデコンパクト化する（拡張する）ことができる、という利点もある。このコンパクションスキームが課す唯一の制約は、同じビューでコンパクト化された命令は、一定の最大長以下のサイズを有さねばならない、ということである。「ビュー」の長さ以下の長さのＶＬＣでコンパクト化された命令が、このビューに収まる。

本発明の第２態様では、第１態様における方法がさらに、複数の命令を含むプログラムを受信する段階と、各命令について、段階ａからｆで決定されたものに対応する命令コンパクションを決定する段階と、命令コンパクションに従って命令を圧縮する段階と、コンパクト化された命令を提供する段階とを備える。

このようにコンパクト化されたプログラムは、命令コンパクションスキームのセットを定義するのに利用されたものと同じプログラムであってよい。

コンパクト化された命令は、特定のアドレス範囲に分類され、命令のアドレスから、利用されているコンパクションスキームのタイプを判別することができるようになっている。

一実施形態では、第２態様による方法がさらにコンパクト化された命令を、利用されているコンパクションスキームのタイプを示す少なくとも１つのインジケータとともに提供する段階をさらに備える。これにより、コンパクト化された命令を、元のプログラムと同じシーケンスに格納することができるようになるので、処理がし易くなる。さらに、コンパクト化された命令を整列する必要がなくなる。

一実施形態では、コンパクト化された命令を、複数のセグメントを含むワードに格納して、各セグメントは、該セグメントがコンパクト化された命令の第１のセグメントであるかを示す少なくとも１つのインジケータを含んでいる。

別の実施形態では、コンパクト化された命令は、複数のセグメントを含むワードに格納して、各コンパクト化された命令が、該コンパクト化された命令内の所定の位置にインジケータを含んでおり、該インジケータは、次のコンパクト化された命令のビューを示している。これは、異なるビューによる命令同士が異なるサイズを持っていたとしても、コンパクト化された命令をデコンパクト化する命令拡張器が、コンパクト化された命令の次のコードワードを正しく適時にプリフェッチすることができるようになる、という利点を有する。

本発明の第３態様では、第１態様または第２態様による方法を実行するよう適切にプログラミングされた装置が提供される。

本発明の第４態様では、装置に、第１態様または第２態様による方法を実行させるプログラムを含む記録キャリアが提供される。

本発明の第５態様では、プログラマブルプロセッサは、第１の命令コンパクションスキームに従ってＮ個のメモリワードセグメントの第１のコードワードとしてコンパクト化された第１の命令群と、第２の命令コンパクションスキームに従ってＭ個のメモリワードセグメントの第２のコードワードとしてコンパクト化された第２の命令群とを少なくとも含むコンパクト化された命令データとして格納される命令シーケンスを有するプログラムメモリ（１０）と、命令復号器（２０）と、少なくとも１つのレジスタファイル（４０、４０ａ）と、レジスタファイル（４０ａ）に連結された少なくとも１つの発行スロット（５０）と、命令拡張器（８０）とを備え、命令拡張器（８０）は、プログラムメモリからフェッチしたコンパクト化された命令データの命令コンパクションスキームを識別するコンパクションスキーム識別器（１７）と、プログラムカウンター（ＰＣ）を受信するための入力と、プログラムメモリワードの少なくとも１つのセグメントを一時格納する格納設備（１４）と、プログラムメモリ（１０）と格納設備（１４）とから、コンパクト化された命令データを選択する選択設備（２７）と、選択されたコンパクト化された命令を、Ｋのサイズを有する拡張された命令に拡張する命令拡張ユニット（８７）と、プログラムカウンター（ＰＣ）に呼応してプログラムメモリ（ＡＤ）のアドレスを生成して、選択設備を制御する制御設備（８５）とを備え、Ｋ、Ｎ、Ｍは、１以上の整数であり、整数Ｎ、ＭはＫ以下であり、ＮおよびＭのうち少なくともいずれかがＫより小さい。

本発明の第１から第５態様は、さらに設計およびテスト設備を含んでもよい環境の一部である。

本発明のこれらおよびその他の態様は、以下に詳述されている。

従来のプログラマブルプロセッサを示す。 別の従来のプログラマブルプロセッサの一部を示す。 図２に一部が示されているプロセッサのプログラムメモリの内容を概略する。 命令コンパクションスキームのセットを決定する方法を示す。 命令コンパクションスキームのセットを生成するツールを示す。 プログラムをコンパクトにするツールを示す。 本発明によるプログラマブルプロセッサの第１の実施形態を概略する。 図７の一部をより詳しく示す。 図８の一部をより詳しく示す。 図９の一部をより詳しく示す。 図７のプロセッサで命令を処理する方法を示す。 本発明によるプログラマブルプロセッサの第２の実施形態を示す。 図１２のプロセッサで命令を処理する方法を示す。 本発明によるプログラマブルプロセッサの第３の実施形態を示す。 本発明によるプログラマブルプロセッサのハードウェア記述を生成するツールを概略する。

以下の詳細な記載では、多くの詳細を述べて、本発明の完全な理解を促す。しかし当業者であれば、本発明をこれら特定の詳細がなくても実施することができることを理解する。他の場合には、公知の方法、手順、コンポーネントは詳述を避けて、本発明の側面を曖昧にしないようにしている箇所もある。

本発明を、以下に添付図面を参照して実施形態の形で詳述する。しかし本発明は、多くの異なる形態で実施することもでき、ここに述べた実施形態に限定されるものとして解釈されるべきではない。これら実施形態は、本開示を完全に行い、当業者に本発明の範囲を完全に伝えることを目的として提供されている。あるエレメントが別のエレメントに「接続」または「連結」されている、という場合には、他のエレメントに直接接続または連結されている場合もあれば、介在するエレメントが存在する場合もある。これに対して、あるエレメントが別のエレメントに「直接接続」または「直接連結」されている、という場合には、介在するエレメントは存在しない。図面全体にわたり、同様の番号は同様のエレメントを示している。「および／または」という表現は、関連する一覧にされているアイテムの１以上の任意の全ての組み合わせを含む。

またここでは、第１、第２、第３等の用語が、様々なエレメント、コンポーネント、および／またはセクションを示すために利用される場合があるが、これらエレメント、コンポーネント、および／またはセクションは、この接頭語により限定はされないこれらの接頭語は、単にあるエレメント、コンポーネント、および／またはセクションを、別のエレメント、コンポーネント、および／またはセクションから区別する目的で利用されているにすぎない。従って第１のエレメント、コンポーネント、および／またはセクションは、本発明の教示から逸脱しない範囲であれば、第２のエレメント、コンポーネント、および／またはセクションという名称でも構わない。

そうではないと定義されていない場合には、ここで利用される全ての用語（技術、科学用語を含み）は、本発明の技術分野の当業者が等しく理解する同じ意味を有するものとする。さらに、よく利用されている辞書に定義されているような用語は、関連する技術のコンテキストの意味に合致した意味で解釈されるべきであり、そうとここで特に明記されていない限りは、理想化され、完全にフォーマルな意味で解釈されるべきではない。ここで記載する全ての公報、特許出願、特許、その他の参考文献は、その全体をここに参照として組み込む。コンフリクトがある場合には、定義を含む本明細書のほうが制御権を握る。加えて、材料、方法、および例は例示であり、限定を意図していない。

図１は、プログラマブルプロセッサを概略する。図１に示す例では、プログラマブルプロセッサはＶＬＩＷプロセッサである。ＶＬＩＷプロセッサは、ＶＬＩＷ命令ワードに分類される複数の命令ワードを並列処理する。これらは、通常、ソフトウェア開発ツールが生成により生成される。図１に示すＶＬＩＷプロセッサは、プログラムメモリ１０と、該プログラムメモリに連結された命令復号器２０とを含む。プログラムメモリ１０は、ＶＬＩＷ命令ワードを含む。ＶＬＩＷプロセッサはさらに、複数のバス７０に、第１の選択エレメント３０ａ，…，６３０ｍを介して連結された複数のレジスタファイル４０ａ，…，４０ｎを含む。１つのレジスタファイルは、１以上の入力ポートと１以上の出力ポートとを有する。１つのレジスタポートは、データ入力または出力、および、アドレス入力からなる。

明瞭化のために、図１には発行スロット５０を1つしか示していない。実際には、ＶＬＩＷプロセッサは複数の発行スロットを有する。複数の発行スロットのそれぞれが、ＶＬＩＷ命令ワードからの特定の命令ワードを処理する。１つの発行スロットは、入力データに限定されたオペレーションセットを実行することのできる１以上の機能ユニットを含む。発行スロット５０は、命令復号器５１、および、複数の機能ユニットＦＵ５３ａ，…，５３ｋ（例えば乗算器、加算器、シフタ等）を有する。発行スロット５０はさらに、様々なソース（例えば、即値を提供する復号器２０からの出力およびレジスタファイル）から入力データを選択する第２の選択エレメント５２ａ，…，５２ｋを有する。機能ユニット５３ａ，…，５３ｋおよび第２の選択エレメント５２ａ，…，５２ｋのオペレーションは、オペレーション復号器５１により制御される。プロセッサはさらに、機能ユニット５３ａ，…，５３ｋをバス７０に選択的に連結する複数の第３の選択エレメント６０ａ，…，６０ｋを含む。

命令は通常、複数の命令フィールドを含む。各フィールドが、プログラマブルプロセッサのデータパスの個々のアイテムを制御している。この特定の例では、命令は、結果ポート選択の選択（ｂｕｓ＿ｓｅｌｅｃｔ）、書き込みポートの選択（ｗｐ＿ｓｅｌｅｃｔ）、書き込みポートのインデックスの指定（ｗｐ＿ｉｎｄｅｘ）、読み出しポートのインデックスの選択（ｒｐ＿ｉｎｄｅｘ）、および、即値の指定、という６つの命令フィールドをオペコード用に含んでいてよい。

通常、各発行スロットは１つのオペコード命令フィールドを有している。このフィールドは、該発行スロットが実行するべきオペレーションを選択する。オペレーションは、発行スロットの機能ユニットのうちの１つにより実行される。オペコードは、機能ユニット選択信号およびオペレーションタイプ（オペタイプ）へと復号されて、特定のＦＵおよび該ＦＵの特定のオペレーションを起動する。ときには、発行スロットが１つのオペレーションの処理（例えば即値のロード等）のみに特化している場合等、オペコードが存在しない場合もある。

１を越える数の発行スロット出力を有する各バスは、別個のｂｕｓ＿ｓｅｌｅｃｔフィールドを有して、バスに接続する発行スロット出力を示す。

各レジスタファイル入力ポートは、１以上のバスに接続されている。１を超える数のバスが１つの書き込みポートに接続されている場合には、マルチプレクサが、レジスタファイルの入力ポートに接続する、正しいバスを選択する。書き込みポート選択（ｗｐ＿ｓｅｌ）命令フィールドは、このマルチプレクサのための選択値を含んでいる。特別なコードｗｐ＿ｓｅｌ＝"１１．．１１"を利用すると、この書き込みポートには書き込み処理を行うべきではないことを示すことができる。

この命令フィールドは、レジスタファイルに書き込まれるレジスタのアドレスを含んでいる。各レジスタ書き込みポートは、それぞれ別個のｗｐ＿ｉｎｄｅｘを有している。

この命令フィールドは、レジスタファイルから読み出されるレジスタのアドレスを含んでいる。各レジスタ読み出しポートは、それぞれ別個のｒｐ＿ｉｎｄｅｘを有している。

即値命令フィールドは、発行スロットの機能ユニットのいずれかに対する入力として利用されうる値を含んでいる。

本発明によらないコードコンパクションの１つの方法に即値オーバレイ（immediate overlaying）と称されるものがあり、これは、発行スロットの機能ユニットの入力が、レジスタファイル出力または即値フィールドを入力として利用できる、という事実に基づいたものである。オペタイプは、入力が何であるかを判断し、これは命令ごとに異なりうる。オペコードが、レジスタファイル出力がオペレーションに利用される旨を示している場合には、その発行スロットの即値フィールドは冗長なものになる。従って、即値が入力として選択されている場合は、その発行スロットの入力に接続されているレジスタ出力ポートのレジスタインデックスフィールドが冗長である、ということである。この即値フィールドおよびこのレジスタインデックスフィールドは、同じ命令内では決して利用されないので、これら２つのフィールドを組み合わせることができる。この即値とレジスタインデックスフィールドの（一部の）組み合わせが、即値オーバレイと称されている。

コードコンパクションの別の方法に、互いに異なるビューを利用するものがある。プロセッサビューとは、プロセッサのリソースのサブセットのみを利用可能とする、コンパイラの対象として定義されている。このサブセットは、（１）レジスタファイル特性：入出力ポート数、アドレス範囲、（２）機能ユニット特性：即値範囲、オペコード数、（３）バスの数、（４）完全な発行スロット、機能ユニット、レジスタファイル等の制限により定義される。

コードコンパクションの観点からは、プロセッサビューは、サブセットを制御する命令ビット数が、完全なプロセッサの命令ビット数より大幅に少ない場合に有用である。プロセッサは、１を越える数のビューを有することができる。

ビューのメカニズムをサポートするハードウェアを図２に示す。第１のビュー（ビュー０）では、プロセッサの全てのリソースが利用可能である。プログラムメモリワードは単一の命令を含んでいる。第２のビュー（ビュー１）では、各プログラムメモリワードが２つのコンパクト化された命令を含んでいる。第３のビュー（ビュー２）では、各プログラムメモリワードが４つのコンパクト化された命令を含んでおり、これは図３に概略されている。

完全なビューは、プログラムメモリ幅に必ずしも等しくなくてよい。場合によっては、小さいビューでも圧縮が良好に行われるように、より幅広のプログラムメモリを選択するほうが好ましい場合がある。例えば、プロセッサの全幅が６０ビットであり、より小さなビューが１６ビット幅である場合を想定する。６０というプログラムメモリ幅とすると、小さいほうのビューは６０／１６＝３．７５の圧縮となる。これは、２の１乗までに切り捨てられる必要があり、これにより２という圧縮率になる。プログラムメモリの幅が６４である場合には、圧縮率は４になる。

図３では、ビュー０の命令が通常配置されており、アドレス０から始まっている。ビュー０の命令については、ＰＣはプログラムメモリアドレスに等しい。ビュー１の命令は、プログラムメモリアドレス０ｘ１Ｂから始まる。ビュー１の第１の命令のプログラムカウンタは、値０を有する１つのＬＳＢ（低位半分のプログラムメモリワード０ｘ１Ｂに命令が含まれている旨を示している）、値が"０１"の２つのＭＳＢ（この命令がビュー１命令である旨を示している）、および、プログラムメモリアドレス０ｘ１Ｂに等しい中間のビットから形成されている。この結果、ＰＣについて０ｘ１０３６となる。後続命令のＰＣ値は、ＰＣを増分することで得られる。アドレス０ｘ２Ａからがビュー２の命令となっている。第１のビュー２命令のＰＣ値は、値"００"であり、ワード内の４つのコンパクト化された命令から１つ目を選択するための値"００である"２ｌｓｂ、メモリアドレス："０ｘ２Ａ"および値２の２つのＭＳＢ（ビュー番号を表す）から形成される。この結果、０ｘ２１５０となる。

図２に示すように、ビューのメカニズムをサポートするハードウェアは、第１および第２のコンパクト化された命令セレクタ２２、２３、第１および第２の命令デコンパクションユニット２４、２５、および、完全な命令セレクタ２６を含む。プログラムを走らせる場合、プロセッサは、プログラムカウンタ（ＰＣ）１２で実行する命令を示す。プログラムカウンタ１２の出力は、第１および第２の命令デコンパクションユニット２４、２５を制御する第１の部分１２ａ、要求されているプログラムメモリワードをアドレス指定する第２の部分１２ｂ、および、完全な命令セレクタ２６を制御する第３の部分１２ｃを有する。部分１２ｃはビュー選択を示している。完全なビューモードでは、ＰＣがプログラムメモリアドレスに等しい。完全なビュー（ビュー０）のプログラムメモリワードは、完全な命令を正確に１つ含む。完全な命令セレクタ２６は単に、この命令を命令復号器に渡す。

「コンパクト化されたビュー」モードでは、ＰＣは、プログラムメモリアドレスに直接マッピングすることができない。この場合、ＰＣの部分１２ａは、プログラムメモリワードのどの命令を選択する必要があるか示している。部分１２ｂのアドレスが示すプログラムメモリワードが読み出される場合には、プログラムカウンタの部分１２ａが制御する第１および第２のコンパクト化された命令セレクタ２２、２３が選択するコンパクト化された命令を、命令デコンパクションユニット２４、２５に抽出する。

命令デコンパクションユニット２４、２５は、コンパクト化された命令を完全な命令に翻訳する。

プロセッサの特定のビューに対応する、実装されたコンパクションスキームそれぞれについて、命令デコンパクター２４、２５を実装する。デコンパクター２４、２５の出力は、完全な命令セレクタ２６の入力となる。ＰＣの部分１２ｃ（ｖｉｅｗ＿ｓｅｌｅｃｔ）は、完全な命令セレクタ２６のどの入力を、命令セレクタ２６の出力として選択するかを決定する。

図２および図３を参照して上述したコードコンパクション方法では、プログラマが、どのコードをどのビューで走らせる必要があるかを定義している。基本構築ブロックの全ての命令は１つのビューを対象とする必要がある。ビュー間の切り替えは、ジャンプオペレーションによってのみ可能となる。これは、ジャンプ命令によってのみ行われる。命令選択およびスケジューリングの後に、アセンブラがコンパクト化された命令を定義して、コンパクト化された命令を１つのプログラムメモリワードにどのように配置するかを決定する。リンカが、各構築されたワードについてのプログラムメモリアドレスを定義する。一般的には、１つのビューに対する命令はひとまとめに分類される。あるグループの第１の命令は、常にプログラムメモリワードのビット０から始まる。そして同じ基本構築ブロック内の後続する命令は、プログラムメモリワード内に後続して配置され、コンパクト化された命令のサイズを圧縮率で乗算した値がプログラムメモリ幅より小さい場合には、それらの間にダミービットを充填する。ワードが完全幅である場合には、次の命令を次のプログラムメモリワードのビット０に配置する。

図４は、プログラマブルプロセッサが処理する命令のサブセットに対してそれぞれ命令コンパクションスキームを生成する、本発明による方法を概略する。本方法は、プログラマブルプロセッサで実行するソフトウェアを表す少なくとも１つの入力コードのサンプルを受信する第１のステップであって（Ｓ１）、入力コードは、第１の命令セットを定義する複数の命令を含む第１のステップを含む（Ｓ１）。

示されている実施形態では、方法は、ユーザに対して、命令コンパクションスキームの数と、各命令コンパクションスキームについて必要な最小圧縮とを指定するように要求する、第２のステップＳ２も含む。このようにして、ユーザは、コンパクションプロセスの制御権を握り、どの仕様が最良の結果をもたらすかを試すことができる。ステップＳ２は必須のステップではない。この代わりに、命令コンパクションスキームの数、および、命令コンパクションスキームごとに必要な圧縮を、固定しておくこともできる。また別の実施形態では、命令コンパクションスキームの数、および、命令コンパクションスキームごとに必要な圧縮を、複数の命令における異なる命令の数および閾値を考慮して自動決定することもできる。

第３のステップ（Ｓ３）では、除去する命令セットを定義して、この除去する命令セットは、空のセットとして初期化される。

ステップＳ４では、第１の命令セットの最もコンパクトな表現を決定する。

ステップＳ５で、最もコンパクトな表現のサイズを閾値と比較する。この比較結果に基づいて、ステップＳ５の後に、ステップＳ６からＳ８を実行する、または、ステップＳ９からＳ１０を実行する。最もコンパクトな表現のサイズが、閾値より大きい場合には、Ｓ６からＳ８を実行して、そうではない場合にはＳ９からＳ１０を実行する。

ステップＳ６では、第１の命令セットのうちのどの命令の符号化コストが最も高いかを判断する。次いでステップＳ７で、この命令を第１の命令セットから除去して、ステップＳ８で、除去した命令セットに追加する。プログラムフローは次にステップＳ４に続く。

最もコンパクトな表現のサイズが閾値以下であると判断された場合には、第１の命令セットを、除去された命令セットとして再定義して（ステップＳ９）、除去された命令セットを空として再定義する（ステップＳ１０）。

本発明の第１態様による方法は、図５に示すビュー生成ツールＶＧで利用することができる。ここに示すように、ビュー生成ツールは、ビュー独立再配置可能オブジェクトファイル１１５（例えばＥＬＦ（実行言語フォーマット）内のもの）から始まる。ビュー独立再配置可能オブジェクトファイル１１５は、プロセッサが実行すべき通常のソフトウェアアプリケーションから取得することができる。再配置可能オブジェクトファイル１１５は、圧縮後に、選択されたプログラムメモリに正確に理想的に収まる。オブジェクトファイル１１５は、リンクステップにより生じ、このなかにプログラムに必要な全てのモジュールが統合されている。ファイル１１５は、ジャンプの対象およびデータオブジェクトのシンボルを含んでいる。ビュー生成ツールＶＧは、シンボルを個々の値として取り扱うべきである。これは真実ではない場合もあるが、２つの異なるシンボルが常に互いに異なる値として参照されることが想定されている。一実施形態では、ビュー生成ツールＶＧは、同じ値のシンボルを識別するために予め再配置処理をしておくことができる。潜在的にこれにより、表のエントリ数を減らすことができるので、圧縮率が向上する。

示されている実施形態では、プロセッサ記述ファイル１０５も提供されている。プロセッサ記述ファイル１０５は、別々にコンパクト化することができる命令フィールドに命令を如何に分割するかについての情報を提供して、最適な命令コンパクションスキームセットを探すための検索スペースの低減を促す。プロセッサのプロセッサ記述ファイル１０５は、第１のアーキテクチャパラメータ抽出（ＡＰＥＸ）モジュール１２０によって、静止時間命令フォーマット（ＴＳＩＦ：time stationary instruction format）データ構造１２５へと変換される。ＡＰＥＸモジュール１２０は、プロセッサのハードウェア記述に定義されているパラメータを抽出するためのアプリケーションプログラマインタフェース（ＡＰＩ）を提供する。このＡＰＩは、プロセッサのハードウェアを構築する際に、ハードウェア構築ブロックライブラリの利用により利用される。ＴＳＩＦデータ構造１２５およびビュー独立再配置可能オブジェクトファイル１１５は、ビュー生成モジュール１３０に提供されるが、これについては後述する。ビュー生成モジュール１３０はビュー定義ファイル１３５を生成する。

ビュー生成モジュール１３０の一実施形態の通常の実装例を以下の擬似コードで示す。この実施形態では、命令コンパクションスキームセットは、再配置可能オブジェクトファイル１１５によってのみ決定される。

ビュー定義ファイル１３５は、好適には以下の情報を含んでいる。

図５に示すビュー生成ツールＶＧは、このプログラマブルプロセッサ上に走らせることが意図されている代表的なプログラムに高い圧縮率が達成されるように、プログラマブルプロセッサのビューを定義する。デコンパクション用のハードウェアが「入手可能（affordable）」であるべきである（つまり、ゲートカウントおよび／またはタイミング数値を超えていてはならない）。

ビュー生成ツールは、命令コンパクションスキームセットを１つ生成する。以下の記載では、各命令コンパクションスキームが、プロセッサの特定のビューに対応していることを想定している。または、命令コンパクションスキームは、プロセッサのビューから独立して決定されてもよい。

ツールＶＧは、ユーザが提供するソフトウェアカーネル１１５を利用してビューを生成する。このソフトウェアカーネルは、プロセッサの（将来の）利用の代表であることを想定している。これは、十分な大きさを持ち、プロセッサの全ての側面が可能（address all aspects）であるべきである。例えば、プロセッサがカスタムオペレーションを含んでいる場合、実際にこれらカスタムオペレーションを利用するカーネルを提供することを推奨する。ユーザは、ビューの数およびビューごとの圧縮を示すことで、ビュー生成プロセスを微調整することができる。ビュー生成ツールＶＧは、供給されるソフトウェアカーネルを走らせるプロセッサの最適なビューを生成することを目標としている。最適なビューとは、最高の圧縮率をもたらすことのできるビューと考えられる。カーネルは、単一のファイルとして供給されるべきである（例えば、ジャンプの対象のシンボルを有するＥＬＦ（実行言語フォーマット）で）。

ツールＶＧは、全ての命令を読み出して、個々の命令フィールドそれぞれを格納する。そして、いわゆる最小ビューを決定する。この最小ビューは、プログラムの全ての命令を実行可能な最小のビューとして定義される。通常は、最小ビューの幅は、元の完全なビューの幅より小さい。最小ビューは、一定の数のエントリを有する各命令フィールドの表からなる。エントリの２を底とする対数値は、その命令フィールドのコンパクト化された幅に等しい。コンパクト化された命令フィールド幅の合計は、コンパクト化された命令の幅に等しい。ユーザは、圧縮率を定義することで、ビューのサイズに制約を課すことができる。ビュー生成ツールＶＧの目的は、この圧縮率および命令セットが与えられたときに、最適なビューを定義することである。最適なビューとは、供給されているセットから最大の命令数をマッピングすることができるビューとして定義される。

最小ビューを作成した後に、供給されたセットから１つの命令を除去して、最小ビューを作成しなおす。次いで、次の命令を除去してから、再度、最小ビューを作成しなおす。命令を除去すると、普通は最小ビューが小さくなる。命令を除去して、最小ビューを再計算する処理は、最小ビューのサイズが、ユーザが意図している目標に達するまで続けられる。次に、第１のビューに収まらない命令から始めて、次のビューを生成することができる。この処理での主な課題は、「どの命令を除去候補とするか」である。

この課題は、各命令のコスト基準を計算して、最も高いコストであるものを除去対象として選択する、ということで解決することができる。アルゴリズムの目的は、最小ビューのビット数を減らすことなので、コストもビット数で表す。最小ビューに必要なビット量は、このビューに収まる全ての命令の結果である。この命令は、表の異なるエントリとなる、それぞれ異なる命令フィールド値を有する。表における異なるエントリの量がビット数を定義する。こうして、ある命令の命令フィールドに応じて、全ての他の命令の命令フィールドとの関連において、ある命令のコストは高くも低くもなる。

定義上は、全ての命令のコストは、最小ビューに必要なビット量に等しくなるはずである。１つの命令のコストは、それが含む全命令フィールドのコストの合計に等しくなるはずである。１つの命令フィールドのコストは、該命令フィールドの値の、全ての命令のフィールド値における頻度に従って決まる。フィールドの値が稀である場合（頻度が低い場合）には、このフィールドの表のエントリを利用する命令が少ないことなので、コストも高くなる。フィールド値がよく利用される場合（頻度が高い場合）には、より多くの他の命令がこの表のエントリを利用するということなので、コストが低くなる。これら２つの場合の１つの表のエントリのコストは等しいが、よく利用される値の場合、コストは数多くの命令により分担負担され、稀な値の場合には、コストは少ない命令で分担負担されることになるので、１つの命令に対するコストが高くなる。

定義上は、１つの命令フィールドの、全ての命令におけるコストは、その命令フィールドの幅に等しい。１つの命令フィールド値のコストが、頻度の繰り返し（reciproke）に応じて決まる場合、全ての命令にわたり１つの命令フィールドついて一定である乗数で補償する必要がある。

公式で表すと、ＮＤ_ｉｆを、全ての命令における１つの命令フィールド_ｉｆの異なる値の数として、ｆ_ｉｆｖを、全ての命令における命令フィールド値ｉｆｖの頻度として、ｂ_ｉｆを命令フィールド_ｉｆのビット数として、ｃｏｓｔ_ｉｆｖを命令フィールド値ｉｆｖのコストとする場合、Ｃｏｓｔ_ｉｆｖ＝ｂ_ｉｆ／ｆ_ｉｆｖ・ＮＤ_ｉｆとなる。

命令フィールド値コスト関数は、以下の表１Ａ、１Ｂに一例が示されている。

この例は、１１個の命令（ｉｎｓｒ＿ｎｒ）からなる小さなプログラムに基づいている。第１の表１Ａは、１１個の命令についての命令フィールド値を示している。第２の表１Ｂは、列である表のエントリに示されるもののうちどの命令フィールド値（ｉｎｓｔｒ＿ｆｌｄ＿ｖｌ）を表に格納するかを示している。第２の表も、命令フィールド値の頻度（ｆｒｅｑ２）を示している（つまり、そのエントリをどのくらいの頻度でプログラムが利用しているか、を示している）。第１の表の頻度の列（ｆｒｅｑ１）は、第２の表の「表のエントリ」列の命令フィールド値（ｉｎｓｔｒ＿ｆｌｄ＿ｖｌ）の頻度（ｆｒｅｑ２）の検索結果である。頻度（ｆｒｅｑ２）では、異なるエントリの数およびフィールド幅、各命令フィールドのコストを、第１の表の「コスト」の列が示すように計算することができる。この場合、少なくとも一度生じる異なるエントリの数ＮＤは４となる。８つの可能性のある命令フィールド値があることから、フィールド幅（つまり、そのフィールドのビット数）は３である。第１の表の一番下の行は、全ての命令フィールドコストの合計を示している。定義上は、これがフィールド幅に等しくなる。

容易に理解されるだろうように、低い頻度の命令フィールド値は、高い頻度の値よりもコストに対して貢献度が高い。これら表は、さらに、各表のエントリのコストが等しい、ということも示している。表のエントリ５は、命令３と命令６とに、計２回生じている。両方のケースで、コストは０．３７５であるので、エントリコストは、２＊０．３７５＝０．７５となる。表のエントリ２は、命令５、８、および９に、計３度生じている。命令１つについてコストが０．２５なので、エントリコストは、３＊０．２５＝０．７５となり、エントリ５と等しくなる。

本発明によれば、ビューの選択は、基本ブロックレベルでは生じず、命令レベルで生じる。従って、次のビューを各命令に対して別個に選択することができる。命令に基づくビューの選択を導入することで、ビューの生成における検索スペースはより広くなる。以前には、プログラマがどのプログラムをどのビューに適用するか、について明確な構想を持つ必要があったが、今ではプログラマはビューに煩わされなくなる。これにより、プロセッサ設計者は、「論理的な」ビューを生成する務めから解放される。ビューの生成は、本発明の第１態様による方法で自動に実行することができる。

命令コンパクションスキームセットを生成すると、プログラマブルプロセッサのプログラムは、図６に示すようにコンパクト化することができる。

通常、プログラムは１を超える数のモジュールから形成されている。モジュール１つについて、アセンブリ（．ｓ）ファイル１６５ａ，…，１６５ｎがスケジューラにより生成される。これらのアセンブリファイルは、アセンブラ１７０によって、ＥＬＦフォーマットの再配置可能オブジェクトファイル１７５ａ，…，１７５ｎに変換される。アセンブラ１７０は、命令の命令フィールド値を定義するために、プロセッサ記述１０５とＡＰＥＸ ＴＳＩＦデータ構造１２５とを必要とする。アセンブラ１７０の出力は、即値フィールドを除いて、全ての命令フィールドの固定値を含んでいる。即値フィールドは、固定値およびシンボルを両方含んでよい。これらシンボルは、分岐対象またはデータオブジェクトを参照することができる。

リンカ１８０は、アセンブラが生成した再配置可能オブジェクトファイル１７５ａ，…，１７５ｎを１つの再配置可能オブジェクトファイル１８５に統合する。即値フィールドの再配置可能シンボルは、シンボルにとどまり、シンボルの定義のみが適合されてよい。

コンパクションツール１９０は、コンパクト化されていない、再配置可能オブジェクトファイル１８５の形式のプログラムを、コンパクト化されたプログラムへと変換する。コンパクト化されていないプログラム１８５は、ＥＦＬ再配置可能オブジェクトファイルの形式でデコンパクションツール１９０に入る。ツールコンパクション１９０は、ビュー定義および完全な命令フォーマットを、ＡＰＥＸによって取得する。ＡＰＥＸは、プロセッサ記述ファイル１０５から情報を収集して、ビュー記述ファイルを形成する。ビュー生成ツールＶＧ同様に、コンパクションツール１９０は、再配置可能シンボルをそれぞれ個々の値として扱う必要がある。一実施形態では、互いに異なるシンボルは常に、互いに異なる値を参照する。好適な実施形態では、コンパクションツール１９０は、再配置前処理（pre relocation）を適用して、同じ値を有するシンボルを識別する。一般的には、これによりプログラムにおける圧縮率が向上する。

プログラムをコンパクト化する間、コンパクションツール１９０は、シンボルを、あたかも通常の値のように表に配置しておく。ツール１９０がこれをサポートする。コンパクションプロセスは（１）ビューｉｄと命令ごとの（コンパクト化された）命令値とを含むコンパクト化されたプログラム１９５、（２）該プログラムについてのビューの表の内容１９７、という２つの結果を生じて、終了する。

ビューの表１９７は再配置可能シンボルを含んでいるが、コンパクト化された表１９５はこれを含まない。

コンパクト化されたプログラム１９５は、プログラムメモリマップに配置される。この例は続きに示される。結果は、ＥＬＦオブジェクトファイルに変換されるべきである。ビューの表の内容もこのオブジェクトファイルに配置されるべきである。

リンカ２００は、表のコンテンツのシンボルの再配置を実行して、オブジェクトファイルをバイナリ表現２０５に転じる（transfer）。

プログラマブルプロセッサが命令をコンパクト化するために利用するビューを識別する手助けをするために、コンパクト化された命令データは、ビュー識別データを有すると好適である。２つの例を以下に示す。

第１の実施形態では、余分のビットをプログラムメモリワードの各セグメントに追加する。１つのセグメントは最小ビューのサイズを有している。追加するビット数は、同じサイズのビューの数に応じて決まる。１つのビット（Ｓ）は、そのセグメントが命令の開始（Ｓ＝１）であるか否かを示している。コンパクト化された命令の長さは、セグメントシーケンスのこれら開始ビットに基づいて決定することができる。同じサイズの複数のビューがソフトウェアのコンパクションに利用される場合には、余分なビットを追加して、正しいビューｉｄを識別する。例えばあるプロセッサが、完全なビューサイズの１／８のサイズを有する最小ビューを持っており、最大の２つのビューが同じサイズである場合を想定する。この場合、２つのビットをセグメント１つについて追加する必要がある。必要となるプログラムメモリビットの総数は、ＰＭｓｉｚｅ＊８＊２＝１６＊ＰＭｓｉｚｅとなり、ここでＰＭｓｉｚｅは、そのプログラムメモリ内のメモリワード数である。この構成では、情報からビュー情報を入手可能なので、もはやプログラムカウンタがビュー情報を含む必要がない。その代わりに、プログラムカウンタは、プログラムメモリの開始セグメントアドレスに等しくなる。

このことを以下の表を参照して説明する。表に示す例では、最小ビューが、１／４の圧縮率を有しており、最大の２つのビューが同じサイズである。さらに、２つのビットＳ、Ｖがセグメント１つについて追加されている。表２は、１１個の命令のシーケンスの一部の命令情報を示している。第１の列がシーケンスの命令の位置を示しており、第２の列が、命令に対応するビューを示しており、第３の列が、命令の長さを示しており、第４の列がビューのビットを示している。この例では、プロセッサは、完全なビューを含む６つのビュー（０，…，５）を促進している。ビュー３と４とが両方とも同じ長さ（３セグメント）であり、さらに、ビュー１と５とが同じ長さ（１セグメント）である。１つの命令の長さは、開始セグメントビットから（ビュー０と２について）導出することができ、この長さによりビューが直接決定される。この長さの次の１、３，４および５のビューについては、ビューを決定するためにはビューのビットが必要となる。

表３は、プログラムメモリにおける命令の配置法を示している。各セグメントは、そのセグメントが新たな命令（１）の開始部であるか、開始部が前のセグメントにあるような命令の一部を含んでいるか、を示す開始セグメントビットＳを有している。命令の長さでこの情報が示されていない場合を想定して、各セグメントは、開始セグメントビットの次に、命令のビューを示すビューのビットＶを有している。ビューのビットは、開始セグメントについてのみ必要である。１セグメントよりも長い命令については、ビューの情報を、各セグメントのビューのビットで分割することができる。これは、２を超える数のビューが同じ長さである場合に有用である。

図７は、本発明によるプログラマブルプロセッサを概略する。この図に示すプログラマブルプロセッサは、上述した命令シーケンスを格納するプログラムメモリ１０を含む。コンパクト化された命令データは少なくとも、Ｎ個のメモリワードセグメントの第１のコードワードとして、第１の命令コンパクションスキームによりコンパクト化された第１の命令と、Ｍ個のメモリワードセグメントの第２のコードワードとして、第２の命令コンパクションスキームによりコンパクト化された第２の命令とを含み、ＮとＭとは、互いに異なる、１以上の整数である。この場合、コンパクト化された命令データは、６つの異なるフォーマットでコンパクト化された命令を含む。

プログラマブルプロセッサはさらに、命令復号器２０、少なくとも１つのレジスタファイル４０、および、レジスタファイル４０に連結された少なくとも１つの発行スロット５０を含む。さらにプログラマブルプロセッサは、データ選択エレメント３０を含む。データ選択エレメント３０、レジスタファイル４０、および、少なくとも１つの発行スロット５０は、命令復号器２０によって制御される。プログラマブルプロセッサは、これより多い数の発行スロットを含むこともでき、この場合、各発行スロットが複数の機能ユニットを含んでよい。格納エレメント（like storage elements）、処理エレメント、および、選択エレメント等のさらなるデータ処理エレメントが存在していてもよい。

プログラマブルプロセッサはさらに、命令拡張器８０を含む。命令拡張器８０は、プログラムメモリ１０からフェッチしたコンパクト化された命令データそれぞれに利用される命令コンパクションスキームを識別するコンパクションスキーム識別器１７を含む。命令拡張器８０は、命令復号器２０が生成するプログラムカウンタＰＣを受信するための入力を有する。プログラマブルプロセッサはさらに、プログラムメモリワードの少なくとも１つのセグメントを一時格納するための格納設備１４と、プログラムメモリ１０および格納設備１４からコンパクト化された命令データを選択するために選択設備（マルチプレクサユニット）２７とを含む。選択された、コンパクト化された命令は、命令拡張ユニット８７により拡張される。命令拡張器８０はさらに、プログラムカウンタＰＣに呼応して、プログラムメモリ１０のアドレスＡＤを生成する制御設備８５を含む。制御設備８５はさらに、信号Ｓｅｌで選択設備２７を制御して、読み出しイネーブル信号Ｒｅｎで格納設備１４を制御する。

本発明によるプログラマブルプロセッサでは、好適には、ビューそれぞれの任意の（コンパクト化された）命令が１つのメモリワードの任意のセグメントから始められてよい。このような構成は、プログラムメモリと命令拡張ユニット８７との間に格納エレメント１４を配置する構成により達成される。こうすることで、２つの連続したメモリワードにまたがり格納される命令をサポートすることができるようになる。

図８は、命令拡張器８０を含む図７のプログラマブルプロセッサの第１の実施形態の一部をより詳しく示す図である。

第１の実施形態では、プログラムメモリ１０が、セグメント０、セグメント１、セグメント２、およびセグメント３のプログラムデータを、出力Ｐ０、Ｐ１、Ｐ２、およびＰ３でそれぞれ提供する。格納エレメント１４は、プログラムメモリ１０が提供するプログラムデータの一部を遅延させる。この場合、格納エレメント１４は、プログラムメモリ１０の出力Ｐ３、Ｐ２、およびＰ１からそれぞれ遅延されたプログラムデータＲ２、Ｒ１、およびＲ０を提供する。マルチプレクサユニット２７は、プログラムメモリ１０および格納エレメント１４が提供するプログラムデータの一部を、制御を受けながら選択する。本実施形態では、マルチプレクサユニット２７は、複数のマルチプレクサモジュール２７ａ、２７ｂ、２７ｃ、２７ｄを含む。マルチプレクサモジュール２７ａ、２７ｂ、２７ｃ、２７ｄはそれぞれ、選択信号ｓｅｌ０、ｓｅｌ１、ｓｅｌ２、ｓｅｌ３により制御される。マルチプレクサモジュール２７ａ、２７ｂ、２７ｃ、２７ｄはそれぞれ、プログラムメモリ１０の出力Ｐ０、Ｐ１、Ｐ２、Ｐ３に連結される。第１のマルチプレクサモジュール２７ａは、追加として格納エレメント１４の出力Ｒ０、Ｒ１、Ｒ２に連結される。第２のマルチプレクサモジュール２７ｂは、追加として格納エレメント１４の出力Ｒ１およびＲ２に連結される。第３のマルチプレクサモジュール２７ｃは、追加として格納エレメント１４の出力Ｒ２に連結される。

本実施形態では、コンパクションスキーム識別器１７は、プログラムメモリ１０に直接連結される。

命令拡張ユニット８７の入力は、（コンパクト化された）命令を含む１以上のセグメントにより形成される。この命令は、プログラムメモリ１０のある位置に格納される。１つのプログラムメモリワードは、ｎ個（ここでは４個の）セグメントを含む。命令は、１以上のセグメントの長さであってよく、１つの命令のセグメントは、異なる（しかし後続する）プログラムメモリワードであってよい。マルチプレクサユニット２７は、命令拡張ユニット８７が、プログラムメモリワードから直接（つまり、レジスタを介さずに）読み出すことを可能とする。プログラムメモリワードをまたぐ命令（program memory word crossing instructions）をサポートするためには、レジスタ１４が、前のメモリワードを格納しておくべきである。最大命令長がｎセグメントである場合には、ｎ−１個のセグメントのみを格納する必要がある。

図９に示すように、出力Ｏ０．．Ｏｎ−２が、命令拡張ユニット８７の様々な命令拡張モジュール８７１−８７８に接続されている。Ｏ０は、全ての命令拡張モジュールにより利用され、Ｏ１．．Ｏｎ−２は、ビューサイズによりそれが必要な場合にのみ接続される。Ｏｎ−１は、コンパクト化されていない命令のみに利用される。

命令拡張モジュール８７１−８７８それぞれは、図１０の命令拡張モジュール８７３の例に示すように、複数の命令デコンパクションセグメント８７３ａ，…，８７３ｆを含む。ここでは、デコンパクションモジュール８７３は、コンパクト化されたオペコードであるｏｐｃｏｄｅ−ｓを、デコンパクト化されたオペコードであるｏｐｃｏｄｅ−ｗに変換するオペコードデコンパクションセグメント８７３ａと、コンパクト化された即値であるｉｍｍｅｄｉａｔｅ−ｓをデコンパクト化された即値であるｉｍｍｅｄｉａｔｅ−ｗに変換する即値デコンパクションセグメント８７３ｂと、コンパクト化された書き込みポート選択ｗｐ＿ｓｅｌｅｃｔ−ｓを、デコンパクト化されたｗｐ＿ｓｅｌｅｃｔ−ｗに変換する書き込みポート選択デコンパクションセグメント８７３ｃと、音波クトかされたバス選択「ｂｕｓ＿ｓｅｌｅｃｔ−ｓ」を、デコンパクト化された「ｂｕｓ＿ｓｅｌｅｃｔ−ｗ」にデコンパクト化するバス選択デコンパクションセグメント８７３ｄと、コンパクト化された書き込みポートインデックス「ｗｐ＿ｉｎｄｅｘ−ｓ」をデコンパクト化された「ｗｐ＿ｉｎｄｅｘ−ｗ」にデコンパクト化する書き込みポートインデックスデコンパクションセグメント８７３ｅと、コンパクト化された読み出しポートインデックス「ｒｐ＿ｉｎｄｅｘ−ｓ」をデコンパクト化された「ｒｐ＿ｉｎｄｅｘ−ｗ」にデコンパクト化する読み出しポートインデックスデコンパクションセグメント８７３ｆとを含む。

オペコードデコンパクションセグメント８７３ａ、バス選択デコンパクションセグメント８７３ｄ、および書き込みポート選択デコンパクションセグメント８７３ｅは、例えばルックアップテーブル（ＬＵＴ）により実装される。書き込みポートインデックスデコンパクションセグメント８７３ｅおよび読み出しポートインデックスデコンパクションセグメント８７３ｆは、０またはより多くの「０」ビットを命令フィールドの最上位側に追加するゼロ拡張セグメントにより実装されてよい。即値デコンパクションセグメント８７３ｂは、命令のオペコードに応じて符号拡張またはゼロ拡張（sign extension or zero extension）を実行する。

レジスタ１４内のレジスタセグメントＲｎ−２．．Ｒ０のみが、２つのメモリワードで分割される命令のｌｓｂセグメントのみを格納する。

最小ビューによる命令のサイズが１つのセグメントのサイズに等しいことから、これらの命令は常に、１つのプログラムメモリワードに完全に格納されることになる。従って、最小ビューのマルチプレクサモジュール２７ｄのみが、プログラムメモリ１０の出力に直接連結される入力を有することになる。２以上のセグメントの命令サイズを有するビューのマルチプレクサ２７ａ、２７ｂ、２７ｃも、レジスタ１４からの入力を受ける。これは、これらの命令が、２つのプログラムメモリワードにより分割されうるという事実に起因している。マルチプレクサのレジスタセグメントの入力数は、命令セグメントから１を差し引いた数に等しくなる。

制御設備８５が提供するマルチプレクサモジュール２７ａ、２７ｂ、２７ｃ、２７ｄ用の選択信号ｓｅｌ０，…，ｓｅｌｎは、それらの前の値と、前の命令のプログラムメモリ・イネーブル信号（つまり、プログラムメモリ出力が新たなものか、既に前に利用されたものか）とに応じて決まる。ある命令の長さによって、出力Ｏ０，…Ｏｎのいずれが実際に利用されるかが決定される。この実施形態の利点は、選択信号を、命令を利用する前のサイクルにおいて予め計算しておくことができる点である。この、予め計算するサイクルにおいて、前の値をレジスタ１４から読み出しておくことができ、プログラムメモリ・イネーブル信号は、プログラムメモリ１０を制御する実際の信号に等しい。現在の命令がジャンプ命令に見える場合には、次の命令のＰＣのＬＳＢを、セレクタの前の値として採用することができる。予め計算する処理によって、ｓｅｌ０，…，ｓｅｌｎ信号のパイプラインレジスタを利用して、命令選択のタイミングを向上させることができるようになる。

図１１のフローチャートに示すように、命令をプログラムメモリ１０からフェッチする。

第１のステップＳ１で、メモリアドレスＡＤを例えば値０に初期化する。第２のステップＳ２で、セグメントカウンタＳＧを、このケースでは０に初期化する。そして第３のステップＳ３では、命令開始アドレスＢＧを初期化する。命令開始アドレスは、メモリアドレスコンポーネントＡＤとセグメントコンポーネントＳＧとからなる。各メモリワードがｎ個のセグメントを含む場合には、命令開始アドレスは、ＢＧ＝ｎ＊ＡＤ＋ＳＧとして計算される。ステップＳ４で、値ＳＧが最大値（例えばｎ―１）に等しいかを検証する。検証結果が肯定的である場合には、ステップＳ５でメモリアドレスＡＤを１増分して、ステップＳ６でセグメント数を０にリセットする。検証結果が否定的である場合には、ステップＳ７でセグメント数を１増分する。ステップＳ６またはステップＳ７の後は、利用可能な場合、ステップＳ８で、セグメントＳを、新たなコンパクト化された命令から始まっているかを判断するべく、検証する。検証結果が否定的である場合には、命令フローはステップＳ４に戻る。検証結果が肯定的である場合には、ステップＳ９で、Ｌ＝ｎ＊ＡＤ＋ＳＧ−ＢＧに従って前の命令の長さを計算して、ステップＳ１０で、ＢＧの値をＢＧ＝ｎ＊ＡＤ＋ＳＧに従って再度計算する。そしてプログラムフローはステップＳ４に戻る。長さＬから、および必要な場合には１以上のさらなるビューのビットＶから、命令をコンパクト化する際の規範となるビュー、および、どのビュー復号器が利用可能かを判断する。

以下に、上述した表３のプログラムによってシークエンシングが如何に行われるかを説明する。命令４が命令９へのジャンプを含んでいる場合を想定する。プログラムはＰＣ＝０から始まる。プログラムメモリアドレス０を読み出し、コンパクションスキーム識別器１７は、プログラムメモリワード内の４つのセグメントの開始セグメントビットＳを識別する。これら４つの開始セグメントビットから、コンパクションスキーム識別器１７は、このワードが２つの命令（第１の命令（０）はセグメント０から始まり、１セグメントの長さであり、第２の命令（１）は、セグメント１から始まり、３または４セグメントの長さである）を含むと判断する。セグメント０のビューのビットＶは「０」なので、命令０はビュー１にマッピングされる。これは、ビュー１命令拡張ユニットを利用してデコンパクト化され、後で実行することができる。命令１は、次のプログラムメモリワードを取得するために格納する必要がある。アドレス１の次のプログラムメモリワードが利用可能となると、コンパクションスキーム識別器１７は、このワードのセグメント０が「１」である開始セグメントビットＳを含むことが分かるようになる。これは、命令１が、３セグメント長を有しており、デコンパクト化して、復号化および実行することができることを意味している。他のセグメント開始ビットは、命令２について３の長さを示している。命令２および３は格納する必要があり、アドレス２のプログラムメモリワードを取得することができる。このワードを受信すると、命令２をデコンパクト化して、復号化および実行して、命令４およびプログラムメモリワード内のその他の情報を格納して、次のプログラムメモリワードを読み出すことができる。命令４（命令９へのジャンプ）が実行されると、プログラムカウンタに命令９の開始セグメントアドレスをロードする。プログラムメモリアドレスをアドレス７に設定して、命令９を含むプログラムメモリワードを読み出す。次のサイクルで、完全なビューにマッピングされているように見受けられる命令９を実行する。

原則として、コードコンパクションスキームを識別するためのこの解決法は、余分なストールサイクルまたは余分の分岐遅延を導入しない。分岐対象が２つのプログラムメモリワードにより分割される場合、分岐対象命令を取得するためには２つのプログラムメモリワードが読み出されねばならないことから、ストールサイクルが導入される。しかし、これは、コンパクションスキーム／ビュー情報を取得する方法とは関連しない。この解決法に対する重要なパスは、ビュー情報および開始セグメントを決定して、命令およびデコンパクションを選択するための正しいセグメントを選択するシーケンスを全て、１つのクロックサイクルで行う必要があることから、長くかかることが予期される。潜在的には、余分のパイプライン段階が、このパスに挿入され、タイミングゴールを達成する必要がある。

別の実施形態では、ビュー情報は、次のビューｉｄ（ｎｘｔ＿ｖｗ＿ＩＤ）フィールドを各（コンパクト化された）命令に加えることで識別される。この一例を、表４および５に示す。このフィールドは、その長さに関わらず、例えば各命令のｌｓｂ側という各命令の所定の位置で利用可能である。このフィールドの幅は、ビューの数のｌｏｇ２に等しい。プログラムをシークエンシングする場合、前の命令の次のビューｉｄおよび現在の命令の位置（現在のＰＣに含まれている）が、このプログラムメモリの次の命令の位置を決定する。８つのビューおよび１／８の最大圧縮率を有するプロセッサについては、次のビューｉｄフィールドが３ビット幅あれば十分である。プログラムが３という圧縮率でコンパクト化された場合（全ての命令で、１つの命令の圧縮を平均化したとき）、プログラムメモリ１つについての命令の平均数は、３になる。すると、次のビューｉｄを識別するために必要な全ビット数は、ＰＭｓｉｚｅ＊３＊３＝９＊ＰＭｓｉｚｅとなる。これは、開始セグメントビットを利用する方法における１６＊ＰＭｓｉｚｅよりもかなり少ない。

表４は、一例であるプログラムにおける命令シーケンスを示しており、表５は、この例のプログラムがプログラムメモリにどのように格納されるかを示しており、ここではコンパクト化されている命令が、上述したように、次のビューｉｄフィールド（ｎｘｔ＿ｖｗ＿ＩＤ）を含んでいる。命令の表４は、ビューおよび長さの列の他に、次の命令のｖｉｅｗ＿ｉｄを示す余分の列も含んでいる。

図１２は、本発明によるプログラマブルプロセッサの第２の実施形態の一部を示しており、これは、上記している表５に示すようなプログラムメモリに格納されているコンパクト化されたプログラムを処理するよう構成されている。

この第２の実施形態は、第１の実施形態と、コンパクションスキーム識別器１７が選択設備２７の出力に連結されている点が異なる。

命令は、図１３のフローチャートに示すように、プログラムメモリ１０からフェッチすることができる。

第１のステップＳ２０でメモリワードをプログラムメモリ１０から読み出す。第２のステップＳ２１で、コンパクションスキーム識別器１７が、次の命令に利用するコンパクションスキームを識別する。ここで、第１の命令のコンパクションスキームが既知であり、メモリワード内の所定の位置に配置されていることを前提とする。第３のステップＳ２２では、次の命令の長さを表から読み出して、ステップＳ２３で、次の命令の最終アドレスを計算する。

最終アドレスは、メモリアドレスコンポーネントＡＤとセグメントコンポーネントＳＧとからなる。ステップＳ２４で、最終アドレスが次のプログラムワードにあるかを判断する。判断結果が否定的である場合には、アドレスカウンタＡＤを現在の値に維持して、ステップＳ２７で、関連するセグメントを、プログラマブルプロセッサがデコンパクト化して実行する命令のコンパクト化されたデータとして選択する。ステップＳ２４で、現在のコンパクト化されている命令の最終アドレスが実際は次のプログラムワードであると判断されると、現在のプログラムワード内の現在のコンパクト化されている命令のセグメントを一時格納設備に格納して、アドレスＡＤを増分する。

プログラムカウンタは、セグメントアドレス、プログラムメモリアドレス、および現在の命令のビューｉｄからなる。プログラム実行開始時（命令０の、およびＰＣからのＰＣ点）には、コンパクションスキーム識別器１７は、第１の命令がビュー１命令（つまり、第１のビューによりコンパクションスキームに従ってコンパクションされる命令のこと）であることを知っている。ハードウェアルックアップテーブルは、ビュー１命令の長さが１セグメントであることを示している。プログラムメモリワードが出力で利用可能な場合、命令０の次のフィールドｉｄフィールドを読み出し、これにより値３となる。長さルックアップテーブルをインデックス化することで、ビュー３にマッピングされている次の命令の長さが３セグメントであることがコンパクションスキーム識別器１７により判断される。この情報は、プログラムメモリ１０の読み出しを、１クロックサイクル分保持することができることを示している（なぜなら、命令１が既に現在のプログラムメモリ出力で完全に利用可能になっているからである）。拡張命令１において、プログラムメモリアドレスを１に設定することで、命令２および３の一部を含むプログラムメモリワードを読み出す。命令２を拡張して、さらに処理する場合には、命令２の次のビューｉｄフィールドがビュー２を示しており、つまり、長さが２の命令であることから、制御設備８５は、次のプログラムメモリアドレスを読み出す決定を行う。開始セグメントはセグメント３にあり、これは、この次の命令が、次のプログラムメモリワードに拡張されることを示唆している。命令４は、プログラムメモリアドレス７、セグメント３に位置している命令９へのジャンクを含んでいる。ジャンプ命令は、命令９のビューｉｄ２を含むＰＣを、この命令のアドレスに加えて配信する。この情報により、制御設備８５は、命令９をデコンパクト化してさらに実行するためには、先ずは２つのプログラムメモリワードを読み出す必要があると判断する。分岐対象９を２つのプログラムメモリワードで分割することにより、分岐対象にジャンプするときにストールサイクルが生じる。

条件付の分岐の場合には、分岐命令は、次の命令のビューＩＤのインディケーションを含んでおり、さらに、分岐アドレスが、セグメントアドレス、プログラムメモリアドレスおよび、条件付の分岐先であるアドレスにおける命令のビューｉｄを含む。

所望の場合（例えばクリティカルループの場合）には、このスタールサイクルは、プログラムメモリワードのセグメント０に分岐対象を置き、２つのメモリワードで分割されないようにすることで回避することができる。これは、分岐対象命令が２つのプログラムメモリワードで分割される場合にのみ必要な処理である。対象がセグメント０から始まらないが、メモリワードに依然として完全に収まる長さである場合には、置き換える必要がない。

セグメント０に分岐対象を配置することにより、ストールサイクルは除去されるが、別の問題が生じる。つまり、メモリマップにギャップが生じる。分岐対象がジャンプによってではなくて、前の命令からのシークエンシングにより達成される場合、このギャップはパスする必要がある。この問題を回避するためには５つ解決法がある。１つ目は、メモリギャップを示すために、次のビューｉｄフィールド（ｎｘｔ＿ｖｗ＿ＩＤ）をリザーブするというものである。ある命令の次のビューフィールドがメモリギャップを示している場合、次の命令は、次のプログラムメモリワードのセグメント０から読み出しを行う必要がある。この命令のビューｉｄは、ギャップの第１のセグメントの次のビューｉｄフィールドに示されている。２つ目は、最小のビューの「不可能」命令値を、ギャップの第１のセグメントに挿入するというものである。「不可能な」命令値とは、コンパイラが生成できない命令値のことである。一例としては、「非ＮＯＰ」入力を有するＮＯＰ命令が挙げられる。プログラマブルプロセッサは、この命令の発生をモニタする命令セレクタを有している。検知されると、不可能な命令を有するセグメントではなくて、次のプログラムメモリワードのセグメント０を選択する。分岐対象のビューｉｄは、追加される不可能な命令の次のビューｉｄにより識別される。３つ目の方法は、「非ＮＯＰ」入力を有するＮＯＰ命令等の、コンパイラが生成できない完全なビューの「不可能な」命令値を、以下のように利用する、というものである。命令フィールドをリシャッフルして、関連する命令ビットを、完全な命令のｌｓｂセグメントに置く。ギャップの第１のセグメントを、完全な命令のこのｌｓｂセグメントで充填する。このセグメントの次のビューｉｄは、位置合わせされた分岐対象のビューｉｄを示している。ギャップの前の最後の命令は、完全なビューｉｄに似た次のビューｉｄを有している。この完全なビューｉｄに基づいて、制御設備８５は次のプログラムメモリワードをロードすることを決める。特別な命令が検知された場合も、制御設備８５は、次の位置合わせされた分岐対象にジャンプすると決める。表７にこの解決法を示す。命令４の後には、プログラムメモリは２つのセグメントのギャップを含む。ギャップの第１のセグメントには、「不可能な」命令（ＩＭＰ）のｌｓｂセグメントを充填して、ギャップの第２のセグメントは、読み出されないので、任意の値（Ｘ）を満たしたままにしておいてよい。

４つ目の解決法は、全てのクリティカルな分岐対象を最小ビューに収める、というものである。これは、これらのクリティカルな分岐対象で、圧縮プロセスを開始して、表をこれらの命令フィールド値で満たすことにより達成することができる。５つ目は、プログラムメモリワード１つについて１つの余分なビットをリザーブする、というものである。このビットが「１」である場合、プログラムメモリワードのｍｓｂセグメントが、ギャップの開始点を示す。ギャップの前の最後の命令が、位置合わせされた分岐対象のビューｉｄを含む。

上で提示した５つの解決法は、実行されるプログラムのタイミング、リンカの複雑度、プログラムのコンパクション率、および、ハードウェアの複雑度および（クリティカルな）タイミングパスに影響する場合がある（表８参照）。当業者であれば、これら係数の重みに基づいて、これらの解決法からいずれかを選択することができる旨を理解するだろう。これら係数の影響を、以下の表に概略する。第１列は、上述した解決法を示しており、第２列が、その解決法の実行可能性を示している。この表で、「−」「０」および「＋」というシンボルはそれぞれ、おそらく実行可能性がない、いつも実行可能であるわけではない、および、実行可能性がある、ことを示している。第３列は、コンパクション率に対する影響を示す。「−」は、コンパクション率が低くなったことを示す。「０」は、コンパクション率に実質的な影響がないことを示す。最終列は、実装に必要なゲート数の観点から、ハードウェア複雑性に対する影響を示しており、「−」が比較的複雑なハードウェア実装を示しており、「＋＋」は、比較的低い複雑度のハードウェア実装を示している。一般的には、より複雑なハードウェア実装により、組み合わせ経路（combinational path）が長くなり、タイミングは遅くなる。

解決法１は、エレガントな解決法であるが、フィールドｉｄのコストによって、コンパクション率が低減する。解決法は、いつも実行可能であるわけではない。特別な「不可能な」命令は、最小ビューでは利用できない。加えて、プログラムメモリ・イネーブル信号へのタイミングパスが比較的長くなる。解決法３には、これらの問題はないので、好適である。しかし、命令フィールドをリシャッフルする必要があるという欠点はある。解決法４は、最小ビューが最適ではない表のエントリを有しているために、潜在的にコンパクション率が低減する。解決法５は、コンパクション率の低減度は低いが、解決法３を越えるような利点はない。

上述を鑑みると、完全なビューに特別な命令を利用する解決法３が好ましい。

全ての分岐対象を位置合わせすると、プログラムのコンパクション率が大幅に低減する。これを回避するためには、タイム・クリティカルな分岐対象のみを、位置合わせされた境界に配置するべきである。一般的には、タイム・クリティカルな分岐対象は、タイム・クリティカルなループの一部である。ユーザまたはスケジューラが、これらの位置を示す必要がある。アセンブラは、この情報を（ＥＬＦ）オブジェクトファイルに含み、コンパクションツール１９０（図６）が、どの命令が位置合わせされたアドレスに位置しているかを知ることができるようにするべきである。

以下の表９は、図１２のアーキテクチャのプログラム実行例を示す。この例では、プログラムメモリ幅が４セグメントに等しい。第１列（ｎｒ）は、デコンパクト化する命令を示す。第２列（部分的）は、プログラムメモリ１０のｍｓｂセグメントが、次のプログラムメモリワードに続く命令の一部である場合に、「１」を含む。列Ｐ３からＰ０までは、プログラムメモリ１０の出力を示す。各列はセグメントを表している。数は、命令数を示している。コンパクト化された命令０は、１セグメントの幅を有するように見え、命令１は２セグメント幅であり、といった具合である。列Ｒ２、Ｒ１およびＲ０は、レジスタの出力に存在する命令（またはそのセグメント）数を表している。列ＭおよびＲは、プログラムメモリのアドレスＡＤが、増分されたか、および／または、レジスタを更新する必要があるか、を示す。出力セグメント列Ｏ３，…，Ｏ０は、メモリセグメントＰ０，…，Ｐ３のどれから、または、レジスタセグメントＲ０，…，Ｒ３のどれから、命令セグメントを読み出し、レジスタ入力Ｒ２、Ｒ１およびＲ０は、プログラムメモリ１０関連のデータのどの部分をレジスタ１４に格納するかを示す。レジスタセグメントＲ０、Ｒ１、Ｒ２は常に、自身のデータを同じプログラムメモリセグメントＰ１、Ｐ２、Ｐ３からそれぞれ取得する点に留意されたい。列ＭＳは、マルチプレクサ２７ａ，…，２７ｄの選択値を示している。全てのマルチプレクサを、この選択値で制御することができるとよい。

この例では、レジスタＲ０、Ｒ１、およびＲ２は、必要な場合のみ書き込まれる。列Ｏ３，…，Ｏ０は、マルチプレクサが常にある値を、この値が利用されない場合であっても、選択することを示している。逆マークのエントリのみが実際には命令拡張ユニット８７により利用されている。

命令２０は、２つのメモリワードで分割されるジャンプ対象である。これによりストールサイクルへ導かれる。

図１４は、本発明によるプログラマブルプロセッサの第２の実施形態を示す。この実施形態は、レジスタ１４が、入力マルチプレクサユニット１６を介してプログラムメモリ１０に連結されているシフトレジスタ１５に置き換わった点で、第１の実施形態と異なっている。本実施形態では、入力マルチプレクサユニット１５は、２つの入力マルチプレクサモジュール１６ａ、１６ｂを含む。この図では、シフトレジスタ１５も、Ｓ２、Ｓ１、およびＳ０と示されている。シフトレジスタ１５の入力は、２つの入力マルチプレクサ１６ａ、１６ｂに接続されている。シフトレジスタ１５の１つの入力は、プログラムメモリ１０のセグメントＰ３の出力により形成されている。他の入力も、これもｌｓｂセグメントから始まるシフトレジスタに接続されている。余分な分岐遅延を避けるために、分岐対象は、単一のプログラムメモリワードに配置されるべきである。分岐対象がプログラムメモリ１０の出力で利用可能な場合には、出力マルチプレクサユニット２７によって供給され、命令拡張ユニット８７の適切な命令拡張モジュールにより拡張される。そしてプログラムメモリワードの残り（たった今復号化した命令は除く）を、ともに１５と称されるシフトレジスタ（Ｓ２、Ｓ１、およびＳ０）にシフトして、次の命令が、シフトレジスタのｌｓｂ（ｌｓセグメント）から始まるようにする。次の命令は、レジスタ１５の、ｌｓｂ側から読み出されてよい。シフトレジスタ１５で命令の一部のみが利用可能である場合には、残りの部分はプログラムメモリ１０の出力から読み出される。シフトマルチプレクサ１６ａ、１６ｂは、プログラムメモリの適切なセグメントを選択するために再利用することができる。

この実施形態の命令フェッチシーケンスは、プログラマブルプロセッサの第１の実施形態と実質的に同じである。出力マルチプレクサのセレクタ信号は、タイミングパスを低減させるためにパイプライン化することができる。

以下の表１０は、デバイスのオペレーションを示している。

第１列のｎｒ数は、プログラムカウンタ値ＰＣに等しい。

第２列は、現在のＰＭワードのＰ３セグメントが、次のＰＭワードに続く命令の一部である場合に、「１」を含む。

第３列は、アドレス指定されているプログラムメモリのメモリアドレスＡＤを示す。

Ｐ０、Ｐ１、Ｐ２、Ｐ３は、アドレス指定されているメモリワードの各セグメントの命令ｉｄを示す。

Ｓ０、Ｓ１、Ｓ２は、そこから命令データをフェッチしてくる、プログラムメモリ１０のセグメントを示す。

Ｍは、次のサイクルでメモリアドレスＡＤを増分するかを示す。

Ｒは、レジスタ１５が、プログラムメモリ１０からデータを受けるためにイネーブルされるかを示す。

Ｏ０，…，Ｏ３は、それぞれ、プログラムメモリセグメントＰ０、Ｐ１、Ｐ２、Ｐ３およびレジスタセグメントのｔＳ０、Ｓ１、Ｓ２のいずれをマルチプレクサモジュール２７ａ，…，２７ｄの出力で見ることができるかを示す。

以下の表を参照して示す例から、以下のことが観察される。

この表の第１のラインには、命令拡張器８０が値０のプログラムカウンタを受信して、この値がプログラムメモリアドレスと想定される旨が示されている。このメモリアドレスでは、プログラムメモリは、第１のセグメントに、第１の命令ワード（０）用にコンパクト化されたデータを含み、第２および第３のセグメントに、第２の命令ワード（１）用にコンパクト化されたデータを含み、第４のセグメントに、第３の命令ワード（２）用にコンパクト化されたデータの一部を含む。コンパクト化された第１の命令ワードを含む１つのセグメントＰ０を選択して、出力Ｏ０を介して、命令拡張ユニット８７に提供する。このケースでは、アドレス指定されるメモリワードが、完全にコンパクト化された第２の命令をセグメントＰ１、Ｐ２に含み、プログラムカウンタＰＣが増えても、プログラムメモリアドレスＡＤが増えない。そうではなくて、第２の命令（１）を含む２つのセグメントＰ１、Ｐ２を選択して、出力Ｏ０およびＯ１をそれぞれ介して命令拡張ユニット８７に提供する。同じサイクルで、出力セグメントＰ３を、レジスタ１５のセグメントＳ０に読み出す。メモリアドレス０はコンパクト化された次の命令（２）の一部のみを有しているので、制御信号Ｍは、次のサイクルでメモリアドレスＡＤを増やす。従って、次のサイクルでは、メモリアドレス１をアドレス指定して、命令２用の命令データを、レジスタセグメントＳ０を選択することで出力Ｏ０、Ｏ１、Ｏ２、Ｏ３、および、プログラムメモリセグメントＰ０、Ｐ１、Ｐ２それぞれに提供する。後続するサイクルでは、コンパクト化された命令データの１以上のセグメントが取得されるたびに、必要に応じて拡張する。

第１の実施形態では（図１２参照）、次の命令の開始セグメントは、現在の命令の開始セグメントおよび現在の命令の長さから計算することができる。この開始セグメントから、ｓｅｌ０のワンホットワードを計算することができる。ｓｅｌ０のＬＳＢの部分は、ｓｅｌ１，…，ｓｅｌｎにコピーする。出力セグメントＯ０．．Ｏｎは常にデータを含んでいる点に留意されたい。命令拡張ユニット８７はこの点を考慮に入れ、命令長に応じてｌｓｂセグメントのみを読み出す必要がある。

第２の実施形態（図１４参照）では、開始セグメントの計算が等しい。ｏ＿ｓｅｌ０の開始セグメントからワンホットワードセレクタへの変換は、ワンホットワードが小さいが、ｏ＿ｓｅｌ０．．ｏ＿ｓｅｌｎの信号が単にシフトされたバージョンではない、という点で少し異なっている。Ｓ０．．Ｓｎで利用可能なセグメント数は、ｏ＿ｓｅｌ信号間の関係に影響する。図１２に示す実施形態では、２ｎ−１ビットのワンホットワードを利用して、マルチプレクサユニットを制御しており、図１４の実施形態では、ｎ＋１ビットのワンホットワードを利用している。第２の実施形態では、ｓｈ＿ｓｅｌ信号を生成する必要がある。これらは、プログラムメモリ１０からの入力シフトレジスタＳｎ．．Ｓ０へのタイミングパス十分短いために、登録される必要はない。選択信号ｓｈ＿ｓｅｌ０．．ｓｈ＿ｓｅｌｎは、次の開始セグメントから生成することができる。

本発明によるプログラマブルプロセッサの仕様は、ハードウェア生成ツールを利用して自動生成することができる。図１５は、このようなツールＰＣを示す。ここでは、従来のプロセッサ（例えば図１に示すようなプロセッサ）ビュー定義ファイル１３５およびプロセッサ記述ファイル１０５が、第２のＡＰＥＸモジュール１４０に提供されている。この第２のＡＰＥＸモジュール１４０は、プロセッサ記述ファイル１０５およびビュー定義ファイル１３５から情報を集めて、プロセッサの記述に定義されているパラメータを抽出するＡＰＩ１４５を提供する。このＡＰＩ１４５は、ハードウェア構築ブロックライブラリ１５０が、仕様１５５を生成する際に利用される。

本発明のプログラマブルプロセッサにおいては、命令または命令フィールドのデコンパクションは、通常、プログラマブル表（ここではデコンパクション表とも称される）のインデックスにより行われる。書き込みおよび読み出し設備は、デコンパクション表に対して書き込みおよび読み出しを行うことを可能とする。一実施形態では、デコンパクション表のためのレジスタは、エントリを書き込みときにだけクロック供給される。通常は、これは、プロセッサに電源を投入した後一度だけ行われる。従って、デコンパクション表レジスタのクロックゲーティングにより、使用電力が大幅に低減される。

一実施形態では、複数のビューによって、少なくとも１つのデコンパクション表を利用して命令をデコンパクト化する。互いに異なるコンパクションスキーム用の命令拡張モジュールが並列実行する必要がないことから、このデコンパクト化実行のために、デコンパクション表にマルチ読み取りポートを設ける必要はない。

デコンパクション表は、命令フィールド用にＮＯＰ値を常に含む。ＮＯＰコードについて各表のアドレス０をリザーブして、レジスタでこのエントリを実装するのではなくて、これを固定エントリとするとよい。

請求項で、「備える」という用語は、他のエレメントまたは他の段階を排除するものではなく、不定冠詞は複数を含む。単一のコンポーネントまたは他のユニットが、請求項に記載する幾つかのアイテムの機能を達成することもできる。互いに異なる請求項に一定の計測値（measures）が記載されているからといって、これは、これら計測値の組み合わせを利用すると効果がない、と言っているわけではない。請求項で利用される参照番号は、範囲を限定しているとみなされるべきではない。さらに、そうではないと明示していない限りは、「または」は、包含的ＯＲであり、排他的なＯＲではない。例えば、条件ＡまたはＢは、Ａが真であり（または存在しており）、Ｂが偽である（または存在しない）、Ａが偽であり（または存在せず）、Ｂが真である（または存在する）、および、ＡおよびＢの両方が真である（または存在する）、のいずれによっても満たされる。

Claims (18)

1. プログラマブルプロセッサが処理する命令のサブセット用の命令コンパクションスキームをそれぞれ生成する方法であって、
   ａ）前記プログラマブルプロセッサで実行するソフトウェアを表す少なくとも１つの入力コードのサンプルを受信する段階であって、前記入力コードは第１の命令セットを定義する複数の命令を含む段階（Ｓ１）と、
   ｂ）除去する命令セットを空として初期化する段階（Ｓ３）と、
   ｃ）前記第１の命令セットの最もコンパクトな表現を決定する段階（Ｓ４）と、
   ｄ）前記最もコンパクトな表現のサイズを閾値と比較する段階（Ｓ５）と、
   ｅ）前記サイズが前記閾値より大きい場合、ステップｅ１からｅ３を実行する段階と、
   ｆ）段階ｂから段階ｆを繰り返す段階であって、前記第１の命令セットは、前記除去する命令セットから形成される段階（Ｓ９、Ｓ１０）と
   を備え、
   前記ステップｅ１からｅ３は、
   ｅ１）前記第１の命令セットのどの命令の符号化コストが最も高いかを判断する段階（Ｓ６）と、
   ｅ２）前記第１の命令セットから、前記最も高い符号化コストを持つ命令を除去する段階（Ｓ７）と、
   ｅ３）前記命令を前記除去する命令セットに追加する段階（Ｓ８）とである方法。
2. 命令コンパクションスキーム数と、命令コンパクションスキーム毎の圧縮の数を要求する前記段階（Ｓ２）を備える請求項１に記載の方法。
3. 複数の命令コンパクションスキームで繰り返しを行い、各命令コンパクションスキームについて達成される圧縮量を決定する段階を備える請求項１に記載の方法。
4. 前記命令には、個々にコンパクト化される複数の命令フィールドが含まれる請求項１または２に記載の方法。
5. 個々にコンパクト化される前記複数の命令フィールドは、少なくともオペコード、書き込みポートのインデックスを示すフィールド、および、読み出しポートのインデックスを示すフィールドを含む請求項４に記載の方法。
6. 互いに異なるサブセット用の前記命令コンパクションスキームは、互いに異なるコードワード幅を有し、前記サブセットのうち、少なくとも１つのサブセットが最小コードワード幅を有する請求項１から５のいずれか一項に記載の方法。
7. 各サブセットの前記コンパクションスキームの前記コードワードのサイズは、前記最小コードワード幅を整数倍した値であり、前記整数は１以上である請求項６に記載の方法。
8. 互いに異なるサブセット同士は、互いに異なる方法でコンパクト化される請求項１から７のいずれか一項に記載の方法。
9. 前記サブセットのうちの少なくとも１つは、可変長コードにコンパクト化される請求項１から８のいずれか一項に記載の方法。
10. 複数の命令を含むプログラムを受信する段階と、
    各命令について、段階ａからｆで決定されたものに対応する命令コンパクションを決定する段階と、
    前記命令コンパクションに従って前記命令を圧縮する段階と、
    コンパクト化された命令を提供する段階と
    をさらに備える請求項１から９のいずれか一項に記載の方法。
11. 前記コンパクト化された命令を、利用した前記コンパクションのタイプを示す少なくとも１つのインジケータとともに提供する段階を備える請求項１０に記載の方法。
12. 前記コンパクト化された命令は、複数のセグメントを含むワードに格納され、各セグメントは、当該セグメントが、コンパクト化された命令の最初のセグメントであるかを示すインジケータを少なくとも含む請求項１０または１１に記載の方法。
13. 前記コンパクト化された命令は、複数のセグメントを含むワードに格納され、各コンパクト化された命令は、当該コンパクト化された命令内の所定の位置にインジケータを含み、前記インジケータは、次のコンパクト化される命令に利用するコンパクションのタイプを示す請求項１０または１１に記載の方法。
14. プログラマブルプロセッサの仕様を受信する段階と、
    前記仕様と、生成した前記命令コンパクションスキームそれぞれとを利用して、命令デコンパクターのためのハードウェア仕様を決定する段階と
    をさらに備える請求項１に記載の方法。
15. 請求項１から１４のいずれか一項に記載の方法の実行に適すようにプログラミングされた装置。
16. 請求項１から１４のいずれか一項に記載の方法を装置に実行させるプログラムを備える記録キャリア。
17. プログラマブルプロセッサであって、
    第１の命令コンパクションスキームに従ってＮ個のメモリワードセグメントの第１のコードワードとしてコンパクト化された第１の命令群と、第２の命令コンパクションスキームに従ってＭ個のメモリワードセグメントの第２のコードワードとしてコンパクト化された第２の命令群とを少なくとも含むコンパクト化された命令データとして格納される命令シーケンスを有するプログラムメモリ（１０）と、
    命令復号器（２０）と、
    少なくとも１つのレジスタファイル（４０、４０ａ）と、
    前記レジスタファイル（４０ａ）に連結された少なくとも１つの発行スロット（５０）と、
    命令拡張器（８０）と
    を備え、
    前記命令拡張器（８０）は、
    前記プログラムメモリからフェッチしたコンパクト化された命令データの命令コンパクションスキームを識別するコンパクションスキーム識別器（１７）と、
    プログラムカウンター（ＰＣ）を受信するための入力と、
    プログラムメモリワードの少なくとも１つのセグメントを一時格納する格納設備（１４）と、
    前記プログラムメモリ（１０）と前記格納設備（１４）とから、コンパクト化された命令データを選択する選択設備（２７）と、
    選択された前記コンパクト化された命令を、Ｋのサイズを有する拡張された命令に拡張する命令拡張ユニット（８７）と、
    前記プログラムカウンター（ＰＣ）に呼応して前記プログラムメモリ（ＡＤ）のアドレスを生成して、前記選択設備を制御する制御設備（８５）と
    を備え、
    Ｋ、Ｎ、Ｍは、１以上の整数であり、整数Ｎ、ＭはＫ以下であり、ＮおよびＭのうち少なくともいずれかがＫより小さいプログラマブルプロセッサ。
18. 前記格納設備（１４）はレジスタであり、前記選択設備（２７）は複数のマルチプレクサモジュール（２７ａ，…，２７ｄ）を含み、各マルチプレクサモジュールは、コンパクト化された命令データの１またはゼロのセグメントを選択する請求項１７に記載のプログラマブルプロセッサ。

Images