JP3595028B2 - リアルタイムｏｓの処理方法 - Google Patents
リアルタイムｏｓの処理方法 Download PDFInfo
- Publication number
- JP3595028B2 JP3595028B2 JP15353795A JP15353795A JP3595028B2 JP 3595028 B2 JP3595028 B2 JP 3595028B2 JP 15353795 A JP15353795 A JP 15353795A JP 15353795 A JP15353795 A JP 15353795A JP 3595028 B2 JP3595028 B2 JP 3595028B2
- Authority
- JP
- Japan
- Prior art keywords
- window
- interrupt
- register
- processing
- windows
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【産業上の利用分野】
本発明はレジスタウィンドを備えたマイクロプロセッサにおけるリアルタイムＯＳの処理方法である。
【０００２】
近年，多数のレジスタを一定数のグループに分割して，一つのウィンドウにおいて所定数のレジスタを使用し，ウィンドウを切替えると，前のウィンドウで使用した一部のレジスタを次のウィンドウのレジスタの一部として使用（オーバラップという）するレジスタウィンドウ方式が知られている。このレジスタウィンドウ方式では，一つのタスクによる動作中に関数の呼び出しによりウィンドウが順次切替えられ，復帰動作により逆方向に切替えられて一定個数のウィンドウを越えると，オーバフローやアンダーフローが生じて，それぞれ退避や復元の処理が行われる。またタスクが切替えられたり，割り込みが発生すると，全てのウィンドウレジスタを退避（保存）して新たなタスクまたは割り込み先のウィンドウレジスタとして使用可能にする。
【０００３】
このようなレジスタウィンドウを備えたマイクロプロセッサを，交換機等のリアルタイム処理を必要とするシステムにおいて利用することができるが，レジスタの退避動作や復元動作に時間がかかるため効率が悪くその改善が望まれている。
【０００４】
【従来の技術】
図１２は従来のレジスタウィンドウのレジスタの構成例である。
レジスタウィンドウを用いたアーキテクチャでは，ウィンドウと呼ばれるレジスタグループのセットに分割されたレジスタファイルモデルを使っている。図１２に示す構成例により説明すると，一つのウィンドウは，それぞれ８個のレジスタを１グループとして，レジスタ番号ｒ０〜ｒ７のグローバルレジスタ（ＧＬＯＢＡＬＳ），レジスタ番号ｒ８〜ｒ１５のアウトレジスタ（ＯＵＴＳ），レジスタ番号ｒ１６〜ｒ２３のローカルレジスタ（ＬＯＣＡＬＳ），レジスタ番号ｒ２４〜ｒ３１のインレジスタ（ＩＮＳ）の合計４グループで構成され，各ウィンドウに対し共通の汎用レジスタでありグローバルレジスタを除いた３つのグループは一つのウィンドウのレジスタセットを構成する。
【０００５】
図１３は各レジスタグループの説明図である。図に示すように，グローバルレジスタ（ｇｌｏｂａｌ：ｒ０〜ｒ７に対応） はｇ０〜ｇ７で表す各レジスタで構成され，アウトレジスタ（ｏｕｔ ：ｒ８〜ｒ１５ に対応）はｏ０〜ｏ５，ｓｐ（スタックポインタ：ｏ６），ｏ７（ｔｅｍｐ）の各レジスタで構成され，ローカルレジスタ（ｌｏｃａｌ ：ｒ１６ 〜ｒ２３ に対応）はｌ０〜ｌ７の各レジスタで構成され，インレジスタ（ｉｎ：ｒ２４ 〜ｒ３１）はｉ０〜ｉ５，ＦＰ（フレームポインタ：ｉ６），ｉ７（ｒｅｔｕｒｎ） の各レジスタで構成されている。
【０００６】
このレジスタウィンドウ方式によれば，８個のウィンドウが設けられ，処理を行うウィンドウはカレントウィンドウ（ＣＷ）であり，プロセッサステータスレジスタ（ＰＳＲ）の中の５ビットであるカレントウィンドウポインタ（ＣＷＰ）を設定することにより選択される。一つのウィンドウに割り当てられたレジスタセットの中で，グローバルレジスタは各ウィンドウに対し共通の汎用レジスタであり，ローカルレジスタはそのウィンドウに固有であるが，他のアウトレジスタ及びインレジスタの一方は隣接する片方のウィンドウと共用（オーバラップで使用）される。各ウィンドウ内でレジスタｒ８〜ｒ３１の２４個のレジスタは，プログラムによりレジスタ番号を用いてアクセスすることができる。
【０００７】
すなわち，図１２に示すように，カレントウィンドウポインタ（ＣＷＰ）により指示される現在のウィンドウにおける処理において，プロシジャ呼び出し（関数呼ぶコール）が発生すると，セーブ命令が実行され，次のウィンドウ（Ｎｅｘｔ Ｗｉｎｄｏｗ）に移行し，カレントウィンドウポインタは（ＣＷＰ−１）となる。この時，元のカレントウィンドウポインタ（ＣＷＰ）のアウトレジスタは，次のウィンドウ（ＣＷＰ−１）のインレジスタとなり，呼び出し元から呼び出し先へ渡すパラメータが格納される。なお，グローバルレジスタの内容も同様に呼び出し先へ渡される。上記の呼び出し元のアウトレジスタが呼び出し先のインレジスタとなることを，レジスタのオーバラップと称され，これによりプロシジャ呼び出し時のパラメータの受け渡しを効率的に行うことができる。
【０００８】
逆に，呼び出されたプロシジャが呼出し元へリターンする場合，結果を呼び出し元へ返す準備ができると，それらの結果をインレジスタに移して，リターンが発生すると，リストア（Ｒｅｓｔｏｒｅ）命令が実行され， ＣＷＰが増大されＣＷＰ＋１となり，前のウィンドウ（Ｐｒｅｖｉｏｕｓ Ｗｉｎｄｏｗ）に戻り，呼び出されたプロシジャのレジスタウィンドウの中のインレジスタは，オーバラップにより呼び出し元のプロシジャではアウトレジスタとなり，ここからコールにより実行された結果を参照することができる。
【０００９】
呼び出し元のプロシジャがアウトレジスタとグローバルレジスタの許容量以上のパラメータを渡さなければならない時は，追加パラメータはメモリ上のスタックを使って渡される。スタックの位置を表すスタックポインタ（ＳＰ）は，カレントウィンドウ内のアトウレジスタ（図１３のレジスタｒ１４）に保持される。
【００１０】
このように，カレントウィンドウポインタを１オフセットずらすと，レジスタは１６（１６個のレジスタ分）だけアドレッシングされる。従って，レジスタグループの共用により，８つのウィンドウを使用する場合，１６×８＋８（グローバルレジスタ）＝１３６のレジスタを使用する。
【００１１】
図１４に８個のウィンドウを使用する場合のウィンドウのシフトの概念図を示す。レジスタウィンドウを８個使用する時，０〜７の番号の各ウィンドウを使用することが可能である。この中の一つのウィンドウがカレントウィンドウポインタ（ＣＷＰ）により指定され，動作中にプロシジャ呼び出し（ＣＡＬＬ）が発生すると，ＳＡＶＥが実行され上記図１４に示すように時計方向にシフトし，更に順番にＳＡＶＥ動作が行われる。このように多数のレジスタファイルが存在しても，レジスタファイルは概念的に円形ファイルであるため，スタックが回転して，先頭の古いウィンドウが上書きされる可能性があるが，これを防止するために，ウィンドウ無効（Ｉｎｖａｌｉｄ）マスク（ＷＩＭ）レジスタを設けている。
【００１２】
ウィンドウ管理は，カレントウィンドウポインタ（ＣＷＰ）が，ＷＩＭレジスタでマークした値になると，オーバフロートラップを発生する。その場合，少なくとも最も古いウィンドウをメモリ退避（セーブ）する。退避したウィンドウは次の呼び出しにより使用される。なお，８個のウィンドウの内１つのウィンドウ（ＷＩＭで設定したウィンドウ７）はトラップ操作部（トラップハンドラ）により常時使用できるように空けられている。こうしてプログラムからは無限にウィンドウがあるように見える。また，逆にリターンによるリストア命令の動作が実行され，図１４の各ウィンドウが反時計回りで順番に移行すると，ＷＩＭレジスタの値になった場合アンダーフローが発生し，この時はメモリに退避していたレジスタファイルをウィンドウに復元する。
【００１３】
次に，オーバフローやアンダーフローによるトラップだけでなく，マルチタスク（またはマルチプロセス）のリアルタイムＯＳであるため，タスクを切替える時には，現在のタスクで使用している全てのレジスタウィンドウ（１乃至多数の各場合がある）を退避して，切替え先のタスクにより各ウィンドウを使用する。切替え先のタスクから元のタスクに戻る場合には，退避された全てのレジスタウィンドウの内容を復元（ＲＥＳＴＯＲＥ）する必要がある。更に，割込みが発生した場合にも，タスク切替と同様に全てのレジスタウィンドウを退避して割込み処理を行い，割込み処理の終了により元の処理に復元する処理を行う必要がある。従来の方式では，レジスタウィンドウ内容の退避，復元処理に要する時間が問題になる。
【００１４】
図１５はシステムコールのソフトウェア構造である。
従来のシステムコールはアプリケーションがＯＳの機能を利用する手段として提供される。この場合，その実行に要する時間は可能な限り少ないことが要求される。基本ＯＳ上でプログラムが動作している状態でソフトウェアを階層分けすると，図１５に示すように，アプリケーション９０，ＵＯＳ９１（ユーザ側のプログラムとリンクされＯＳ本体側とのインタフェースをとるＯＳ），ＫＯＳ９２（ＯＳ本体側のモジュールであり，ユーザ側のＵＯＳ９１からのシステムコールのインタフェースをとるＯＳ），システムコール本体処理を行う本体９３（カーネルとも呼ばれる）の４層からなっている。
【００１５】
アプリケーション９０は，システムコールを利用するもので，タスクや割込みハンドラに相当し，ＵＯＳ９１はユーザＯＳインタフェースであり，アプリケーションとＫＯＳ９２の間にあり，異なったロードモジュールなので呼出し番地を知ることができないためにトラップで呼び出されるシステムコールを，アプリケーション９０から関数形式で実行できる手段を提供する。これは，アプリケーション９０にリンクしてその１部として利用される。ＫＯＳ９２は，ＯＳでのシステムコール受付処理を行い，システムコールの種類を判定して実際に処理を行う本体（またはカーネル）９３を呼び出す。本体９３は，システムコールの実際の処理を行う部分である。
【００１６】
図１６は従来のシステムコールの処理の流れを示し，上記図１５に示す構造により実行される。これによれば，アプリケーション９０でシステムコールＡが発生すると，ＵＯＳ９１のシステムコールＡ処理部が動作し，コンパイラによりＳＡＶＥ命令が実行され，最初の（１） でレジスタウィンドウを１段進め，（２） でパラメータを設定し，（３） でシステムコール番号を設定し，（４）でトラップ（システムコール）が発生する。これによりＫＯＳ９２のシステムコール受付部が動作し，（１） 〜（３） の処理が行われて， システムコールＡが呼び出され，本体９３のシステムコールＡ本体の処理が実行される。すなわち，（１） でレジスタウィンドウを１段進め，（２） でシステムコール処理を行い，（３）でリターンを行い，ＫＯＳ９２へ戻り，以下図１６に示すようにＫＯＳ９２，ＵＯＳ９１のそれぞれでリターンを行ってアプリケーション９０へ戻る。
【００１７】
この図１６に示すシステムコールの処理方法では，レジスタウィンドウという環状のレジスタにより，関数呼び出しのパラメータの受け渡しを効率的に行うことができ，関数呼出しに要する時間を少なくすることができるが，タスク切替時に保存，復元する処理が増えてしまい，タスク切替に要する時間が長くなる。また，ウィンドウオーバフローも起き易くなる。
【００１８】
次に上記の従来のレジスタウィンドウ方式では，割込みが発生した場合，その時の情報はカレントウィンドウのレジスタに格納されているが，その内容を保存したり，復帰する動作はソフトウェアにより処理していたが，割込みが繰り返されると，ソフトウェアへの負担が増大していた。
【００１９】
図１７は命令を書替えて走行する処理の従来例の説明図である。
図１７には，リアルタイムＯＳの処理システムにおいて，命令を書替えて走行する場合のユーザプログラムとＯＳの処理が示されている。
【００２０】
図１７において，ユーザプログラムが命令１，命令２である時に，ＯＳが命令２の退避と命令２をシステムコールＢに書替える処理を行う（この時，命令１は関係ない）。これにより命令２はシステムコールＢに書替えられているため，システムコールＢがＯＳにより実行され，終了後，退避されていた命令２が復元される。この処理の過程において，命令２をシステムコールＢに書き替えた後にシステムの障害等により，プログラムが正常に走行できない状態になると，元の命令を正常に実行できない可能性がある。
【００２１】
【発明が解決しようとする課題】
（１） リアルタイム処理装置においては，ＯＳ（オペレーティングシステム）の処理速度が重要であるが，上記したレジスタウィンドウ方式を使用したマイクロプロセッサ上で動作する従来のリアルタイムＯＳでは，関数呼び出しや復帰動作によりオーバフローやアンダーフローが発生するとメモリへの退避，復元の処理が頻繁に行われるため，オーバヘッドが増大して，実行処理速度を低下させるという問題があった。同様に，割り込み発生やタスク切替え時には，レジスタウィンドウの使用数は特別に制限せず，割込み発生時またはタスク切替時には単純に，使用中の全レジスタウィンドウをメモリに退避していた。このため，割込みやタスク切替による退避や復元の処理でオーバヘッドが増大していた。
【００２２】
（２） 従来のレジスタウィンドウ方式の割込みの処理では，割込み発生時の退避と復帰の処理が複雑な処理を要し，定期起動の割込み等によるレジスタウィンドウの使用により時間を要していた。
【００２３】
（３） 次に上記従来のシステムコール処理方式（図１５，図１６参照）によれば，システムコールにより，ＵＯＳにおいてレジスタウィンドウを新たに使用し，更に本体の処理でもレジスタウィンドウが１段進められる。その場合，ウィンドウ切替による保存・復元するウィンドウ数が増えて，タスク切替の処理時間が長くなり，オーバフローが起き易くなるという問題があった。
【００２４】
（４） また，従来の命令を書替えて走行するシステムの処理方法（図１７参照）では，命令を書替えた後のシステム障害等に対し元のプログラムへの復元ができない可能性があるという問題があった。
【００２５】
本発明は上記の従来の問題を解決するもので，交換機等のリアルタイム処理を必要とするシステムのレジスタウィンドウ方式を使用した処理装置において，レジスタウィンドウを効率良く使用して実行処理速度を向上することができるリアルタイム処理装置を提供することを目的とする。また，本発明は割込み発生時の復帰点や情報を退避したスタックの情報を効率的に管理することを目的とする。更に，アプリケーションからのシステムコール発生時の処理におけるレジスタウィンドウの切替数を削減して処理時間を短縮することを目的する。また，命令の書替え後に，前状態に戻す前に装置の異常等が発生しても命令を書替える必要性のある装置にプログラム復元を行うことができること等を目的とする。
【００２６】
【課題を解決するための手段】
図１は本発明の第１の原理説明図，図２は本発明の第２の原理説明図である。図１にはマイクロプロセッサ等のリアルタイム処理を行うレジスタウィンドウ方式の処理装置における，本発明によるレジスタウィンドウの制御方式の原理が示され，図１において，１は環状のレジスタウィンドウを表し，この例では＃０〜＃７の合計８個のウィンドウで構成され，各ウィンドウは従来例と同様にインレジスタ，ローカルレジスタ，アウトレジスタの３つのグループで構成され，各グループのウィンドウレジスタは８個のレジスタで構成され，一つのウィンドウに対し２４個のウィンドウレジスタが設けられ，インレジスタとアウトレジスタは，前，後のウィンドウに対しオーバラップする。また，グローバルレジスタは，全てのウィンドウにより共用される。
【００２７】
２ａはＯＳ側で使用するレジスタウィンドウの範囲，２ｂはアプリケーションプログラム（以下，単にアプリケーションという）側で使用するレジスタウィンドウの範囲を表し，３ａはＯＳ側の境界を越えたウィンドウ位置（番号）が設定された第１ウィンドウ無効マスク（第１ＷＩＭで表示），３ｂはアプリケーション側の境界を越えたウィンドウ位置（番号）が設定された第２ウィンドウ無効マスク（第２ＷＩＭで表示），４は現在のウィンドウ位置を表すカレントウィンドウポインタ（ＣＷＰで表示）である。
【００２８】
図２において，２０は割込み制御ブロック（ＩＣＢで表示：Ｉｎｔｅｒｒｕｐｔ Ｃｏｎｔｒｏｌ Ｂｌｏｃｋ）であり，２１〜２７の各領域により構成され，２１は次のＩＣＢの位置を表す次のＩＣＢへのポインタを表し，２２はプロセッサ割込みレベルの情報，２３はカレントウィンドウ（ＣＷ）のローカルレジスタの一部，２４はカレントウィンドウのインレジスタの一部，２５はカレントウィンドウのアウトレジスタの一部，２６は外部割込み番号，２７はシステムコール作業域である。
【００２９】
本発明の第１の原理は環状のレジスタウィンドウを，アプリケーションプログラムが使用するウィンドウの範囲を制限するか，オペレーティングシステム（ＯＳ）が使用するウィンドウの範囲を制限するものである。また，アプリケーションプログラムまたはＯＳで使用するウィンドウの個数を一定にしてその範囲を固定化せずに，可変にするものである。また，本発明の第２の原理は割込み発生時に，割込み処理を起動する前に割込み復帰点や，スタックに関する情報を割込み処理により破壊されないように管理ブロックのキューを設けて高速なリアルタイム処理を行うものである。
【００３０】
【作用】
図１において，最初にＯＳ側で使用するレジスタウィンドウとアプリケーションプログラムで使用するレジスタウィンドウの位置をそれぞれ固定して制限する場合について説明する。
【００３１】
ＯＳ側で使用するレジスタウィンドウを＃０〜＃３とし，アプリケーションプログラム側で使用するレジスタウィンドウの範囲は＃４〜＃７とする。そのため，第１ウィンドウ無効マスク３ａに“０”を設定し，第２ウィンドウ無効マスク３ｂに“４”を設定する。なお，現在処理を行っているウィンドウの番号（ポインタ）は，カレントウィンドウポインタ４により示される。
【００３２】
ＯＳ側のウィンドウは，ＯＳ内での処理により＃３から＃０へ順次，切替えられる。但し，＃０は常に割込み処理（トラップック処理）のために残すため，カレントウィンドウポインタ４の値が第１ウィンドウ無効マスク３ａに設定された値（０）になるとオーバフローとなり，逆に復帰（ＲＥＴＵＲＮ）命令により，カレントウィンドウポインタ４の番号が増大して第２ウィンドウ無効マスク３ｂに設定された値（４）と一致するとアンダーフロー割込みを発生する。
【００３３】
アプリケーションプログラム側のウィンドウ２ｂについても，ＯＳ側と同様に，ウィンドウ＃７〜＃４の中の＃７〜＃５の３つのウィンドウを通常の動作で使用し，呼び出し（ＣＡＬＬ）命令が順番に発生して＃７，＃６，＃５とウィンドウが切替えられ，＃４になるとオーバフローを生じ，逆に復帰（ＲＥＴＵＲＮ）命令が実行され，カレントウィンドウポインタ４の番号が増加して第１ウィンドウ無効マスク３ａの値（＝０）と一致するとアンダーフロー割込みを発生する。
【００３４】
このような構成により，アプリケーション側では最大３つのウィンドウレジスタを使用（それ以上は，メモリに退避）することにより，オーバフロー発生時に退避するウィンドウ数を制限でき，ＯＳ側は常に一定数のウィンドウを確保することができる。
【００３５】
次に，ＯＳ側で使用するレジスタウィンドウとアプリケーション側で使用するレジスタウィンドウの個数を一定とするが，その範囲を可変にする場合について説明する。すなわち，最初に，第１ウィンドウ無効マスク３ａ，第２ウィンドウ無効マスク３ｂに対し，上記の固定の場合と同様にそれぞれ数値“０”，“４”を設定する。この後，ＯＳ側でオーバフローが発生した場合には，第１及び第２のウィンドウ無効マスク３ａ，３ｂを１つづつずらして設定する。すなわち，１つづれると，第１，第２のウィンドウ無効マスク３ａ，３ｂを“７”，“３”に設定する。
【００３６】
更に，ＯＳ側で使用するレジスタウィンドウとアプリケーション側で使用するレジスタウィンドウの中で，一方だけを制限して，他方は制限を加えないようにすることができる。ＯＳ側で使用するウィンドウに制限を加えない場合について説明する。この場合，アプリケーション側のウィンドウ数を３個として，第２ウィンドウ無効マスク３ｂに“４”を設定し，ＯＳ側のウィンドウを＃３から使用を開始して，３つの関数を呼び出し（ＣＡＬＬ）すると，オーバフロー（＃０に達する）が発生する。この時，アプリケーションの１つのウィンドウ（＃７）または，使用している全ウィンドウ（＃７から＃５までの範囲）をメモリ上のスタックへ退避する。このようにして，ＯＳ側のウィンドウ数に対しては制限を加えないようにする。同様の原理により，ＯＳ側のウィンドウ数を制限してアプリケーション側のウィンドウ数に制限を加えないようにすることができる。
【００３７】
次に図２の構成において，図示されない割込み管理部で割込み動作が開始すると，発生した割込み毎に，割込み制御ブロック（ＩＣＢ）２０のポインタを得て，新たな割込み制御ブロックを得てそれをＩＣＢキューに登録し，実行中の割込みを管理する。割込みがネストした時には，新しい割込みのＩＣＢを先頭に追加し，以前の割込みのＩＣＢはその後に接続される。
【００３８】
【実施例】
図３は本発明が実施される処理装置のブロック構成図である。
図３において，３０はレジスタウィンドウ制御によりリアルタイム処理を行う交換機等の処理装置（ＣＰＵ及びメモリ），３１はオペレーティングシステム部（ＯＳ部），３２はアプリケーション（ユーザ）プログラムを実行するアプリケーション部，３３はカレントウィンドウポインタ（ＣＷＰ）３３ａ，第１ウィンドウ無効マスク（ＷＩＭ）３３ｂ，第２ウィンドウ無効マスク３３ｃを格納する各レジスタ，３４は８個のウィンドウを構成するためのレジスタ群，３５はＩＣＢ（割込み制御ブロック），３６はメモリでありオーバフロー，アンダーフロー，割込み動作等によりレジスタウィンドウの内容やパラメータが退避されるスタックを備えるメモリである。
【００３９】
この構成において，ＯＳ側の処理において使用するウィンドウを上記図１に示すように，ＯＳ部とアプリケーション部により使用するウィンドウの領域を固定（第１ＷＩＭ及び第２ＷＩＭを固定）する場合の動作を説明する。この場合，ＯＳ側で使用するウィンドウのオーバフローを生じさせる第１ＷＩＭ３３ｂ（図３）に「０」，アプリケーション側で使用するウィンドウのオーバフローを生じさせる第２ＷＩＭ３３ｃ（図３）に「４」を設定する。
【００４０】
この場合，ＯＳ側の処理においてウィンドウを３，２，１と使用して，ウィンドウが０になると第１ＷＩＭ３３ｂの設定値と一致してオーバフロートラップが発生し，アプリケーション（ユーザ）側の処理において，ウィンドウを７，６，５と使用してウィンドウが第２ＷＩＭ３３ｃと一致してオーバフロートラップが発生する。
【００４１】
図４は範囲固定時のオーバフロー発生の処理フローを示す図である。
使用ウィンドウの２つの範囲を固定した時にオーバフローが発生すると，走行プログラムがＯＳ側かアプリケーション側かを判別し（図４のＳ１），ＯＳのプログラムである場合はウィンドウ３，２，１をメモリのスタック３６（図３）に保存して（図４のＳ２），ＣＷＰ３３ａ（図３）を「３」に戻し（図４のＳ３），元の処理に復帰する。また，アプリケーション（ユーザ）プログラムである場合は，ウィンドウ７，６，５を保存し（図４のＳ４），ＣＷＰ３３ａを「７」に戻して（同Ｓ５），元のアプリケーションに復帰する。
【００４２】
次にアンダーフローの場合は，処理フローは図示省略されているが基本的には図４に示すフローの逆となる。すなわち，アプリケーションプログラムの例で説明すると，アプリケーションプログラムが５，６，７と逆行（ＲＥＴＵＲＮ）して第２ＷＩＭ３３ｃの数値（０）と一致してアンダーフローが発生すると，ウィンドウ７，６，５をメモリのスタックから復元し，ＣＷＰ３３ａを「５」に戻す処理を行う。ＯＳ側の場合にも同様の処理によりウィンドウ３，２，１をメモリのスタックから復元し，ＣＷＰ３３ａを「１」に戻す。
【００４３】
次にＯＳ側の処理で使用するウィンドウの個数と，アプリケーション側の処理で使用するウィンドウの個数を一定とするが，使用するウィンドウの範囲を可変としてシフトする場合（第１ＷＩＭ及び第２ＷＩＭを固定しない場合）について説明する。
【００４４】
この場合も最初は上記図１と同様に，ＯＳ側で使用するウィンドウのオーバフローを生じさせる第１ＷＩＭ３３ｂに「０」，アプリケーション側で使用するウィンドウのオーバフローを生じさせる第２ＷＩＭ３３ｃに「４」を設定する。
【００４５】
この状態でＯＳ側の処理においてウィンドウを３，２，１と使用して，ウィンドウが０になると第１ＷＩＭ３３ｂの設定値と一致してオーバフロートラップが発生し，アプリケーション（ユーザ）側の処理において，ウィンドウを７，６，５と使用してウィンドウが第２ＷＩＭ３３ｃと一致してオーバフロートラップが発生する。
【００４６】
図５は範囲可変時のオーバフロー発生の処理フローを示す図である。
ＯＳ側とアプリケーション側のそれぞれで使用するウィンドウの範囲を可変にしてシフトする場合にオーバフローが発生すると，走行プログラムがＯＳ側かアプリケーション側かを判別し（図５のＳ１），ＯＳのプログラムである場合はウィンドウ３をメモリに保存し（同Ｓ２），第２ＷＩＭの内容を「３」に設定し（同Ｓ３），ウィンドウ７〜５のうち，使用しているものを１つづつずらす（同Ｓ４）。ウィンドウ７〜５を全て使用していた場合，ウィンドウ７を６，ウィンドウ６を５，ウィンドウ５を４へそれぞれ内容を移す。続いて，第１ＷＩＭの内容を「７」に設定する（同Ｓ５）。これにより，ＯＳのプログラムで使用可能なウィンドウが６〜４の範囲にシフトする。上記Ｓ１において，アプリケーションプログラムであることが判別されると，ウィンドウ７を保存し（図５のＳ６），第１ＷＩＭ３３ｂを「７」にする（同Ｓ７）。次にウィンドウ３〜１のうち，使用しているものを１つづつずらし（同Ｓ８），第２ＷＩＭを「３」に変更し（同Ｓ９），元のアプリケーションプログラムへ戻る。
【００４７】
上記の，実施例ではアプリケーション側及びＯＳ側の両方のウィンドウ数を一定に制限しているが，これらの一方のウィンドウ数だけを制限して，他方に制限を設けないように構成することができる。その場合，制限されない方が走行している時に，ＷＩＭの値と一致してウィンドウオーバフローになると，相手のウィンドウ内容をメモリに退避し，ＷＩＭの数を順次移動させていき，最終的に全ウィンドウを使用可能にする。この他に，制限されない方に切り替わった時点で，制限する方が使用していたウィンドウを全てセーブする方式がある。
【００４８】
次に本発明による割込み管理を説明する。
図６は割込み制御ブロック（ＩＣＢで表示）の構成図であり，上記図２に対応する。この割込み制御ブロック（ＩＣＢ）は，割込み処理を行う割込みハンドラを起動する前に，カレントウィンドウに設定されている割込み復帰点やスタックに関する情報をハンドラが破壊しないように保存するためにメモリに設けられる。また，割込みハンドラで関数呼び出しの階層が深い位置で割込みハンドラ終了（ＥＸＴ−ＩＮＨ：Ｅｘｉｔ ＩＮｔａｒｒｕｐｔ Ｈａｎｄｌｅｒ，割込みハンドラの最後に置かれるシステムコール）を実行した時にも割込み点に関する情報を容易に得られるようにするために，割込み管理ブロックＩＣＢが用意される。
【００４９】
図６において，２１，２２，２４〜２６は，それぞれ上記図２の同じ符号に対応し，図６の２３ａ，２３ｂは図２の２３に対応し，図６の２７ａ〜２７ｃは図２の２７に対応し，それぞれ４バイトが格納される。すなわち，２１は割込み処理中に次の割込みが発生した時に設けられた次のＩＣＢへのポインタが格納され，割込みがネスト（割込み動作中に更に割込みが発生した時）した時にキュー構成でＩＣＢが順次設けられ，キュー最後の場合はこのポインタにＮＵＬＬが設定される。２２は割込み起動制御の先頭でのＰＳＲ（プログラムステータスレジスタ）を保存し，実際に必要なのはＰＩＬ（プロセッサ割込みレベル）である。
【００５０】
次に図６の２３ａは，割込み起動制御の先頭でのカレントウィンドウのローカル１レジスタ（旧ＰＣ：元のプログラムカウンタ）の内容，２３ｂは割込み起動制御の先頭でのカレントウィンドウのローカル２レジスタ（旧ｎＰＣ：ｎ のプログラムカウンタ）の内容，２４は割込み起動制御の先頭でのカレントウィンドウのイン６レジスタ（フレームポインタ）の内容，２５は割込み起動制御の先頭でのカレントウィンドウのアウト６レジスタ（スタッフポインタ）の内容，２６は発生した外部割込み番号，２７ａ〜２７ｃはシステムコール実行時に使用する作業域で，それぞれイン７レジスタ（リターンアドレス），スタックポインタ（ｓｐまたはＳＰ），フレームポインタ（ｆｐまたはＦＰ）が保存される。
【００５１】
次に上記図６に示す割込み制御ブロック（ＩＣＢ）を用いた割込み処理を説明する。図７は一般の割込み処理のフロー，図８は基本クロック割込み（または一定数以上のウィンドウを使っていない場合の割込み）処理のフローを示す。図７，図８のＡ．は割込みの処理，Ｂ．は割込みハンドラ終了（ＥＸＴ−ＩＮＨ）の処理である。
【００５２】
図７，図８のＡ．において，割込み処理がスタートすると，外部割込み番号を得て（各図のＳ１），ＩＣＢを確保して，ＩＣＢキューの先頭に入れる（同Ｓ２）。更に，カレントウィンドウのレジスタｒ１７，ｒ１８，ｒ３０（ｆｐ），ｒ１４（ｓｐ）をＩＣＢに保存し（同Ｓ３），ＰＳＲ（プログラムステータスレジスタ）をＩＣＢに設定する（同Ｓ４）。続いてＩＣＢキューに確保したＩＣＢを設定する（同Ｓ５）。この後，ソフトマスクがかかっていないか判別し（同Ｓ６），割込みのソフトマスクがかかっていると処理を終了するが，かかっていない場合（ｙｅｓの場合），図７と図８で処理が異なる。
【００５３】
一般の割込みの処理の図７の場合，使用中のレジスタウィンドウをスタックへ保存し（図７のＳ７），次に割込みのネスト（割込み処理中の新たな割込み）か判別し（同Ｓ８），ネストでない場合は割込み用スタックに切替える（同Ｓ９）。また割込みのネストである場合は，ハンドラを起動する（同Ｓ１０）。
【００５４】
図８の場合，一定周期で頻繁に発生する基本クロック割込みであるか，一定数以上のウィンドウを使ってないかを判別し（図８のＳ７），該当しない場合は使用中のレジスタウィンドウをスタックへ保存し（同Ｓ８）。基本クロック割込みであるか一定数以上のウィンドウを使っていない場合，次に割込みネストであるか判別する（図８のＳ９）。割込みのネストでない場合，割込み用スタックに切り替え（同Ｓ１０），割込みのネストである場合はハンドラを起動する（同Ｓ１１）。
【００５５】
このようにして，一定周期で頻繁に発生する基本クロック割込み等に対しては，レジスタウィンドウを保存することなく，ユーザ定義のハンドラにより処理を行うことができる。
【００５６】
図７，図８のＢ．に示す割込みハンドラ終了（ＥＸＴ−ＩＮＨ）の処理は，同じ内容であり，カレントＩＣＢから上記の図７，図８のＡ．の処理で保存したカレントウィンドウのレジスタｒ１７，ｒ１８，ｒ３０，ｒ３１，ｓｐを復元する（各図のＳ１）。次にカレントＩＣＢを開放し（同Ｓ２），待ちＩＣＢキューの先頭をはずして，カレントＩＣＢへ入れて（同Ｓ３），リターンを行う（同Ｓ４）。
【００５７】
図９は本発明によるシステムコール処理の流れ図である。この処理は，上記従来のシステムコール処理（上記図１６参照）において使用するレジスタウィンドウの数が多いことにより処理時間が長くなるという問題を解決するものである。
【００５８】
図９において，６０〜６３は上記図１５，図１６（従来例）の９０〜９３に対応し，６０はアプリケーション，６１はＵＯＳ，６２はＫＯＳ，６３はシステムコール本体処理を行う本体（カーネルとも呼ばれる）であり，６０ａ，６１ａ，６２ａ，６２ｂ，６３ａは６０〜６３の処理に対応するレジスタウィンドウの使用状態を表す。なお，図９のＵＯＳ６１，ＫＯＳ６２は，上記図２では図示省略されている。
【００５９】
ａ．アプリケーション６０は，通常の関数を呼ぶのと同じ方法で，カレントウィンドウのアウトレジスタ（図１２参照）へパラメータを設定してシステムコール（図９ではシステムコールＡで示す）を呼ぶ。図９の例では，この時のアプリケーション６０の動作時に，レジスタウィンドウの番号は６０ａに示すように「２」である。
【００６０】
ｂ．ＵＯＳ６１でのウィンドウ使用数の削減方法
ＵＯＳ６１でのウィンドウ使用数を削減するため，ＵＯＳ６１で新しいウィンドウを使用しないようにする。この場合，ＵＯＳ６１はアプリケーションとＯＳとのインタフェースをとることであり，具体的にはＫＯＳ６２を呼び出すトラップを発生させる。そのため，ここではアプリケーション６０からのパラメータをＫＯＳ６２が参照できるようにカレントウィンドウのアウトレジスタ（図１２のｒ８〜ｒ１５）に設定する。アプリケーション６０はＵＯＳ６１を呼び出す時にパラメータをアウトレジスタに設定しているので，ウィンドウを回転させないことでカレントウィンドウのアウトレジスタにパラメータが格納されたままになり，ＫＯＳ６２ではカレントウィンドウのインレジスタ（図１２のｒ２４〜ｒ３１）でパラメータを参照できる。
【００６１】
具体的には，ＵＯＳ６１はシステムコール毎の命令が集合して出来ており，それらの関数では最初にシステムコール毎に割り当てられているシステムコール番号をグローバルレジスタ（図１２のｒ０〜ｒ７）へ設定する（図９のＵＯＳ６１の（１） 参照） 。グローバルレジスタには，カレントウィンドウが変化しても同じレジスタを参照できるので，ＫＯＳ６２で同じ値を得ることができる。次に別のＬＭ（ロードモジュール）であるＫＯＳ６２へ実行を移すためにトラップを発生させる（図９のＵＯＳ６１の（２） 参照） 。
【００６２】
これにより，ウィンドウを回転させた時に行わなければならなかったインレジスタからアウトレジスタへパラメータをコピーする必要がなくなり，ＵＯＳの処理自体も少なく済むようになる。また，本発明ではＫＯＳ６２からＵＯＳ６１に戻り，アプリケーション６０へ戻る手順ではなく，ＫＯＳ６２から直接アプリケーションに戻るようにする。
ｃ．ＫＯＳ６２でのウィンドウ使用数の削減方法
本発明ではＫＯＳ６２で使用するウィンドウを一時的に使用しないようにしてから，ＯＳ本体６３（図９の例では含まれないパラメータチェック部を備える場合は，パラメータチェック部）を呼び出すことで見かけ上のウィンドウ使用数を削減する。
【００６３】
具体的には，このＫＯＳ６２では，全てのシステムコールに共通な処理を行っており，最初にカレントウィンドウのｓｐ（スタックポインタ），ｆｐ（フレームポインタ），インレジスタｉ［７］の各レジスタをＫＯＳ６２に設けられたＴＣＢ（タスク・コントロール・ブロック）に保存する。次にＵＯＳ６１で設定したグローバルレジスタからシステムコール番号を得て（図９のＫＯＳ６２の（１） ），これをインデックスにしてシステムコール本来の機能を実現する関数のテーブル（以下，関数テーブルという）から，関数のアドレスを得る。次に，レジスタウィンドウを一段戻す（図９のＫＯＳ６２の（２） ）。
【００６４】
これにより，ＣＷＰ（カレントウィンドウポインタ）は＋１され，図９の例では，レジスタウィンドウ番号が「１」の状態６２ａからレジスタウィンドウ番号が「２」の状態６２ｂとなる。この後，得られたアドレスの関数をコールする（図９のＫＯＳ６２の（３） ）。
【００６５】
ｄ．ＯＳ本体６３
レジスタウィンドウを一段進める（ＣＷＰ−１）。図９の例では，ＯＳ本体６３の（１） の処理に対応し，レジスタウィンドウの番号「２」の状態６２ｂから「１」の状態６３ａになる。次に関数（システムコール本来の処理）の実行を終了すると，ＫＯＳ６２へ復帰（リターン）する。このリターン時に，レジスタウィンドウ番号が１つ戻されて，状態６２ｂとなる。
【００６６】
ＯＳ本体６３からのリターン動作により，ＫＯＳ６２では，上記のＴＣＢに保存しておいた，ｓｐ，ｆｐを復元する。さらに，ＴＣＢに保存したインレジスタのｉ［７］をカレントウィンドウのローカルレジスタに設定する。詳細にはｉ［７］をｌ［１］に，ｉ［７］＋４をｌ［２］に設定する。最後にＫＯＳ６２の復帰（リターン）命令により，ＫＯＳ６２の処理を終わる（図９のＫＯＳ６２の（４） ）。このリターン命令により，ＵＯＳ６１を経由せずに直接アプリケーション６０に戻る。
【００６７】
このようにして，従来のシステムコール発行時の処理（上記図２０参照）に比べて，使用するレジスタウィンドウの数を少なくなるため処理速度が向上する。次に，割込みの発生によりウィンドウ使用数が増大することによる処理速度が遅くなる。このような割込みが使用ウィンドウ数が多い場合には特に影響が大きくなる。これを改善する本発明の方法を図１０により説明する。
【００６８】
図１０は割込み処理の制御を行う処理フローである。
図１０のＡ．に示す割込み処理では，割込みが発生すると（図１０のＡ．のＳ１），現在使用中のウィンドウ数を調べて，これが一定数以上か否かによりその割込み処理を保留可か否かの判定をする（同Ｓ２）。もし，ウィンドウ数が一定数に達していない場合は，通常の割込み処理を行うが，ウィンドウ数が一定以上の場合は，保留中フラグをセットする（同Ｓ３）。続いて，ウィンドウ無効マスク（ＷＩＭ）をセットし（同Ｓ４），割込み処理を実行することなくリターンする。この場合，ＷＩＭとしては，使用ウィンドウ数が上記Ｓ２の保留可の判別を行う基準となる一定数以下の数に設定し（例えば，使用数「３」に設定し），その数になったらアンダーフローを発生させるためにセットされる。
【００６９】
その後，使用中のウィンドウ数が一定以下になるとアンダーフローが発生すると，アンダーフロー処理を開始する（図１０のＢ．のＳ１）。この場合，保留中フラグがセットされているか否か判定し（同Ｓ２），セットされていない場合は通常処理を行い，セットされている場合は，ウィンドウ無効マスク（ＷＩＭ）をリカバリーする（同Ｓ３）。このリカバリーは，上記図１０のＡ．のＳ２でセットする前状態に戻すことである。次に割込みハンドラを起動し（図１０のＢ．のＳ４），割込み処理を行ってリターンする。
【００７０】
このようにして，割込み処理に対し制限を加えて処理速度を向上することができる。
図１１は命令書替えを行う場合のプログラム復元を保証する処理フローである。この処理フローは，従来の命令を書替えて走行するシステムにおける処理（上記図１７参照）の問題を解決するものである。
【００７１】
命令を書替えて走行するようなシステムでは，例えば，システムコールの戻り値がエラーの場合にユーザプログラムを通常の後続の命令ではなく，終了処理ルーチン等の例外処理を実行させたい場合に，ＯＳにより命令の書替えを行う。
【００７２】
この場合，図１１のＡ．に示すようにＯＳは，命令２の１つ前の命令１と，命令２を図１１のＢ．に示す退避エリアに退避する（図１１のＡ．のＳ１）。この時，退避エリアには，「命令１」，「命令２」に続いて，「命令２の次命令へジャンプ」も格納される。次に，ユーザプログラムの命令１を「退避エリアジャンプ」の内容に書替え，更に命令２を「システムコールＢ」に書替える（図１１のＡ．のＳ２）。この後，ＯＳからの復帰によりユーザプログラムの命令２が実行されると，システムコールＢが実行され，その復帰命令は復元される。
【００７３】
このように，書替えを行うことにより，例えば，命令２をシステムコールＢに書替えた後にシステムの障害等により，システム再開等が発生してしまった場合でも，退避エリアに格納されている通常ルートが走行可能となり，レジスタウィンドウ方式によるリアルタイムＯＳの処理において，命令を書替えて走行する場合，プログラム復元の信頼性を高めることができる。
【００７４】
【発明の効果】
本発明によれば，以下に述べるような効果を奏することができる。
▲１▼レジスタウィンドウ方式のリアルタイムＯＳにおいて，レジスタウィンドウを効率良く使用して実行処理速度を向上することができる。
【００７５】
▲２▼割込み発生時の復帰点や情報を退避したスタックの情報を効率的に管理することが可能となる。
▲３▼システムコール発生時の処理におけるレジスタウィンドウの切替数を削減して処理時間を短縮することが可能となる。
【００７６】
▲４▼命令を書替えて実行するシステムにおいて，命令の書替え後に，前状態に戻す前に装置の異常等が発生しても命令を復元することを可能とし，信頼性を向上することができる。
【図面の簡単な説明】
【図１】本発明の第１の原理説明図である。
【図２】本発明の第２の原理説明図である。
【図３】本発明が実施される処理装置のブロック構成図である。
【図４】範囲固定時のオーバフロー発生の処理フローを示す図である。
【図５】範囲可変時のオーバフロー発生の処理フローを示す図である。
【図６】割込み制御ブロック（ＩＣＢ）の構成図である。
【図７】一般の割込み処理のフローを示す図である。
【図８】基本クロック割込み処理のフローを示す図である。
【図９】本発明によるシステムコール処理の流れ図である。
【図１０】割込み処理の制御を行う処理フローを示す図である。
【図１１】命令書替えを行う場合のプログラム復元を保証する処理フローを示す図である。
【図１２】従来のレジスタウィンドウのレジスタの構成例を示す図である。
【図１３】各レジスタグループの説明図である。
【図１４】８個のウィンドウを使用する場合のウィンドウのシフトの概念図である。
【図１５】システムコールのソフトウェア構造を示す図である。
【図１６】従来のシステムコールの処理の流れを示す図である。
【図１７】命令を書替えて走行する処理の従来例の説明図である。
【符号の説明】
１ 環状の８個のレジスタウィンドウ（＃０〜＃７）
２ａ ＯＳ側で使用するレジスタウィンドウの範囲
２ｂ アプリケーション側で使用するレジスタウィンドウの範囲
３ａ 第１ウィンドウ無効マスク（第１ＷＩＭ）
３ｂ 第２ウィンドウ無効マスク（第２ＷＩＭ）
４ カレントウィンドウポインタ（ＣＷＰ）
【産業上の利用分野】
本発明はレジスタウィンドを備えたマイクロプロセッサにおけるリアルタイムＯＳの処理方法である。
【０００２】
近年，多数のレジスタを一定数のグループに分割して，一つのウィンドウにおいて所定数のレジスタを使用し，ウィンドウを切替えると，前のウィンドウで使用した一部のレジスタを次のウィンドウのレジスタの一部として使用（オーバラップという）するレジスタウィンドウ方式が知られている。このレジスタウィンドウ方式では，一つのタスクによる動作中に関数の呼び出しによりウィンドウが順次切替えられ，復帰動作により逆方向に切替えられて一定個数のウィンドウを越えると，オーバフローやアンダーフローが生じて，それぞれ退避や復元の処理が行われる。またタスクが切替えられたり，割り込みが発生すると，全てのウィンドウレジスタを退避（保存）して新たなタスクまたは割り込み先のウィンドウレジスタとして使用可能にする。
【０００３】
このようなレジスタウィンドウを備えたマイクロプロセッサを，交換機等のリアルタイム処理を必要とするシステムにおいて利用することができるが，レジスタの退避動作や復元動作に時間がかかるため効率が悪くその改善が望まれている。
【０００４】
【従来の技術】
図１２は従来のレジスタウィンドウのレジスタの構成例である。
レジスタウィンドウを用いたアーキテクチャでは，ウィンドウと呼ばれるレジスタグループのセットに分割されたレジスタファイルモデルを使っている。図１２に示す構成例により説明すると，一つのウィンドウは，それぞれ８個のレジスタを１グループとして，レジスタ番号ｒ０〜ｒ７のグローバルレジスタ（ＧＬＯＢＡＬＳ），レジスタ番号ｒ８〜ｒ１５のアウトレジスタ（ＯＵＴＳ），レジスタ番号ｒ１６〜ｒ２３のローカルレジスタ（ＬＯＣＡＬＳ），レジスタ番号ｒ２４〜ｒ３１のインレジスタ（ＩＮＳ）の合計４グループで構成され，各ウィンドウに対し共通の汎用レジスタでありグローバルレジスタを除いた３つのグループは一つのウィンドウのレジスタセットを構成する。
【０００５】
図１３は各レジスタグループの説明図である。図に示すように，グローバルレジスタ（ｇｌｏｂａｌ：ｒ０〜ｒ７に対応） はｇ０〜ｇ７で表す各レジスタで構成され，アウトレジスタ（ｏｕｔ ：ｒ８〜ｒ１５ に対応）はｏ０〜ｏ５，ｓｐ（スタックポインタ：ｏ６），ｏ７（ｔｅｍｐ）の各レジスタで構成され，ローカルレジスタ（ｌｏｃａｌ ：ｒ１６ 〜ｒ２３ に対応）はｌ０〜ｌ７の各レジスタで構成され，インレジスタ（ｉｎ：ｒ２４ 〜ｒ３１）はｉ０〜ｉ５，ＦＰ（フレームポインタ：ｉ６），ｉ７（ｒｅｔｕｒｎ） の各レジスタで構成されている。
【０００６】
このレジスタウィンドウ方式によれば，８個のウィンドウが設けられ，処理を行うウィンドウはカレントウィンドウ（ＣＷ）であり，プロセッサステータスレジスタ（ＰＳＲ）の中の５ビットであるカレントウィンドウポインタ（ＣＷＰ）を設定することにより選択される。一つのウィンドウに割り当てられたレジスタセットの中で，グローバルレジスタは各ウィンドウに対し共通の汎用レジスタであり，ローカルレジスタはそのウィンドウに固有であるが，他のアウトレジスタ及びインレジスタの一方は隣接する片方のウィンドウと共用（オーバラップで使用）される。各ウィンドウ内でレジスタｒ８〜ｒ３１の２４個のレジスタは，プログラムによりレジスタ番号を用いてアクセスすることができる。
【０００７】
すなわち，図１２に示すように，カレントウィンドウポインタ（ＣＷＰ）により指示される現在のウィンドウにおける処理において，プロシジャ呼び出し（関数呼ぶコール）が発生すると，セーブ命令が実行され，次のウィンドウ（Ｎｅｘｔ Ｗｉｎｄｏｗ）に移行し，カレントウィンドウポインタは（ＣＷＰ−１）となる。この時，元のカレントウィンドウポインタ（ＣＷＰ）のアウトレジスタは，次のウィンドウ（ＣＷＰ−１）のインレジスタとなり，呼び出し元から呼び出し先へ渡すパラメータが格納される。なお，グローバルレジスタの内容も同様に呼び出し先へ渡される。上記の呼び出し元のアウトレジスタが呼び出し先のインレジスタとなることを，レジスタのオーバラップと称され，これによりプロシジャ呼び出し時のパラメータの受け渡しを効率的に行うことができる。
【０００８】
逆に，呼び出されたプロシジャが呼出し元へリターンする場合，結果を呼び出し元へ返す準備ができると，それらの結果をインレジスタに移して，リターンが発生すると，リストア（Ｒｅｓｔｏｒｅ）命令が実行され， ＣＷＰが増大されＣＷＰ＋１となり，前のウィンドウ（Ｐｒｅｖｉｏｕｓ Ｗｉｎｄｏｗ）に戻り，呼び出されたプロシジャのレジスタウィンドウの中のインレジスタは，オーバラップにより呼び出し元のプロシジャではアウトレジスタとなり，ここからコールにより実行された結果を参照することができる。
【０００９】
呼び出し元のプロシジャがアウトレジスタとグローバルレジスタの許容量以上のパラメータを渡さなければならない時は，追加パラメータはメモリ上のスタックを使って渡される。スタックの位置を表すスタックポインタ（ＳＰ）は，カレントウィンドウ内のアトウレジスタ（図１３のレジスタｒ１４）に保持される。
【００１０】
このように，カレントウィンドウポインタを１オフセットずらすと，レジスタは１６（１６個のレジスタ分）だけアドレッシングされる。従って，レジスタグループの共用により，８つのウィンドウを使用する場合，１６×８＋８（グローバルレジスタ）＝１３６のレジスタを使用する。
【００１１】
図１４に８個のウィンドウを使用する場合のウィンドウのシフトの概念図を示す。レジスタウィンドウを８個使用する時，０〜７の番号の各ウィンドウを使用することが可能である。この中の一つのウィンドウがカレントウィンドウポインタ（ＣＷＰ）により指定され，動作中にプロシジャ呼び出し（ＣＡＬＬ）が発生すると，ＳＡＶＥが実行され上記図１４に示すように時計方向にシフトし，更に順番にＳＡＶＥ動作が行われる。このように多数のレジスタファイルが存在しても，レジスタファイルは概念的に円形ファイルであるため，スタックが回転して，先頭の古いウィンドウが上書きされる可能性があるが，これを防止するために，ウィンドウ無効（Ｉｎｖａｌｉｄ）マスク（ＷＩＭ）レジスタを設けている。
【００１２】
ウィンドウ管理は，カレントウィンドウポインタ（ＣＷＰ）が，ＷＩＭレジスタでマークした値になると，オーバフロートラップを発生する。その場合，少なくとも最も古いウィンドウをメモリ退避（セーブ）する。退避したウィンドウは次の呼び出しにより使用される。なお，８個のウィンドウの内１つのウィンドウ（ＷＩＭで設定したウィンドウ７）はトラップ操作部（トラップハンドラ）により常時使用できるように空けられている。こうしてプログラムからは無限にウィンドウがあるように見える。また，逆にリターンによるリストア命令の動作が実行され，図１４の各ウィンドウが反時計回りで順番に移行すると，ＷＩＭレジスタの値になった場合アンダーフローが発生し，この時はメモリに退避していたレジスタファイルをウィンドウに復元する。
【００１３】
次に，オーバフローやアンダーフローによるトラップだけでなく，マルチタスク（またはマルチプロセス）のリアルタイムＯＳであるため，タスクを切替える時には，現在のタスクで使用している全てのレジスタウィンドウ（１乃至多数の各場合がある）を退避して，切替え先のタスクにより各ウィンドウを使用する。切替え先のタスクから元のタスクに戻る場合には，退避された全てのレジスタウィンドウの内容を復元（ＲＥＳＴＯＲＥ）する必要がある。更に，割込みが発生した場合にも，タスク切替と同様に全てのレジスタウィンドウを退避して割込み処理を行い，割込み処理の終了により元の処理に復元する処理を行う必要がある。従来の方式では，レジスタウィンドウ内容の退避，復元処理に要する時間が問題になる。
【００１４】
図１５はシステムコールのソフトウェア構造である。
従来のシステムコールはアプリケーションがＯＳの機能を利用する手段として提供される。この場合，その実行に要する時間は可能な限り少ないことが要求される。基本ＯＳ上でプログラムが動作している状態でソフトウェアを階層分けすると，図１５に示すように，アプリケーション９０，ＵＯＳ９１（ユーザ側のプログラムとリンクされＯＳ本体側とのインタフェースをとるＯＳ），ＫＯＳ９２（ＯＳ本体側のモジュールであり，ユーザ側のＵＯＳ９１からのシステムコールのインタフェースをとるＯＳ），システムコール本体処理を行う本体９３（カーネルとも呼ばれる）の４層からなっている。
【００１５】
アプリケーション９０は，システムコールを利用するもので，タスクや割込みハンドラに相当し，ＵＯＳ９１はユーザＯＳインタフェースであり，アプリケーションとＫＯＳ９２の間にあり，異なったロードモジュールなので呼出し番地を知ることができないためにトラップで呼び出されるシステムコールを，アプリケーション９０から関数形式で実行できる手段を提供する。これは，アプリケーション９０にリンクしてその１部として利用される。ＫＯＳ９２は，ＯＳでのシステムコール受付処理を行い，システムコールの種類を判定して実際に処理を行う本体（またはカーネル）９３を呼び出す。本体９３は，システムコールの実際の処理を行う部分である。
【００１６】
図１６は従来のシステムコールの処理の流れを示し，上記図１５に示す構造により実行される。これによれば，アプリケーション９０でシステムコールＡが発生すると，ＵＯＳ９１のシステムコールＡ処理部が動作し，コンパイラによりＳＡＶＥ命令が実行され，最初の（１） でレジスタウィンドウを１段進め，（２） でパラメータを設定し，（３） でシステムコール番号を設定し，（４）でトラップ（システムコール）が発生する。これによりＫＯＳ９２のシステムコール受付部が動作し，（１） 〜（３） の処理が行われて， システムコールＡが呼び出され，本体９３のシステムコールＡ本体の処理が実行される。すなわち，（１） でレジスタウィンドウを１段進め，（２） でシステムコール処理を行い，（３）でリターンを行い，ＫＯＳ９２へ戻り，以下図１６に示すようにＫＯＳ９２，ＵＯＳ９１のそれぞれでリターンを行ってアプリケーション９０へ戻る。
【００１７】
この図１６に示すシステムコールの処理方法では，レジスタウィンドウという環状のレジスタにより，関数呼び出しのパラメータの受け渡しを効率的に行うことができ，関数呼出しに要する時間を少なくすることができるが，タスク切替時に保存，復元する処理が増えてしまい，タスク切替に要する時間が長くなる。また，ウィンドウオーバフローも起き易くなる。
【００１８】
次に上記の従来のレジスタウィンドウ方式では，割込みが発生した場合，その時の情報はカレントウィンドウのレジスタに格納されているが，その内容を保存したり，復帰する動作はソフトウェアにより処理していたが，割込みが繰り返されると，ソフトウェアへの負担が増大していた。
【００１９】
図１７は命令を書替えて走行する処理の従来例の説明図である。
図１７には，リアルタイムＯＳの処理システムにおいて，命令を書替えて走行する場合のユーザプログラムとＯＳの処理が示されている。
【００２０】
図１７において，ユーザプログラムが命令１，命令２である時に，ＯＳが命令２の退避と命令２をシステムコールＢに書替える処理を行う（この時，命令１は関係ない）。これにより命令２はシステムコールＢに書替えられているため，システムコールＢがＯＳにより実行され，終了後，退避されていた命令２が復元される。この処理の過程において，命令２をシステムコールＢに書き替えた後にシステムの障害等により，プログラムが正常に走行できない状態になると，元の命令を正常に実行できない可能性がある。
【００２１】
【発明が解決しようとする課題】
（１） リアルタイム処理装置においては，ＯＳ（オペレーティングシステム）の処理速度が重要であるが，上記したレジスタウィンドウ方式を使用したマイクロプロセッサ上で動作する従来のリアルタイムＯＳでは，関数呼び出しや復帰動作によりオーバフローやアンダーフローが発生するとメモリへの退避，復元の処理が頻繁に行われるため，オーバヘッドが増大して，実行処理速度を低下させるという問題があった。同様に，割り込み発生やタスク切替え時には，レジスタウィンドウの使用数は特別に制限せず，割込み発生時またはタスク切替時には単純に，使用中の全レジスタウィンドウをメモリに退避していた。このため，割込みやタスク切替による退避や復元の処理でオーバヘッドが増大していた。
【００２２】
（２） 従来のレジスタウィンドウ方式の割込みの処理では，割込み発生時の退避と復帰の処理が複雑な処理を要し，定期起動の割込み等によるレジスタウィンドウの使用により時間を要していた。
【００２３】
（３） 次に上記従来のシステムコール処理方式（図１５，図１６参照）によれば，システムコールにより，ＵＯＳにおいてレジスタウィンドウを新たに使用し，更に本体の処理でもレジスタウィンドウが１段進められる。その場合，ウィンドウ切替による保存・復元するウィンドウ数が増えて，タスク切替の処理時間が長くなり，オーバフローが起き易くなるという問題があった。
【００２４】
（４） また，従来の命令を書替えて走行するシステムの処理方法（図１７参照）では，命令を書替えた後のシステム障害等に対し元のプログラムへの復元ができない可能性があるという問題があった。
【００２５】
本発明は上記の従来の問題を解決するもので，交換機等のリアルタイム処理を必要とするシステムのレジスタウィンドウ方式を使用した処理装置において，レジスタウィンドウを効率良く使用して実行処理速度を向上することができるリアルタイム処理装置を提供することを目的とする。また，本発明は割込み発生時の復帰点や情報を退避したスタックの情報を効率的に管理することを目的とする。更に，アプリケーションからのシステムコール発生時の処理におけるレジスタウィンドウの切替数を削減して処理時間を短縮することを目的する。また，命令の書替え後に，前状態に戻す前に装置の異常等が発生しても命令を書替える必要性のある装置にプログラム復元を行うことができること等を目的とする。
【００２６】
【課題を解決するための手段】
図１は本発明の第１の原理説明図，図２は本発明の第２の原理説明図である。図１にはマイクロプロセッサ等のリアルタイム処理を行うレジスタウィンドウ方式の処理装置における，本発明によるレジスタウィンドウの制御方式の原理が示され，図１において，１は環状のレジスタウィンドウを表し，この例では＃０〜＃７の合計８個のウィンドウで構成され，各ウィンドウは従来例と同様にインレジスタ，ローカルレジスタ，アウトレジスタの３つのグループで構成され，各グループのウィンドウレジスタは８個のレジスタで構成され，一つのウィンドウに対し２４個のウィンドウレジスタが設けられ，インレジスタとアウトレジスタは，前，後のウィンドウに対しオーバラップする。また，グローバルレジスタは，全てのウィンドウにより共用される。
【００２７】
２ａはＯＳ側で使用するレジスタウィンドウの範囲，２ｂはアプリケーションプログラム（以下，単にアプリケーションという）側で使用するレジスタウィンドウの範囲を表し，３ａはＯＳ側の境界を越えたウィンドウ位置（番号）が設定された第１ウィンドウ無効マスク（第１ＷＩＭで表示），３ｂはアプリケーション側の境界を越えたウィンドウ位置（番号）が設定された第２ウィンドウ無効マスク（第２ＷＩＭで表示），４は現在のウィンドウ位置を表すカレントウィンドウポインタ（ＣＷＰで表示）である。
【００２８】
図２において，２０は割込み制御ブロック（ＩＣＢで表示：Ｉｎｔｅｒｒｕｐｔ Ｃｏｎｔｒｏｌ Ｂｌｏｃｋ）であり，２１〜２７の各領域により構成され，２１は次のＩＣＢの位置を表す次のＩＣＢへのポインタを表し，２２はプロセッサ割込みレベルの情報，２３はカレントウィンドウ（ＣＷ）のローカルレジスタの一部，２４はカレントウィンドウのインレジスタの一部，２５はカレントウィンドウのアウトレジスタの一部，２６は外部割込み番号，２７はシステムコール作業域である。
【００２９】
本発明の第１の原理は環状のレジスタウィンドウを，アプリケーションプログラムが使用するウィンドウの範囲を制限するか，オペレーティングシステム（ＯＳ）が使用するウィンドウの範囲を制限するものである。また，アプリケーションプログラムまたはＯＳで使用するウィンドウの個数を一定にしてその範囲を固定化せずに，可変にするものである。また，本発明の第２の原理は割込み発生時に，割込み処理を起動する前に割込み復帰点や，スタックに関する情報を割込み処理により破壊されないように管理ブロックのキューを設けて高速なリアルタイム処理を行うものである。
【００３０】
【作用】
図１において，最初にＯＳ側で使用するレジスタウィンドウとアプリケーションプログラムで使用するレジスタウィンドウの位置をそれぞれ固定して制限する場合について説明する。
【００３１】
ＯＳ側で使用するレジスタウィンドウを＃０〜＃３とし，アプリケーションプログラム側で使用するレジスタウィンドウの範囲は＃４〜＃７とする。そのため，第１ウィンドウ無効マスク３ａに“０”を設定し，第２ウィンドウ無効マスク３ｂに“４”を設定する。なお，現在処理を行っているウィンドウの番号（ポインタ）は，カレントウィンドウポインタ４により示される。
【００３２】
ＯＳ側のウィンドウは，ＯＳ内での処理により＃３から＃０へ順次，切替えられる。但し，＃０は常に割込み処理（トラップック処理）のために残すため，カレントウィンドウポインタ４の値が第１ウィンドウ無効マスク３ａに設定された値（０）になるとオーバフローとなり，逆に復帰（ＲＥＴＵＲＮ）命令により，カレントウィンドウポインタ４の番号が増大して第２ウィンドウ無効マスク３ｂに設定された値（４）と一致するとアンダーフロー割込みを発生する。
【００３３】
アプリケーションプログラム側のウィンドウ２ｂについても，ＯＳ側と同様に，ウィンドウ＃７〜＃４の中の＃７〜＃５の３つのウィンドウを通常の動作で使用し，呼び出し（ＣＡＬＬ）命令が順番に発生して＃７，＃６，＃５とウィンドウが切替えられ，＃４になるとオーバフローを生じ，逆に復帰（ＲＥＴＵＲＮ）命令が実行され，カレントウィンドウポインタ４の番号が増加して第１ウィンドウ無効マスク３ａの値（＝０）と一致するとアンダーフロー割込みを発生する。
【００３４】
このような構成により，アプリケーション側では最大３つのウィンドウレジスタを使用（それ以上は，メモリに退避）することにより，オーバフロー発生時に退避するウィンドウ数を制限でき，ＯＳ側は常に一定数のウィンドウを確保することができる。
【００３５】
次に，ＯＳ側で使用するレジスタウィンドウとアプリケーション側で使用するレジスタウィンドウの個数を一定とするが，その範囲を可変にする場合について説明する。すなわち，最初に，第１ウィンドウ無効マスク３ａ，第２ウィンドウ無効マスク３ｂに対し，上記の固定の場合と同様にそれぞれ数値“０”，“４”を設定する。この後，ＯＳ側でオーバフローが発生した場合には，第１及び第２のウィンドウ無効マスク３ａ，３ｂを１つづつずらして設定する。すなわち，１つづれると，第１，第２のウィンドウ無効マスク３ａ，３ｂを“７”，“３”に設定する。
【００３６】
更に，ＯＳ側で使用するレジスタウィンドウとアプリケーション側で使用するレジスタウィンドウの中で，一方だけを制限して，他方は制限を加えないようにすることができる。ＯＳ側で使用するウィンドウに制限を加えない場合について説明する。この場合，アプリケーション側のウィンドウ数を３個として，第２ウィンドウ無効マスク３ｂに“４”を設定し，ＯＳ側のウィンドウを＃３から使用を開始して，３つの関数を呼び出し（ＣＡＬＬ）すると，オーバフロー（＃０に達する）が発生する。この時，アプリケーションの１つのウィンドウ（＃７）または，使用している全ウィンドウ（＃７から＃５までの範囲）をメモリ上のスタックへ退避する。このようにして，ＯＳ側のウィンドウ数に対しては制限を加えないようにする。同様の原理により，ＯＳ側のウィンドウ数を制限してアプリケーション側のウィンドウ数に制限を加えないようにすることができる。
【００３７】
次に図２の構成において，図示されない割込み管理部で割込み動作が開始すると，発生した割込み毎に，割込み制御ブロック（ＩＣＢ）２０のポインタを得て，新たな割込み制御ブロックを得てそれをＩＣＢキューに登録し，実行中の割込みを管理する。割込みがネストした時には，新しい割込みのＩＣＢを先頭に追加し，以前の割込みのＩＣＢはその後に接続される。
【００３８】
【実施例】
図３は本発明が実施される処理装置のブロック構成図である。
図３において，３０はレジスタウィンドウ制御によりリアルタイム処理を行う交換機等の処理装置（ＣＰＵ及びメモリ），３１はオペレーティングシステム部（ＯＳ部），３２はアプリケーション（ユーザ）プログラムを実行するアプリケーション部，３３はカレントウィンドウポインタ（ＣＷＰ）３３ａ，第１ウィンドウ無効マスク（ＷＩＭ）３３ｂ，第２ウィンドウ無効マスク３３ｃを格納する各レジスタ，３４は８個のウィンドウを構成するためのレジスタ群，３５はＩＣＢ（割込み制御ブロック），３６はメモリでありオーバフロー，アンダーフロー，割込み動作等によりレジスタウィンドウの内容やパラメータが退避されるスタックを備えるメモリである。
【００３９】
この構成において，ＯＳ側の処理において使用するウィンドウを上記図１に示すように，ＯＳ部とアプリケーション部により使用するウィンドウの領域を固定（第１ＷＩＭ及び第２ＷＩＭを固定）する場合の動作を説明する。この場合，ＯＳ側で使用するウィンドウのオーバフローを生じさせる第１ＷＩＭ３３ｂ（図３）に「０」，アプリケーション側で使用するウィンドウのオーバフローを生じさせる第２ＷＩＭ３３ｃ（図３）に「４」を設定する。
【００４０】
この場合，ＯＳ側の処理においてウィンドウを３，２，１と使用して，ウィンドウが０になると第１ＷＩＭ３３ｂの設定値と一致してオーバフロートラップが発生し，アプリケーション（ユーザ）側の処理において，ウィンドウを７，６，５と使用してウィンドウが第２ＷＩＭ３３ｃと一致してオーバフロートラップが発生する。
【００４１】
図４は範囲固定時のオーバフロー発生の処理フローを示す図である。
使用ウィンドウの２つの範囲を固定した時にオーバフローが発生すると，走行プログラムがＯＳ側かアプリケーション側かを判別し（図４のＳ１），ＯＳのプログラムである場合はウィンドウ３，２，１をメモリのスタック３６（図３）に保存して（図４のＳ２），ＣＷＰ３３ａ（図３）を「３」に戻し（図４のＳ３），元の処理に復帰する。また，アプリケーション（ユーザ）プログラムである場合は，ウィンドウ７，６，５を保存し（図４のＳ４），ＣＷＰ３３ａを「７」に戻して（同Ｓ５），元のアプリケーションに復帰する。
【００４２】
次にアンダーフローの場合は，処理フローは図示省略されているが基本的には図４に示すフローの逆となる。すなわち，アプリケーションプログラムの例で説明すると，アプリケーションプログラムが５，６，７と逆行（ＲＥＴＵＲＮ）して第２ＷＩＭ３３ｃの数値（０）と一致してアンダーフローが発生すると，ウィンドウ７，６，５をメモリのスタックから復元し，ＣＷＰ３３ａを「５」に戻す処理を行う。ＯＳ側の場合にも同様の処理によりウィンドウ３，２，１をメモリのスタックから復元し，ＣＷＰ３３ａを「１」に戻す。
【００４３】
次にＯＳ側の処理で使用するウィンドウの個数と，アプリケーション側の処理で使用するウィンドウの個数を一定とするが，使用するウィンドウの範囲を可変としてシフトする場合（第１ＷＩＭ及び第２ＷＩＭを固定しない場合）について説明する。
【００４４】
この場合も最初は上記図１と同様に，ＯＳ側で使用するウィンドウのオーバフローを生じさせる第１ＷＩＭ３３ｂに「０」，アプリケーション側で使用するウィンドウのオーバフローを生じさせる第２ＷＩＭ３３ｃに「４」を設定する。
【００４５】
この状態でＯＳ側の処理においてウィンドウを３，２，１と使用して，ウィンドウが０になると第１ＷＩＭ３３ｂの設定値と一致してオーバフロートラップが発生し，アプリケーション（ユーザ）側の処理において，ウィンドウを７，６，５と使用してウィンドウが第２ＷＩＭ３３ｃと一致してオーバフロートラップが発生する。
【００４６】
図５は範囲可変時のオーバフロー発生の処理フローを示す図である。
ＯＳ側とアプリケーション側のそれぞれで使用するウィンドウの範囲を可変にしてシフトする場合にオーバフローが発生すると，走行プログラムがＯＳ側かアプリケーション側かを判別し（図５のＳ１），ＯＳのプログラムである場合はウィンドウ３をメモリに保存し（同Ｓ２），第２ＷＩＭの内容を「３」に設定し（同Ｓ３），ウィンドウ７〜５のうち，使用しているものを１つづつずらす（同Ｓ４）。ウィンドウ７〜５を全て使用していた場合，ウィンドウ７を６，ウィンドウ６を５，ウィンドウ５を４へそれぞれ内容を移す。続いて，第１ＷＩＭの内容を「７」に設定する（同Ｓ５）。これにより，ＯＳのプログラムで使用可能なウィンドウが６〜４の範囲にシフトする。上記Ｓ１において，アプリケーションプログラムであることが判別されると，ウィンドウ７を保存し（図５のＳ６），第１ＷＩＭ３３ｂを「７」にする（同Ｓ７）。次にウィンドウ３〜１のうち，使用しているものを１つづつずらし（同Ｓ８），第２ＷＩＭを「３」に変更し（同Ｓ９），元のアプリケーションプログラムへ戻る。
【００４７】
上記の，実施例ではアプリケーション側及びＯＳ側の両方のウィンドウ数を一定に制限しているが，これらの一方のウィンドウ数だけを制限して，他方に制限を設けないように構成することができる。その場合，制限されない方が走行している時に，ＷＩＭの値と一致してウィンドウオーバフローになると，相手のウィンドウ内容をメモリに退避し，ＷＩＭの数を順次移動させていき，最終的に全ウィンドウを使用可能にする。この他に，制限されない方に切り替わった時点で，制限する方が使用していたウィンドウを全てセーブする方式がある。
【００４８】
次に本発明による割込み管理を説明する。
図６は割込み制御ブロック（ＩＣＢで表示）の構成図であり，上記図２に対応する。この割込み制御ブロック（ＩＣＢ）は，割込み処理を行う割込みハンドラを起動する前に，カレントウィンドウに設定されている割込み復帰点やスタックに関する情報をハンドラが破壊しないように保存するためにメモリに設けられる。また，割込みハンドラで関数呼び出しの階層が深い位置で割込みハンドラ終了（ＥＸＴ−ＩＮＨ：Ｅｘｉｔ ＩＮｔａｒｒｕｐｔ Ｈａｎｄｌｅｒ，割込みハンドラの最後に置かれるシステムコール）を実行した時にも割込み点に関する情報を容易に得られるようにするために，割込み管理ブロックＩＣＢが用意される。
【００４９】
図６において，２１，２２，２４〜２６は，それぞれ上記図２の同じ符号に対応し，図６の２３ａ，２３ｂは図２の２３に対応し，図６の２７ａ〜２７ｃは図２の２７に対応し，それぞれ４バイトが格納される。すなわち，２１は割込み処理中に次の割込みが発生した時に設けられた次のＩＣＢへのポインタが格納され，割込みがネスト（割込み動作中に更に割込みが発生した時）した時にキュー構成でＩＣＢが順次設けられ，キュー最後の場合はこのポインタにＮＵＬＬが設定される。２２は割込み起動制御の先頭でのＰＳＲ（プログラムステータスレジスタ）を保存し，実際に必要なのはＰＩＬ（プロセッサ割込みレベル）である。
【００５０】
次に図６の２３ａは，割込み起動制御の先頭でのカレントウィンドウのローカル１レジスタ（旧ＰＣ：元のプログラムカウンタ）の内容，２３ｂは割込み起動制御の先頭でのカレントウィンドウのローカル２レジスタ（旧ｎＰＣ：ｎ のプログラムカウンタ）の内容，２４は割込み起動制御の先頭でのカレントウィンドウのイン６レジスタ（フレームポインタ）の内容，２５は割込み起動制御の先頭でのカレントウィンドウのアウト６レジスタ（スタッフポインタ）の内容，２６は発生した外部割込み番号，２７ａ〜２７ｃはシステムコール実行時に使用する作業域で，それぞれイン７レジスタ（リターンアドレス），スタックポインタ（ｓｐまたはＳＰ），フレームポインタ（ｆｐまたはＦＰ）が保存される。
【００５１】
次に上記図６に示す割込み制御ブロック（ＩＣＢ）を用いた割込み処理を説明する。図７は一般の割込み処理のフロー，図８は基本クロック割込み（または一定数以上のウィンドウを使っていない場合の割込み）処理のフローを示す。図７，図８のＡ．は割込みの処理，Ｂ．は割込みハンドラ終了（ＥＸＴ−ＩＮＨ）の処理である。
【００５２】
図７，図８のＡ．において，割込み処理がスタートすると，外部割込み番号を得て（各図のＳ１），ＩＣＢを確保して，ＩＣＢキューの先頭に入れる（同Ｓ２）。更に，カレントウィンドウのレジスタｒ１７，ｒ１８，ｒ３０（ｆｐ），ｒ１４（ｓｐ）をＩＣＢに保存し（同Ｓ３），ＰＳＲ（プログラムステータスレジスタ）をＩＣＢに設定する（同Ｓ４）。続いてＩＣＢキューに確保したＩＣＢを設定する（同Ｓ５）。この後，ソフトマスクがかかっていないか判別し（同Ｓ６），割込みのソフトマスクがかかっていると処理を終了するが，かかっていない場合（ｙｅｓの場合），図７と図８で処理が異なる。
【００５３】
一般の割込みの処理の図７の場合，使用中のレジスタウィンドウをスタックへ保存し（図７のＳ７），次に割込みのネスト（割込み処理中の新たな割込み）か判別し（同Ｓ８），ネストでない場合は割込み用スタックに切替える（同Ｓ９）。また割込みのネストである場合は，ハンドラを起動する（同Ｓ１０）。
【００５４】
図８の場合，一定周期で頻繁に発生する基本クロック割込みであるか，一定数以上のウィンドウを使ってないかを判別し（図８のＳ７），該当しない場合は使用中のレジスタウィンドウをスタックへ保存し（同Ｓ８）。基本クロック割込みであるか一定数以上のウィンドウを使っていない場合，次に割込みネストであるか判別する（図８のＳ９）。割込みのネストでない場合，割込み用スタックに切り替え（同Ｓ１０），割込みのネストである場合はハンドラを起動する（同Ｓ１１）。
【００５５】
このようにして，一定周期で頻繁に発生する基本クロック割込み等に対しては，レジスタウィンドウを保存することなく，ユーザ定義のハンドラにより処理を行うことができる。
【００５６】
図７，図８のＢ．に示す割込みハンドラ終了（ＥＸＴ−ＩＮＨ）の処理は，同じ内容であり，カレントＩＣＢから上記の図７，図８のＡ．の処理で保存したカレントウィンドウのレジスタｒ１７，ｒ１８，ｒ３０，ｒ３１，ｓｐを復元する（各図のＳ１）。次にカレントＩＣＢを開放し（同Ｓ２），待ちＩＣＢキューの先頭をはずして，カレントＩＣＢへ入れて（同Ｓ３），リターンを行う（同Ｓ４）。
【００５７】
図９は本発明によるシステムコール処理の流れ図である。この処理は，上記従来のシステムコール処理（上記図１６参照）において使用するレジスタウィンドウの数が多いことにより処理時間が長くなるという問題を解決するものである。
【００５８】
図９において，６０〜６３は上記図１５，図１６（従来例）の９０〜９３に対応し，６０はアプリケーション，６１はＵＯＳ，６２はＫＯＳ，６３はシステムコール本体処理を行う本体（カーネルとも呼ばれる）であり，６０ａ，６１ａ，６２ａ，６２ｂ，６３ａは６０〜６３の処理に対応するレジスタウィンドウの使用状態を表す。なお，図９のＵＯＳ６１，ＫＯＳ６２は，上記図２では図示省略されている。
【００５９】
ａ．アプリケーション６０は，通常の関数を呼ぶのと同じ方法で，カレントウィンドウのアウトレジスタ（図１２参照）へパラメータを設定してシステムコール（図９ではシステムコールＡで示す）を呼ぶ。図９の例では，この時のアプリケーション６０の動作時に，レジスタウィンドウの番号は６０ａに示すように「２」である。
【００６０】
ｂ．ＵＯＳ６１でのウィンドウ使用数の削減方法
ＵＯＳ６１でのウィンドウ使用数を削減するため，ＵＯＳ６１で新しいウィンドウを使用しないようにする。この場合，ＵＯＳ６１はアプリケーションとＯＳとのインタフェースをとることであり，具体的にはＫＯＳ６２を呼び出すトラップを発生させる。そのため，ここではアプリケーション６０からのパラメータをＫＯＳ６２が参照できるようにカレントウィンドウのアウトレジスタ（図１２のｒ８〜ｒ１５）に設定する。アプリケーション６０はＵＯＳ６１を呼び出す時にパラメータをアウトレジスタに設定しているので，ウィンドウを回転させないことでカレントウィンドウのアウトレジスタにパラメータが格納されたままになり，ＫＯＳ６２ではカレントウィンドウのインレジスタ（図１２のｒ２４〜ｒ３１）でパラメータを参照できる。
【００６１】
具体的には，ＵＯＳ６１はシステムコール毎の命令が集合して出来ており，それらの関数では最初にシステムコール毎に割り当てられているシステムコール番号をグローバルレジスタ（図１２のｒ０〜ｒ７）へ設定する（図９のＵＯＳ６１の（１） 参照） 。グローバルレジスタには，カレントウィンドウが変化しても同じレジスタを参照できるので，ＫＯＳ６２で同じ値を得ることができる。次に別のＬＭ（ロードモジュール）であるＫＯＳ６２へ実行を移すためにトラップを発生させる（図９のＵＯＳ６１の（２） 参照） 。
【００６２】
これにより，ウィンドウを回転させた時に行わなければならなかったインレジスタからアウトレジスタへパラメータをコピーする必要がなくなり，ＵＯＳの処理自体も少なく済むようになる。また，本発明ではＫＯＳ６２からＵＯＳ６１に戻り，アプリケーション６０へ戻る手順ではなく，ＫＯＳ６２から直接アプリケーションに戻るようにする。
ｃ．ＫＯＳ６２でのウィンドウ使用数の削減方法
本発明ではＫＯＳ６２で使用するウィンドウを一時的に使用しないようにしてから，ＯＳ本体６３（図９の例では含まれないパラメータチェック部を備える場合は，パラメータチェック部）を呼び出すことで見かけ上のウィンドウ使用数を削減する。
【００６３】
具体的には，このＫＯＳ６２では，全てのシステムコールに共通な処理を行っており，最初にカレントウィンドウのｓｐ（スタックポインタ），ｆｐ（フレームポインタ），インレジスタｉ［７］の各レジスタをＫＯＳ６２に設けられたＴＣＢ（タスク・コントロール・ブロック）に保存する。次にＵＯＳ６１で設定したグローバルレジスタからシステムコール番号を得て（図９のＫＯＳ６２の（１） ），これをインデックスにしてシステムコール本来の機能を実現する関数のテーブル（以下，関数テーブルという）から，関数のアドレスを得る。次に，レジスタウィンドウを一段戻す（図９のＫＯＳ６２の（２） ）。
【００６４】
これにより，ＣＷＰ（カレントウィンドウポインタ）は＋１され，図９の例では，レジスタウィンドウ番号が「１」の状態６２ａからレジスタウィンドウ番号が「２」の状態６２ｂとなる。この後，得られたアドレスの関数をコールする（図９のＫＯＳ６２の（３） ）。
【００６５】
ｄ．ＯＳ本体６３
レジスタウィンドウを一段進める（ＣＷＰ−１）。図９の例では，ＯＳ本体６３の（１） の処理に対応し，レジスタウィンドウの番号「２」の状態６２ｂから「１」の状態６３ａになる。次に関数（システムコール本来の処理）の実行を終了すると，ＫＯＳ６２へ復帰（リターン）する。このリターン時に，レジスタウィンドウ番号が１つ戻されて，状態６２ｂとなる。
【００６６】
ＯＳ本体６３からのリターン動作により，ＫＯＳ６２では，上記のＴＣＢに保存しておいた，ｓｐ，ｆｐを復元する。さらに，ＴＣＢに保存したインレジスタのｉ［７］をカレントウィンドウのローカルレジスタに設定する。詳細にはｉ［７］をｌ［１］に，ｉ［７］＋４をｌ［２］に設定する。最後にＫＯＳ６２の復帰（リターン）命令により，ＫＯＳ６２の処理を終わる（図９のＫＯＳ６２の（４） ）。このリターン命令により，ＵＯＳ６１を経由せずに直接アプリケーション６０に戻る。
【００６７】
このようにして，従来のシステムコール発行時の処理（上記図２０参照）に比べて，使用するレジスタウィンドウの数を少なくなるため処理速度が向上する。次に，割込みの発生によりウィンドウ使用数が増大することによる処理速度が遅くなる。このような割込みが使用ウィンドウ数が多い場合には特に影響が大きくなる。これを改善する本発明の方法を図１０により説明する。
【００６８】
図１０は割込み処理の制御を行う処理フローである。
図１０のＡ．に示す割込み処理では，割込みが発生すると（図１０のＡ．のＳ１），現在使用中のウィンドウ数を調べて，これが一定数以上か否かによりその割込み処理を保留可か否かの判定をする（同Ｓ２）。もし，ウィンドウ数が一定数に達していない場合は，通常の割込み処理を行うが，ウィンドウ数が一定以上の場合は，保留中フラグをセットする（同Ｓ３）。続いて，ウィンドウ無効マスク（ＷＩＭ）をセットし（同Ｓ４），割込み処理を実行することなくリターンする。この場合，ＷＩＭとしては，使用ウィンドウ数が上記Ｓ２の保留可の判別を行う基準となる一定数以下の数に設定し（例えば，使用数「３」に設定し），その数になったらアンダーフローを発生させるためにセットされる。
【００６９】
その後，使用中のウィンドウ数が一定以下になるとアンダーフローが発生すると，アンダーフロー処理を開始する（図１０のＢ．のＳ１）。この場合，保留中フラグがセットされているか否か判定し（同Ｓ２），セットされていない場合は通常処理を行い，セットされている場合は，ウィンドウ無効マスク（ＷＩＭ）をリカバリーする（同Ｓ３）。このリカバリーは，上記図１０のＡ．のＳ２でセットする前状態に戻すことである。次に割込みハンドラを起動し（図１０のＢ．のＳ４），割込み処理を行ってリターンする。
【００７０】
このようにして，割込み処理に対し制限を加えて処理速度を向上することができる。
図１１は命令書替えを行う場合のプログラム復元を保証する処理フローである。この処理フローは，従来の命令を書替えて走行するシステムにおける処理（上記図１７参照）の問題を解決するものである。
【００７１】
命令を書替えて走行するようなシステムでは，例えば，システムコールの戻り値がエラーの場合にユーザプログラムを通常の後続の命令ではなく，終了処理ルーチン等の例外処理を実行させたい場合に，ＯＳにより命令の書替えを行う。
【００７２】
この場合，図１１のＡ．に示すようにＯＳは，命令２の１つ前の命令１と，命令２を図１１のＢ．に示す退避エリアに退避する（図１１のＡ．のＳ１）。この時，退避エリアには，「命令１」，「命令２」に続いて，「命令２の次命令へジャンプ」も格納される。次に，ユーザプログラムの命令１を「退避エリアジャンプ」の内容に書替え，更に命令２を「システムコールＢ」に書替える（図１１のＡ．のＳ２）。この後，ＯＳからの復帰によりユーザプログラムの命令２が実行されると，システムコールＢが実行され，その復帰命令は復元される。
【００７３】
このように，書替えを行うことにより，例えば，命令２をシステムコールＢに書替えた後にシステムの障害等により，システム再開等が発生してしまった場合でも，退避エリアに格納されている通常ルートが走行可能となり，レジスタウィンドウ方式によるリアルタイムＯＳの処理において，命令を書替えて走行する場合，プログラム復元の信頼性を高めることができる。
【００７４】
【発明の効果】
本発明によれば，以下に述べるような効果を奏することができる。
▲１▼レジスタウィンドウ方式のリアルタイムＯＳにおいて，レジスタウィンドウを効率良く使用して実行処理速度を向上することができる。
【００７５】
▲２▼割込み発生時の復帰点や情報を退避したスタックの情報を効率的に管理することが可能となる。
▲３▼システムコール発生時の処理におけるレジスタウィンドウの切替数を削減して処理時間を短縮することが可能となる。
【００７６】
▲４▼命令を書替えて実行するシステムにおいて，命令の書替え後に，前状態に戻す前に装置の異常等が発生しても命令を復元することを可能とし，信頼性を向上することができる。
【図面の簡単な説明】
【図１】本発明の第１の原理説明図である。
【図２】本発明の第２の原理説明図である。
【図３】本発明が実施される処理装置のブロック構成図である。
【図４】範囲固定時のオーバフロー発生の処理フローを示す図である。
【図５】範囲可変時のオーバフロー発生の処理フローを示す図である。
【図６】割込み制御ブロック（ＩＣＢ）の構成図である。
【図７】一般の割込み処理のフローを示す図である。
【図８】基本クロック割込み処理のフローを示す図である。
【図９】本発明によるシステムコール処理の流れ図である。
【図１０】割込み処理の制御を行う処理フローを示す図である。
【図１１】命令書替えを行う場合のプログラム復元を保証する処理フローを示す図である。
【図１２】従来のレジスタウィンドウのレジスタの構成例を示す図である。
【図１３】各レジスタグループの説明図である。
【図１４】８個のウィンドウを使用する場合のウィンドウのシフトの概念図である。
【図１５】システムコールのソフトウェア構造を示す図である。
【図１６】従来のシステムコールの処理の流れを示す図である。
【図１７】命令を書替えて走行する処理の従来例の説明図である。
【符号の説明】
１ 環状の８個のレジスタウィンドウ（＃０〜＃７）
２ａ ＯＳ側で使用するレジスタウィンドウの範囲
２ｂ アプリケーション側で使用するレジスタウィンドウの範囲
３ａ 第１ウィンドウ無効マスク（第１ＷＩＭ）
３ｂ 第２ウィンドウ無効マスク（第２ＷＩＭ）
４ カレントウィンドウポインタ（ＣＷＰ）
Claims (5)
- それぞれ複数のレジスタグループにより構成されたレジスタウィンドウが予め設定された数の複数個が環状に設けられ，関数呼び出しにより順次隣接するウィンドウへ切替えられ，復帰動作により逆方向の隣接ウィンドウへ戻されるリアルタイムＯＳの処理方法において，
前記複数個の環状に設けられたレジスタウィンドウ全体をアプリケーション部で使用可能な一定個数のレジスタウィンドウとＯＳ部で使用可能な一定個数のレジスタウィンドウの範囲に対応して，ＯＳ部側の境界を越えたウィンドウ番号が設定された第１ウィンドウマスクと，アプリケーション部側の境界を越えたウィンドウ番号が設定された第２ウィンドウマスクを設け，
関数呼び出しにより現在処理を行っているウィンドウ番号が更新されて，前記第１ウィンドウマスクまたは第２ウィンドウマスクの番号と一致すると，オーバフロー割り込みを発生し，
復帰動作により現在処理を行っているウィンドウ番号が更新されて，前記第１ウィンドウマスクまたは第２ウィンドウマスクの番号と一致すると，アンダーフロー割り込みを発生することを特徴とするリアルタイムＯＳの処理方法。 - 請求項１において，
前記第１ウィンドウマスクと第２ウィンドウマスクに設定されたウィンドウ番号は，前記のオーバフロー割り込みが発生すると，それぞれの使用可能な範囲が拡大するよう一つずつシフトさせることを特徴とするリアルタイムＯＳの処理方法。 - 請求項１において，
割込み発生時に割込み処理が起動する前に現在のウィンドウに設定されている割込み復帰点やスタックに関する情報を保存する割込み制御ブロックを設け，
前記割込み制御ブロックは，発生順にキューを構成することを特徴とするリアルタイムＯＳの処理方法。 - 請求項３において，
基本クロック割込み等の一定周期で頻繁に発生する割込みに対し，レジスタウィンドウの内容の退避をせず，割込み処理を行うことを特徴とするリアルタイムＯＳの処理方法。 - 請求項１において，
割込みの発生時に使用中のウィンドウ数を調べて一定数に達しない場合だけ割込み処理を行い，一定数以上の場合は割込みを保留し，
ウィンドウ数が一定数以下になるとアンダーフローを発生させて前記保留中の割込みの処理を起動することを特徴とするリアルタイムＯＳの処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP15353795A JP3595028B2 (ja) | 1995-06-20 | 1995-06-20 | リアルタイムｏｓの処理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP15353795A JP3595028B2 (ja) | 1995-06-20 | 1995-06-20 | リアルタイムｏｓの処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH096630A JPH096630A (ja) | 1997-01-10 |
| JP3595028B2 true JP3595028B2 (ja) | 2004-12-02 |
Family
ID=15564690
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP15353795A Expired - Fee Related JP3595028B2 (ja) | 1995-06-20 | 1995-06-20 | リアルタイムｏｓの処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3595028B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2044517A4 (en) * | 2006-07-10 | 2010-08-25 | Silverbrook Res Pty Ltd | SYSTEM FOR PROTECTING SENSITIVE DATA BEFORE USER CODE IN A REGISTER PANEL ARCHITECTURE |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH10302389A (ja) * | 1997-04-22 | 1998-11-13 | Ricoh Co Ltd | データ処理回路 |
| JP2006039874A (ja) * | 2004-07-26 | 2006-02-09 | Fujitsu Ltd | 情報処理装置 |
| JP5028774B2 (ja) * | 2005-09-22 | 2012-09-19 | 富士通株式会社 | 演算処理装置，情報処理装置，及びレジスタファイルの制御方法 |
-
1995
- 1995-06-20 JP JP15353795A patent/JP3595028B2/ja not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2044517A4 (en) * | 2006-07-10 | 2010-08-25 | Silverbrook Res Pty Ltd | SYSTEM FOR PROTECTING SENSITIVE DATA BEFORE USER CODE IN A REGISTER PANEL ARCHITECTURE |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH096630A (ja) | 1997-01-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7178062B1 (en) | Methods and apparatus for executing code while avoiding interference | |
| JP5680679B2 (ja) | 例外イベントを取り扱うための装置および方法 | |
| US5701493A (en) | Exception handling method and apparatus in data processing systems | |
| JPWO2009157178A1 (ja) | 仮想計算機制御装置、仮想計算機制御プログラム及び仮想計算機制御回路 | |
| JPH0353328A (ja) | レジスタ退避回復方法ならびに処理装置 | |
| JPH0450621B2 (ja) | ||
| JP3595028B2 (ja) | リアルタイムｏｓの処理方法 | |
| JP2004157636A (ja) | データ処理装置 | |
| JPH0638237B2 (ja) | マルチプログラミング・モードで動作するデータ処理システム | |
| JPS6362039A (ja) | 計算機 | |
| JP2001256062A (ja) | 割込処理方法およびその方法を用いた演算処理装置 | |
| US20060168428A1 (en) | Method of providing microcontroller context management | |
| JPH02148223A (ja) | レジスタ退避復活装置 | |
| US5715439A (en) | Bi-directional co-processor interface | |
| US7562207B2 (en) | Deterministic microcontroller with context manager | |
| JPH01217635A (ja) | レジスタ退避方式 | |
| JP3539984B2 (ja) | プロセッサ | |
| CN1016905B (zh) | 在非微码数据处理***上提供扩展的处理环境的装置和方法 | |
| JPH0668725B2 (ja) | データ処理システムにおける割込条件に応答する装置及び非同期割込条件に応答する方法 | |
| JP2562838B2 (ja) | プロセッサ及びストアバッファ制御方法 | |
| JPH03225535A (ja) | プログラムトレース方式 | |
| JP2003505758A (ja) | プロセッサ・アーキテクチャ | |
| WO1990005951A1 (en) | Method of handling unintended software interrupt exceptions | |
| JP2509244B2 (ja) | 分岐命令処理装置 | |
| JPH03204036A (ja) | 割込み処理後の動的再開機構を備えた計算機 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040127 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040329 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040831 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040902 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080910 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080910 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090910 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090910 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100910 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100910 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110910 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120910 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120910 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130910 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |