JP2015122063A - マルチスレッディングを支援するための演算ユニット、それを含むプロセッサ及びプロセッサの動作方法 - Google Patents

Abstract

【課題】マルチスレッディングを支援する演算ユニット、それを含むプロセッサ及びプロセッサの動作方法を提供する。【解決手段】演算ユニット１００は、互いに異なるスレッドに対するオペコード及びオペランドをそれぞれ入力される複数の入力ポート１１０と、入力されたオペランドを用いて演算を行う複数の演算子１２０と、各オペコードに基づいて、受信されたオペランドのうち１つを使って特定の演算を行う演算子１２０を、複数の演算子１２０のうちから選択する演算子選択部１３０と、各スレッドの演算遂行結果を出力する複数の出力ポート１４０と、を含む。【選択図】図１

Description

本発明は、マルチスレッディングプロセッサに関する。特には、マルチスレッディングを支援するための演算ユニット、それを含むプロセッサ及びプロセッサの動作方法に関する。

コンピュータ分野の技術の発達につれて、１つの作業だけではなく、多数の作業を同時に実行しなければならない場合が頻繁に発生する。このように同時に多くの作業を処理することを、マルチプロセッシング（ｍｕｌｔｉｐｒｏｃｅｓｓｉｎｇ）、マルチタスキング（ｍｕｌｔｉｔａｓｋｉｎｇ）、マルチプログラミング（ｍｕｌｔｉｐｒｏｇｒａｍｍｉｎｇ）、及び／またはマルチスレッディング（ｍｕｌｔｉｔｈｒｅａｄｉｎｇ）と言う。

このようなマルチプロセッシングは、マルチタスキング、多重化（Ｍｕｌｔｉｐｌｅｘｉｎｇ）などの方法で提供されるが、前者の場合、多数の作業を多数のプロセス（または、スレッド）に分けて処理することを意味し、後者の場合、１つのプロセス内で多数の作業を処理することを意味する。

例えば、マルチタスキングは、多くの作業（すなわち、タスク）を並行して処理するものであって、オペレーティングシステム（ＯＳ）は、マルチタスキングのためにプロセスを多数個使って実行させるか（マルチプロセス）、スレッドを多数個実行させる技法（マルチスレッド）を使う。

この際、マルチプロセスとマルチスレッドは、両方とも複数の流れが同時に進行するという共通点を有している。しかし、マルチプロセスにおいて、各プロセスは、独立して実行され、それぞれ別個のメモリを占めているのとは異なって、マルチスレッドでは、プロセス内のメモリを共有することができる。また、プロセス間の転換速度よりもスレッド間の転換速度が速く、スレッド間のスケジューリングも、プロセス間のスケジューリングよりも相対的に速くなされる。

本発明は、マルチスレッディングを支援するための演算ユニット、それを含むプロセッサ及びプロセッサの動作方法を提供する。

本発明の一態様によるマルチスレッディングを支援するための演算ユニットは、互いに異なるスレッドに対するオペコード及びオペランドをそれぞれ入力される複数の入力ポートと、前記入力されたオペランドを用いて演算を行う複数の演算子と、各オペコードに基づいて、受信されたオペランドのうち１つを使って特定の演算を行う演算子を、前記複数の演算子のうちから選択する演算子選択部と、各スレッドの演算遂行結果を出力する複数の出力ポートと、を含みうる。

前記複数の出力ポートそれぞれは、互いに異なるスレッドに対する演算遂行結果を出力することができる。

前記複数の演算子は、データパス上に各スレッドに割り当てられて演算遂行結果を保存する複数のレジスタを含みうる。

前記複数の演算子それぞれは、前記複数の演算子のうち、他の演算子が行う演算とは異なる特定の演算を行うことができる。

前記複数の演算子のうち少なくとも２つの演算子は、互いに同じ演算を行うことができる。

前記少なくとも２つの演算子は、前記演算ユニット内で遂行頻度の高い演算を行うことができる。

前記少なくとも２つの演算子は、自身の現在状態を表わす信号を生成して、前記演算子選択部に伝送しうる。

本発明の他の態様によるプロセッサは、複数のスレッドを同時に処理する少なくとも１つの演算ユニットを含むプロセッシング部と、前記複数のスレッドのうち少なくとも２つのスレッドが、同じ演算ユニット内で同じ演算を行うために同時に試みているか否かを判断して、リソースの衝突を感知するリソース衝突感知部と、リソースの衝突が感知されれば、設定された基準によって、前記衝突された少なくとも２つのスレッド間の処理順序を決定するリソーススケジューラと、を含みうる。

