													TOPPERS Confidential
		TOPPERS/HRP2カーネル
		TOPPERS/HRPカーネルとの主な違い

		作成者: 高田広章（名古屋大学）
		最終更新: 2013年3月4日

○メモの位置付け

このメモは，TOPPERS/HRP2カーネル（以下，HRP2カーネル）のTOPPERS/HRPカー
ネル（以下，HRPカーネル）との違いについて，仕様面の違いを中心にまとめた
ものである。

○目次

・両カーネルの開発の経緯
・機能とAPIの増減
	- 大きい単位の機能の削除／新設
	- APIの削除／新設
・システムコンフィギュレーション処理の変更
	- システムコンフィギュレーションファイル中のディレクティブの扱い
	- メモリオブジェクトの自動配置機能
・ミューテックス機能の違い
	- 優先度継承ミューテックスの削除
	- 優先度上限ミューテックスの振舞いの違い
・メールボックス機能と優先度データキュー機能
・アクセス許可ベクタを設定する静的API
・待ち禁止状態の扱いとrel_waiの振舞い
・処理単位の実行開始／リターン時のシステム状態の規定
	- 参考：HRPカーネルにおける規定
・カーネルオブジェクトに対する操作／アクセスの保護の違い
・タスク優先度の範囲
・その他の違い

○両カーネルの開発の経緯

HRPカーネルは，JAXAと名古屋大学の共同研究の一環で，トロン協会で開発され
たIIMPカーネル（μITRON4.0/PX仕様に準拠）と，実装開始時点（2005年8月頃）
のTOPPERS/ASPカーネル（以下，ASPカーネル）をベースとして開発したもので
ある。

HRPカーネルの仕様および実装は，2006年夏頃にはフリーズされており，それ以
降は最低限の修正しか実施していない。そのため，ASPカーネルのこれ以降の変
更に追従しておらず，TOPPERS新世代カーネル統合仕様にも準拠していない。つ
まり，HRPカーネルの仕様は，μITRON4.0/PX仕様とTOPPERS新世代カーネル統合
仕様の中間的なものとなっている。

HRP2カーネルは，開発開始時点（2008年末頃）のASPカーネルをベースとして，
HRPカーネルの設計メモを参考にして，その時点のTOPPERS新世代カーネル統合
仕様に準拠するように開発したものである。また，この時点で，IIMPカーネル
由来のコードの書き直しを実施した。

それ以降，HRP2カーネルは，TOPPERS新世代カーネル統合仕様およびASPカーネ
ルと一体で保守されており，仕様およびコードの一貫性が保たれている。

○機能とAPIの増減

ここでは，HRP2カーネルにおいて，HRPカーネルに対して削除／新設された機能
とAPIを列挙する。

●大きい単位の機能の削除／新設

HRP2カーネルで削除された機能は次の通りである。

　・メールボックス機能
　・優先度継承ミューテックス

HRP2カーネルで新設された機能は次の通りである。

　・メモリオブジェクトの自動配置機能
　・優先度データキュー機能

●APIの削除／新設

HRP2カーネルで削除されたAPIは次の通りである。

・メールボックス機能のAPI

	CRE_MBX		メールボックスの生成
	CRA_MBX		メールボックスの生成（アクセス許可ベクタ付き）
	snd_mbx		メールボックスへの送信
	rcv_mbx		メールボックスからの受信
	prcv_mbx	メールボックスからの受信（ポーリング）
	trcv_mbx	メールボックスからの受信（タイムアウト付き）
	ini_mbx		メールボックスの再初期化
	ref_mbx		メールボックスの状態参照

・アクセス許可ベクタを指定してオブジェクトを生成する静的API

	CRA_TSK		タスクの生成（アクセス許可ベクタ付き）
	CRA_SEM		セマフォの生成（アクセス許可ベクタ付き）
	CRA_FLG		イベントフラグの生成（アクセス許可ベクタ付き）
	CRA_DTQ		データキューの生成（アクセス許可ベクタ付き）
	CRA_MTX		ミューテックスの生成（アクセス許可ベクタ付き）
	CRA_MPF		固定長メモリプールの生成（アクセス許可ベクタ付き）
	CRA_CYC		周期ハンドラの生成（アクセス許可ベクタ付き）
	CRA_ALM		アラームハンドラの生成（アクセス許可ベクタ付き）

