JP2594557B2

JP2594557B2 - マルチタスク処理装置

Info

Publication number: JP2594557B2
Application number: JP62093663A
Authority: JP
Inventors: 肇佐久間
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 1987-04-15
Filing date: 1987-04-15
Publication date: 1997-03-26
Anticipated expiration: 2012-03-26
Also published as: JPS63257833A

Description

【発明の詳細な説明】〔産業上の利用分野〕本発明は、プログラムを複数の処理単位（以下タス
ク）に分割し、複数のタスクを並列に動作させることに
より、プログラム全体の効率を向上させることを目的と
したマルチタスク処理装置に関するものである。

〔従来の技術〕

従来、複数のタスクを並列に実行させるために、リア
ルタイムOSは管理ソフトウェアとして必要不可欠なもの
となっており、その機能としては、タスクに起動をかけ
たり、処理を終了させたりするタスク管理機能、タスク
間の待ち合わせをしたりデータの送受信を行なったりす
るタスク間同期通信機能、割り込みに関係する機能、そ
の他メモリエリアの管理機能、時間の管理機能などの数
々の機能を備えているのが一般的となっている。

アプリケーションプログラムが、リアルタイムOSを利
用する際には、各機能毎の処理要求をリアルタイムOSに
対して出すが、この処理要求のことをシステムコールと
呼び、処理要求を出すことをシステムコールの発行と呼
ぶ。システムコール発行の例を以下に挙げる。

第２図は、２つのタスク間でのデータ送受信の例であ
る。タスク間のデータ送受信には、通常メールボックス
と呼ばれる共有バッファが利用される。タスクＡは、送
信データを生成し、データへのポインタをパラメータと
してメールボックス１番（＃MBO−１）にシステムコー
ルSEND−DATAで送信する。ここで、システムコールSEND
D−ATAのパラメータはレジスタROであるとする。

タスクＢは、タスクＡより送信されたデータを、シス
テムコールRECEIVE−DATAで、メールボックス１番経由
で受信し、受信データを基にその後の処理を行なう。受
信データは、データへのポインタがレジスタROに格納さ
れるものとする。システムコール発行時に、送信データ
が存在しない場合にタスクＢはメールボックス１番に対
して持ち状態となり処理は一時保留となり、他のタスク
に制御を移す。

第３図に、各システムコールの処理を示す。従来のリ
アルタイムOSはシステムソフトウェアとして命令の組み
合わせで実現されており、そのため処理の先頭ではシス
テムコールを発行したタスクのレジスタやプログラムス
テータスワード（以下PSW）など、プログラム走行に必
要な環境（以下コンテキスト）を退避してから各システ
ムコールの処理を行なう必要がある。通常コンテキスト
の退避エリアとしてタスク制御ブロック（以下TCB）と
呼ばれるエリアがメモリ上に各タスク毎に確保され、シ
ステムコール発行時には、発行タスクに相当するTCBに
タスクのコンテキストが退避される。

システムコールの処理後は、実行可能なタスクの内、
もっとも優先順位の高いタスクを選択して制御を移すこ
と（以下ディスパッチング）を行なう。

具体的に、システムコールRECEIVE−DATAでは、先ず
最初に発行タスクのコンテキストをTCBに退避する。次
に、パラメータで示されたメールボックス番号よりメー
ルボックスの状態を判定し、データが既に送信されてい
れば、そのデータへのポインタを、システムコール発行
タスクのTCB中のレジスタROに相当するエリアに格納し
たのちディスパッチングを行なう。データが送信されて
いない場合には、発行タスクはメールボックス待ちとな
り、発行タスクのタスクステータスを待ち状態とする。
タスクステータスもタスクのコンテキストと同様に、各
タスクのTCB中に確保されるのが普通である。

