JP2898105B2 - コンパイル中にソフトウェア・スケジューリング技術を用いてハードウェアのパイプライン処理の中断を最小化する方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はコンピュータ・プログラ
ミングの技術、特にコンパイラに関し、さらに詳細には
パイプライン処理の中断を最小化するために命令をスケ
ジュールするコンパイラに関するものである。

【０００２】

【従来の技術】コンピュータ・プログラムは一般に、一
連のマシン・レベルの命令のリストよりも、プログラム
作成者にとって（またはそのプログラム構造を理解しよ
うとする他者にとって）より容易に理解されうる意味を
もつ「Ｃ」、フォートラン、パスカル、ベーシックなど
の高級言語で書かれる。高級言語で表現されたプログラ
ムは「ソース・コード」として知られている。しかし、
ソース・コードは直接には実行されず、したがって、プ
ログラムが走っているときに、実行可能なコードに、一
文毎に変換されるか、またはまず、（所定のオペレーテ
ィング・システムを用いる所定のハードウェア上で意味
を有する）「オブジェクト・コード」にコンパイル（翻
訳）されてオブジェクト・コードとして走る。このコン
パイルはそのオブジェクト・コードが使用されるコンピ
ュータ・システムの構造を知っており、したがって、各
ソース・コード文を１以上の特定なオブジェクト・コー
ド命令に変換することができる特定な用途の「コンパイ
ラ」プログラムにより成され得る。この分野の熟練家で
あれば、コンパイルされたオブジェクト・コードを実行
することはインタプリタによりソース・コードを実行す
るよりもずっと速いことを理解するだろうし、ほとんど
の商用のコードはコンパイルされた形態のみにより供給
されている。

【０００３】コンピュータのより速い動作が追求される
につれ、その目的を達成するために多くのハードウェア
／ファームウェアのフィーチャが用いられてきた。動作
速度を速くするために、広く組み込まれてきた１つのフ
ィーチャは一連の連続するマシン・レベルの命令の実行
の様々な段階が同時に行われるパイプライン処理であ
る。しかして、所定の一単位時間の間に、（実行の順番
が）４番目の命令の第１の段階が行われる一方で、３番
目の命令の第２の段階、２番目の命令の第３の段階、お
よび１番目の命令の第４の段階が全て、同時に行われ
る。

【０００４】