・その他のAPI

	frsm_tsk	強制待ち状態からの強制再開
	SAC_TIM		システム時刻のアクセス許可ベクタの設定
	set_tim		システム時刻の設定

HRP2カーネルで新設されたAPIは次の通りである。

・優先度データキュー機能のAPI

	CRE_PDQ		優先度データキューの生成
	SAC_PDQ		優先度データキューのアクセス許可ベクタの設定
	snd_pdq		優先度データキューへの送信
	psnd_pdq	優先度データキューへの送信（ポーリング）
	ipsnd_pdq	優先度データキューへの送信（ポーリング，非タスクコンテキスト）
	tsnd_pdq	優先度データキューへの送信（タイムアウトあり）
	rcv_pdq		優先度データキューからの受信
	prcv_pdq	優先度データキューからの受信（ポーリング）
	trcv_pdq	優先度データキューからの受信（タイムアウトあり）
	ini_pdq		優先度データキューの再初期化
	ref_pdq		優先度データキューの状態参照

・オブジェクトのアクセス許可ベクタを設定する静的API

	SAC_TSK		タスクのアクセス許可ベクタの設定
	SAC_SEM		セマフォのアクセス許可ベクタの設定
	SAC_FLG		イベントフラグのアクセス許可ベクタの設定
	SAC_DTQ		データキューのアクセス許可ベクタの設定
	SAC_MTX		ミューテックスのアクセス許可ベクタの設定
	SAC_MPF		固定長メモリプールのアクセス許可ベクタの設定
	SAC_CYC		周期ハンドラのアクセス許可ベクタの設定
	SAC_ALM		アラームハンドラのアクセス許可ベクタの設定

・メモリリージョンを登録する静的API

	ATT_REG		メモリリージョンの登録
	DEF_SRG		標準メモリリージョンの定義

・メモリオブジェクトを登録する静的API

	ATT_SEC		セクションの登録
	ATA_SEC		セクションの登録（アクセス許可ベクタ付き）
	ATT_MOD		オブジェクトモジュールの登録
	ATA_MOD		オブジェクトモジュールの登録（アクセス許可ベクタ付き）
	ATT_PMA		物理メモリ領域の登録
	ATA_PMA		物理メモリ領域の登録（アクセス許可ベクタ付き）

・その他のAPI

	get_inf		自タスクの拡張情報の参照
	dis_wai		待ち禁止状態への遷移
	idis_wai	待ち禁止状態への遷移（非タスクコンテキスト用）
	ena_wai		待ち禁止状態の解除
	iena_wai	待ち禁止状態の解除（非タスクコンテキスト用）
	ista_ovr	オーバランハンドラの動作開始（非タスクコンテキスト用）
	istp_ovr	オーバランハンドラの動作停止（非タスクコンテキスト用）
	LNK_SEC		セクションの配置

HRPカーネルとHRP2カーネルで，パラメータに変更のあったAPIは次の通りであ
る。

	DEF_SVC		拡張サービスコールの定義
	prb_mem		メモリ領域に対するアクセス権のチェック

○システムコンフィギュレーション処理の変更

●システムコンフィギュレーションファイル中のディレクティブの扱い

システムコンフィギュレーションファイルにおけるC言語プリプロセッサのディ
レクティブの扱いを全面的に見直した。

システムコンフィギュレーションファイルを記述する上での，HRPカーネルとの
主な違いは次の通り。

(1) システムコンフィギュレーションファイルに記述できるC言語プリプロセッ
サのディレクティブを，インクルードディレクティブ（#include）と条件ディ
レクティブ（#if，#ifdefなど）のみに限定した。

インクルードディレクティブは，静的APIのパラメータを解釈するために必要な
C言語のヘッダファイルを指定するために用いるためのもので，HRPカーネルの
共通静的API INCLUDEに相当する機能である。また，条件ディレクティブは，有
効とする静的APIを選択するために用いる。

(2) HRPカーネルにおけるC言語プリプロセッサのインクルードディレクティブ
（#include）と同等の機能として，HRP2カーネルでは，INCLUDEディレクティブ
を用意している。

(3) 保護ドメインの囲みの文法が変更になっている。カーネルドメインについ
ては，小文字か大文字かの違いのみであるが，ユーザドメインについては，文
法が以下のように変更になっている。

	HRPカーネル
	----------------------------------------
	user_domain <保護ドメイン名> {
		ユーザドメインに属するオブジェクトを登録する静的API等
	}
	----------------------------------------

	HRP2カーネル
	----------------------------------------
	DOMAIN(<保護ドメイン名>) {
		ユーザドメインに属するオブジェクトを登録する静的API等
	}
	----------------------------------------

その他に，静的APIのパラメータの分類を変更したなどの違いがある。

内部的には，HRPカーネルでは，システムコンフィギュレーションファイルを，
C言語プリプロセッサを通した後で，コンフィギュレータによって処理していた。
それに対してHRP2カーネルでは，直接コンフィギュレータが処理する。HRP2カー
ネルにおけるシステムコンフィギュレーション手順は，TOPPERS新世代カーネル
統合仕様書の2.12節を参照すること。

●メモリオブジェクトの自動配置機能

HRPカーネルは，メモリ領域をどのように配置するかはシステム設計者が決定し，
その結果（どのようにメモリ保護を行うか）を静的API ATT_MEM／ATA_MEMによっ
てカーネルに伝えるという方針で設計されている。

それに対してHRP2カーネルでは，メモリの有効利用を促進するために，メモリ
領域の配置をコンフィギュレータ（およびリンカ）が決定する。そのため，メ
モリ保護の対象となるメモリオブジェクトを，カーネルに登録することが必要
である。そのための静的APIとして，ATT_MEM／ATA_MEMに加えて，ATT_SEC／
ATA_SEC，ATT_MOD／ATA_MOD，ATT_PMA／ATA_PMAを新設している。また，配置先
のメモリリージョンを登録する静的APIとして，ATT_REGとDEF_SRGを新設してい
る。これらの仕様については，TOPPERS新世代カーネル統合仕様書の4.8節を参
照すること。

○ミューテックス機能の違い

●優先度継承ミューテックスの削除

HRPカーネルでは，優先度継承ミューテックスと優先度上限ミューテックスの両
方（ただし，厳密な優先度制御規則のみ）をサポートしているが，HRP2カーネ
ルでは，優先度継承ミューテックスをサポートしていない。

●優先度上限ミューテックスの振舞いの違い

ミューテックス機能によりタスクの現在優先度が変化する場合で，現在優先度
を変化させるサービスコールの前後とも，当該タスクが実行できる状態である
場合を考える。この時，HRPカーネルでは，現在優先度が変更されたタスクの優
先順位を，同じ優先度を持つタスクの間で最も低くする。それに対して，HRP2
カーネルでは，同じ優先度を持つタスクの間で最も高くする。

これは，HRPカーネルの振舞いでは，次のような現象（問題とまでは言えない）
が生じるためである。

低優先度タスクAがディスパッチ禁止した後，高優先度タスクBがレディ状態に
なり（ディスパッチ禁止なのでタスク切換えは起こらない），その後にタスク
Aが，優先度上限がタスクBの優先度と同じ優先度上限ミューテックスに対して
ploc_mtxを発行し，タスクBと同じ優先度になる状況を考える。この時，HRPカー
ネルでは，タスクAはタスクBよりも優先順位が低くなる。その後，タスクAがディ
スパッチ許可すると，タスクBに切り換わる。つまり，優先度上限ミューテック
スをロックしているにもかかわらず，その優先度上限と同じ優先度のタスクBに
プリエンプトされてしまう可能性がある。

○メールボックス機能と優先度データキュー機能

HRPカーネルでは，μITRON4.0/PX仕様に準拠したメールボックス機能をサポー
トしているが，HRP2カーネルでは，メールボックス機能を削除し，それに代わ
る機能として優先度データキュー機能を新設している。