前記リソース衝突感知部は、前記少なくとも１つの演算ユニットについての演算子情報を保存するリソース情報保存部と、前記複数のスレッドのオペコードを各演算ユニット別に比較するオペコード比較部と、前記オペコード比較部の比較の結果及び前記リソース情報保存部に保存された演算子情報に基づいてリソースの衝突有無を判断するリソース衝突有無判断部と、を含みうる。

前記演算子情報は、各演算ユニットに含まれている演算子の種類、個数及び各演算子の状態情報のうち少なくとも１つを含みうる。

前記リソーススケジューラは、前記衝突された少なくとも２つのスレッドのうち、処理順序の低いスレッドに対するストール信号を生成することができる。

プロセッサは、前記リソース衝突感知部から受信されたリソース衝突感知結果を保存するキューをさらに含みうる。

プロセッサは、前記複数のスレッドのうち、一部に含まれた制御文の実行によって、前記キューに保存されたリソース衝突感知結果が有効ではない場合、前記キューをフラッシュするフラッシュ部をさらに含みうる。

本発明のさらに他の態様による複数のスレッドを同時に処理する少なくとも１つの演算ユニットを含むプロセッサの動作方法は、少なくとも２つのスレッドが、同じ演算ユニット内で同じ演算を行うために同時に試みているか否かを判断して、リソースの衝突を感知する段階と、リソースの衝突が感知されれば、既定の基準によって、前記衝突された少なくとも２つのスレッド間の処理順序を決定する段階と、を含みうる。

前記感知する段階は、前記複数のスレッドのオペコードを各演算ユニット別に比較する段階と、比較の結果及び保存された演算子情報に基づいてリソースの衝突有無を判断する段階と、を含みうる。

前記演算子情報は、各演算ユニットに含まれている演算子の種類、個数及び各演算子の状態情報のうち少なくとも１つを含みうる。

プロセッサの動作方法は、前記衝突された少なくとも２つのスレッドのうち、処理順序の低いスレッドをストールする段階をさらに含みうる。

プロセッサの動作方法は、リソース衝突感知結果をキューに保存する段階をさらに含みうる。

プロセッサの動作方法は、前記複数のスレッドのうち、一部に含まれた制御文の実行によって、前記キューに保存されたリソース衝突感知結果が有効ではない場合、前記キューをフラッシュする段階をさらに含みうる。

本発明のさらに他の態様によるプロセッサは、第１演算を行い、第１現在状態信号を生成及び伝送する第１演算子と、第２演算を行い、第２現在状態信号を生成及び伝送する第２演算子と、前記第１現在状態信号、前記第２現在状態信号、及び第１スレッドの第１オペランドを利用する第１オペコードに基づいて、前記第１演算子及び前記第２演算子のうち１つを選択し、前記第１現在状態信号、前記第２現在状態信号、及び第２スレッドの第２オペランドを利用する第２オペコードに基づいて、前記第１演算子及び前記第２演算子のうち１つを選択する演算子選択部を含む演算ユニットと、前記第１スレッド及び前記第２スレッドに対して同じ演算子が選択されれば、リソース衝突を感知するリソース衝突感知部と、前記第１スレッド及び前記第２スレッドのうち、優先順位の低いスレッドをストールして、前記第１スレッド及び前記第２スレッドの処理順序を決定するリソーススケジューラと、を含みうる。

前記リソース衝突感知部は、演算子タイプ、演算子の数、及び各演算子の状態情報のうち少なくとも１つを含む演算ユニットについての演算子情報を保存するリソース情報保存部と、前記第１オペコード及び前記第２オペコードを比較するオペコード比較部と、オペコードの比較の結果及び前記演算子情報に基づいてリソースの衝突有無を判断するリソース衝突判断部と、を含みうる。

プロセッサは、前記リソース衝突感知部から受信されたリソース衝突感知結果を保存するキューと、前記第１スレッド及び前記第２スレッドのうち少なくとも１つに含まれた制御文の実行によって、前記キューに保存されたリソース衝突感知結果が有効ではない場合、キューをフラッシュするフラッシュ部と、をさらに含みうる。

本発明の一実施形態によるマルチスレッディングを支援するための演算ユニットの概略的な構成図である。 本発明の一実施形態によるマルチスレッディングを支援するための演算ユニットの例示図である。 本発明の一実施形態によるプロセッサの構成図である。 本発明の一実施形態による図３のリソース衝突感知部３２０の詳細構成図である。 本発明の他の実施形態によるプロセッサの構成図である。 本発明の一実施形態によるプロセッサ５００の動作方法を示す図面である。 本発明の一実施形態による図６のリソースの衝突を感知する過程（６１０）の詳細フローチャートである。

以下、添付図面を参照して、本発明の一実施形態を詳細に説明する。本発明を説明するにあたり、関連した公知機能または構成についての具体的な説明が、本発明の要旨を不明にするおそれがあると判断される場合には、その詳細な説明を省略する。また、後述される用語は、本発明での機能を考慮して定義された用語であって、これは、ユーザ、運用者の意図または慣例などによって変わりうる。したがって、その定義は、本明細書の全般に亘った内容に基づいて下されなければならない。

取り立てて説明がない限り、図面及び詳細な説明の全般に亘って、同じ参照符号は、同じ構成、特徴、構造を参照するものと理解される。

一実施形態によれば、演算ユニット（ｆｕｎｃｔｉｏｎａｌ ｕｎｉｔ）は、実行ユニット（ｅｘｅｃｕｔｉｏｎ ｕｎｉｔ）と呼称され、中央処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ：ＣＰＵ）またはプロセッサの一部になりうる。また、演算ユニットは、ＣＰＵで実行中であるか、実行準備中であるコンピュータプログラムによって要求される動作（ｏｐｅｒａｔｉｏｎｓ）及び計算（ｃａｌｃｕｌａｔｉｏｎｓ）を行うことができる。演算ユニットは、ＣＰＵメイン制御ユニットと区分され、演算子選択部と呼称されてよく、内部制御シーケンスユニット（ｉｎｔｅｒｎａｌ ｃｏｎｔｒｏｌ ｓｅｑｕｅｎｃｅ ｕｎｉｔ）を含みうる。演算ユニットは、１つ以上のレジスタ及び内部装置（例えば、サブ算術論理ユニット（ｓｕｂ−Ａｒｉｔｈｍｅｔｉｃ Ｌｏｇｉｃ Ｕｎｉｔ）、浮動小数点ユニット（ｆｌｏａｔｉｏｎ−ｐｏｉｎｔ ｕｎｉｔ）など）を含みうる。

一実施形態によれば、ＣＰＵは、スカラーまたはスーパースカラー設計で配列される時、多数の並列機能ユニットを含みうる。そして、ＣＰＵの機能ユニットは、パイプラインになることもあり、１つの機能ユニットは、メモリインターフェースを管理するためにバスマネージャーとして使われ、残りの機能ユニットは、ＣＰＵによって実行されるコンピュータプログラムのための計算を行うように配置されることもある。

図１は、本発明の一実施形態によるマルチスレッディングを支援するための演算ユニットの構成図である。図１を参照すれば、演算ユニット（Ｆｕｎｃｔｉｏｎａｌ Ｕｎｉｔ；ＦＵ）１００は、入力ポート１１０ａ〜１１０ｃ、演算子１２０ａ〜１２０ｃ、演算子選択部１３０及び出力ポート１４０ａ〜１４０ｃを含みうる。

入力ポート１１０ａ〜１１０ｃは、オペコード及びオペランドをスレッド別に入力され得る。例えば、入力ポート＃１（１１０ａ）は、スレッド１に対するオペコード及びオペランドを、入力ポート＃２（１１０ｂ）は、スレッド２に対するオペコード及びオペランドを、入力ポート＃ｎ（１１０ｃ）は、スレッドｎに対するオペコード及びオペランドを入力され得る。この際、入力ポートの個数は、同時に処理しようとするスレッドの個数と同じでもあってもよいが、これに限定されるものではない。

演算子１２０ａ〜１２０ｃは、オペランド（ｏｐｅｒａｎｄ）に対する所定の演算を行うことができる。演算子１２０ａ〜１２０ｃは、加算器、乗算器、除算器、比較器などとして具現され得るが、これらに限定されるものではない。

一実施形態によれば、各演算子１２０ａ〜１２０ｃは、マルチスレッディングのために、各演算子１２０ａ〜１２０ｃのデータパス上に各スレッドに割り当てられて、演算結果を保存するレジスタ＃１、レジスタ＃ｎを含みうる。この際、レジスタ＃１は、スレッド１に割り当てられ、レジスタ＃ｎは、スレッドｎに割り当てられる。

演算子選択部１３０は、各入力ポート１１０ａ〜１１０ｃを通じて入力されたオペコードに基づいて、各オペランドに対する演算を行う演算子を選択することができる。例えば、演算子１２０ａは加算器、演算子１２０ｂは乗算器、演算子１２０ｃは比較器であると仮定する。この際、スレッド１のオペコードが加算命令であり、スレッド２のオペコードが乗算命令である場合、演算子選択部１３０は、スレッド１のオペランドを処理する演算子として演算子１２０ａを、スレッド２のオペランドを処理する演算子として演算子１２０ｂを選択することができる。この場合、演算子１２０ａは、スレッド１のオペランドに対して加算演算を行い、それと同時に、演算子１２０ｂは、スレッド２のオペランドに対して乗算演算を行う。