【発明が解決しようとする課題】この方法はコンピュー
タ・システムの外見上の動作速度を劇的に速くする。し
かしがら、パイプライン処理の「中断」(break）すなわ
ち、衝突を回避するために連続する命令の円滑な介挿
（interleave）を中止する必要をもたらしうる、連続す
る命令間の衝突が生じる場合がある。初歩的な例とし
て、４番目の命令の第１の段階が行われているとき、あ
るレジスタがオペランド・アドレスのために使用され、
同じレジスタが３番目の命令の第２の段階を行うことに
より、同時に変更されているならば、衝突することとな
り、４番目の命令の第１の段階は延期されなければなら
ず、これにより、パイプラインの処理は中断され、その
結果、外見上の実行速度は遅くなる。本発明はパイプラ
イン化された構造を用いるコンピュータ・プロセッサ内
に使われているコンパイルされたオブジェクト・コード
内のソフトウェアの中断の問題を提起し、その問題を最
小化するためのものである。

【０００５】本発明の広汎な目的は改善されたコンパイ
ラを提供することである。

【０００６】本発明のより特定の目的はパイプライン処
理の中断を極力少なくするために、接近して連続するオ
ブジェクト・コード命令を選択的に再スケジュールする
コンパイラ・モジュールを提供することである。

【０００７】

【課題を解決するための手段】簡潔に述べると、本発明
のこれらおよび他の目的は、バッファ内に一時的に保持
される小規模な連続するグループの各オブジェクト・コ
ードの命令の表現を、各々がスケジューリング・プロセ
スに入るときに、命令属性テーブル（Instrluction Att
ribute Table）から展開される一対の属性ワイド（Attr
ibute Words）に割り当てるコンパイラ・モジュールに
よって達成される。新しい命令と既にバッファ内にある
命令との間に起こりうる潜在的衝突は、ゼロ以外の応答
が潜在的衝突を示すように、その属性ワードと他の命令
の属性ワードとの論理積をとることにより、第１のサブ
・プロセスにおいて容易に確かめられる。衝突がなけれ
ば、バッファ内の最も古い命令はオブジェクト・モジュ
ールへ送られ、最も新しい命令がそのバッファにプッシ
ュされる。しかしながら、衝突が存在すれば、可能であ
れば、または可能な範囲において、バッファ内に既にあ
る、その衝突する命令がその衝突が最小にされるか、ま
たは除かれるようにバッファ内の１以上の他の命令の前
に動かしうる否かを決定することにより、その衝突を解
決するように第２のサブ・プロセスが行われる。このサ
ブ・プロセスはバッファ内の他の命令と動かされるべき
候補の命令の属性ワイドを比較することを含む。その衝
突する命令の移動が可能であり、その衝突を解決または
最小化するならば、そのバッファ内の命令は適宜、再ス
ケジュールされ、最も古い命令はオブジェクト・モジュ
ールへ送られ、新しい命令がバッファへプッシュされ
る。

【０００８】

【実施例】以下の本発明の説明において、本発明を説明
するために選ばれた例示的構成は基本のワード長が３６
ビットである４段のパイプライン・プロセッサである。
本技術の熟練者であれば、プロセッサは異なる段数のパ
イプラインおよび／または異なる長さの基本ワードによ
るものでもよいことは理解するであろう。また、本発明
の例示的な動作を説明する目的のために特定の例が選ば
れたが、様々なバッファ、スタック、属性ワードなどの
機能を設定し、構成するために異なる技術が用いられう
ることも理解されうるであろう。

【０００９】まず、図１を参照すると、本実施例の４つ
のパイプラインの段は「フェッチ（fethc）」、「アド
レス（address）」、「キャッシュ（cache）」、および
「実行（execution）」であることがわかるであろう。
「フェッチ」の段階の間に、命令それ自体がプロセッサ
の命令復号ロジックにもってこられる。「アドレス」の
段階の間に、命令の実行に必要とされるオペランドまた
は他のアドレスが展開される。「キャッシュ」の段階の
間には、メモリからの必要とされるオペランド／データ
が（一般的にはキャッシュ・メモリから）フェッチされ
る。そして、「実行」の段階の間に、命令の実際の実行
が行われる。

【００１０】さて、図１において（単に例として）ｔ２
の間に、Ｉ３がフェッチされている一方で、アドレス成
分がＩ２のために展開されており、Ｉ１は必要とされる
とき、キャッシュ・メモリまたは主メモリをアクセスし
ており、一つ前の命令が実行されている。理想的にはｔ
３の間、Ｉ４がフェッチされながら、アドレス成分がＩ
３のために展開され、Ｉ２がキャッシュ（cache）をア
クセスし、Ｉ１が実行されるだろう。そしてｔ４の間、
Ｉ５がフェッチされる等であろう。しかしＩ３によって
ロードされているレジスタを、Ｉ４がオペランドアドレ
スのために使用する状況を考えてみよう。Ｉ３の実行フ
ェーズがそのレジスタをロードするｔ５の後になるまで
Ｉ４はパイプライン処理のアドレス段階へ進むことがで
きない。その結果、（２つのアスタリスクにより示され
るように）パイプライン処理を中断して待たなければな
らず、これに応じてシステム効率が低下することにな
る。

【００１１】しかしながら、例において、Ｉ３が新しい
衝突を起こすことなくＩ１の前に再付ジュールできれ
ば、そのパイプライン処理の中断は避けられるか、また
最小にすることができ、これは本件発明の動作のための
基本をなすものである。図２はパイプライン処理の中断
を避けるためにマシン言語の命令を再スケジュールする
基本概念を示す高いレベルのフローチャートである。図
２に述べられ、示されているとおり、斯くように簡単で
あるが、効率的な意志決定のプロセスは理解しにくいも
のであり、本発明の意志決定のプロセスはその重要な特
徴の中にある。

【００１２】本発明に基づき用いられている意志決定プ
ロセスのポイントはスケジュール・プロセスの際、各命
令に一時的に関係付けられる属性ワードの展開である。
また、これらの属性ワードは命令属性テーブルの中に保
持されている情報から個々に展開される。各命令（すな
わち、所定のコンピュータ・プロセッサにより使用され
る多くの命令のうちの各々）は（レジスタおよび／また
はメモリのような）個々のリソースを参照し、使用する
ことができるので、アドレシングが行われうる方法（ア
ドレシングは暗黙的にレジスタおよび／またメモリを使
用するかもしれない）において、どのレジスタが使われ
るか、レジスタが使われる方法においてどのレジスタが
変更されるか、およびレジスタが変更される方法と他の
関連する情報とが全て、そのシステム内のある命令のた
めの独自な命令テーブル属性ワードに組み込まれうる。

【００１３】ＢＵＬＬ ＧＣＯＳ ８ オペレーティン
グ・システムを用いる大規模コンピュータ・システムの
ためのオブジェクト・コードを作成するコンパイラによ
り使われうる命令テーブル属性ワードの例が図３に示さ
れている。前述したとおり、令令属性テーブル内の各エ
ントリはシステム内のある命令のための属性を与え、そ
のシステムにある命令と同じ数のエントリがテーブル内
に一般的には存在するであろう。これらの属性はある命
令が使用するレジスタ／メモリおよびその中での前後関
係を定義する。例において、興味のあるシステム属性
は、以下の４つの属性（図示せず）である。 アドレシング属性 Ｔ＝命令はダグ付けされうる（ビット３０〜３５） Ｍ＝命令はメモリ・アドレスをもちうる ＡＲ＝命令はビット２９がオンであれば、アドレスレジ
スタを使用しうる。 使用属性（アドレシング属性を含む） Ｘ＝（命令の２４〜２６ビットにおいて）インデックス
を使用 ＸＤ＝Ｘ＋１も使用 Ｅ＝エクスポネント・レジスタを使用 Ａ＝Ａレジスタを使用 Ｑ＝Ｑレジスタを使用 Ｇ＝ジュネラル・レジスタを使用（命令の０〜３ビッ
ト） ＧＤ＝Ｇ＋１を使用 Ｒ＝ジュネラル・レジスタを使用（命令の３２〜３５ビ
ット） ＲＤ＝Ｒ＋１を使用 変更属性 Ｘ＝インデックスを変更（命令の２４〜２６ビット） ＸＤ＝Ｘ＋１も変更 Ｅ＝エクスポネント・レジスタを変更 Ａ＝Ａレジスタを変更 Ｑ＝Ｑレジスタを変更 Ｇ＝ジュネラル・レジスタを変更（命令の０〜３ビッ
ト） ＧＤ＝Ｇ＋１を変更 Ｒ＝ジュネラル・レジスタを変更（命令の３２〜３５ビ
ット） ＲＤ＝Ｒ＋１を変更 一般属性 ＴＲ＝制御を移すことができる ＳＰ＝特殊特殊（sreg,lreg・・・） ＥＩ＝eisタイプの命令 ＶＣ＝ベクトル・タイプの命令 図３において命令テーブル属性ワードのフォーマットは
以下の通りである。 tra＝制御の移転 eis＝マルチワードeis vec＝マルチワード・ベクトル spc＝特殊（lreg,sreg,・・・） n1、n2、n3＝eis／vec命令のタイプを指定する３ビット
の数

【００１４】命令バッファは現在、「バッファの中にあ
る」命令を表わす情報（表現）を含んでいる。命令バッ
ファは適当な長さの循環的なＦＩＦＯスタックとして容
易に実現される。（４段階のパイプライン処理の例のた
めには５個の長さが適当であるが、必ずそうでなければ
ならないことはない）それは２つのインデックス、すな
わち、そのバッファ内に入った最新の命令を指し示すＴ
ＯＰＳＴおよびバッファ内の最も古い命令を指し示すＢ
ＯＴＳＴにより容易に管理されうる。そして、ＴＯＰＳ
ＴがＢＯＴＳＴと等しければ、バッファ内には命令がな
い。命令をバッファ内に入れるためには、ＴＯＰＳＴは
１だけ増される。ＴＯＰＳＴがバッファ内の長さを越え
ると、ＴＯＰＳＴは０にリセットされる。

【００１５】命令バッファはいくつかのフィールド（図
示せず）を含んでいる。 ＩＳＳＡ＝命令スケジュール・スタックａ（命令） ＩＳＳＱ＝命令スケジュール・スタックｑ（再配置のタ
イプ） ＩＳＳＩＣ＝命令のメモリ内の位置 ＩＳＳＡＴＴ＝命令の属性（２ワード）

【００１６】バッファ内に格納された各命令のために展
開された命令のアドレス／使用／変更の属性ワードのフ
ォーマットは図４および図５に示されている。属性ワー
ド１はアドレスおよび使用を属性を含んいる。属性ワー
ド２は変更および特殊の属性を含んでいる。属性ワード
２において、 tra＝転送命令 eis＝eis命令（mlr,mtm,・・・） vec＝ベクトル命令（vfad,・・・） sp＝special（lreg,steg,・・・） dsc＝ベクトルまたはeisのための記述子（vdsc,adsc
９，・・・） lst＝lstouのために使用されるワード（注釈フェーズ） mu＝使用されたメモリ mc＝変更されたメモリ

【００１７】さて、次にスケジューリング・プロセスに
入れられている“ロードＡレジスタ”命令のための属性
ワードが例示の状況にひき出される方法の具体例を考え
てみよう。“ＬＤＡ”命令はそのｏｐコード・フィール
ドに加え、オペランド・フィールドを備えている。その
機能はそのオペランド・フィールド内で指定される場所
にある情報がフェッチされＡレジスタに格納されるよう
にすることである。このオペランドは インディエート（immediate) ；例えば、ＬＤＡ７、Ｄ
Ｌ＝定義７ オフセットのみ；例えば、ＬＤＡ Ａ＝位置Ａ内の値ま
たは、ＬＤＡ １２＝位置１２内の値 インデックス付；例えば、ＬＤＡ Ａ，７＝メモリ位置
（Ａ＋インデックス７の内容）からの値 または、ＬＤＡ Ａ，，０＝アドレス、レジスタ０内
の情報により修飾されるメモリ位置Ａからの値