μITRON4.0仕様のメールボックス機能は，送受信するメッセージの先頭の数バ
イトを，メッセージのキューを作るためにリザーブしている。ところが，この
キュー領域をアプリケーションが破壊すると，カーネルの動作が保証できなく
なる。そこで，μITRON4.0/PX仕様では，アプリケーションが不具合を起こして
もカーネルの動作に悪影響を与えないために，メッセージのキューをカーネル
の管理領域として確保している。その結果，メールボックス生成時に入れるこ
とができるメッセージの数を指定する必要がある，メールボックスへの送信時
にキューイングオーバフローのエラーになる可能性があるという2つの点で，
μITRON4.0仕様のメールボックス機能とは振舞いが異なっている。HRPカーネル
のメールボックス機能は，μITRON4.0/PX仕様に準拠している。

それに対してTOPPERS新世代カーネル統合仕様では，メールボックス機能は
μITRON4.0仕様のままとし，保護機能対応カーネルではサポートしないことと
し，それに変わる機能として優先度データキュー機能を追加した。HRPカーネル
のメールボックス機能は，FIFO順の場合は従来のデータキュー機能，優先度順
の場合は優先度データキュー機能を使うことで，同等の機能を実現することが
可能である。

○アクセス許可ベクタを設定する静的API

HRPカーネルでは，アクセス許可ベクタを指定してオブジェクトを生成する静的
API（CRA_XXX）をサポートしていたが，HRP2カーネルではこれらをサポートせ
ず，代わりに，オブジェクトのアクセス許可ベクタを設定する静的API
（SAC_XXX）をサポートしている。どちらを用いても，機能的には同じことが実
現可能である。

○待ち禁止状態の扱いとrel_waiの振舞い

HRPカーネルでは，ソフトウェア割込みを経由してサービスコール（拡張サービ
スコールを含む）を実行中のタスクに対してrel_wai／irel_waiを発行すると，
対象タスクは待ち禁止状態となる。また，待ち禁止状態のタスクがサービスコー
ルからリターンすると，待ち禁止状態は解除される。

そのため，待ち状態でないタスクに対して，rel_wai／irel_waiを発行した場合
でも，対象タスクを待ち禁止状態とするという副作用があることから，E_OBJエ
ラーとならず，E_OKが返る。また，rel_waiにおいては，対象タスクにTSK_SELF
を指定することができる。

以上のHRPカーネルの仕様は，μITRON4.0/PX仕様に準拠している。rel_wai／
irel_waiの振舞いに関しては，μITRON4.0/PX仕様は，μITRON4.0仕様と互換性
がない。

それに対してHRP2カーネルでは，rel_wai／irel_waiによりタスクを待ち禁止状
態にするのではなく，タスクを待ち禁止状態にするためのサービスコールとし
て，dis_wai／idis_waiを新設した。待ち禁止状態のタスクがサービスコールか
らリターンすると，待ち禁止状態が解除されるのは，HRPカーネルと同じである。
また，待ち禁止状態を解除するためのサービスコールであるena_wai／iena_wai
も新設している。

また，タスクが待ち禁止状態になることができるのを，ユーザタスクについて
は特権モードで実行している間，システムタスクについては拡張サービスコー
ルを実行している間であると明確化した。これらの状態では，タスク例外処理
ルーチンの実行は開始されないことから，これらの状態を，タスク例外処理マ
スク状態と呼ぶこととした。

rel_wai／irel_waiは，対象タスクを待ち禁止状態にするという副作用を持たな
いことから，待ち状態のタスクに対して発行すると，E_OBJエラーとなる。これ
は，μITRON4.0仕様に準拠した振舞いである。

さらに，HRP2カーネルでは，ref_tskで参照できる情報に，タスク例外マスク状
態か否か，待ち禁止状態か否か，拡張サービスコールのネストレベルを追加し
ている。

○処理単位の実行開始／リターン時のシステム状態の規定

処理単位の実行開始／リターン時のシステム状態について，μITRON4.0仕様に
おいて実装依存であった点を，HRPカーネルでは厳密に規定し，ターゲットによ
る違いが生じないようにした。HRP2カーネルでは，さらに安全側に規定を見直
している。

具体的な違いは次の通りである。

(1) タスク例外処理ルーチンの実行開始条件の変更

割込み優先度マスク全解除状態でない場合には，タスク例外処理ルーチンの実
行が開始されないという仕様に変更した（HRPカーネルでは，タスク例外処理ルー
チンの実行開始に，割込み優先度マスクは関係しない）。

(2) タスク例外処理ルーチンからのリターン時処理の変更

タスク例外処理ルーチンからのリターン時に，割込み優先度マスクとディスパッ
チ禁止フラグを，タスク例外処理ルーチン実行開始前の状態に戻すという仕様
に変更した（HRPカーネルでは，いずれも，そのままにするという仕様になって
いる）。ただし，ディスパッチ禁止フラグを元に戻す処理は，そのタスクにディ
スパッチ禁止フラグの変更を許可している場合にのみ行われる。

(3) CPU例外ハンドラからのリターン時処理の変更

CPU例外ハンドラからのリターン時に，割込み優先度マスクを元に戻すという仕
様に変更した（HRPカーネルでは，元に戻すか，そのままとするか，実装依存で
ある）。

●参考：HRPカーネルにおける規定

HRPカーネルにおける処理単位の実行開始／リターン時のシステム状態は，次の
通りである。HRP2カーネルに関しては，TOPPERS新世代カーネル統合仕様書
2.5.10節を参照すること。

				CPUロック／		割込み優先度	ディスパッチ	タスク例外
				ロック解除状態	マスク			禁止／許可状態	禁止／許可状態
------------------------------------------------------------------------------
【タスク】
実行開始条件	解除			0				許可			−
実行開始時処理	そのまま		そのまま		そのまま		禁止する
終了前			原則解除(*1)	原則0(*1)		原則許可(*1)	任意
終了時処理		解除する		0にする			許可する		−
------------------------------------------------------------------------------
【タスク例外処理ルーチン】
実行開始条件	解除			任意			任意			許可
実行開始時処理	そのまま		そのまま		そのまま		禁止する
リターン前		原則解除(*1)	元に戻す(*2)	元に戻す(*2)	原則禁止(*1)
リターン時処理	解除する		そのまま(*2)	そのまま(*2)	許可する
------------------------------------------------------------------------------
【割込みハンドラ，ISR，タイムイベントハンドラ】
実行開始条件	解除			任意			任意			任意
実行開始時処理	そのまま		自優先度に		そのまま		そのまま
リターン前		原則解除(*1)	変更不可(*3)	変更不可(*3)	変更不可(*3)
リターン時処理	解除する		元に戻す		そのまま		そのまま
------------------------------------------------------------------------------
【CPU例外ハンドラ】
実行開始条件	任意			任意			任意			任意
実行開始時処理	そのまま(*5)	そのまま		そのまま		そのまま
リターン前		(*5)			変更不可(*3)	変更不可(*3)	変更不可(*3)
リターン時処理	(*5)			そのまま		そのまま		そのまま
								or 元に戻す(*4)
------------------------------------------------------------------------------
【拡張サービスコールルーチン】
実行開始条件	任意			任意			任意			任意
実行開始時処理	そのまま		そのまま		そのまま		そのまま
リターン前		任意			任意			任意			任意
リターン時処理	そのまま		そのまま		そのまま		そのまま
------------------------------------------------------------------------------

(*1)「原則XX」とは，XXにすることを推奨するが，そのようにしなくても支障
がないことを意味する。

(*2) 元に戻さずにリターンした場合，リターン直後もそのままの状態となり，
タスクに悪影響を与えるおそれがある。

これを「元に戻す」にしないのは，次の理由による。保護機能付きのカーネル
（HRPカーネル）では，ユーザタスクに対するタスク例外処理ルーチンを実行開
始する際には，これらの状態を元に戻すための情報を，ユーザスタック上に置
く必要がある。ユーザスタック上の情報は，ユーザタスクから書き換えること
ができるため，これを用いると，割込み優先度マスクやディスパッチ禁止／許
可状態の変更を許可されていないユーザタスクから，これらを変更することが
できることになり，保護の抜け道ができてしまうためである。

(*3) その処理単位中で，そのシステム状態を変更するAPIが用意されていない
ことを示す。処理単位中で，APIを用いずにシステム状態を変更することは禁止
であり，変更した場合の動作は未定義である。