出力ポート１４０ａ〜１４０ｃは、演算遂行結果をスレッド別に出力することができる。例えば、出力ポート＃１（１４０ａ）はスレッド１に対する演算遂行結果を、出力ポート＃２（１４０ｂ）はスレッド２に対する演算遂行結果を、出力ポート＃ｎ（１４０ｃ）はスレッドｎに対する演算遂行結果を出力することができる。この際、出力ポートの個数は、同時に処理しようとするスレッドの個数と同じであってもよいが、これに限定されるものではない。

上述のように、演算ユニット１００は、複数のスレッドを同時に処理することが可能なので、スレッドレベル並列性（Ｔｈｒｅａｄ Ｌｅｖｅｌ Ｐａｒａｌｌｅｌｉｓｍ；ＴＬＰ）を極大化させることが可能である。

一方、一実施形態によれば、演算子１２０ａ〜１２０ｃは、互いに異なる演算を行うように具現され得る。この場合、演算ユニット１００は、複数のスレッドに対する互いに異なるオペコードを同時に処理することが可能である。

しかし、演算子１２０ａ〜１２０ｃが互いに異なる演算を行い、かつ、２つ以上のスレッドが同じ演算ユニット１００を用いて同じ演算を行う場合は、リソース衝突（ｒｅｓｏｕｒｃｅ ｃｏｎｆｌｉｃｔ）が発生して、優先順位の低いスレッドがストール（ｓｔａｌｌ）されて、システムの性能低下を引き起こすことがある。

一実施形態によれば、このような問題を解決するために、演算子１２０ａ〜１２０ｃのうち一部は、互いに同じ演算を行うように具現され得る。特に、演算ユニット１００内で遂行頻度の高い演算をリソース衝突なしに行うために、使用頻度の高い演算子を演算ユニット１００に複数個配置することができる。例えば、よく行われる動作を決定するために、多様なスレッドの動作をあらかじめプロファイリングし、その結果に基づいて、よく使われる演算子を演算ユニット１００に複数個配置することができる。例えば、プロファイリングの結果、加算演算をよく使うスレッドによってリソース衝突がよく発生して、システムの性能低下が発生したならば、演算ユニット１００に加算器をさらに１つ追加し、各加算器は、自身の現在状態情報、すなわち、現在使用可能であるか否かを知らせる信号を生成して、演算子選択部１３０に伝送することによって、演算子選択部１３０が適切な選択を行うことを可能にする。

特に、一実施形態によれば、同じ演算を行うように具現された一部演算子それぞれは、自身の現在状態を表わす信号を生成して、演算子選択部１３０に出力することができる。現在状態を表わす信号は、各演算子が使用可能か否かを知らせる信号を意味する。例えば、一部演算子それぞれは、自身が現在演算を行っていて、他のスレッドに対する演算を行えない時、ビジー（ｂｕｓｙ）信号を生成して、演算子選択部１３０に伝送しうる。この場合、演算子選択部１３０は、ビジー信号を送信した演算子を除いた残りの演算子のうちから演算を行う演算子を選択する。

また、ビジー信号を演算子選択部１３０に送信した演算子は、ビジー信号送信当時に遂行中であった演算が完了すれば、他のスレッドが当該演算子を利用できるように、完了信号を生成して出力することができる。

図２は、本発明の一実施形態によるマルチスレッディングを支援するための演算ユニットの例示図である。図２の演算ユニット２００は、２つのスレッドの同時処理を支援するための演算ユニットの例であって、２つの演算子（加算器及び比較器）を含む。図２は、説明の便宜上、２つの演算子を含むものと図示しただけのことであり、発明の用途及び性能によって多様な演算子を含むことも可能である。

図２を参照すれば、演算ユニット２００は、スレッド１及びスレッド２に対するオペランド及びオペコードを入力される。演算ユニット２００は、各オペコードに基づいて、各スレッドのオペランドに対する演算を行う演算子をスレッド別に選択し、スレッド別に選択した演算子を用いて、各スレッドのオペランドに対する演算を行う。例えば、スレッド１のオペコードが加算命令であり、スレッド２のオペコードが比較命令である場合、演算ユニット２００は、加算器を用いてスレッド１のオペランドに対して加算演算を行い、それと同時に、比較器を用いてスレッド２のオペランドに対して比較演算を行う。

各演算子のデータパス上には、各スレッドのためのレジスタが含まれる。例えば、レジスタ＃１は、スレッド１のためのレジスタであり、レジスタ＃２は、スレッド２のためのレジスタである。すなわち、スレッド１のオペランドに対する演算結果は、レジスタ＃１に保存され、スレッド２のオペランドに対する演算結果は、レジスタ＃２に保存される。