【００１８】さて、８進および２進の各々で表わされ
た、ＬＤＡ命令のための命令属性ワードは次の通りであ
る。 0 7 4 0 0 0 0 0 0 4 0 0 000 111 100 000 000 000 000 000 000 100 000 000

【００１９】命令テーブル属性ワードの様々な位置にセ
ットされている１の意味は次のとおりである。２番目の
８進数値７において、最上位の２進数はインデックス・
アドレッシングが可能であり、２番目の２進数はメモリ
の利用が可能であり、最下位の２進数はアドレス・レジ
スタの利用が可能であることを示している。３番目の８
進数値４において、最上位の２進数はメモリが実行の間
に使用されることを示しており、１０番目の８進数値４
において、最上位の２進数はＡれレジスタが実行の間に
変更されることを示している。この情報から、例示のＬ
ＤＡ名のための（８進で表わされた）属性ワードの展開
はすでにバッファ内にある他の命令と可能性のあるロー
ド／使用の衝突のために調べられるべきである。 命令 ワード１ ワード２ ＬＤＡ５，ＤＬ 0000000 000000 00002 000000 （イメディエート・オペランド (Ａレジスタ変更) のためのアドレスなし） ＬＤＡ Ａ 000000 000000 000002 000000 ＬＤＡ Ａ，１ 000400 000000 000002 000000 （アドレスの中で用いられているＸ１） ＬＤＡ Ａ,,Ｏ 400000 000000 000002 000000 （アドレスの中で用いられている ＡＲ０）