(*4) どちらにするかはターゲット依存。CPU例外ハンドラ中では割込み優先度
マスクは変更不可なので，どちらであっても同じ結果になる。

(*5) CPUロック解除状態でCPU例外が発生した場合，CPU例外ハンドラの実行開
始直後はCPUロック解除状態となっており，CPU例外ハンドラからのリターン前
には，元に戻しておく（すなわち，CPUロック解除状態にしておく）のが原則で
ある(*1)。元に戻さない場合でも，CPU例外ハンドラからのリターン時に，CPU
ロック解除状態に戻す。

CPUロック状態でCPU例外が発生した場合，CPU例外ハンドラの実行開始直後は
CPUロック状態となっており（実装上，注意が必要），xsns_dpn，xsns_xpnとも
TRUEを返すために，CPU例外ハンドラ中でCPUロック状態を解除することができ
ない（規則を無視してCPUロック状態を解除しようとした場合の動作は未定義）。
そのため，CPU例外ハンドラからのリターン時には，「そのまま」としても，
CPUロック状態に戻しても，同じ結果となる。

○カーネルオブジェクトに対する操作／アクセスの保護の違い

カーネルオブジェクトに対する操作／アクセスの保護に関する違い，次の通り
である。

(1) get_priは，タスクの参照操作に対するアクセス許可パターンによって，操
作の可否を決めるように変更した（HRPカーネルでは，タスクの通常操作1に対
するアクセス許可パターンで決めていた）。

(2) システム時刻に対するアクセス許可ベクタは廃止した。get_timは，システ
ム状態の参照操作に対するアクセス許可パターンによって，操作の可否を決め
るように変更した（HRPカーネルでは，システム時刻の通常操作2に対するアク
セス許可パターンで決めていた）。

(3) get_ipmは，システム状態の参照操作に対するアクセス許可パターンによっ
て，操作の可否を決めるように変更した（HRPカーネルでは，システム状態の通
常操作2に対するアクセス許可パターンで決めていた）。

(4) ena_dspはシステム状態の通常操作1に対するアクセス許可パターンによっ
て，unl_cpuはシステム状態の通常操作2に対するアクセス許可パターンによっ
て，操作の可否を決めるように変更した（HRPカーネルでは，これらは，すべて
の保護ドメインから呼び出すことができるサービスコールとしていた）。

(5) ext_kerは，カーネルドメインのみから呼び出すことができるサービスコー
ルに変更した（HRPカーネルでは，システム状態の管理操作に対するアクセス許
可パターンで，呼出しの可否を決めていた）。

○タスク優先度の範囲

HRPカーネルのタスク優先度の範囲は，JAXAからの要望により32段階に拡張され
ているが，HRP2カーネルは16段階である。

○その他の違い

HRPカーネルとのその他の主な違いを以下に列挙する。

(1) ITRON標準データ型の見直しとヘッダファイルの変更

サイズの決まった整数型（B，H, Wなど）やITRON仕様の独特のデータ型（INT，
UINT，VP，VP_INTなど）について，C99に準拠した型の名称（int8_t，int16_t，
int32_tなど）やそれと相性が良い名称に変更した。

これに関連して，itron.hの中でTOPPERS新世代カーネル統合仕様で有効な定義
をt_stddef.hに移し，itron.hはμITRON4.0仕様との互換性が必要な場合にイン
クルードするためのヘッダファイルという位置付けにした。ITRON標準データ型
（B，H, Wなど）は，itron.hの中で定義されている。

(2) 処理単位とメモリ領域のデータ型の見直し

処理単位のエントリ番地のデータ型を，パラメータが反映されないFP型ではな
く，処理単位毎の専用のデータ型とした。例えば，タスクのエントリ番地のデー
タ型をTASK型，タスク例外処理ルーチンのデータ型をTEXRTN型とした。

また，スタック領域と固定長メモリプール領域のデータ型を，それぞれSTK_T型
とMPF_T型とした。

(3) 値が0の定数（オブジェクト属性等）の見直し

コーディングミスを防ぐために，値が0の定数の扱いを見直した。オブジェクト
属性（TA_TFIFO等）については，値が0のものはデフォルト扱いして廃止し，定
義をitron.hに移した。値が0のサービスコールの動作モード（TWF_ANDW）やオ
ブジェクトの状態（TTEX_ENA等）については，値を変更した。