次にパラメータで示されたメールボックスに対して、
発行タスクが待ちになったことを示すために、メールボ
ックスに対してタスクの識別子を付加する。またリアル
タイムOSは、実行可能タスクを一括して扱うための構造
体（以下レディキュー）を管理しており、これも通常メ
モリ上に確保される。待ち状態になったタスクは、実行
不可能状態であるのでレディキューの登録から削除され
る。削除した後は、同様にディスパッチング処理に移
る。

次に、システムコールSEND−DATAの処理では、他のシ
ステムコール同様、先ず発行タスクのコンテキストがTC
Bに退避される。パラメータで指定されたメールボック
スの状態を判定し、待ちタスクがなければレジスタROで
示されたデータエリアへのポインタをメールボックスに
格納し、ディスパッチング処理を行なう。

メールボックスに対して待ちタスクが存在する場合に
は、待ちタスクのタスクステータスを実行可能状態にセ
ットし、メールボックスからタスクの識別子を削除し、
レディキューに登録した後、そのタスクのレジスタRO
に、送信データのポインタを格納した後、ディスパッチ
ング処理を行なう。

以上の処理を行なうことで、第２図に示したタスク
Ａ、タスクＢの実行の流れがどのようになるかを示した
のが第４図である。

タスクには夫々優先順位が設定されており、タスクＡ
よりもタスクＢの方が高いものとする。先ずタスクＢが
実行状態で動作し、システムコールRECEIVE−DATAでメ
ールボックス＃MBO−１からのデータの受信要求を発行
する。この時点ではメールボックスにデータが送信され
ておらず、発行タスクは待ち状態に遷移し、タスクＡに
制御が移る。タスクＡは、データを生成した後、メール
ボックス＃MBO−１に対してシステムコールＳ−END−DA
TAでデータを送信する。メールボックス＃MBO−１には
既にタスクＢが待ちになっているため、送信データはタ
スクＢに送られ、タスクＢは待ち状態から解除され実行
可能状態となる。ディスパッチング処理では、タスクＢ
の方がタスクＡよりも優先順位が高いため、タスクＢが
選択され制御が移る。

〔発明が解決しようとする問題点〕

以上説明したように、従来のリアルタイムOSは、命令
の組み合わせで実現されており、マルチタスクの処理を
実現する中心的システムソフトウェアであるため、その
処理はかなり複雑なものになっている。OSの規模にもよ
るが、一般的にいって、各々システムコールの処理に数
十ステップから数百ステップにも及ぶ。

また、一つの中央処理装置上で、各タスクの処理とOS
の処理が、共通のレジスタやその他のハードウェア資源
を利用するため、タスク毎のコンテキストを壊さないよ
うに、OS処理の最初と最後でコンテキストの退避、復帰
処理が必ず必要になる。この退避、復帰処理やディスパ
ッチング処理にも、数十ステップから数百ステップ要す
るのが普通となっている。

リアルタイムOSはその名の示す通り、数々の事象に対
して実時間で応答する必要があるが、現実には処理が複
雑であるためアプリケーションプログラムの要求を十分
満足するだけの性能が得られていないのが現状である。
リアルタイムOSの性能を評価する際によく問題となるの
がシステムコールのオーバヘッドであるが、これはシス
テムコールを発行してから再度タスクに制御が戻って来
る迄の時間をいう。前記例でシステムコールを発行し、
コンテキストの退避，復帰処理をした後、各システムコ
ールの処理を行ない、ディスパッチング処理を実行し、
タスクへ制御を戻すまでのステップを、仮に200ステッ
プ、中央処理装置の平均命令実行クロック数を10クロッ
ク、動作周波数を5MHzとすると平均オーバヘッドは、40
0μSECとなる。

この時間は、特にリアルタイム性が要求されるアプリ
ケーション分野では無視できない時間で、オーバヘッド
を低く抑えることがリアルタイムOSを設計する上での課
題となっている。