【００２０】図６は図２のブロック「バッファ内の命令
とロード／使用の衝突はあるか」が広汎な決定を行うた
めに必要なサブプロセス・ステップに分解された点にお
いて図２より詳細なフローチャートである。以下に更に
説明されるとおり、「命令」は現実に、バッファのフラ
ッシュを要求するラベルであることがこの時点でわかる
かもしれない。そこで、図６において、新しい命令はま
ず、それがラベルであれか否かチェックされ、もしそう
であれば、バッファ内の全ての命令がオブジェクト・モ
ジュールへ送られ、別の新しい命令がプロセスの中に呼
び込まれる。新しい命令がレベルでなければ、オペラン
ド利用属性フィールド（例の中の属性ワード２）、レジ
スタ／メモリ利用フィールド（例の中の属性ワード１の
最初の半分）、およびレジスタ／メモリ変換フィールド
（例の中の属性ワード２の２番目の半分）が例えば、前
述したように展開される。（もちろん、これらの属性フ
ィールドの展開の順番は重要ではなく、システムにとっ
て都合のいいように行われうる。）

【００２１】そして、衝突のための実際のテストは新し
い命令の属性フィールド（すなわち、例の中では属性ワ
ード１および２）を、現在、バッファの中にある他の命
令の属性フィールドと論理的にアンドをとることによっ
て行われる。ゼロという結果は衝突が存在しないことを
表わし、その結果、バッファ内の最も古い命令がスタッ
クの底から取り除かれ、オブジェクト・モジュールへ送
られ、新しい命令がスタックの一番上に置かれる。新し
い命令が制御の転送でなければ、調べられるべき次の命
令が呼び出される。しかしながら、新しい命令が制御の
移転（例えば、無条件の分岐）であれば、ラベルが特定
された行き先に対してセットされ、次の新しい命令がプ
ロセスの中に呼び出される前にバッファの内容はフラッ
シュされる。

【００２２】論理積動作の結果がゼロでなければ、衝突
が存在し、それを解消するよう試みられる。その衝突が
（すでに解消プロセスが少なくとも１回成功裏に終了し
ていることを示す）移動された命令とのものであれば、
パイプライン処理の中断の影響が最小となるので、（こ
のことは完全な除去となるかもしれない）、フローは結
果がゼロであったかのように進みうる。しかしながら、
衝突が移動された命令とのものでなく、更なる改善が可
能であることを示していれば、衝突解消サブプロセスが
続行される。

【００２３】さて、解消サブプロセス自体について考え
てみると、図７は図２のブロック「可能であればロード
／使用の衝突を解消する」が決定を行うために、およ
び、可能であれば衝突解消動作を実行するために必要な
ステップに分解されている点で図２より詳細なフローチ
ャートである。もう少し詳細に説明すると、図７は図６
のブロック「新しい命令をＩmとして指定し、衝突を解
消しに行く」の展開であるとも考えられる。以下の説明
において、Ｉmが新しい命令ではなく、衝突を解消する
ために、シーケンス内でより前に移されるべき候補であ
る、すでにバッファ内にある命令であることを理解する
ことは重要なことである。常にではないが、しばしば、
ＩmはＩmが移されるまで、新しい命令の直前の命令であ
ろう。

【００２４】解析を実行する際、一連のイエス／ノーの
判定がＩmはおよびバッファ内のその前に現在ある命令
の各々に対して行われる。くり返すが、判定の順番（お
よび判定自体さえも）はそのシステム環境に都合よく、
適合するように選択されうる。Ｉm以前のバッファ内の
全ての命令に対し所望の判定をして、次の判定に移るよ
り、図７に示されるようにＩmに対するある命令のため
のいくつかの判定を順次、行うことの方がより効率的で
好ましいことがわかっている。このより好ましい方法に
よれば各テストが失敗となるポイントの数を節約する必
要性を避け、また、Ｉmはがそれと相互に関係付けられ
たより古い命令を越えて移され得なければ、その可能性
のある最も早い時点でそのプロセスを停止させることが
できる。

【００２５】実施例においては第１の判定は（Ｉnと示
されている）Ｉmの次の古い、バッファ内の命令がＩmに
より使用されるレジスタを変更するか否かである。これ
はＩmの属性ワード１の前半分とＩnの属性ワード１の後
半分との論理積をとることにより行われうる。ゼロでな
い結果であれば、Ｉmが衝突する命令を越えて移され得
ないことを示し、その解消プロセスが終了する。この時
点において、サブプロセスがパイプライン処理の中断の
影響を最小化するであろう。

【００２６】本実施例での２番目の判定はＩmがアドレ
シングのためにＩnにより使用されるレジスタを変更す
るか否かである。これはＩmの属性ワード２の前半分と
Ｉnの属性ワード１の前半分との論理積をとることによ
り行われる。

【００２７】本実施例での３番目の判定はＩnが実行時
にＩmにより変更されるレジスタを変更するか否かであ
る。これはＩmの属性ワード２の後半分とＩnの属性ワー
ド１の前半分との論理積をとることにより行われる。

【００２８】本実施例での４番目の判定はＩmが実行時
にＩnにより変更されるレジスタを変更するか否かであ
る。これはＩmの属性ワード１の前半分とＩnの属性ワー
ドの前半分との論理積をとることにより行われる。

【００２９】本実施例での５番目の判定はＩnがアドレ
シングのために、Ｉmにより使用されるメモリを変更す
るか否かである。Ｉnのための属性ワード２のビット３
５が「１」にセットされていなければ（すなわち、メモ
リが変更されていれば）、この場合は生ぜず、そして、
異なるテストが行われうる。それが「１」であれば、命
令Ｉmのアドレシング・モードがメモリを使用している
か否かを判定するためのチェックが行われうる。メモリ
を使用していなければ、フローは次の判定に進み、使用
していれば、ＩmアドレスがＩnのアドレスとははっきり
と異なるか否かを判定するためのチェックが行われる。
これが判定され得なければ、ＩnはＩmがアドレシングの
際に使用するメモリを変更すると仮定されなければなら
ない。本分野の熟練家であれば、２つのアドレスが等し
いか否かを判定することができる、いくつかの簡単なケ
ースがありうることがわかるであろう。

【００３０】本実施例での６番目の判定はＩmがアドレ
シングのためにＩnにより使用されるメモリを変更する
か否かである。Ｉmのための属性ワード２のビット３５
が「１」にセットされていなければ（すなわち、メモリ
が変更されなければ）、このケースは生ぜず、更なるチ
ェックが行われうるが、このビットが１」にセットされ
ていれば、Ｉnのアドレシング・モードがメモリを使用
するか否かを判定するようチェックが行われる。メモリ
を使用しなければ、次の判定が行われ、メモリを使用す
れば、ＩnのアドレスがＩmのためのアドレスとははっき
りと異なるか否かを判定するようチェックが行われる。
これが判定され得なければ、ＩmはＩnがアドレシングの
際に使用するメモリを変更すると仮定されなければなら
ない。

【００３１】本実施例での第７番目の判定はＩnが実行
の間にＩmより使用されるメモリを変更するか否かであ
る。Ｉnのための属性ワード２のビット３５が「１」セ
ットされていなければ、またはＩmのための属性ワード
２のビット３４が「１」にセットされていなければ（そ
れはメモリが使用されていることを示しているが）、事
象は生ぜず、次の判定が行われうる。両ビットともオン
であれば、両命令のアドレスはそれらがはっきりと異な
るものであるか否かを判定するようチェックが行われな
ければならない。それが判定され得なければ、それは同
じであり、ＩmはＩnの後に移され得ないと仮定されなけ
ればならない。

【００３２】本実施例での８番目の判定はＩmが実行の
間にＩnにより使用されるメモリを変更するか否かであ
る。Ｉmのための属性ワード２のビット３５が「１」に
セットされていなければ、または、Ｉnのための属性ワ
ード２のビット３４が「１」にセットされていなければ
（それはメモリが使用されていることを示している
が）、事象は生ぜず、プロセスは次に進みうる。両ビッ
トともオンであれば、両命令のアドレスはそれらがはっ
きりと異なるものであるか否かを判定するようチェック
されなければならない。これが判定され得なければ、そ
れらは同じであり、ＩmはＩnの後に移され得ないと仮定
されなければならない。

【００３３】このプロセスによりＩmがすぐ前の命令の
前には移され得ないと判定されると、パイプライン処理
の中断は現行の命令列により可能な範囲で最小化され
た。そして、次の新しい命令が解析のために呼び出され
る。しかしながら、Ｉmがすぐ前の命令の前に移され得
ると判定されると、その判定は選択的に（しかし、そう
することが好ましいのであるが）パイプライン処理の中
断を更に最小化し、若しくは除去するために、それが更
に前に移され得るか否かをみるよう続けられうる。この
フィーチャは図７に示されており、同図において、全て
のテストにおける解消法がＩmおよびＩnの交換を生じせ
しめ、バッファ内の次に古い命令がＩnとして指定され
た後、このサブプロセスを反復せしめることがわかるで
あろう。もちろん、バッファ内により古い命令がさらに
なければ、全ての可能性のあるケースはその状態に至る
までに解消されるであろう。

【００３４】図６に示されるように、Ｉmを受け入れら
れる最も早い位置が決定されると、バッファ内の最も古
い命令はオブジェクト・モジュールへ送られ、新しい命
令がバッファ内のスタックの最も上に置かれる。そし
て、次の新しい命令が解析のために呼び出される。中断
が解消され、新しい命令がバッファの中にプッシュされ
た後、その新しい命令が制御の移転であるか否かを判定
するチェックが行われる。そうであれば、制御の移転命
令を含むバッファは制御の移転の前に命令を移すことは
誤まりであろうために、オブジェクト・モジュールにそ
の内容が流し出される。（実用においては、バッファの
大きさは場合によって変わりうるであろう。それは長さ
ゼロのところで再スタートし得、命令が処理されるにつ
れ、最大の大きさ、本実施例においては５、にまで長く
なり、その結果、新しい命令が含まれることにより命令
がオブジェクト・モジュールに「押し出されること」が
開始されるようになる。）さらに、その移転の宛先が調
べられ、それが現行のプログラム内にあり、かつ以前の
位置になければ、その宛先の位置は「ラベル」（この意
味においてラベルとは一般に転送の宛先である）テーブ
ルの中に保持される。そして、この情報は命令が処理の
ために再び呼び出されるときに使用されうる。

【００３５】

【発明の効果】再び図１および図８も参照すると、本発
明による再スケジュールがうまくいった、その結果が理
解され得よう。図８においては、Ｉm（すなわち、Ｉ
３）がＩ２およびＩ１の前に確実に移され得、確実に行
われるかぎり移されうると判定されたと一実施例として
想定されている。図１および図８の比較から明らかなよ
うにパイプライン処理の中断を完全に除去する結果とな
り、これにより処理効率の実質的向上がもたらされる。
他の例においても、上述のように、パイプライン処理の
中断が本発明を適用することにより完全に除去され得る
か、また最小化され得、そのことは明らかにプロセッサ
の処理効率を向上せしめる。