(4) 強制待ち要求ネストの廃止

強制待ち要求をネストする機能を廃止した。言い換えると，強制待ち要求ネス
ト数の最大値を1に固定した。これに伴い，frsm_tskは廃止し，itron.hにおい
てfrsm_tskをrsm_tskにマクロ定義した。また，TMAX_SUSCNTの定義をitron.hに
移した。

(5) システム時刻の設定機能の廃止

set_tim（システム時刻の設定）を廃止した。

(6) 周期ハンドラの仕様変更

sta_cycを呼び出した後，最初に周期ハンドラが起動される時刻を変更した。
HRPカーネルでは，sta_cycを呼び出してから周期ハンドラの起動周期で指定し
た相対時間後としているが，HRP2カーネルでは，起動位相で指定した相対時間
後とした。

(7) 自タスクの拡張情報の参照

自タスクの拡張情報を参照するためのサービスコールを新設した。ライブラリ
等の中で用いることを想定している。

	get_inf		自タスクの拡張情報の参照

(8) isig_timの扱いの変更

システム時刻を更新する機構をカーネル内部に持つ扱いとし，サービスコール
としてのisig_timは廃止した。

(9) ista_ovrとistp_ovrの新設

ista_ovrとistp_ovrを新設し，非タスクコンテキストからオーバランハンドラ
の動作開始／停止できるようにした。

(10) メモリオブジェクト属性の変更

メモリオブジェクト属性に，TA_NOREAD，TA_EXEC，TA_MEMINI，TA_MEMPRSV，
TA_IODEVを追加した。また，TA_ROはTA_NOWRITEに改名した。

(11) prb_memのパラメータの変更

prb_memのパラメータから，domid（ドメインID）を削除し，tskidで指定された
タスクからメモリ領域に対してアクセスが許可されているかをチェックするサー
ビスコールとした。また，pmmodeにTPM_EXECを指定することで，実行アクセス
権のチェックが行えるようにした。さらに，prb_memを，CPUロック状態からも
呼び出せるものとした。

(12) 拡張サービスコールにおけるスタックチェック

拡張サービスコールが呼び出される時に，スタックの残り領域のサイズをチェッ
クする機能を追加した。

これに伴い，DEF_SVCのパラメータに，stksz（拡張サービスコールで使用する
スタックサイズ）を追加した。

(13) 拡張サービスコールを呼び出した保護ドメインを渡す機能の追加

拡張サービスコールに，それを呼び出した処理単位が属する保護ドメインのID
番号（cdmid）を渡す機能を追加した。

(14) CPUロック状態からのdis_intとena_intの呼出し

dis_intとena_intを，CPUロック状態からも呼び出せるものとした。

(15) unl_mtxのアクセス保護

unl_mtxを，対象ミューテックスの通常操作1としてアクセス保護する仕様に変
更した（HRP2カーネル Release 2.2より変更）。

(16) カーネルの用いる領域の指定方法

HRPカーネルでは，ユーザタスクのユーザスタック領域を除いて，オブジェクト
に付随するメモリ領域はすべて自動割付けであったが，HRP2カーネルでは，タ
スクのユーザスタック領域とシステムスタック領域，固定長メモリプールの固
定長メモリプール領域については，静的APIで先頭番地を指定することもできる
ようにした（自動割付けもサポートする）。

(17) タスク例外実行開始時スタック不正の場合の処理

HRPカーネルでは，タスク例外処理ルーチンの実行開始時にユーザスタックポイ
ンタの妥当でない場合には，タスク例外処理を禁止し，タスク例外実行開始時
スタック不正例外ハンドラ（HRPカーネルでは，タスク例外起動時スタック不正
例外ハンドラと呼んでいる）を呼び出していた。それに対してHRP2カーネルで
は，タスク例外処理の禁止は行わずに，単にタスク例外実行開始時スタック不
正例外ハンドラを呼び出すこととした。

(18) 機能コードの割付け直し

HRP2カーネルでは，サービスコールの機能コードを，全面的に割り付け直した。

以上