次いで、演算ユニット２００は、２つの出力端子を通じて演算遂行結果を各スレッド別に出力する。

図３は、本発明の一実施形態によるプロセッサの構成図である。図３を参照すれば、プロセッサ３００は、プロセッシング部３１０、リソース衝突感知部３２０及びリソーススケジューラ３３０を含みうる。

プロセッシング部３１０は、複数のスレッドを同時に処理することができる。このために、プロセッシング部３１０は、複数のスレッドに対する複数の演算を同時に行うことができる１つ以上の演算ユニットＦＵ＃０〜ＦＵ＃ｎを含みうる。この際、複数のスレッドに対する複数の演算を同時に行うことができる演算ユニットは、図１を参照して説明した演算ユニットと同一なので、その詳細な説明は省略する。

リソース衝突感知部３２０は、２つ以上のスレッドが同時に同じ演算ユニット内で同じ演算を行うか否かを検査して、リソースの衝突を感知することができる。例えば、スレッド１は、ＦＵ＃０内で加算演算を行い、スレッド２は、ＦＵ＃０内で乗算演算を行うならば、ＦＵ＃０は、加算演算及び乗算演算を同時に行うことが可能なので、リソース衝突が発生しない。しかし、スレッド１及びスレッド２が、ＦＵ＃１内で同じ演算である比較演算を行うならば、比較演算を行う比較器がＦＵ＃１内に１つだけ存在する場合、リソース衝突が発生する。この場合、リソース衝突感知部３２０は、ＦＵ＃１のリソース衝突を感知することができる。

リソース衝突感知部３２０の詳しい説明は、図４を参照して後述する。

リソーススケジューラ３３０は、既定の基準によって衝突されたスレッド間に処理順序を決定することができる。例えば、リソーススケジューラ３３０は、各スレッドでキャッシュミス（ｃａｃｈｅ ｍｉｓｓ）が発生したか否かを直接判断するか、外部からこれに関する情報を受信して、これにより、スレッド間に処理順序を決定することができる。他の例を挙げれば、リソーススケジューラ３３０は、ユーザまたはシステムによって設定された優先順位によって、各スレッドの処理順序を決定することもできる。しかし、前述した例に限定されるものではない。

一方、キャッシュミスが発生せず、外部情報も提供されず、衝突されたスレッド間にスレッド優先順位が存在しない場合、リソーススケジューラ３３０は、スレッドの特定属性に基づいて処理順序を決定することができる。例えば、特定属性は、スレッドに対する処理時間、保存時間、スレッドが要請したメモリ情報を呼び出す時間の量、演算複雑性及びサイクルのような値を含みうる。そして、このような値は、衝突されたスレッドと関連したあらゆる情報を考慮する加重決定アルゴリズム（ｗｅｉｇｈｔｅｄ ｄｅｃｉｓｉｏｎａｌｇｏｒｉｔｈｍ）に使われる。

リソーススケジューラ３３０は、決定された処理順序に基づいて処理順序の低いスレッドのデータパス（ｄａｔａｐａｔｈ）をストール（ｓｔａｌｌ）させるように、ストール信号を生成することができる。また、リソーススケジューラ３３０は、ストールされたスレッドのリソース使用権が許可されれば、グラント（ｇｒａｎｔ）信号を生成することができる。

プロセッシング部３１０は、ストール信号を受信すれば、処理順序の低いスレッドのデータパスをストールさせ、以後、ストールされたスレッドのリソース使用権が許可されて発生したグラント信号を受信すれば、ストールが解かれて、スレッドの処理を再開する。

図４は、本発明の一実施形態による図３のリソース衝突感知部３２０の詳細構成図である。図４を参照すれば、リソース衝突感知部３２０は、リソース情報保存部４１０、オペコード比較部４２０及びリソース衝突有無判断部４３０を含みうる。

リソース情報保存部４１０は、スレッド情報、演算ユニット情報及び演算子情報などをリソーステーブルに保存することができる。この際、スレッド情報は、同時に処理しようとするスレッドのＩＤ、現在処理中であるスレッドのＩＤなどを含みうる。演算ユニット情報は、プロセッシング部３１０に含まれている演算ユニットの個数、演算ユニットＩＤなどを含みうる。演算子情報は、各演算ユニットに含まれている演算子の種類、個数、演算子の状態情報などを含みうる。この際、演算子の状態情報は、各演算子が現在演算を行っているか否かに関する情報をいう。

一方、演算ユニット１００に含まれた演算子１２０ａ〜１２０ｃのうち、一部が同じオペコードを処理するように具現された場合であって、ビジー信号を演算子選択部１３０に送信した演算子がビジー信号送信当時処理中であったオペコードの処理が完了して、完了信号を送信すれば、リソース情報保存部４１０は、これを受信して、当該演算ユニットの演算子の状態情報を更新することができる。この際、演算子テーブルの運用は、多様な方法によって可能である。

オペコード比較部４２０は、各スレッドのオペコードを演算ユニット別に比較することができる。例えば、各スレッドの命令語を解釈（ｄｅｃｏｄｉｎｇ）すれば、各演算ユニット別に行うようとする演算の種類をオペコードを通じて分かる。この際、オペコード比較部４２０は、演算ユニット別に各スレッドのオペコードを相互比較することによって、各演算ユニットが同時に同じ演算を行うか否かを判断することができる。

リソース衝突有無判断部４３０は、リソース情報保存部４１０に保存された情報及びオペコード比較部４２０で比較した結果に基づいて、リソースの衝突有無を判断することができる。例えば、スレッド１及びスレッド２が、同時にＦＵ＃０で加算演算を行うものと仮定する。この場合、リソース情報保存部４１０に保存されたＦＵ＃０の演算子情報に照らして、ＦＵ＃０に２つの加算器が含まれている場合、ＦＵ＃０は、２つの加算器を同時に使うことができるので、リソースの衝突が発生しない。一方、ＦＵ＃０に１つの加算器だけが含まれている場合は、ＦＵ＃０は１つの加算器だけしか使えず、２つの加算演算を同時にできないので、スレッド１及びスレッド２のオペコードを同時に処理することができない。この場合、リソース衝突有無判断部４３０は、ＦＵ＃０でリソース衝突が発生すると判断することができる。

一方、プロセッサ３００は、パイプライン技法を適用する。一般的に、プロセッサパイプラインは、命令語の取出し（ｆｅｔｃｈ）段階、命令語解釈段階、命令語実行（ｅｘｅｃｕｔｅ）段階、結果保存（ｗｒｉｔｅ ｂａｃｋ）段階を含む。

一実施形態によれば、リソース衝突感知部３２０は、プロセッサパイプラインのうち、命令語解釈段階で各スレッドのオペコードを比較して、リソースの衝突有無を感知することができる。

図５は、本発明の他の実施形態によるプロセッサの構成図である。図５を参照すれば、プロセッサ５００は、プロセッシング部３１０、リソース衝突感知部３２０及びリソーススケジューラ３３０に追加して、キュー５１０及びフラッシュ部５２０をさらに含みうる。

プロセッサ５００で同時に処理される一部スレッドにブランチ（ｂｒａｎｃｈ）のような制御文が含まれている場合、制御文の実行によって、リソース衝突感知部３２０が命令語解釈段階で感知した結果が有効ではないこともある。このために、プロセッサ５００は、図３のプロセッサ３００の各構成にキュー５１０及びフラッシュ部５２０をさらに含みうる。

キュー５１０は、リソース衝突感知部３２０の感知結果を保存することができる。

フラッシュ部５２０は、制御文の実行によってキュー５１０に保存されている感知結果が有効ではない場合、キュー５１０をフラッシュ（ｆｌｕｓｈ）することができる。

もし、スレッドに制御文が含まれていない場合、または制御文を実行しても、キュー５１０に保存されている感知結果が有効な場合は、キュー５１０は、感知結果をリソーススケジューラ３３０に伝送し、リソーススケジューラ３３０は、感知結果に基づいて衝突されたスレッドのデータパスをストールさせることができる。この際、如何なるスレッドをストールさせるかは、リソーススケジューラ３３０で既定の基準によって決定された処理順序による。

図６は、本発明の一実施形態によるプロセッサの動作方法を示す図面である。図６を参照すれば、プロセッサの動作方法は、まず、複数のスレッドが同時に同じ演算ユニット内で同じ演算を行うかを検査して、リソースの衝突有無を感知する（６１０）。

次いで、衝突感知結果をキュー５１０に保存する（６２０）。

次いで、複数のスレッドのうち、一部に含まれた制御文の実行によってキュー５１０に保存されている感知結果が有効であるか否かを判断する（６３０）。

段階６３０の判断の結果、キュー５１０に保存された感知結果が有効な場合、既定の基準によって衝突されたスレッド間の処理順序を決定し（６４０）、衝突されたスレッドのうち、処理順序の低いスレッドをストールする（６５０）。

段階６３０の判断の結果、キュー５１０に保存された感知結果が有効ではない場合、キューをフラッシュし（６６０）、段階６１０に戻る。