また、リアルタイムOSを利用したアプリケーションシ
ステムでは、数々の割り込みを契機として処理の流れを
変化させることがよく起こるため、割り込みに対する応
答性も良くする必要がある。しかし、マルチタスク処理
を制御するOSは、各タスクの状態を管理したり、優先順
位毎に実行可能状態のタスクを管理したりする共通のデ
ータ構造を操作するため、アクセスの競合が起こらない
ように、外部から非同期に発生する割り込みに対して、
ガードしなければならない部分も多く存在する。

以下、具体的に割り込みに対するガードがなかった場
合の誤動作の例を示す。第３図のシステムコールRECEIV
E−DATAで、INTの位置に割り込みが発生したとする。割
り込みINTにより起動される割り込み処理ルーチンを、
第５図に示す。割り込み処理ルーチンは、通常割り込み
不可状態で動作するため、簡単な処理をした後、ディス
パッチングを要求するシステムコールを発行する。

今、システムコールRECEIVE−DATAの処理中、INTの位
置に割み込みが発生した場合、システムコール発行タス
クはメールボックス待ちになろうとする処理の過程で、
タスクステータスは待ち状態となり、メールボックスに
対し、タスクの識別子が登録されている。制御が移った
割り込み処理ルーチンでは、簡単な処理の後、ディスパ
ッチング処理要求を発行する。OSのディスパッチング処
理では、レディキューを判定し、最も優先順位の高いタ
スクを選択するが、この時、割り込まれたシステムコー
ルRECEIVE−DATAを発行したタスクは、レディキューよ
り登録は削除されていない。従って、発行タスクはディ
スパッチング処理により再び選択され実行状態へと戻る
ことになる。実行が再開したタスクは、システムコール
RECEIVE−DATAの発行で、データが受信できたものと判
断し処理を継続するが、実際には受信されたデータへの
ポインタは不確定値となり、その後の動作は保証されな
い。

従って、本例のようなシステムコールの場合には、処
理の大部分に割り込みに対するカードをかける必要があ
る。

このカード部分が多ければ多いほど、システム全体の
安定性は向上するが、一方、割り込み応答性は低下す
る。この点も、リアルタイムOSを設計する上での難題と
なっている。

〔問題を解決するための手段〕

本発明のマルチタスク処理装置は、一つの中央処理装
置を用いて複数のタスクを処理するマルチタスク処理装
置において、マルチタスク処理を実行中に必要となるリ
アルタイムOSに対する処理要求を前記処理要求を示すオ
ペレーションコードと前記処理要求によって処理される
処理が必要とするパラメータを示すオペランドとから成
る前記処理要求の専用命令を用いて行い、かつ前記中央
処理装置は、前記専用命令の前記オペレーションコード
を解読する命令デコーダ部と、前記専用命令のオペラン
ドを格納するオペランド格納部と、前記命令デコーダ部
からの解読情報により起動され前記要求を実行するため
のオペレーションコードに対応するマイクロプログラム
を格納しているマイクロプログラムメモリと、前記複数
のタスクにそれぞれ対応して設けられた複数のレジスタ
バンクおよびタスク制御ブロックと、前記オペランド格
納部に格納された前記オペランドの情報と前記マイクロ
プログラムメモリからの選択信号により前記タスク制御
ブロックの選択信号を発生する選択信号発生部と、前記
処理要求を発行したタスクに対応する前記レジスタバン
クを認識するレジスタバンク管理部とを有し、前記レジ
スタバンク管理部からの信号と前記マイクロプログラム
メモリからの選択信号に基づき前記複数のレジスタバン
クの中の一つのレジスタバンクを選択する。

〔実施例１〕次に、本発明の実施例について説明する。

第１図は、マルチタスク処理を行なうために必要な、
ハードウエア資源及びマイクロプログラムメモリを備え
たコンピュータの構成例で、中央処理装置１とメモリ２
によって構成される。

