JP3595028B2

JP3595028B2 - Real-time OS processing method

Info

Publication number: JP3595028B2
Application number: JP15353795A
Authority: JP
Inventors: 貴幸森山; 尚樹門田; 敬功原田; 潔史繁野; 智美 ▲高▼橋
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1995-06-20
Filing date: 1995-06-20
Publication date: 2004-12-02
Anticipated expiration: 2019-12-02
Also published as: JPH096630A

Description

【０００１】
【産業上の利用分野】
本発明はレジスタウィンドを備えたマイクロプロセッサにおけるリアルタイムＯＳの処理方法である。
【０００２】
近年，多数のレジスタを一定数のグループに分割して，一つのウィンドウにおいて所定数のレジスタを使用し，ウィンドウを切替えると，前のウィンドウで使用した一部のレジスタを次のウィンドウのレジスタの一部として使用（オーバラップという）するレジスタウィンドウ方式が知られている。このレジスタウィンドウ方式では，一つのタスクによる動作中に関数の呼び出しによりウィンドウが順次切替えられ，復帰動作により逆方向に切替えられて一定個数のウィンドウを越えると，オーバフローやアンダーフローが生じて，それぞれ退避や復元の処理が行われる。またタスクが切替えられたり，割り込みが発生すると，全てのウィンドウレジスタを退避（保存）して新たなタスクまたは割り込み先のウィンドウレジスタとして使用可能にする。
【０００３】
このようなレジスタウィンドウを備えたマイクロプロセッサを，交換機等のリアルタイム処理を必要とするシステムにおいて利用することができるが，レジスタの退避動作や復元動作に時間がかかるため効率が悪くその改善が望まれている。
【０００４】
【従来の技術】
図１２は従来のレジスタウィンドウのレジスタの構成例である。
レジスタウィンドウを用いたアーキテクチャでは，ウィンドウと呼ばれるレジスタグループのセットに分割されたレジスタファイルモデルを使っている。図１２に示す構成例により説明すると，一つのウィンドウは，それぞれ８個のレジスタを１グループとして，レジスタ番号ｒ０〜ｒ７のグローバルレジスタ（ＧＬＯＢＡＬＳ），レジスタ番号ｒ８〜ｒ１５のアウトレジスタ（ＯＵＴＳ），レジスタ番号ｒ１６〜ｒ２３のローカルレジスタ（ＬＯＣＡＬＳ），レジスタ番号ｒ２４〜ｒ３１のインレジスタ（ＩＮＳ）の合計４グループで構成され，各ウィンドウに対し共通の汎用レジスタでありグローバルレジスタを除いた３つのグループは一つのウィンドウのレジスタセットを構成する。
【０００５】
図１３は各レジスタグループの説明図である。図に示すように，グローバルレジスタ（ｇｌｏｂａｌ：ｒ０〜ｒ７に対応）はｇ０〜ｇ７で表す各レジスタで構成され，アウトレジスタ（ｏｕｔ：ｒ８〜ｒ１５に対応）はｏ０〜ｏ５，ｓｐ（スタックポインタ：ｏ６），ｏ７（ｔｅｍｐ）の各レジスタで構成され，ローカルレジスタ（ｌｏｃａｌ：ｒ１６〜ｒ２３に対応）はｌ０〜ｌ７の各レジスタで構成され，インレジスタ（ｉｎ：ｒ２４〜ｒ３１）はｉ０〜ｉ５，ＦＰ（フレームポインタ：ｉ６），ｉ７（ｒｅｔｕｒｎ）の各レジスタで構成されている。
【０００６】
このレジスタウィンドウ方式によれば，８個のウィンドウが設けられ，処理を行うウィンドウはカレントウィンドウ（ＣＷ）であり，プロセッサステータスレジスタ（ＰＳＲ）の中の５ビットであるカレントウィンドウポインタ（ＣＷＰ）を設定することにより選択される。一つのウィンドウに割り当てられたレジスタセットの中で，グローバルレジスタは各ウィンドウに対し共通の汎用レジスタであり，ローカルレジスタはそのウィンドウに固有であるが，他のアウトレジスタ及びインレジスタの一方は隣接する片方のウィンドウと共用（オーバラップで使用）される。各ウィンドウ内でレジスタｒ８〜ｒ３１の２４個のレジスタは，プログラムによりレジスタ番号を用いてアクセスすることができる。
【０００７】
すなわち，図１２に示すように，カレントウィンドウポインタ（ＣＷＰ）により指示される現在のウィンドウにおける処理において，プロシジャ呼び出し（関数呼ぶコール）が発生すると，セーブ命令が実行され，次のウィンドウ（ＮｅｘｔＷｉｎｄｏｗ）に移行し，カレントウィンドウポインタは（ＣＷＰ−１）となる。この時，元のカレントウィンドウポインタ（ＣＷＰ）のアウトレジスタは，次のウィンドウ（ＣＷＰ−１）のインレジスタとなり，呼び出し元から呼び出し先へ渡すパラメータが格納される。なお，グローバルレジスタの内容も同様に呼び出し先へ渡される。上記の呼び出し元のアウトレジスタが呼び出し先のインレジスタとなることを，レジスタのオーバラップと称され，これによりプロシジャ呼び出し時のパラメータの受け渡しを効率的に行うことができる。
【０００８】
逆に，呼び出されたプロシジャが呼出し元へリターンする場合，結果を呼び出し元へ返す準備ができると，それらの結果をインレジスタに移して，リターンが発生すると，リストア（Ｒｅｓｔｏｒｅ）命令が実行され，ＣＷＰが増大されＣＷＰ＋１となり，前のウィンドウ（ＰｒｅｖｉｏｕｓＷｉｎｄｏｗ）に戻り，呼び出されたプロシジャのレジスタウィンドウの中のインレジスタは，オーバラップにより呼び出し元のプロシジャではアウトレジスタとなり，ここからコールにより実行された結果を参照することができる。
【０００９】
呼び出し元のプロシジャがアウトレジスタとグローバルレジスタの許容量以上のパラメータを渡さなければならない時は，追加パラメータはメモリ上のスタックを使って渡される。スタックの位置を表すスタックポインタ（ＳＰ）は，カレントウィンドウ内のアトウレジスタ（図１３のレジスタｒ１４）に保持される。
【００１０】
このように，カレントウィンドウポインタを１オフセットずらすと，レジスタは１６（１６個のレジスタ分）だけアドレッシングされる。従って，レジスタグループの共用により，８つのウィンドウを使用する場合，１６×８＋８（グローバルレジスタ）＝１３６のレジスタを使用する。
【００１１】
図１４に８個のウィンドウを使用する場合のウィンドウのシフトの概念図を示す。レジスタウィンドウを８個使用する時，０〜７の番号の各ウィンドウを使用することが可能である。この中の一つのウィンドウがカレントウィンドウポインタ（ＣＷＰ）により指定され，動作中にプロシジャ呼び出し（ＣＡＬＬ）が発生すると，ＳＡＶＥが実行され上記図１４に示すように時計方向にシフトし，更に順番にＳＡＶＥ動作が行われる。このように多数のレジスタファイルが存在しても，レジスタファイルは概念的に円形ファイルであるため，スタックが回転して，先頭の古いウィンドウが上書きされる可能性があるが，これを防止するために，ウィンドウ無効（Ｉｎｖａｌｉｄ）マスク（ＷＩＭ）レジスタを設けている。
【００１２】
ウィンドウ管理は，カレントウィンドウポインタ（ＣＷＰ）が，ＷＩＭレジスタでマークした値になると，オーバフロートラップを発生する。その場合，少なくとも最も古いウィンドウをメモリ退避（セーブ）する。退避したウィンドウは次の呼び出しにより使用される。なお，８個のウィンドウの内１つのウィンドウ（ＷＩＭで設定したウィンドウ７）はトラップ操作部（トラップハンドラ）により常時使用できるように空けられている。こうしてプログラムからは無限にウィンドウがあるように見える。また，逆にリターンによるリストア命令の動作が実行され，図１４の各ウィンドウが反時計回りで順番に移行すると，ＷＩＭレジスタの値になった場合アンダーフローが発生し，この時はメモリに退避していたレジスタファイルをウィンドウに復元する。
【００１３】
次に，オーバフローやアンダーフローによるトラップだけでなく，マルチタスク（またはマルチプロセス）のリアルタイムＯＳであるため，タスクを切替える時には，現在のタスクで使用している全てのレジスタウィンドウ（１乃至多数の各場合がある）を退避して，切替え先のタスクにより各ウィンドウを使用する。切替え先のタスクから元のタスクに戻る場合には，退避された全てのレジスタウィンドウの内容を復元（ＲＥＳＴＯＲＥ）する必要がある。更に，割込みが発生した場合にも，タスク切替と同様に全てのレジスタウィンドウを退避して割込み処理を行い，割込み処理の終了により元の処理に復元する処理を行う必要がある。従来の方式では，レジスタウィンドウ内容の退避，復元処理に要する時間が問題になる。
【００１４】
図１５はシステムコールのソフトウェア構造である。
従来のシステムコールはアプリケーションがＯＳの機能を利用する手段として提供される。この場合，その実行に要する時間は可能な限り少ないことが要求される。基本ＯＳ上でプログラムが動作している状態でソフトウェアを階層分けすると，図１５に示すように，アプリケーション９０，ＵＯＳ９１（ユーザ側のプログラムとリンクされＯＳ本体側とのインタフェースをとるＯＳ），ＫＯＳ９２（ＯＳ本体側のモジュールであり，ユーザ側のＵＯＳ９１からのシステムコールのインタフェースをとるＯＳ），システムコール本体処理を行う本体９３（カーネルとも呼ばれる）の４層からなっている。
【００１５】
アプリケーション９０は，システムコールを利用するもので，タスクや割込みハンドラに相当し，ＵＯＳ９１はユーザＯＳインタフェースであり，アプリケーションとＫＯＳ９２の間にあり，異なったロードモジュールなので呼出し番地を知ることができないためにトラップで呼び出されるシステムコールを，アプリケーション９０から関数形式で実行できる手段を提供する。これは，アプリケーション９０にリンクしてその１部として利用される。ＫＯＳ９２は，ＯＳでのシステムコール受付処理を行い，システムコールの種類を判定して実際に処理を行う本体（またはカーネル）９３を呼び出す。本体９３は，システムコールの実際の処理を行う部分である。
【００１６】
図１６は従来のシステムコールの処理の流れを示し，上記図１５に示す構造により実行される。これによれば，アプリケーション９０でシステムコールＡが発生すると，ＵＯＳ９１のシステムコールＡ処理部が動作し，コンパイラによりＳＡＶＥ命令が実行され，最初の（１）でレジスタウィンドウを１段進め，（２）でパラメータを設定し，（３）でシステムコール番号を設定し，（４）でトラップ（システムコール）が発生する。これによりＫＯＳ９２のシステムコール受付部が動作し，（１）〜（３）の処理が行われて，システムコールＡが呼び出され，本体９３のシステムコールＡ本体の処理が実行される。すなわち，（１）でレジスタウィンドウを１段進め，（２）でシステムコール処理を行い，（３）でリターンを行い，ＫＯＳ９２へ戻り，以下図１６に示すようにＫＯＳ９２，ＵＯＳ９１のそれぞれでリターンを行ってアプリケーション９０へ戻る。
【００１７】
この図１６に示すシステムコールの処理方法では，レジスタウィンドウという環状のレジスタにより，関数呼び出しのパラメータの受け渡しを効率的に行うことができ，関数呼出しに要する時間を少なくすることができるが，タスク切替時に保存，復元する処理が増えてしまい，タスク切替に要する時間が長くなる。また，ウィンドウオーバフローも起き易くなる。
【００１８】
次に上記の従来のレジスタウィンドウ方式では，割込みが発生した場合，その時の情報はカレントウィンドウのレジスタに格納されているが，その内容を保存したり，復帰する動作はソフトウェアにより処理していたが，割込みが繰り返されると，ソフトウェアへの負担が増大していた。
【００１９】
図１７は命令を書替えて走行する処理の従来例の説明図である。
図１７には，リアルタイムＯＳの処理システムにおいて，命令を書替えて走行する場合のユーザプログラムとＯＳの処理が示されている。
【００２０】
図１７において，ユーザプログラムが命令１，命令２である時に，ＯＳが命令２の退避と命令２をシステムコールＢに書替える処理を行う（この時，命令１は関係ない）。これにより命令２はシステムコールＢに書替えられているため，システムコールＢがＯＳにより実行され，終了後，退避されていた命令２が復元される。この処理の過程において，命令２をシステムコールＢに書き替えた後にシステムの障害等により，プログラムが正常に走行できない状態になると，元の命令を正常に実行できない可能性がある。
【００２１】
【発明が解決しようとする課題】
（１）リアルタイム処理装置においては，ＯＳ（オペレーティングシステム）の処理速度が重要であるが，上記したレジスタウィンドウ方式を使用したマイクロプロセッサ上で動作する従来のリアルタイムＯＳでは，関数呼び出しや復帰動作によりオーバフローやアンダーフローが発生するとメモリへの退避，復元の処理が頻繁に行われるため，オーバヘッドが増大して，実行処理速度を低下させるという問題があった。同様に，割り込み発生やタスク切替え時には，レジスタウィンドウの使用数は特別に制限せず，割込み発生時またはタスク切替時には単純に，使用中の全レジスタウィンドウをメモリに退避していた。このため，割込みやタスク切替による退避や復元の処理でオーバヘッドが増大していた。
【００２２】
（２）従来のレジスタウィンドウ方式の割込みの処理では，割込み発生時の退避と復帰の処理が複雑な処理を要し，定期起動の割込み等によるレジスタウィンドウの使用により時間を要していた。
【００２３】
（３）次に上記従来のシステムコール処理方式（図１５，図１６参照）によれば，システムコールにより，ＵＯＳにおいてレジスタウィンドウを新たに使用し，更に本体の処理でもレジスタウィンドウが１段進められる。その場合，ウィンドウ切替による保存・復元するウィンドウ数が増えて，タスク切替の処理時間が長くなり，オーバフローが起き易くなるという問題があった。
【００２４】
（４）また，従来の命令を書替えて走行するシステムの処理方法（図１７参照）では，命令を書替えた後のシステム障害等に対し元のプログラムへの復元ができない可能性があるという問題があった。
【００２５】
本発明は上記の従来の問題を解決するもので，交換機等のリアルタイム処理を必要とするシステムのレジスタウィンドウ方式を使用した処理装置において，レジスタウィンドウを効率良く使用して実行処理速度を向上することができるリアルタイム処理装置を提供することを目的とする。また，本発明は割込み発生時の復帰点や情報を退避したスタックの情報を効率的に管理することを目的とする。更に，アプリケーションからのシステムコール発生時の処理におけるレジスタウィンドウの切替数を削減して処理時間を短縮することを目的する。また，命令の書替え後に，前状態に戻す前に装置の異常等が発生しても命令を書替える必要性のある装置にプログラム復元を行うことができること等を目的とする。
【００２６】
【課題を解決するための手段】
図１は本発明の第１の原理説明図，図２は本発明の第２の原理説明図である。図１にはマイクロプロセッサ等のリアルタイム処理を行うレジスタウィンドウ方式の処理装置における，本発明によるレジスタウィンドウの制御方式の原理が示され，図１において，１は環状のレジスタウィンドウを表し，この例では＃０〜＃７の合計８個のウィンドウで構成され，各ウィンドウは従来例と同様にインレジスタ，ローカルレジスタ，アウトレジスタの３つのグループで構成され，各グループのウィンドウレジスタは８個のレジスタで構成され，一つのウィンドウに対し２４個のウィンドウレジスタが設けられ，インレジスタとアウトレジスタは，前，後のウィンドウに対しオーバラップする。また，グローバルレジスタは，全てのウィンドウにより共用される。
【００２７】
２ａはＯＳ側で使用するレジスタウィンドウの範囲，２ｂはアプリケーションプログラム（以下，単にアプリケーションという）側で使用するレジスタウィンドウの範囲を表し，３ａはＯＳ側の境界を越えたウィンドウ位置（番号）が設定された第１ウィンドウ無効マスク（第１ＷＩＭで表示），３ｂはアプリケーション側の境界を越えたウィンドウ位置（番号）が設定された第２ウィンドウ無効マスク（第２ＷＩＭで表示），４は現在のウィンドウ位置を表すカレントウィンドウポインタ（ＣＷＰで表示）である。
【００２８】
図２において，２０は割込み制御ブロック（ＩＣＢで表示：ＩｎｔｅｒｒｕｐｔＣｏｎｔｒｏｌＢｌｏｃｋ）であり，２１〜２７の各領域により構成され，２１は次のＩＣＢの位置を表す次のＩＣＢへのポインタを表し，２２はプロセッサ割込みレベルの情報，２３はカレントウィンドウ（ＣＷ）のローカルレジスタの一部，２４はカレントウィンドウのインレジスタの一部，２５はカレントウィンドウのアウトレジスタの一部，２６は外部割込み番号，２７はシステムコール作業域である。
【００２９】
本発明の第１の原理は環状のレジスタウィンドウを，アプリケーションプログラムが使用するウィンドウの範囲を制限するか，オペレーティングシステム（ＯＳ）が使用するウィンドウの範囲を制限するものである。また，アプリケーションプログラムまたはＯＳで使用するウィンドウの個数を一定にしてその範囲を固定化せずに，可変にするものである。また，本発明の第２の原理は割込み発生時に，割込み処理を起動する前に割込み復帰点や，スタックに関する情報を割込み処理により破壊されないように管理ブロックのキューを設けて高速なリアルタイム処理を行うものである。
【００３０】
【作用】
図１において，最初にＯＳ側で使用するレジスタウィンドウとアプリケーションプログラムで使用するレジスタウィンドウの位置をそれぞれ固定して制限する場合について説明する。
【００３１】
ＯＳ側で使用するレジスタウィンドウを＃０〜＃３とし，アプリケーションプログラム側で使用するレジスタウィンドウの範囲は＃４〜＃７とする。そのため，第１ウィンドウ無効マスク３ａに“０”を設定し，第２ウィンドウ無効マスク３ｂに“４”を設定する。なお，現在処理を行っているウィンドウの番号（ポインタ）は，カレントウィンドウポインタ４により示される。
【００３２】
ＯＳ側のウィンドウは，ＯＳ内での処理により＃３から＃０へ順次，切替えられる。但し，＃０は常に割込み処理（トラップック処理）のために残すため，カレントウィンドウポインタ４の値が第１ウィンドウ無効マスク３ａに設定された値（０）になるとオーバフローとなり，逆に復帰（ＲＥＴＵＲＮ）命令により，カレントウィンドウポインタ４の番号が増大して第２ウィンドウ無効マスク３ｂに設定された値（４）と一致するとアンダーフロー割込みを発生する。
【００３３】
アプリケーションプログラム側のウィンドウ２ｂについても，ＯＳ側と同様に，ウィンドウ＃７〜＃４の中の＃７〜＃５の３つのウィンドウを通常の動作で使用し，呼び出し（ＣＡＬＬ）命令が順番に発生して＃７，＃６，＃５とウィンドウが切替えられ，＃４になるとオーバフローを生じ，逆に復帰（ＲＥＴＵＲＮ）命令が実行され，カレントウィンドウポインタ４の番号が増加して第１ウィンドウ無効マスク３ａの値（＝０）と一致するとアンダーフロー割込みを発生する。
【００３４】
このような構成により，アプリケーション側では最大３つのウィンドウレジスタを使用（それ以上は，メモリに退避）することにより，オーバフロー発生時に退避するウィンドウ数を制限でき，ＯＳ側は常に一定数のウィンドウを確保することができる。
【００３５】
次に，ＯＳ側で使用するレジスタウィンドウとアプリケーション側で使用するレジスタウィンドウの個数を一定とするが，その範囲を可変にする場合について説明する。すなわち，最初に，第１ウィンドウ無効マスク３ａ，第２ウィンドウ無効マスク３ｂに対し，上記の固定の場合と同様にそれぞれ数値“０”，“４”を設定する。この後，ＯＳ側でオーバフローが発生した場合には，第１及び第２のウィンドウ無効マスク３ａ，３ｂを１つづつずらして設定する。すなわち，１つづれると，第１，第２のウィンドウ無効マスク３ａ，３ｂを“７”，“３”に設定する。
【００３６】
更に，ＯＳ側で使用するレジスタウィンドウとアプリケーション側で使用するレジスタウィンドウの中で，一方だけを制限して，他方は制限を加えないようにすることができる。ＯＳ側で使用するウィンドウに制限を加えない場合について説明する。この場合，アプリケーション側のウィンドウ数を３個として，第２ウィンドウ無効マスク３ｂに“４”を設定し，ＯＳ側のウィンドウを＃３から使用を開始して，３つの関数を呼び出し（ＣＡＬＬ）すると，オーバフロー（＃０に達する）が発生する。この時，アプリケーションの１つのウィンドウ（＃７）または，使用している全ウィンドウ（＃７から＃５までの範囲）をメモリ上のスタックへ退避する。このようにして，ＯＳ側のウィンドウ数に対しては制限を加えないようにする。同様の原理により，ＯＳ側のウィンドウ数を制限してアプリケーション側のウィンドウ数に制限を加えないようにすることができる。
【００３７】
次に図２の構成において，図示されない割込み管理部で割込み動作が開始すると，発生した割込み毎に，割込み制御ブロック（ＩＣＢ）２０のポインタを得て，新たな割込み制御ブロックを得てそれをＩＣＢキューに登録し，実行中の割込みを管理する。割込みがネストした時には，新しい割込みのＩＣＢを先頭に追加し，以前の割込みのＩＣＢはその後に接続される。
【００３８】
【実施例】
図３は本発明が実施される処理装置のブロック構成図である。
図３において，３０はレジスタウィンドウ制御によりリアルタイム処理を行う交換機等の処理装置（ＣＰＵ及びメモリ），３１はオペレーティングシステム部（ＯＳ部），３２はアプリケーション（ユーザ）プログラムを実行するアプリケーション部，３３はカレントウィンドウポインタ（ＣＷＰ）３３ａ，第１ウィンドウ無効マスク（ＷＩＭ）３３ｂ，第２ウィンドウ無効マスク３３ｃを格納する各レジスタ，３４は８個のウィンドウを構成するためのレジスタ群，３５はＩＣＢ（割込み制御ブロック），３６はメモリでありオーバフロー，アンダーフロー，割込み動作等によりレジスタウィンドウの内容やパラメータが退避されるスタックを備えるメモリである。
【００３９】
この構成において，ＯＳ側の処理において使用するウィンドウを上記図１に示すように，ＯＳ部とアプリケーション部により使用するウィンドウの領域を固定（第１ＷＩＭ及び第２ＷＩＭを固定）する場合の動作を説明する。この場合，ＯＳ側で使用するウィンドウのオーバフローを生じさせる第１ＷＩＭ３３ｂ（図３）に「０」，アプリケーション側で使用するウィンドウのオーバフローを生じさせる第２ＷＩＭ３３ｃ（図３）に「４」を設定する。
【００４０】
この場合，ＯＳ側の処理においてウィンドウを３，２，１と使用して，ウィンドウが０になると第１ＷＩＭ３３ｂの設定値と一致してオーバフロートラップが発生し，アプリケーション（ユーザ）側の処理において，ウィンドウを７，６，５と使用してウィンドウが第２ＷＩＭ３３ｃと一致してオーバフロートラップが発生する。
【００４１】
図４は範囲固定時のオーバフロー発生の処理フローを示す図である。
使用ウィンドウの２つの範囲を固定した時にオーバフローが発生すると，走行プログラムがＯＳ側かアプリケーション側かを判別し（図４のＳ１），ＯＳのプログラムである場合はウィンドウ３，２，１をメモリのスタック３６（図３）に保存して（図４のＳ２），ＣＷＰ３３ａ（図３）を「３」に戻し（図４のＳ３），元の処理に復帰する。また，アプリケーション（ユーザ）プログラムである場合は，ウィンドウ７，６，５を保存し（図４のＳ４），ＣＷＰ３３ａを「７」に戻して（同Ｓ５），元のアプリケーションに復帰する。
【００４２】
次にアンダーフローの場合は，処理フローは図示省略されているが基本的には図４に示すフローの逆となる。すなわち，アプリケーションプログラムの例で説明すると，アプリケーションプログラムが５，６，７と逆行（ＲＥＴＵＲＮ）して第２ＷＩＭ３３ｃの数値（０）と一致してアンダーフローが発生すると，ウィンドウ７，６，５をメモリのスタックから復元し，ＣＷＰ３３ａを「５」に戻す処理を行う。ＯＳ側の場合にも同様の処理によりウィンドウ３，２，１をメモリのスタックから復元し，ＣＷＰ３３ａを「１」に戻す。
【００４３】
次にＯＳ側の処理で使用するウィンドウの個数と，アプリケーション側の処理で使用するウィンドウの個数を一定とするが，使用するウィンドウの範囲を可変としてシフトする場合（第１ＷＩＭ及び第２ＷＩＭを固定しない場合）について説明する。
【００４４】
この場合も最初は上記図１と同様に，ＯＳ側で使用するウィンドウのオーバフローを生じさせる第１ＷＩＭ３３ｂに「０」，アプリケーション側で使用するウィンドウのオーバフローを生じさせる第２ＷＩＭ３３ｃに「４」を設定する。
【００４５】
この状態でＯＳ側の処理においてウィンドウを３，２，１と使用して，ウィンドウが０になると第１ＷＩＭ３３ｂの設定値と一致してオーバフロートラップが発生し，アプリケーション（ユーザ）側の処理において，ウィンドウを７，６，５と使用してウィンドウが第２ＷＩＭ３３ｃと一致してオーバフロートラップが発生する。
【００４６】
図５は範囲可変時のオーバフロー発生の処理フローを示す図である。
ＯＳ側とアプリケーション側のそれぞれで使用するウィンドウの範囲を可変にしてシフトする場合にオーバフローが発生すると，走行プログラムがＯＳ側かアプリケーション側かを判別し（図５のＳ１），ＯＳのプログラムである場合はウィンドウ３をメモリに保存し（同Ｓ２），第２ＷＩＭの内容を「３」に設定し（同Ｓ３），ウィンドウ７〜５のうち，使用しているものを１つづつずらす（同Ｓ４）。ウィンドウ７〜５を全て使用していた場合，ウィンドウ７を６，ウィンドウ６を５，ウィンドウ５を４へそれぞれ内容を移す。続いて，第１ＷＩＭの内容を「７」に設定する（同Ｓ５）。これにより，ＯＳのプログラムで使用可能なウィンドウが６〜４の範囲にシフトする。上記Ｓ１において，アプリケーションプログラムであることが判別されると，ウィンドウ７を保存し（図５のＳ６），第１ＷＩＭ３３ｂを「７」にする（同Ｓ７）。次にウィンドウ３〜１のうち，使用しているものを１つづつずらし（同Ｓ８），第２ＷＩＭを「３」に変更し（同Ｓ９），元のアプリケーションプログラムへ戻る。
【００４７】
上記の，実施例ではアプリケーション側及びＯＳ側の両方のウィンドウ数を一定に制限しているが，これらの一方のウィンドウ数だけを制限して，他方に制限を設けないように構成することができる。その場合，制限されない方が走行している時に，ＷＩＭの値と一致してウィンドウオーバフローになると，相手のウィンドウ内容をメモリに退避し，ＷＩＭの数を順次移動させていき，最終的に全ウィンドウを使用可能にする。この他に，制限されない方に切り替わった時点で，制限する方が使用していたウィンドウを全てセーブする方式がある。
【００４８】
次に本発明による割込み管理を説明する。
図６は割込み制御ブロック（ＩＣＢで表示）の構成図であり，上記図２に対応する。この割込み制御ブロック（ＩＣＢ）は，割込み処理を行う割込みハンドラを起動する前に，カレントウィンドウに設定されている割込み復帰点やスタックに関する情報をハンドラが破壊しないように保存するためにメモリに設けられる。また，割込みハンドラで関数呼び出しの階層が深い位置で割込みハンドラ終了（ＥＸＴ−ＩＮＨ：ＥｘｉｔＩＮｔａｒｒｕｐｔＨａｎｄｌｅｒ，割込みハンドラの最後に置かれるシステムコール）を実行した時にも割込み点に関する情報を容易に得られるようにするために，割込み管理ブロックＩＣＢが用意される。
【００４９】
図６において，２１，２２，２４〜２６は，それぞれ上記図２の同じ符号に対応し，図６の２３ａ，２３ｂは図２の２３に対応し，図６の２７ａ〜２７ｃは図２の２７に対応し，それぞれ４バイトが格納される。すなわち，２１は割込み処理中に次の割込みが発生した時に設けられた次のＩＣＢへのポインタが格納され，割込みがネスト（割込み動作中に更に割込みが発生した時）した時にキュー構成でＩＣＢが順次設けられ，キュー最後の場合はこのポインタにＮＵＬＬが設定される。２２は割込み起動制御の先頭でのＰＳＲ（プログラムステータスレジスタ）を保存し，実際に必要なのはＰＩＬ（プロセッサ割込みレベル）である。
【００５０】
次に図６の２３ａは，割込み起動制御の先頭でのカレントウィンドウのローカル１レジスタ（旧ＰＣ：元のプログラムカウンタ）の内容，２３ｂは割込み起動制御の先頭でのカレントウィンドウのローカル２レジスタ（旧ｎＰＣ：ｎのプログラムカウンタ）の内容，２４は割込み起動制御の先頭でのカレントウィンドウのイン６レジスタ（フレームポインタ）の内容，２５は割込み起動制御の先頭でのカレントウィンドウのアウト６レジスタ（スタッフポインタ）の内容，２６は発生した外部割込み番号，２７ａ〜２７ｃはシステムコール実行時に使用する作業域で，それぞれイン７レジスタ（リターンアドレス），スタックポインタ（ｓｐまたはＳＰ），フレームポインタ（ｆｐまたはＦＰ）が保存される。
【００５１】
次に上記図６に示す割込み制御ブロック（ＩＣＢ）を用いた割込み処理を説明する。図７は一般の割込み処理のフロー，図８は基本クロック割込み（または一定数以上のウィンドウを使っていない場合の割込み）処理のフローを示す。図７，図８のＡ．は割込みの処理，Ｂ．は割込みハンドラ終了（ＥＸＴ−ＩＮＨ）の処理である。
【００５２】
図７，図８のＡ．において，割込み処理がスタートすると，外部割込み番号を得て（各図のＳ１），ＩＣＢを確保して，ＩＣＢキューの先頭に入れる（同Ｓ２）。更に，カレントウィンドウのレジスタｒ１７，ｒ１８，ｒ３０（ｆｐ），ｒ１４（ｓｐ）をＩＣＢに保存し（同Ｓ３），ＰＳＲ（プログラムステータスレジスタ）をＩＣＢに設定する（同Ｓ４）。続いてＩＣＢキューに確保したＩＣＢを設定する（同Ｓ５）。この後，ソフトマスクがかかっていないか判別し（同Ｓ６），割込みのソフトマスクがかかっていると処理を終了するが，かかっていない場合（ｙｅｓの場合），図７と図８で処理が異なる。
【００５３】
一般の割込みの処理の図７の場合，使用中のレジスタウィンドウをスタックへ保存し（図７のＳ７），次に割込みのネスト（割込み処理中の新たな割込み）か判別し（同Ｓ８），ネストでない場合は割込み用スタックに切替える（同Ｓ９）。また割込みのネストである場合は，ハンドラを起動する（同Ｓ１０）。
【００５４】
図８の場合，一定周期で頻繁に発生する基本クロック割込みであるか，一定数以上のウィンドウを使ってないかを判別し（図８のＳ７），該当しない場合は使用中のレジスタウィンドウをスタックへ保存し（同Ｓ８）。基本クロック割込みであるか一定数以上のウィンドウを使っていない場合，次に割込みネストであるか判別する（図８のＳ９）。割込みのネストでない場合，割込み用スタックに切り替え（同Ｓ１０），割込みのネストである場合はハンドラを起動する（同Ｓ１１）。
【００５５】
このようにして，一定周期で頻繁に発生する基本クロック割込み等に対しては，レジスタウィンドウを保存することなく，ユーザ定義のハンドラにより処理を行うことができる。
【００５６】
図７，図８のＢ．に示す割込みハンドラ終了（ＥＸＴ−ＩＮＨ）の処理は，同じ内容であり，カレントＩＣＢから上記の図７，図８のＡ．の処理で保存したカレントウィンドウのレジスタｒ１７，ｒ１８，ｒ３０，ｒ３１，ｓｐを復元する（各図のＳ１）。次にカレントＩＣＢを開放し（同Ｓ２），待ちＩＣＢキューの先頭をはずして，カレントＩＣＢへ入れて（同Ｓ３），リターンを行う（同Ｓ４）。
【００５７】
図９は本発明によるシステムコール処理の流れ図である。この処理は，上記従来のシステムコール処理（上記図１６参照）において使用するレジスタウィンドウの数が多いことにより処理時間が長くなるという問題を解決するものである。
【００５８】
図９において，６０〜６３は上記図１５，図１６（従来例）の９０〜９３に対応し，６０はアプリケーション，６１はＵＯＳ，６２はＫＯＳ，６３はシステムコール本体処理を行う本体（カーネルとも呼ばれる）であり，６０ａ，６１ａ，６２ａ，６２ｂ，６３ａは６０〜６３の処理に対応するレジスタウィンドウの使用状態を表す。なお，図９のＵＯＳ６１，ＫＯＳ６２は，上記図２では図示省略されている。
【００５９】
ａ．アプリケーション６０は，通常の関数を呼ぶのと同じ方法で，カレントウィンドウのアウトレジスタ（図１２参照）へパラメータを設定してシステムコール（図９ではシステムコールＡで示す）を呼ぶ。図９の例では，この時のアプリケーション６０の動作時に，レジスタウィンドウの番号は６０ａに示すように「２」である。
【００６０】
ｂ．ＵＯＳ６１でのウィンドウ使用数の削減方法
ＵＯＳ６１でのウィンドウ使用数を削減するため，ＵＯＳ６１で新しいウィンドウを使用しないようにする。この場合，ＵＯＳ６１はアプリケーションとＯＳとのインタフェースをとることであり，具体的にはＫＯＳ６２を呼び出すトラップを発生させる。そのため，ここではアプリケーション６０からのパラメータをＫＯＳ６２が参照できるようにカレントウィンドウのアウトレジスタ（図１２のｒ８〜ｒ１５）に設定する。アプリケーション６０はＵＯＳ６１を呼び出す時にパラメータをアウトレジスタに設定しているので，ウィンドウを回転させないことでカレントウィンドウのアウトレジスタにパラメータが格納されたままになり，ＫＯＳ６２ではカレントウィンドウのインレジスタ（図１２のｒ２４〜ｒ３１）でパラメータを参照できる。
【００６１】
具体的には，ＵＯＳ６１はシステムコール毎の命令が集合して出来ており，それらの関数では最初にシステムコール毎に割り当てられているシステムコール番号をグローバルレジスタ（図１２のｒ０〜ｒ７）へ設定する（図９のＵＯＳ６１の（１）参照）。グローバルレジスタには，カレントウィンドウが変化しても同じレジスタを参照できるので，ＫＯＳ６２で同じ値を得ることができる。次に別のＬＭ（ロードモジュール）であるＫＯＳ６２へ実行を移すためにトラップを発生させる（図９のＵＯＳ６１の（２）参照）。
【００６２】
これにより，ウィンドウを回転させた時に行わなければならなかったインレジスタからアウトレジスタへパラメータをコピーする必要がなくなり，ＵＯＳの処理自体も少なく済むようになる。また，本発明ではＫＯＳ６２からＵＯＳ６１に戻り，アプリケーション６０へ戻る手順ではなく，ＫＯＳ６２から直接アプリケーションに戻るようにする。
ｃ．ＫＯＳ６２でのウィンドウ使用数の削減方法
本発明ではＫＯＳ６２で使用するウィンドウを一時的に使用しないようにしてから，ＯＳ本体６３（図９の例では含まれないパラメータチェック部を備える場合は，パラメータチェック部）を呼び出すことで見かけ上のウィンドウ使用数を削減する。
【００６３】
具体的には，このＫＯＳ６２では，全てのシステムコールに共通な処理を行っており，最初にカレントウィンドウのｓｐ（スタックポインタ），ｆｐ（フレームポインタ），インレジスタｉ［７］の各レジスタをＫＯＳ６２に設けられたＴＣＢ（タスク・コントロール・ブロック）に保存する。次にＵＯＳ６１で設定したグローバルレジスタからシステムコール番号を得て（図９のＫＯＳ６２の（１）），これをインデックスにしてシステムコール本来の機能を実現する関数のテーブル（以下，関数テーブルという）から，関数のアドレスを得る。次に，レジスタウィンドウを一段戻す（図９のＫＯＳ６２の（２））。
【００６４】
これにより，ＣＷＰ（カレントウィンドウポインタ）は＋１され，図９の例では，レジスタウィンドウ番号が「１」の状態６２ａからレジスタウィンドウ番号が「２」の状態６２ｂとなる。この後，得られたアドレスの関数をコールする（図９のＫＯＳ６２の（３））。
【００６５】
ｄ．ＯＳ本体６３
レジスタウィンドウを一段進める（ＣＷＰ−１）。図９の例では，ＯＳ本体６３の（１）の処理に対応し，レジスタウィンドウの番号「２」の状態６２ｂから「１」の状態６３ａになる。次に関数（システムコール本来の処理）の実行を終了すると，ＫＯＳ６２へ復帰（リターン）する。このリターン時に，レジスタウィンドウ番号が１つ戻されて，状態６２ｂとなる。
【００６６】
ＯＳ本体６３からのリターン動作により，ＫＯＳ６２では，上記のＴＣＢに保存しておいた，ｓｐ，ｆｐを復元する。さらに，ＴＣＢに保存したインレジスタのｉ［７］をカレントウィンドウのローカルレジスタに設定する。詳細にはｉ［７］をｌ［１］に，ｉ［７］＋４をｌ［２］に設定する。最後にＫＯＳ６２の復帰（リターン）命令により，ＫＯＳ６２の処理を終わる（図９のＫＯＳ６２の（４））。このリターン命令により，ＵＯＳ６１を経由せずに直接アプリケーション６０に戻る。
【００６７】
このようにして，従来のシステムコール発行時の処理（上記図２０参照）に比べて，使用するレジスタウィンドウの数を少なくなるため処理速度が向上する。次に，割込みの発生によりウィンドウ使用数が増大することによる処理速度が遅くなる。このような割込みが使用ウィンドウ数が多い場合には特に影響が大きくなる。これを改善する本発明の方法を図１０により説明する。
【００６８】
図１０は割込み処理の制御を行う処理フローである。
図１０のＡ．に示す割込み処理では，割込みが発生すると（図１０のＡ．のＳ１），現在使用中のウィンドウ数を調べて，これが一定数以上か否かによりその割込み処理を保留可か否かの判定をする（同Ｓ２）。もし，ウィンドウ数が一定数に達していない場合は，通常の割込み処理を行うが，ウィンドウ数が一定以上の場合は，保留中フラグをセットする（同Ｓ３）。続いて，ウィンドウ無効マスク（ＷＩＭ）をセットし（同Ｓ４），割込み処理を実行することなくリターンする。この場合，ＷＩＭとしては，使用ウィンドウ数が上記Ｓ２の保留可の判別を行う基準となる一定数以下の数に設定し（例えば，使用数「３」に設定し），その数になったらアンダーフローを発生させるためにセットされる。
【００６９】
その後，使用中のウィンドウ数が一定以下になるとアンダーフローが発生すると，アンダーフロー処理を開始する（図１０のＢ．のＳ１）。この場合，保留中フラグがセットされているか否か判定し（同Ｓ２），セットされていない場合は通常処理を行い，セットされている場合は，ウィンドウ無効マスク（ＷＩＭ）をリカバリーする（同Ｓ３）。このリカバリーは，上記図１０のＡ．のＳ２でセットする前状態に戻すことである。次に割込みハンドラを起動し（図１０のＢ．のＳ４），割込み処理を行ってリターンする。
【００７０】
このようにして，割込み処理に対し制限を加えて処理速度を向上することができる。
図１１は命令書替えを行う場合のプログラム復元を保証する処理フローである。この処理フローは，従来の命令を書替えて走行するシステムにおける処理（上記図１７参照）の問題を解決するものである。
【００７１】
命令を書替えて走行するようなシステムでは，例えば，システムコールの戻り値がエラーの場合にユーザプログラムを通常の後続の命令ではなく，終了処理ルーチン等の例外処理を実行させたい場合に，ＯＳにより命令の書替えを行う。
【００７２】
この場合，図１１のＡ．に示すようにＯＳは，命令２の１つ前の命令１と，命令２を図１１のＢ．に示す退避エリアに退避する（図１１のＡ．のＳ１）。この時，退避エリアには，「命令１」，「命令２」に続いて，「命令２の次命令へジャンプ」も格納される。次に，ユーザプログラムの命令１を「退避エリアジャンプ」の内容に書替え，更に命令２を「システムコールＢ」に書替える（図１１のＡ．のＳ２）。この後，ＯＳからの復帰によりユーザプログラムの命令２が実行されると，システムコールＢが実行され，その復帰命令は復元される。
【００７３】
このように，書替えを行うことにより，例えば，命令２をシステムコールＢに書替えた後にシステムの障害等により，システム再開等が発生してしまった場合でも，退避エリアに格納されている通常ルートが走行可能となり，レジスタウィンドウ方式によるリアルタイムＯＳの処理において，命令を書替えて走行する場合，プログラム復元の信頼性を高めることができる。
【００７４】
【発明の効果】
本発明によれば，以下に述べるような効果を奏することができる。
▲１▼レジスタウィンドウ方式のリアルタイムＯＳにおいて，レジスタウィンドウを効率良く使用して実行処理速度を向上することができる。
【００７５】
▲２▼割込み発生時の復帰点や情報を退避したスタックの情報を効率的に管理することが可能となる。
▲３▼システムコール発生時の処理におけるレジスタウィンドウの切替数を削減して処理時間を短縮することが可能となる。
【００７６】
▲４▼命令を書替えて実行するシステムにおいて，命令の書替え後に，前状態に戻す前に装置の異常等が発生しても命令を復元することを可能とし，信頼性を向上することができる。
【図面の簡単な説明】
【図１】本発明の第１の原理説明図である。
【図２】本発明の第２の原理説明図である。
【図３】本発明が実施される処理装置のブロック構成図である。
【図４】範囲固定時のオーバフロー発生の処理フローを示す図である。
【図５】範囲可変時のオーバフロー発生の処理フローを示す図である。
【図６】割込み制御ブロック（ＩＣＢ）の構成図である。
【図７】一般の割込み処理のフローを示す図である。
【図８】基本クロック割込み処理のフローを示す図である。
【図９】本発明によるシステムコール処理の流れ図である。
【図１０】割込み処理の制御を行う処理フローを示す図である。
【図１１】命令書替えを行う場合のプログラム復元を保証する処理フローを示す図である。
【図１２】従来のレジスタウィンドウのレジスタの構成例を示す図である。
【図１３】各レジスタグループの説明図である。
【図１４】８個のウィンドウを使用する場合のウィンドウのシフトの概念図である。
【図１５】システムコールのソフトウェア構造を示す図である。
【図１６】従来のシステムコールの処理の流れを示す図である。
【図１７】命令を書替えて走行する処理の従来例の説明図である。
【符号の説明】
１環状の８個のレジスタウィンドウ（＃０〜＃７）
２ａＯＳ側で使用するレジスタウィンドウの範囲
２ｂアプリケーション側で使用するレジスタウィンドウの範囲
３ａ第１ウィンドウ無効マスク（第１ＷＩＭ）
３ｂ第２ウィンドウ無効マスク（第２ＷＩＭ）
４カレントウィンドウポインタ（ＣＷＰ）[0001]
[Industrial applications]
The present invention relates to processing of a real-time OS in a microprocessor having a register window. Method It is.
[0002]
In recent years, a large number of registers are divided into a fixed number of groups, a predetermined number of registers are used in one window, and when the windows are switched, some of the registers used in the previous window are replaced with the registers in the next window. A register window system used as a unit (called an overlap) is known. In this register window method, windows are sequentially switched by a function call during operation by one task, and are switched in the reverse direction by a return operation. When a certain number of windows are exceeded, overflow or underflow occurs, and each is saved. And restoration processing is performed. When a task is switched or an interrupt occurs, all window registers are saved (saved) so that they can be used as new task or interrupt destination window registers.
[0003]
A microprocessor having such a register window can be used in a system requiring real-time processing, such as an exchange, but the saving and restoring operations of the register take time, so the efficiency is low and improvement is desired. ing.
[0004]
[Prior art]
FIG. 12 shows a configuration example of a register of a conventional register window.
An architecture using a register window uses a register file model divided into a set of register groups called a window. To explain using the configuration example shown in FIG. 12, one window is composed of eight registers as one group, global registers (GLOBALS) with register numbers r0 to r7, out registers (OUTS) with register numbers r8 to r15, and registers. It is composed of a total of 4 groups of local registers (LOCALS) of numbers r16 to r23 and in-registers (INS) of register numbers r24 to r31. The three groups excluding global registers are common general-purpose registers for each window. Configure a register set for one window.
[0005]
FIG. 13 is an explanatory diagram of each register group. As shown in the figure, the global register (global: corresponding to r0 to r7) is composed of registers represented by g0 to g7, and the out register (out: corresponding to r8 to r15) is o0 to o5, sp (stack pointer: o6) and o7 (temp), the local register (local: corresponding to r16 to r23) is configured by each of registers 10 to 17, and the in-register (in: r24 to r31) is i0 to i5. FP (frame pointer: i6) and i7 (return) registers.
[0006]
According to this register window system, eight windows are provided, the window for processing is the current window (CW), and the current window pointer (CWP), which is 5 bits in the processor status register (PSR), is set. To be selected. In the register set assigned to one window, the global register is a general-purpose register common to each window, the local register is specific to that window, but one of the other out registers and in registers is adjacent Shared with one window (used for overlap). Within each window, the 24 registers r8 to r31 can be accessed by the program using the register numbers.
[0007]
That is, as shown in FIG. 12, in the processing in the current window designated by the current window pointer (CWP), when a procedure call (call to call a function) occurs, a save instruction is executed, and the next window (Next Window) is executed. And the current window pointer becomes (CWP-1). At this time, the out register of the original current window pointer (CWP) becomes the in register of the next window (CWP-1), and stores parameters to be passed from the caller to the callee. The contents of the global register are also passed to the call destination. The fact that the out-register of the caller becomes the in-register of the callee is referred to as register overlap, whereby the parameters can be efficiently transferred at the time of calling the procedure.
[0008]
Conversely, when the called procedure returns to the caller, when the result is ready to be returned to the caller, the result is moved to the in-register, and when a return occurs, a restore (Restore) instruction is executed. CWP is increased to CWP + 1, the window returns to the previous window (Previous Window), the in-register in the register window of the called procedure becomes an out-register in the calling procedure due to the overlap, and the call is executed from here. You can see the result.
[0009]
If the calling procedure must pass more parameters than the out and global registers allow, additional parameters are passed using the in-memory stack. A stack pointer (SP) indicating the position of the stack is held in an atto register (register r14 in FIG. 13) in the current window.
[0010]
As described above, when the current window pointer is shifted by one offset, the registers are addressed by 16 (for 16 registers). Therefore, when eight windows are used by sharing a register group, 16 × 8 + 8 (global registers) = 136 registers are used.
[0011]
FIG. 14 shows a conceptual diagram of a window shift when eight windows are used. When eight register windows are used, it is possible to use windows of numbers 0 to 7. One of these windows is designated by the current window pointer (CWP), and if a procedure call (CALL) occurs during operation, SAVE is executed and shifted clockwise as shown in FIG. The operation is performed. Even if there are many register files in this way, the register file is conceptually a circular file, so the stack may rotate and the old window at the top may be overwritten. To prevent this, Is provided with a window invalid (Invalid) mask (WIM) register.
[0012]
Window management generates an overflow trap when the current window pointer (CWP) reaches the value marked in the WIM register. In that case, at least the oldest window is saved in memory. The saved window is used by the next call. One of the eight windows (the window 7 set by the WIM) is opened by the trap operation unit (trap handler) so that it can be always used. Thus, the program appears to have infinite windows. On the contrary, when the operation of the restore instruction by return is executed and each window in FIG. 14 sequentially moves counterclockwise, an underflow occurs when the value of the WIM register is reached, and at this time, the data is saved to the memory. Restores the previous register file to the window.
[0013]
Next, since it is a multitask (or multiprocess) real-time OS as well as a trap due to overflow or underflow, when switching tasks, all register windows (one to many Is saved, and each window is used by the task at the switching destination. When returning from the task at the switching destination to the original task, it is necessary to restore (RESTORE) the contents of all the saved register windows. Further, even when an interrupt occurs, it is necessary to perform an interrupt process by saving all register windows as in the case of the task switching, and to perform a process of restoring the original process upon completion of the interrupt process. In the conventional method, the time required to save and restore the contents of the register window becomes a problem.
[0014]
FIG. 15 shows the software structure of the system call.
Conventional system calls are provided as means for an application to use the functions of the OS. In this case, the time required for the execution is required to be as short as possible. When the software is divided into layers while the program is operating on the basic OS, as shown in FIG. 15, the application 90, the UOS 91 (the OS that is linked to the program on the user side and takes the interface with the OS itself), the KOS 92 ( It is a module on the OS main body side, and is composed of four layers of a main body 93 (also called a kernel) that performs system call main body processing, which is an OS that interfaces with a system call from the UOS 91 on the user side.
[0015]
The application 90 uses a system call and corresponds to a task or an interrupt handler. The UOS 91 is a user OS interface, which is located between the application and the KOS 92 and has different load modules. A means is provided for executing a system call called by a trap from the application 90 in a function format. This is linked to the application 90 and used as a part thereof. The KOS 92 performs a system call acceptance process in the OS, calls a main body (or kernel) 93 that determines the type of the system call and actually performs the process. The main body 93 is a part that performs the actual processing of the system call.
[0016]
FIG. 16 shows a processing flow of a conventional system call, which is executed by the structure shown in FIG. According to this, when the system call A occurs in the application 90, the system call A processing unit of the UOS 91 operates, the SAVE instruction is executed by the compiler, and the register window is advanced by one step at the first (1), and (2) The parameter is set with, the system call number is set with (3), and a trap (system call) is generated with (4). As a result, the system call receiving unit of the KOS 92 operates, and the processing of (1) to (3) is performed, the system call A is called, and the processing of the system call A of the main body 93 is executed. That is, the register window is advanced by one step in (1), the system call processing is performed in (2), the return is performed in (3), and the process returns to the KOS 92. Thereafter, the return is performed in each of the KOS 92 and the UOS 91 as shown in FIG. Go back to application 90.
[0017]
In the processing method of the system call shown in FIG. 16, the parameters of the function call can be efficiently transferred and the time required for the function call can be reduced by the circular register called the register window. Sometimes, saving and restoring processes increase, and the time required for task switching becomes longer. Also, a window overflow is likely to occur.
[0018]
Next, in the conventional register window method described above, when an interrupt occurs, the information at that time is stored in the register of the current window, but the operation of saving and restoring the contents was processed by software. When interrupts are repeated, the load on software increases.
[0019]
FIG. 17 is an explanatory diagram of a conventional example of a process of traveling by rewriting a command.
FIG. 17 shows the processing of the user program and the OS when the vehicle travels while rewriting instructions in the processing system of the real-time OS.
[0020]
In FIG. 17, when the user program is the instruction 1 and the instruction 2, the OS performs a process of saving the instruction 2 and rewriting the instruction 2 to the system call B (at this time, the instruction 1 does not matter). As a result, since the instruction 2 has been rewritten to the system call B, the system call B is executed by the OS, and after completion, the saved instruction 2 is restored. In the course of this processing, if the program cannot run normally due to a system failure or the like after rewriting the instruction 2 to the system call B, the original instruction may not be able to be executed normally.
[0021]
[Problems to be solved by the invention]
(1) In a real-time processing device, the processing speed of an OS (operating system) is important. However, in a conventional real-time OS operating on a microprocessor using the above-described register window method, overflow occurs due to a function call or a return operation. When an underflow occurs, the process of saving and restoring to the memory is frequently performed, so that there is a problem that the overhead increases and the execution processing speed decreases. Similarly, when an interrupt or task switching occurs, the number of register windows used is not particularly limited, and when an interrupt or task switching occurs, all register windows in use are simply saved to memory. For this reason, overhead has been increased in the processing of saving and restoring due to interrupts and task switching.
[0022]
(2) In conventional register window interrupt processing, saving and restoring processing when an interrupt occurs requires complicated processing, and time is required by using a register window due to a periodic start interrupt or the like.
[0023]
(3) Next, according to the above-described conventional system call processing method (see FIGS. 15 and 16), a register window is newly used in the UOS by a system call, and the register window is advanced by one step in the processing of the main unit. . In this case, there is a problem that the number of windows to be saved / restored by the window switching increases, the processing time of the task switching becomes longer, and an overflow easily occurs.
[0024]
(4) Also, the conventional processing method of a system that runs by rewriting instructions (see FIG. 17) has a problem in that it may not be possible to restore the original program due to a system failure or the like after rewriting instructions. there were.
[0025]
An object of the present invention is to solve the above-mentioned conventional problems and to improve the execution processing speed by efficiently using a register window in a processing device using a register window system of a system requiring real-time processing such as an exchange. It is an object of the present invention to provide a real-time processing device that can perform the processing. Another object of the present invention is to efficiently manage information on a stack at which a return point or information is saved when an interrupt occurs. It is another object of the present invention to reduce the number of register window switches in the processing when a system call from an application occurs, thereby shortening the processing time. Another object of the present invention is to be able to restore a program to a device that needs to rewrite an instruction even if an error occurs in the device before returning to the previous state after rewriting the instruction.
[0026]
[Means for Solving the Problems]
FIG. 1 is a diagram illustrating a first principle of the present invention, and FIG. 2 is a diagram illustrating a second principle of the present invention. FIG. 1 shows the principle of a register window control method according to the present invention in a register window type processing device such as a microprocessor which performs real-time processing. In FIG. 1, reference numeral 1 denotes an annular register window. Each of the windows is composed of three groups of an in-register, a local register, and an out-register, as in the conventional example. The window register of each group is composed of eight registers. In this configuration, 24 window registers are provided for one window, and the in-register and the out-register overlap the previous and subsequent windows. The global register is shared by all windows.
[0027]
2a indicates the range of the register window used on the OS side, 2b indicates the range of the register window used on the application program (hereinafter simply referred to as application) side, and 3a indicates the window position (number) beyond the boundary on the OS side. The first window invalidation mask (displayed in the first WIM), 3b is the second window invalidation mask (displayed in the second WIM) in which the window position (number) beyond the application-side boundary is set, and 4 is the current window position Is a current window pointer (represented by CWP).
[0028]
In FIG. 2, reference numeral 20 denotes an interrupt control block (indicated by ICB: Interrupt Control Block), which is constituted by areas 21 to 27, 21 denotes a pointer to the next ICB indicating the position of the next ICB, and 22 Is the information of the processor interrupt level, 23 is a part of the local register of the current window (CW), 24 is a part of the in register of the current window, 25 is a part of the out register of the current window, 26 is an external interrupt number, 27 Is a system call work area.
[0029]
A first principle of the present invention is to limit the range of a circular register window to a window used by an application program or to limit the range of a window used by an operating system (OS). In addition, the number of windows used in the application program or the OS is made constant, and the range is not fixed but variable. Further, the second principle of the present invention is that, when an interrupt occurs, a queue of a management block is provided before starting the interrupt processing so as to prevent the information related to the stack and the stack from being destroyed by the interrupt processing, thereby performing high-speed real-time processing. Things.
[0030]
[Action]
In FIG. 1, a case will be described in which the positions of the register window used on the OS side and the register window used in the application program are fixed and restricted.
[0031]
The register windows used on the OS side are # 0 to # 3, and the range of the register windows used on the application program side is # 4 to # 7. Therefore, "0" is set in the first window invalidation mask 3a and "4" is set in the second window invalidation mask 3b. The number (pointer) of the window currently being processed is indicated by the current window pointer 4.
[0032]
The window on the OS side is sequentially switched from # 3 to # 0 by processing in the OS. However, since # 0 is always retained for interrupt processing (traplock processing), an overflow occurs when the value of the current window pointer 4 reaches the value (0) set in the first window invalidation mask 3a, and conversely, returns (RETURN) When an instruction increases the number of the current window pointer 4 and matches the value (4) set in the second window invalidation mask 3b, an underflow interrupt is generated.
[0033]
Similarly to the OS side, the application program side window 2b uses three windows # 7 to # 5 among the windows # 7 to # 4 in a normal operation, and a call (CALL) instruction is sequentially generated. Then, the windows are switched to # 7, # 6, and # 5. When the window becomes # 4, an overflow occurs. On the contrary, the return (RETURN) instruction is executed, and the number of the current window pointer 4 is increased to invalidate the first window invalid mask. When the value matches the value of 3a (= 0), an underflow interrupt is generated.
[0034]
With this configuration, the application can use a maximum of three window registers (more than three are saved in memory) to limit the number of windows saved when an overflow occurs, and the OS always secures a fixed number of windows can do.
[0035]
Next, the case where the number of register windows used on the OS side and the number of register windows used on the application side are fixed, and the range thereof is made variable will be described. That is, first, numerical values “0” and “4” are set for the first window invalid mask 3a and the second window invalid mask 3b, respectively, as in the above-mentioned fixed case. Thereafter, when an overflow occurs on the OS side, the first and second window invalid masks 3a and 3b are shifted and set one by one. That is, if one is missed, the first and second window invalid masks 3a and 3b are set to "7" and "3".
[0036]
Furthermore, only one of the register window used on the OS side and the register window used on the application side can be restricted, and the other can be unrestricted. A case in which a window used on the OS is not restricted will be described. In this case, when the number of windows on the application side is set to 3, the second window invalid mask 3b is set to “4”, the window on the OS side is started to be used from # 3, and three functions are called (CALL). , Overflow (reach # 0) occurs. At this time, one window (# 7) of the application or all the windows used (range from # 7 to # 5) are saved to the stack on the memory. In this way, no limit is imposed on the number of windows on the OS side. By the same principle, it is possible to limit the number of windows on the OS side and not to limit the number of windows on the application side.
[0037]
Next, in the configuration of FIG. 2, when an interrupt operation is started by an interrupt management unit (not shown), a pointer of an interrupt control block (ICB) 20 is obtained for each generated interrupt, a new interrupt control block is obtained, and the ICB is obtained. Registers in a queue and manages interrupts being executed. When an interrupt is nested, the ICB of the new interrupt is added to the head, and the ICB of the previous interrupt is connected thereafter.
[0038]
【Example】
FIG. 3 is a block diagram of a processing apparatus in which the present invention is implemented.
In FIG. 3, reference numeral 30 denotes a processing device (CPU and memory) such as an exchange which performs real-time processing by register window control, 31 denotes an operating system unit (OS unit), 32 denotes an application unit that executes an application (user) program, and 33 denotes Registers for storing a current window pointer (CWP) 33a, a first window invalid mask (WIM) 33b, and a second window invalid mask 33c, a register group for configuring eight windows, and an ICB (interrupt control) Block), 36 is a memory having a stack in which the contents and parameters of the register window are saved by overflow, underflow, interrupt operation and the like.
[0039]
In this configuration, an operation in a case where the window used in the processing on the OS side is fixed (the first WIM and the second WIM are fixed) as shown in FIG. . In this case, "0" is set to the first WIM 33b (FIG. 3) that causes the overflow of the window used on the OS side, and "4" is set to the second WIM 33c (FIG. 3) that causes the overflow of the window used on the application side.
[0040]
In this case, the windows are used as 3, 2, and 1 in the processing on the OS side, and when the window becomes 0, it coincides with the set value of the first WIM 33b, and an overflow trap is generated. Are used as 7, 6, 5 so that the window matches the second WIM 33c and an overflow trap occurs.
[0041]
FIG. 4 is a diagram showing a processing flow of the occurrence of an overflow when the range is fixed.
If an overflow occurs when the two ranges of the used windows are fixed, it is determined whether the running program is the OS side or the application side (S1 in FIG. 4). If the running program is the OS program, the windows 3, 2, and 1 are stored in the memory. The data is stored in the stack 36 (FIG. 3) (S2 in FIG. 4), the CWP 33a (FIG. 3) is returned to "3" (S3 in FIG. 4), and the process returns to the original processing. If the program is an application (user) program, the windows 7, 6, and 5 are saved (S4 in FIG. 4), the CWP 33a is returned to "7" (S5), and the original application is restored.
[0042]
Next, in the case of an underflow, the processing flow is omitted from illustration, but is basically the reverse of the flow shown in FIG. That is, in the example of the application program, when the application program goes backward (RETURN) to 5, 6, and 7 and matches the numerical value (0) of the second WIM 33c and an underflow occurs, the windows 7, 6, and 5 are stored in the memory. From the stack and returns the CWP 33a to “5”. In the case of the OS, the windows 3, 2, and 1 are restored from the memory stack by the same processing, and the CWP 33a is returned to "1".
[0043]
Next, the number of windows to be used in the processing on the OS side and the number of windows to be used in the processing on the application side are fixed, but the range of the window to be used is variable and shifted (the first WIM and the second WIM are not fixed). Case) will be described.
[0044]
In this case as well, first, as in FIG. 1, "0" is set to the first WIM 33b causing an overflow of the window used on the OS side, and "4" is set to the second WIM 33c causing the overflow of the window used on the application side. .
[0045]
In this state, the windows are used as 3, 2, and 1 in the processing on the OS side, and when the window becomes 0, an overflow trap occurs in accordance with the setting value of the first WIM 33b, and the processing on the application (user) side Are used as 7, 6, 5 so that the window matches the second WIM 33c and an overflow trap occurs.
[0046]
FIG. 5 is a diagram showing a processing flow of occurrence of overflow when the range is changed.
When an overflow occurs when shifting is performed by changing the range of the window used on each of the OS side and the application side, it is determined whether the running program is the OS side or the application side (S1 in FIG. 5), and the running program is the OS program. In this case, the window 3 is stored in the memory (S2), the content of the second WIM is set to "3" (S3), and the windows 7 to 5 are shifted one by one (S4). ). If all windows 7 to 5 have been used, the contents are moved to window 6, window 6, and window 5, respectively. Subsequently, the content of the first WIM is set to “7” (S5). As a result, the window usable in the OS program is shifted to the range of 6 to 4. If it is determined in S1 that the application program is the application program, the window 7 is saved (S6 in FIG. 5), and the first WIM 33b is set to "7" (S7). Next, one of the windows 3 to 1 is shifted one by one (S8), the second WIM is changed to “3” (S9), and the process returns to the original application program.
[0047]
In the above-described embodiment, the number of windows on both the application side and the OS side is limited to a fixed number. However, it is possible to limit only the number of one of these windows and not to limit the other. . In this case, when the unlimited one is running and the window overflows due to coincidence with the value of WIM, the contents of the window of the other party are saved in the memory, the number of WIMs is sequentially moved, and finally all the windows are moved. Enable In addition, there is a method of saving all windows used by the restricting person when switching to the unrestricted one.
[0048]
Next, interrupt management according to the present invention will be described.
FIG. 6 is a configuration diagram of an interrupt control block (indicated by ICB), and corresponds to FIG. 2 described above. The interrupt control block (ICB) is provided in a memory for saving information on an interrupt return point and a stack set in the current window so as not to destroy the handler before activating an interrupt handler that performs interrupt processing. . Also, when the interrupt handler executes an interrupt handler termination (EXT-INH: Exit Interrupt Handler, a system call placed at the end of the interrupt handler) at a position deep in the function call hierarchy, information on the interrupt point can be easily obtained. For this purpose, an interrupt management block ICB is prepared.
[0049]
6, 21, 22, 24 to 26 correspond to the same reference numerals in FIG. 2, 23a and 23b in FIG. 6 correspond to 23 in FIG. 2, and 27a to 27c in FIG. , And 4 bytes are stored for each. That is, the pointer 21 to the next ICB provided when the next interrupt occurs during the interrupt processing is stored. When the interrupt is nested (when another interrupt occurs during the interrupt operation), the ICB is stored in a queue configuration. The pointers are sequentially provided, and NULL is set in this pointer at the end of the queue. Reference numeral 22 stores a PSR (program status register) at the head of the interrupt activation control, and what is actually required is a PIL (processor interrupt level).
[0050]
Next, 23a in FIG. 6 shows the contents of the local 1 register (old PC: original program counter) of the current window at the beginning of the interrupt activation control, and 23b shows the local 2 registers (old) of the current window at the beginning of the interrupt activation control. nPC: The content of the n program counter), 24 is the content of the in 6 register (frame pointer) of the current window at the beginning of the interrupt activation control, and 25 is the Out 6 register (stuff pointer) of the current window at the beginning of the interrupt activation control ), 26 is an external interrupt number that has occurred, and 27a to 27c are work areas used when executing a system call, each of which is an in7 register (return address), a stack pointer (sp or SP), and a frame pointer (fp or FP). Is saved.
[0051]
Next, an interrupt process using the interrupt control block (ICB) shown in FIG. 6 will be described. FIG. 7 shows a flow of a general interrupt process, and FIG. 8 shows a flow of a basic clock interrupt (or an interrupt when a certain number or more of windows are not used). 7 and FIG. Is the processing of an interrupt, Is the processing of the end of the interrupt handler (EXT-INH).
[0052]
7 and FIG. When the interrupt process starts, the external interrupt number is obtained (S1 in each drawing), the ICB is secured, and the ICB is placed at the head of the ICB queue (S2). Further, the registers r17, r18, r30 (fp), and r14 (sp) of the current window are stored in the ICB (S3), and the PSR (program status register) is set in the ICB (S4). Subsequently, the ICB secured in the ICB queue is set (S5). Thereafter, it is determined whether or not the soft mask is applied (S6). If the soft mask for the interrupt is applied, the processing is terminated. If not (in the case of yes), the processing is performed in FIG. 7 and FIG. different.
[0053]
In the case of the general interrupt processing shown in FIG. 7, the register window in use is saved on the stack (S7 in FIG. 7), and then it is determined whether or not the interrupt is nested (new interrupt during interrupt processing) (S8). If it is not a nest, the stack is switched to the interrupt stack (S9). If the nest is an interrupt, the handler is activated (S10).
[0054]
In the case of FIG. 8, it is determined whether the interrupt is a basic clock interrupt that frequently occurs in a fixed cycle or whether a certain number or more of windows are used (S7 in FIG. 8). (S8). If it is a basic clock interrupt or if no more than a certain number of windows are used, then it is determined whether it is an interrupt nest (S9 in FIG. 8). If the interrupt is not nested, the stack is switched to the interrupt stack (S10). If the interrupt is nested, the handler is activated (S11).
[0055]
In this way, a basic clock interrupt that frequently occurs at a fixed cycle can be processed by a user-defined handler without saving the register window.
[0056]
7 and 8. The processing of the end of the interrupt handler (EXT-INH) shown in FIG. The registers r17, r18, r30, r31, and sp of the current window saved in the processing of (1) are restored (S1 in each drawing). Next, the current ICB is released (S2), the head of the waiting ICB queue is removed, the current ICB is placed in the current ICB (S3), and the return is performed (S4).
[0057]
FIG. 9 is a flowchart of a system call process according to the present invention. This processing solves the problem that the processing time becomes longer due to the large number of register windows used in the conventional system call processing (see FIG. 16).
[0058]
In FIG. 9, 60 to 63 correspond to 90 to 93 in FIGS. 15 and 16 (conventional example), 60 is an application, 61 is a UOS, 62 is a KOS, and 63 is a main body that performs system call main processing (both kernels). 60a, 61a, 62a, 62b, and 63a indicate the use states of the register windows corresponding to the processes of 60 to 63. The UOS 61 and KOS 62 in FIG. 9 are not shown in FIG.
[0059]
a. The application 60 sets a parameter in the out register (see FIG. 12) of the current window and calls a system call (indicated by a system call A in FIG. 9) in the same manner as calling a normal function. In the example of FIG. 9, when the application 60 operates at this time, the number of the register window is “2” as shown by 60a.
[0060]
b. How to reduce the number of windows used in UOS61
In order to reduce the number of windows used in the UOS 61, a new window is not used in the UOS 61. In this case, the UOS 61 acts as an interface between the application and the OS, and specifically generates a trap for calling the KOS 62. Therefore, here, the parameters from the application 60 are set in the out registers (r8 to r15 in FIG. 12) of the current window so that the KOS 62 can refer to them. Since the application 60 sets the parameters in the out register when calling the UOS 61, the parameters are kept stored in the out registers of the current window by not rotating the window. In the KOS 62, the in registers of the current window (FIG. Parameters can be referred to in (r24 to r31).
[0061]
Specifically, the UOS 61 is composed of a set of instructions for each system call, and in these functions, the system call number initially assigned for each system call is set in the global register (r0 to r7 in FIG. 12). (See (1) of UOS61 in FIG. 9). Since the same register can be referred to the global register even when the current window changes, the same value can be obtained by the KOS 62. Next, a trap is generated to transfer the execution to another KOS 62, which is another LM (load module) (see (2) of UOS 61 in FIG. 9).
[0062]
This eliminates the need to copy the parameters from the in-register to the out-register, which had to be performed when rotating the window, and reduces the UOS processing itself. Further, in the present invention, instead of returning from the KOS 62 to the UOS 61 and returning to the application 60, the KOS 62 directly returns to the application.
c. How to reduce the number of windows used in KOS62
In the present invention, the window used in the KOS 62 is temporarily not used, and then the OS main body 63 (or a parameter check unit when a parameter check unit not included in the example of FIG. 9 is provided) is called by calling the OS main unit 63. Reduce window usage.
[0063]
Specifically, the KOS 62 performs processing common to all system calls. First, the sp (stack pointer), fp (frame pointer), and in-register i [7] registers of the current window are stored in the KOS 62 In the TCB (task control block) provided in the. Next, a system call number is obtained from the global register set by the UOS 61 ((1) of KOS 62 in FIG. 9), and this is used as an index to obtain a function table realizing the original function of the system call (hereinafter referred to as a function table). , Get the address of the function. Next, the register window is returned by one level ((2) of KOS62 in FIG. 9).
[0064]
As a result, the CWP (current window pointer) is incremented by 1, and in the example of FIG. 9, the state changes from the state 62a with the register window number “1” to the state 62b with the register window number “2”. Thereafter, the function of the obtained address is called ((3) of KOS62 in FIG. 9).
[0065]
d. OS body 63
The register window is advanced by one (CWP-1). In the example of FIG. 9, corresponding to the processing of (1) of the OS main body 63, the state 62b of the register window number "2" is changed to the state 63a of "1". Next, when the execution of the function (the original processing of the system call) is completed, the processing returns to the KOS 62 (return). At the time of this return, the register window number is returned by one, and the state becomes the state 62b.
[0066]
By the return operation from the OS main body 63, the KOS 62 restores sp and fp saved in the TCB. Further, i [7] of the in-register stored in the TCB is set as a local register of the current window. Specifically, i [7] is set to l [1], and i [7] +4 is set to l [2]. Finally, the process of the KOS 62 is terminated by a return instruction of the KOS 62 ((4) of the KOS 62 in FIG. 9). By this return command, the program returns directly to the application 60 without passing through the UOS 61.
[0067]
In this manner, the number of register windows to be used is reduced and the processing speed is improved as compared with the conventional processing at the time of issuing a system call (see FIG. 20). Next, the processing speed is reduced due to an increase in the number of used windows due to occurrence of an interrupt. Such an interrupt has a particularly large effect when the number of used windows is large. The method of the present invention for improving this will be described with reference to FIG.
[0068]
FIG. 10 is a processing flow for controlling the interrupt processing.
FIG. In the interrupt processing shown in (1), when an interrupt occurs (S1 of A in FIG. 10), the number of windows currently in use is checked, and whether or not the interrupt processing can be suspended is determined based on whether or not the number is a certain number or more. (S2). If the number of windows has not reached the predetermined number, normal interrupt processing is performed. If the number of windows is equal to or more than the predetermined number, a pending flag is set (S3). Subsequently, the window invalid mask (WIM) is set (S4), and the process returns without executing the interrupt processing. In this case, as the WIM, the number of used windows is set to a number equal to or less than a certain number serving as a reference for determining whether or not the hold is possible in S2 (for example, the number of used windows is set to “3”). Set to generate a flow.
[0069]
Thereafter, when an underflow occurs when the number of windows in use falls below a certain value, an underflow process is started (S1 in FIG. 10B). In this case, it is determined whether or not the pending flag is set (S2). If the flag is not set, normal processing is performed. If the flag is set, the window invalid mask (WIM) is recovered (S3). ). This recovery is performed in the manner described in FIG. Is to return to the state before setting in S2. Next, an interrupt handler is started (S4 of B. in FIG. 10), an interrupt process is performed, and the process returns.
[0070]
In this way, the processing speed can be improved by limiting the interrupt processing.
FIG. 11 is a processing flow for guaranteeing program restoration when performing instruction rewriting. This processing flow solves the problem of the processing (see FIG. 17) in the conventional system in which the command is rewritten and traveled.
[0071]
In a system in which an instruction is rewritten and run, for example, when the return value of a system call is an error, if the user program wants to execute an exception process such as an end processing routine instead of a normal subsequent instruction, the OS uses Rewrite the instruction.
[0072]
In this case, FIG. As shown in FIG. 11, the OS transmits the instruction 1 immediately before the instruction 2 and the instruction 2 to B. in FIG. (A1 in FIG. 11). At this time, "jump to next instruction after instruction 2" is also stored in the save area following "instruction 1" and "instruction 2". Next, the instruction 1 of the user program is rewritten to the content of “evacuation area jump”, and the instruction 2 is further rewritten to “system call B” (S2 in FIG. 11A). Thereafter, when the instruction 2 of the user program is executed by returning from the OS, the system call B is executed and the return instruction is restored.
[0073]
In this way, by performing the rewriting, even if, for example, the system restarts due to a system failure after rewriting the instruction 2 to the system call B, the normal route stored in the save area is restored. In the real-time OS processing by the register window method, when running by rewriting instructions, the reliability of program restoration can be improved.
[0074]
【The invention's effect】
According to the present invention, the following effects can be obtained.
{Circle around (1)} In the real-time OS of the register window system, the execution speed can be improved by using the register window efficiently.
[0075]
{Circle around (2)} It is possible to efficiently manage the information on the return point when an interrupt occurs and the stack in which the information is saved.
{Circle around (3)} It is possible to reduce the number of switching of the register window in the processing at the time of occurrence of the system call, thereby reducing the processing time.
[0076]
{Circle around (4)} In a system that rewrites and executes an instruction, it is possible to restore the instruction even if an error occurs in the device before returning to the previous state after rewriting the instruction, thereby improving the reliability.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating a first principle of the present invention.
FIG. 2 is a diagram illustrating a second principle of the present invention.
FIG. 3 is a block diagram of a processing apparatus in which the present invention is implemented.
FIG. 4 is a diagram showing a processing flow of occurrence of an overflow when a range is fixed.
FIG. 5 is a diagram showing a processing flow of occurrence of an overflow when the range is variable.
FIG. 6 is a configuration diagram of an interrupt control block (ICB).
FIG. 7 is a diagram showing a flow of general interrupt processing.
FIG. 8 is a diagram showing a flow of a basic clock interrupt process.
FIG. 9 is a flowchart of a system call process according to the present invention.
FIG. 10 is a diagram showing a processing flow for controlling interrupt processing.
FIG. 11 is a diagram showing a processing flow for guaranteeing program restoration when performing instruction rewriting.
FIG. 12 is a diagram illustrating a configuration example of a register of a conventional register window.
FIG. 13 is an explanatory diagram of each register group.
FIG. 14 is a conceptual diagram of shifting a window when eight windows are used.
FIG. 15 is a diagram showing a software structure of a system call.
FIG. 16 is a diagram showing a processing flow of a conventional system call.
FIG. 17 is an explanatory diagram of a conventional example of a process of traveling by rewriting a command.
[Explanation of symbols]
1 8 circular register windows (# 0 to # 7)
2a Range of register window used on OS side
2b Range of register window used by application
3a First window invalid mask (first WIM)
3b Second window invalid mask (second WIM)
4 Current window pointer (CWP)

Claims

A real-time OS in which a predetermined number of register windows each formed by a plurality of register groups are provided in a ring shape, and sequentially switched to an adjacent window by a function call, and returned to an adjacent window in a reverse direction by a return operation. In the processing method of
The entirety of the plurality of ring-shaped register windows is moved beyond the boundary on the OS unit side in accordance with the range of the fixed number of register windows usable by the application unit and the fixed number of register windows usable by the OS unit. A first window mask in which a window number is set, and a second window mask in which a window number beyond the boundary of the application section is set.
When the window number currently being processed is updated by the function call and matches the number of the first window mask or the second window mask, an overflow interrupt is generated, and
A method of processing a real-time OS, wherein an underflow interrupt is generated when a window number currently being processed is updated by a return operation and matches the number of the first window mask or the second window mask .

In claim 1,
The processing of the real-time OS , wherein the window numbers set in the first window mask and the second window mask are shifted one by one so as to expand their usable ranges when the overflow interrupt occurs. Method.

In claim 1,
An interrupt control block is provided to save information about the interrupt return point and stack set in the current window before interrupt processing starts when an interrupt occurs.
A processing method for a real-time OS, wherein the interrupt control block forms a queue in the order of occurrence.

In claim 3,
A processing method for a real-time OS , wherein interrupt processing is performed without interrupting the contents of a register window for an interrupt that frequently occurs at a fixed cycle such as a basic clock interrupt .

In claim 1,
When an interrupt occurs, the number of windows in use is checked. If the number does not reach a certain number, interrupt processing is performed. If the number exceeds a certain number, the interrupt is suspended.
A processing method for a real-time OS, wherein an underflow is generated when the number of windows becomes equal to or less than a predetermined number, and processing of the pending interrupt is started .