図７は、図６のリソースの衝突を感知する過程（６１０）の詳細なフローチャートである。図７を参照すれば、リソースの衝突を感知する過程（６１０）は、まず、同時に処理しようとする複数のスレッドのオペコードを各演算ユニット別に比較する（７１０）。例えば、各スレッドの命令語を解釈すれば、各演算ユニット別に行うようとする演算の種類がオペコードを通じて分かる。したがって、命令語パイプラインのうち、命令語解釈段階で演算ユニット別に各スレッドのオペコードを相互比較することによって、各演算ユニットが同時に同じ演算を行うか否かを判断することができる。

次いで、比較の結果及びあらかじめ保存された演算子情報に基づいてリソースの衝突有無を判断する（７２０）。この際、演算子情報は、各演算ユニットに含まれている演算子の種類、個数及び各演算子の状態情報などを含みうる。

本発明の一態様は、コンピュータで読み取り可能な記録媒体にコンピュータで読み取り可能なコードとして具現しうる。プログラムを具現するコード及びコードセグメントは、当該分野のコンピュータプログラマーによって容易に推論され得る。コンピュータで読み取り可能な記録媒体は、コンピュータシステムによって読み取れるデータが保存されるあらゆる種類の記録装置を含む。コンピュータで読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光ディスクなどを含む。また、コンピュータで読み取り可能な記録媒体は、ネットワークで連結されたコンピュータシステムに分散されて、分散方式でコンピュータで読み取り可能なコードとして保存されて実行可能である。

以上、本発明について、その望ましい実施形態を中心に説明した。当業者ならば、本発明が、本発明の本質的な特性から外れない範囲内で変形された形態として具現可能であることを理解できるであろう。したがって、本発明の範囲は、前述した実施形態に限定されず、特許請求の範囲に記載の内容と同等な範囲内にある多様な実施形態が含まれるように解釈しなければならない。

本発明は、マルチスレッディングを支援するための演算ユニット、それを含むプロセッサ及びプロセッサの動作方法関連の技術分野に適用可能である。

１１０ 入力ポート
１２０ 演算子
１４０ 出力ポート
３００ プロセッサ
３１０ プロセッシング部
３２０ リソース衝突感知部
３３０ リソーススケジューラ
４１０ リソース情報保存部
４２０ オペコード比較部
４３０ リソース衝突有無判断部
５１０ キュー
５２０ フラッシュ部

Claims (22)

1. マルチスレッディングを支援するための演算ユニットであって、
   互いに異なるスレッドに対するオペコード及びオペランドをそれぞれ入力される複数の入力ポートと、
   前記入力されたオペランドを用いて演算を行う複数の演算子と、
   各オペコードに基づいて、受信されたオペランドのうち１つを使って特定の演算を行う演算子を、前記複数の演算子のうちから選択する演算子選択部と、
   各スレッドの演算遂行結果を出力する複数の出力ポートと、
   を含む、演算ユニット。
2. 前記複数の出力ポートそれぞれは、互いに異なるスレッドに対する演算遂行結果を出力する、
   請求項１に記載の演算ユニット。
3. 前記複数の演算子は、
   データパス上に各スレッドに割り当てられて演算遂行結果を保存する複数のレジスタを含む、
   請求項１または２に記載の演算ユニット。
4. 前記複数の演算子それぞれは、前記複数の演算子のうち、他の演算子が行う演算とは異なる特定の演算を行う、
   請求項１乃至３いずれか一項に記載の演算ユニット。
5. 前記複数の演算子のうち少なくとも２つの演算子は、互いに同じ演算を行う、
   請求項１乃至３いずれか一項に記載の演算ユニット。
6. 前記少なくとも２つの演算子は、前記演算ユニット内で遂行頻度の高い演算を行う、
   請求項５に記載の演算ユニット。
7. 前記少なくとも２つの演算子は、自身の現在状態を表わす信号を生成し、前記演算子選択部に伝送する、
   請求項５に記載の演算ユニット。
8. 複数のスレッドを同時に処理する少なくとも１つの演算ユニットを含むプロセッシング部と、
   前記複数のスレッドのうち少なくとも２つのスレッドが、同じ演算ユニット内で同じ演算を行うために同時に試みているか否かを判断して、リソースの衝突を感知するリソース衝突感知部と、
   リソースの衝突が感知されれば、設定された基準によって、前記衝突された少なくとも２つのスレッド間の処理順序を決定するリソーススケジューラと、
   を含む、プロセッサ。