【００３６】本発明の原理が図示された実施例の中で明
らかにされてきたが、本技術の熟練家にとって、これら
の原理を逸脱することなく特定の環境および動作要件の
ために特に採用された本発明の実際に用いられうる多く
の構造、配置、比率、順番などの変形例があることは明
らかであろう。

【図面の簡単な説明】

【図１】パイプライン処理の中断を起こす状況下での４
段階のパイプラインの例において用いられる命令を示し
た表を表わしたものである。

【図２】本発明の高レベルのフローチャートである。

【図３】本発明の具体例に用いられている命令テーブル
属性ワードの例を図示している。

【図４】本発明の具体例に用いられているアドレス／使
用の属性ワードの例を図示している。

【図５】本発明の具体例に用いられている変換／特殊の
属性ワードの例を図示している。

【図６】本発明の第１のサブプロセスの要素を特に説明
するためのより詳細なフローチャートである。

【図７】本発明の第２のサブプロセスの要素を特に説明
するためのより詳細なフローチャートである。

【図８】パイプライン処理の中断を避けるために、パイ
プライン処理の命令が本発明により再スケジュールされ
た、図１に類似する表を表わしたものである。

フロントページの続き (58)調査した分野(Int.Cl.⁶，ＤＢ名) G06F 9/38 G06F 9/45

Claims (5)

(57)【特許請求の範囲】
1. 【請求項１】 パイプライン処理の中断を最も少なくす
   るように、パイプライン化された構造のプロセッサ内で
   用いられる、コンパイルされたプログラムの命令の順序
   をスケジューリングする方法であって、 （Ａ） すでに命令バッファ内に存在する命令の表現に
   関して、スケジュール処理されるべき新しい命令の表現
   を受け取るための命令バァファを準備し、 （Ｂ） スケジュール処理されるべき命令が残っていれ
   ば新しい命令を呼び、そうでなければそのスケジュール
   ・プロセスを終結し、 （Ｃ） そのスケジュール処理されるべき新しい命令の
   ために、アドレシングが行われうる方法と、どのレジス
   タが使用されるかと、レジスタが使用される方法と、ど
   のレジスタが修飾されるかと、スケジューリング・プロ
   セスが適用されるべきコンピュータ・プロセッサに与え
   られた命令の各々のためにレジスタが修飾される方法に
   ついて、符号化された記述を含む命令属性テーブルの内
   容をアクセスすることにより、前記命令のメモリ及びレ
   ジスタの利用方法に関する情報をもたらす複数の属性フ
   ィールドを設定し、 （Ｄ） 衝突が存在するか否かを判別するために新しい
   命令の属性フィールドをその時バァファ内にある複数の
   命令の属性フィールドと論理的に比較し、 （Ｅ） ステップ（Ｄ）において衝突がないと判別され
   るとステップ（Ｆ）へ進み、 （Ｆ） バッファ内の最も古い命令をオブジェクト・モ
   ジュールへ送り、新しい命令を前記バッファへプッシュ
   し、 （Ｇ） ステップ（Ｂ）へ復帰し、 （Ｈ） ステップ（Ｄ）において衝突があると判別され
   るとステップ（Ｉ）へ進み、 （Ｉ） 前記バッファ内にすでにある最新の命令を前記
   バッファ内のより前の位置に動かされるべき候補、Ｉm
   として指定し、 （Ｊ） Ｉmの複数の属性フィールドを、バッファ内の
   命令のうちのＩmの直前にある選択されたＩnの複数の属
   性フィールドと逐次かつ論理的に比較する事によって、
   ＩmおよびＩnのバッファ内の位置が安全に交換できるか
   否か決定し、 （Ｋ） ＩmおよびＩnが安全に交換できれば、その交換
   を行い、Ｉmがバッファ内のさらに前に動かせるか否か
   決定するためにステップ（Ｊ）に復帰し、 （Ｌ） ＩmおよびＩnが安全に交換できなければ、又は
   Ｉnとして指定される命令が前記バッファ内に残ってい
   なければステップ（Ｆ）へ進む ステップを含む、スケジューリング方法。