アドレス生成部３は、メモリアクセス時、オペレーシ
ョンコードのフェッチ時にメモリに対してアドレスを発
生する。命令バッファ４は、フェッチした命令を一時的
に蓄え、命令デコード部６によりオペレーションコード
は解読され、マイクロプログラムメモリ11へのエントリ
アドレスを発生する。マイクロプログラムアドレス発生
部７は、命令デコード部６から発生されるエントリアド
レスまたはマイクロプログラムメモリ11から発生される
アドレス情報を基に、次に実行されるべきマイクロプロ
グラムメモリ11へのアドレスを発生する。オペランド格
納部５は、システムコールのパラメータが、専用命令の
オペランドとして存在する場合、そのオペランドを格納
する。

レジスタバンク12は、プログラムが走行する上で必要
な汎用レジスタのセット、その他アドレスレジスタ、PS
Wの退避エリアなどを含み、複数のバンクで構成され
る。この複数のバンクは、複数のタスク一つ一つに対応
し、マイクロプログラムのディスパッチング処理で選択
されるまで、システムコール専用命令を発行した時点の
コンテキストを保持する。従って、一つの中央処理装置
上で各タスクの処理とOSの処理が資源を共有して動作し
ている場合に必要だったTCBへのコンテキストの退避、
復帰処理は必要なく、タスクを切り換える場合には、た
だバンクを切り換えればよいハードウェア構成となって
いる。

レジスタバンク管理部８は、ある時点で中央処理装置
がどのレジスタバンクを対象として動作しているかを示
す部分で、ディスパッチング処理で操作する。レジスタ
選択部９は、マイクロプログラムメモリ11からの選択信
号と、レジスタバンク管理部８からのバンク識別信号か
らレジスタを一意的に選択するための信号を発生する。

ALU14は演算部で、一時的なレジスタセットであるテ
ンポラリレジスタセット13を利用しながら演算処理を行
なう。PSW15は、演算の結果を反映するフラグ類を保持
する。

TCB16、レディキュー17、メールボックス18はマルチ
タスク処理を行なう上で特に必要となるハードウェア資
源で、TCB16は必要なタスク数分だけTCBを備え、各TCB
にはタスクステータス、タスクの優先順位などが格納さ
れる。レディキュー17は、優先順位の数だけ存在し、実
行可能状態であるタスクの識別子を保持する。メールボ
ックス18は、メールボックスの個数分存在し、各メール
ボックスの構成は、メールボックス待ちとなったタスク
の識別子と受信待ちとなったデータエリアへのポインタ
を管理する。また選択信号発生部10は、オペランド格納
部５に格納された情報と、マイクロプログラムメモリ11
からの信号を基に、TCB16、レディキュー17、メールボ
ックス18への選択信号を発生する。

割り込み要求保持部19は、外部から割り込み要求信号
20が発生した場合、絶えず要求が発生したことを記憶し
ておくためのレジスタである。

以下システムコール専用命令RECEIVE−DATAの処理を
説明する。

RECEIVE−DATAは、入力パラメータとしてメールボッ
クス番号、出力パラメータとして受信データへのポイン
タを有する。第９図にシステムコール専用命令の構成を
示している。入力パラメータのメールボックス番号は専
用命令のオペランドとしてオペレーションコードに続く
１バイトに格納されている。本例でのメールボックス番
号はメールボックスMBO−１を示すものとする。出力パ
ラメータとして受信データへのポインタは、レジスタRO
に格納されているものとする。命令バッファ４に格納さ
れた専用命令のオペレーションコード部は、命令デコー
ド部６で解読され、マイクロプログラムメモリへのエン
トリアドレスを発生する。一方オペランドとしてのメー
ルボックス番号は、オペランド格納部５に格納される。

RECEIVE−DATAのマイクロプログラム処理の最初で
は、オペランド格納部５に格納されたメールボックス番
号からMBO−１への選択信号を発生させ、MBO−１の状態
を判定する。受信データへのポインタが格納されていた
場合には、既に他のタスクよりデータが送信されてお
り、発行タスクはこのポインタを受け取る。レジスタバ
ンク管理部８より、その時システムコール専用命令を発
行したタスクに対応するレジスタバンクを指定し、その
バンクのレジスタROにデータのポインタを格納する。格
納した後、デイスパッチング処理に移る。ディスパッチ
ング処理では、レディキュー17の優先順位の最も高いPR
Oから判定し、タスクの識別子が存在した場合にはその
タスクを選択し制御を移す。選択されたタスクに対応す
るレジスタバンクが、その時点のレジスタバンクと異な
る場合には、レジスタバンク管理部８の情報を更新し、
レジスタバンクを切り替え、タスクに制御を移す。

メールボックスMBO−１に受信データへのポインタが
格納されていない時、発行タスクはメールボックス待ち
となる。選択信号発生部10は、レジスタバンク管理部８
の情報から、TCB16中の発行タスクに対応するTCBへの選
択信号を発生し、タスクステータスをメールボックス待
ち状態に修飾する。次にMBO−１に対し、発行タスクの
識別子を格納し、レディキュー17の発行タスクの優先順
位に対応する管理エリアからタスクの識別子の登録を削
除し、ディスパッチング処理に移る。

ディスパッチング処理の最後のマイクロプログラムで
は、割り込み要求保持部19に割り込み要求があったか否
かの判定を行ない、もし割り込み要求があった場合には
タスクに制御を戻さず、割り込み処理のマイクロプログ
ラムを起動する。

ALU14、テンポラリレジスタセット13は、処理の過程
で必要な時に、データの加工や一時的な保持に利用す
る。

以上説明したような方法で、リアルタイムOSに対する
システムコールを専用命令として実現することが可能と
なる。

〔実施例２〕第６図は、第１図とほぼ同等の構成で、中央処理装置
１とメモリ２により構成されているが、TCBやメールボ
ールボックスなどのデータ構造は、ハードウエア化せず
外部メモリ上に展開されている例である。但し、ここで
は説明上メールボックスについては省略する。

アドレス生成部３、命令バッファ４、オペランド格納
部５、命令デコード部６、マイクロプログラムアドレス
発生部７、レジスタバンク管理部８、レジスタ選択部
９、マイクロプログラムメモリ11、レジスタバンク12、
テンポラリレジスタセット13、ALU14、PSW15、レディキ
ュー17、割り込み要求保持部19、割り込み要求信号20
は、実施例１と同等の機能を持つ。TCBは、特別なハー
ドウェア構成とはせず、外部メモリ上のデータ構造とし
て管理される。

制御ブロックアドレス生成部16は、マイクロプログラ
ムメモリ11からの指定と、オペランド格納部５の情報か
ら、メモリ上に展開されたTCBなどのデータ構造へのア
ドレスを生成する。

以上のハードウェア構成を用い、システムコール専用
命令START−TASK,SUSPEND−TASK,RESUME−TASKの動作説
明及び、発行タスクの制御の流れを示す。

第９図にシステムコール専用命令の構成を示してい
る。START−TASKとRESUME−TASKは、オペレーションコ
ードに読く１バイトにタスクの識別子が格納され、SUSP
END−TASKはオペランドなしの構成である。

第７図は、優先順位の低いタスクＣと高いタスクＤの
２タスクからなるマルチタスク処理の例で、初期状態は
タスクＣが実行状態、タスクＤは実行不可能状態にあ
る。タスクＣは処理の過程で、タスクＤを起動するシス
テムコール専用命令START−TASK＃Ｄを発行する。この
専用命令は中央処理装置１に取り込まれ、命令バッファ
４を経て、命令デコード部６で解読される。命令デコー
ドによって、マイクロプログラムメモリ11への先頭アド
レスが生成され、マイクロプログラムが動作を開始す
る。

マイクロプログラムの最初の処理では、オペランド格
納部５に格納されたタスクの識別子＃Ｄから、メモリ上
に構成されたタスクＤに対応するTCBへのアドレスを生
成するために、制御ブロックアドレス生成部16を制御す
る。生成されたTCBへのアドレスは、アドレス生成部３
を経ることで実際の物理メモリ上のアドレスに変換さ
れ、メモリ上の目的のTCBをアクセスする。タスクＤのT
CB中のタスクステータス、この段階では実行不可能状態
となっているが、これを実行可能状態に修飾する。次の
ステップでは、タスクＤの優先順位を読み出し、レディ
キュー17の相当する優先順位のエリアに識別子を格納す
る。

その後のディスパッチング処理では、最も優先順位の
高いタスクを選択するが、この場合タスクＣよりタスク
Ｄの方が優先順位が高いため、タスクＤが選択される。
タスクＤに対応したレジスタバンクが選択され、レジス
タバンク管理部８も更新されタスクＤに制御が移され
る。

以上の処理により、制御がタスクＣからタスクＤへ移
ったことを第７図は示している。

第８図は、タスクを一時的に中断するシステムコール
専用命令（SUSPEND−TASKとタスクの中断状態を解除す
るシステムコール専用命令RBS−UME−TASKの例を示して
いる。

優先順位はタスクＥの方が、タスクＦより高く、初期
状態はタスクＥが実行状態でタスクＦが実行可能状態で
ある。タスクＥは、一時的に中断すべくシステムコール
専用命令SUSPEND−TASKを発行する。前述と同様の過程
を経て、SUSPEND−TASKのマイクロプログラムが起動す
る。

先ず、現在動作中のタスクの識別子をレジスタバンク
管理部８から判断し、外部メモリ中のタスクＥに対応す
るTCB中のタスクステータスを、実行状態から中断状態
にセットし、タスクＥに対応するレディキュー17の優先
順位エリアから、タスクの識別子の登録を削除する。

ディスパッチング処理では実行可能状態のタスクの
内、最も優先順位の高いタスクを選択するため、タスク
Ｆが選択されタスクＦに制御が移される。

タスクＦの動作中、割り込みINT₁が発生したとする
と、INT₁に対応する割り込み処理ルーチンに制御が移
る。割り込み処理ルーチンINT₁中で、システムコール専
用命含RESUMU−TASK＃Ｅを発行し、タスクＥの中断状態
を解除したとすると、RESUME−TASKのマイクロプログラ
ム処理では、タスクＥに対応するTCB中のタスクステー
タスを中断状態から実行可能状態へ設定し、タスクＥの
優先順位に相当する、レディキューのエリアにタスクＥ
のタスク識別子を登録した後、ディスパッチング処理を
実行するため、タスクＥが選択され再度タスクＥが実行
権を得る。

以上説明したように、OSが管理するデータ構造を外部
メモリ上に展開することでも、システムコールを専用命
令としてマイクロプログラムで実現することは可能で、
実施例１のようにOSが必要とするデータ構造を総て中央
処理装置内にハードウェアとして実現した場合に比べ
て、システムコール専用命令の実行速度は、外部バスサ
イクルを起動する分遅くなるが、その分ハードウェア資
源は削減される。

ハードウェアによる実現をどこまで行なうかは、シス
テム毎の用途に応じて適宣選択し設計することが可能で
ある。

〔発明の効果〕

前述したように本発明は、リアルタイムOSに対するシ
ステムコールを命令の組み合わせで実現せず、専用命令
として扱い、その処理を総てマイクロプログラムで実現
し、且つ専用命令実現のためのハードウェア手段を利用
することにより、システムコールの処理を高速化し、ま
たレジスタバンクなどの特殊なハードウェアを利用する
ことでメモリ空間上にコンテキストを退避、復帰する必
要がなく、従来問題となっていたシステムコールのオー
バヘッドを削減することができる。前述したように命令
の組み合わせでシステムコールを実現した場合の平均オ
ーバヘッドが400μSECに対して、マイクロプログラムで
システムコールの処理を行なった場合にもステップ数が
200ステップと仮定した場合、マイクロプログラムでは
１ステップが１クロックに相当するため、同一周波数で
40μSEC程度になる。実際には、マイクロプログラムで
はハードウエア資源に対して、１クロックで同時に複数
の処理が可能であるため、より少ないステップ数で実現
できると考えられ、殆どのアプリケーションシステムで
問題とならない程のオーバヘッドとなる。また専用命令
として１命令で実現していることで、割り込みに対して
のガード部分の設定などの配慮がいらず、リアルタイム
OSを設計する際に難しかった割り込み応答性に対する考
慮が必要なくなり、OS設計の面でも有効となると同時に
割り込み応答性も格段に向上する。

【図面の簡単な説明】

第１図は実施例１のブロック図である。１……中央処理装置、２……メモリ、３……アドレス生
成部、４……命令バッファ、５……オペランド格納部、
６……命令デコード部、７……マイクロプログラムアド
レス生成部、８……レジスタバンク管理部、９……レジ
スタ選択部、10……選択信号発生部、11……マイクロプ
ログラムメモリ、12……レジスタバンク、13……テンポ
ラリレジスタセット、14……ALU、15……PSW、16……TC
B、17……レディキュー、18……メールボックス、19…
…割り込み要求保持部、20……割り込み要求信号、第２図はマルチタスク処理でのデータ送受信に関するシ
ステムコール発行を示す流れ図、第３図はデータ送受信
システムコールの命令の組み合わせによるフローチャー
ト、第４図はマルチタスク処理における、各タスクの処
理の流れ図、第５図は割り込み処理ルーチンの流れ図、
第６図は実施例２のブロック図である。１……中央処理装置、２……メモリ、３……アドレス生
成部、４……命令バッファ、５……オペランド格納部、
６……命令デコード部、７……マイクロプログラムアド
レス生成部、８……レジスタバンク管理部、９……レジ
スタ選択部、11……マイクロプログラムメモリ、12……
レジスタバンク、13……テンポラリレジスタセット、14
……ALU、15……PSW、16……制御ブロックアドレス生成
部、17……レディキュー、19……割り込み要求保持部、
20……割り込み要求信号、第７図，第８図は、マルチタスク処理における、各タス
クの処理の流れ図、第９図は、システムコール専用命令
のフォーマット図である。

Claims

(57)【特許請求の範囲】

【請求項１】一つの中央処理装置を用いて複数のタスク
を処理するマルチタスク処理装置において、マルチタス
ク処理を実行中に必要となるリアルタイムOSに対する処
理要求を前記処理要求を示すオペレーションコードと前
記処理要求によって処理される処理が必要とするパラメ
ータを示すオペランドとから成る前記処理要求の専用命
令を用いて行い、かつ前記中央処理装置は、前記専用命
令の前記オペレーションコードを解読する命令デコーダ
部と、前記専用命令のオペランドを格納するオペランド
格納部と、前記命令デコーダ部からの解読情報により起
動され前記要求を実行するためのオペレーションコード
に対応するマイクロプログラムを格納しているマイクロ
プログラムメモリと、前記複数のタスクにそれぞれ対応
して設けられた複数のレジスタバンクおよびタスク制御
ブロックと、前記オペランド格納部に格納された前記オ
ペランドの情報と前記マイクロプログラムメモリからの
選択信号により前記タスク制御ブロックの選択信号を発
生する選択信号発生部と、前記処理要求を発行したタス
クに対応する前記レジスタバンクを認識するレジスタバ
ンク管理部とを有し、前記レジスタバンク管理部からの
信号と前記マイクロプログラムメモリからの選択信号に
基づき前記複数のレジスタバンクの中の一つのレジスタ
バンクを選択することを特徴とするマルチタスク処理装
置。