9. 前記リソース衝突感知部は、
   前記少なくとも１つの演算ユニットについての演算子情報を保存するリソース情報保存部と、
   前記複数のスレッドのオペコードを各演算ユニット別に比較するオペコード比較部と、
   前記オペコード比較部の比較の結果及び前記リソース情報保存部に保存された演算子情報に基づいてリソースの衝突有無を判断するリソース衝突有無判断部と、
   を含む、
   請求項８に記載のプロセッサ。
10. 前記演算子情報は、各演算ユニットに含まれている演算子の種類、個数及び各演算子の状態情報のうち少なくとも１つを含む、
    請求項９に記載のプロセッサ。
11. 前記リソーススケジューラは、前記衝突された少なくとも２つのスレッドのうち、処理順序の低いスレッドに対するストール信号を生成する、
    請求項８乃至１０いずれか一項に記載のプロセッサ。
12. 前記プロセッサは、さらに、
    前記リソース衝突感知部から受信されたリソース衝突感知結果を保存するキューを含む、
    請求項８乃至１１いずれか一項に記載のプロセッサ。
13. 前記プロセッサは、さらに、
    前記複数のスレッドのうち、一部に含まれた制御文の実行によって、前記キューに保存されたリソース衝突感知結果が有効ではない場合、前記キューをフラッシュするフラッシュ部、を含む、
    請求項１２に記載のプロセッサ。
14. 複数のスレッドを同時に処理する少なくとも１つの演算ユニットを含むプロセッサの動作方法であって、
    少なくとも２つのスレッドが、同じ演算ユニット内で同じ演算を行うために同時に試みているか否かを判断して、リソースの衝突を感知する段階と、
    リソースの衝突が感知されれば、既定の基準によって、前記衝突された少なくとも２つのスレッド間の処理順序を決定する段階と、
    を含む、方法。
15. 前記感知する段階は、
    前記複数のスレッドのオペコードを各演算ユニット別に比較する段階と、
    比較の結果及び保存された演算子情報に基づいてリソースの衝突有無を判断する段階と、
    を含む、
    請求項１４に記載の方法。
16. 前記演算子情報は、各演算ユニットに含まれている演算子の種類、個数及び各演算子の状態情報のうち少なくとも１つを含む、
    請求項１５に記載の方法。
17. 前記方法は、さらに、
    前記衝突された少なくとも２つのスレッドのうち、処理順序の低いスレッドをストールする段階を含む、
    請求項１４乃至１６いずれか一項に記載の方法。
18. 前記方法は、さらに、
    リソース衝突感知結果をキューに保存する段階を含む、
    請求項１４乃至１７いずれか一項に記載のプロセッサの動作方法。
19. 前記複数のスレッドのうち、一部に含まれた制御文の実行によって、前記キューに保存されたリソース衝突感知結果が有効ではない場合、前記キューをフラッシュする段階をさらに含む、
    請求項１８に記載のプロセッサの動作方法。
20. 第１演算を行い、第１現在状態信号を生成かつ伝送する第１演算子と、
    第２演算を行い、第２現在状態信号を生成かつ伝送する第２演算子と、
    前記第１現在状態信号、前記第２現在状態信号、及び、第１スレッドの第１オペランドを利用する第１オペコードに基づいて、前記第１演算子及び前記第２演算子のうち１つを選択し、かつ、前記第１現在状態信号、前記第２現在状態信号、及び、第２スレッドの第２オペランドを利用する第２オペコードに基づいて、前記第１演算子及び前記第２演算子のうち１つを選択する、演算子選択部と、
    を含む演算ユニットと、
    前記第１スレッド及び前記第２スレッドに対して同じ演算子が選択されれば、リソース衝突を感知するリソース衝突感知部と、
    前記第１スレッド及び前記第２スレッドのうち、優先順位の低いスレッドをストールして、前記第１スレッド及び前記第２スレッドの処理順序を決定するリソーススケジューラと、
    を含む、プロセッサ。
21. 前記リソース衝突感知部は、
    演算子タイプ、演算子の数、及び、各演算子の状態情報のうち少なくとも１つを含む演算ユニットについての演算子情報を保存するリソース情報保存部と、
    前記第１オペコード及び前記第２オペコードを比較するオペコード比較部と、
    オペコードの比較の結果及び前記演算子情報に基づいてリソースの衝突有無を判断するリソース衝突判断部と、
    を含む、
    請求項２０に記載のプロセッサ。
22. 前記リソース衝突感知部から受信されたリソース衝突感知結果を保存するキューと、
    前記第１スレッド及び前記第２スレッドのうち少なくとも１つに含まれた制御文の実行によって、前記キューに保存されたリソース衝突感知結果が有効ではない場合、キューをフラッシュするフラッシュ部と、
    をさらに含む、
    請求項２０または２１に記載のプロセッサ。