2. 【請求項２】 ステップ（Ｇ）とステップ（Ｂ）との間
   に次のステップが含まれることを特徴とする請求項１の
   方法。 （Ｍ） 前記バッファにプッシュされた新しい命令が制
   御の移転であるか否かを決定するステップ、 （Ｎ） ステップ（Ｍ）で新しい命令が制御の移転であ
   ると決定されれば、前記バッファの内容を前記オブジェ
   クト・モジュールに流し出し、そしてステップ（Ｂ）へ
   進むステップ、および （Ｏ） ステップ（Ｍ）で新しい命令が制御の移転でな
   いと決定されれば、ステップ（Ｂ）へ進むステップ。
3. 【請求項３】 ステップ（Ｎ）の間、後刻にそのプロセ
   スに再エントリーするために、宛先ラベルが発生される
   ことを特徴とする請求項２記載の方法。
4. 【請求項４】 プロセッサーのパイプライン形態で用い
   るために準備されたコンピュータ命令の当初の順序を並
   べ変える方法であって、前記プロセッサーは前記命令の
   順序付けられたサブセットを保持するためのデータ記憶
   （バッファ）を含む方法を実行し、前記記憶から取り出
   された命令は前記プロセッサーのパイプライン形態で用
   いるための新たな命令の順序を与えるように取り出され
   た順序に組み合わせられ、前記プロセッサーが、前記当
   初の順序に含まれ得る異なるタイプのコンピュータ命令
   の夫々に対する、夫々の命令の属性の符号化された表現
   を含むエントリーを有する表をアクセスし、前記並べ変
   える方法が、 （１）前記当初の順序を検査して、処理するべき残りの
   命令が含まれているかどうか決定し、 （ｉ）もし無ければ、この方法を終了する。 （ｉｉ）もし有れば、ステップ（２）へ行く。 （２）前記当初の順序における次の順番の命令をアクセ
   スし、 （３）前記次の順番の命令のために、該次の順番の命令
   のタイプに対応するエントリーに対する前記表をアクセ
   スして得られたエントリー内の符号化された表現を用い
   て前記次の順番の命令の実行によるメモリーおよびレジ
   スターのアクセスと用途を表す属性情報フィールドを作
   り、 （４）前記次の順番の命令の前記属性情報フィールド内
   の項目を、前記データ記憶内に現在保持されている前記
   命令に関連した属性情報フィールド内の対応する項目と
   比較し、 （ｉ）もし比較された対応する項目に関して衝突が無け
   れば、 （ａ）もし前記データ記憶が一杯なら、前記データ記憶
   に現在保持されている前記サブセットの実行のための最
   初の命令を前記データ記憶から取り出し、 （ｂ）前記次の順番の命令を前記データ記憶に入れて、
   ステップ（１）へ行く。 （ｉｉ）もし比較された対応する項目に関して衝突が有
   れば、ステップ（５）へ行く。 （５）前記データ記憶に入れられた最後の命令に関連し
   た前記属性情報フィールド内の項目を、前記データ記憶
   内に現在保持されているものの内の前記命令の直前の１
   つに関連した属性情報フィールド内の対応する項目と比
   較し、 （ｉ）もし比較された対応する項目に関して衝突が無け
   れば、属性情報の関連する項目をステップ（５）で比較
   した前記命令の前記データ記憶内での位置を交換し、前
   記データ記憶に入れられた前記最後の命令に関連した前
   記属性情報フィールド内の項目を、前記データ記憶内に
   現在保持されている前記他の命令の異なるものの内の１
   つに関連した属性情報フィールド内の対応する項目と比
   較するために、前記他の命令の全てに対してステップ
   （５）が繰り返されるまで、ステップ（５）を繰り返
   し、その後にステップ（４）（ｉ）（ａ）へ行く。 （ｉｉ）もし比較された対応する項目に関して衝突が有
   れば、ステップ（４）（ｉ）（ａ）へ行く。 ステップからなる、コンピュータ命令の当初の順序を並
   べ変える方法。
5. 【請求項５】 前記ステップ（４）（ｉ）（ｂ）におい
   て、ステップ（１）へ行く前に、前記次の順番の命令を
   検査して、その実行が制御の移転を起こすかどうかを決
   定し、 （４）（ｉ）（ｂ）（α）もし制御の移転が起こらない
   なら、ステップ（１）へ行く。 （４）（ｉ）（ｂ）（β）もし制御の移転が起こるな
   ら、前記データ記憶内に残っている全ての命令を取り出
   すことによって、前記データ記憶をクリアーして、その
   後にステップ（１）へ行く。 ことを特徴とする請求項４に記載の方法。