Changeset 315 for rubycfg_asp/trunk/asp_dcre/doc/design.txt

Timestamp:

Jul 23, 2017, 2:29:40 PM (7 years ago)

Author:

coas-nagasima

Message:

SVNプロパティを設定

File:

• rubycfg_asp/trunk/asp_dcre/doc/design.txt (modified) (20 diffs, 1 prop)

rubycfg_asp/trunk/asp_dcre/doc/design.txt

@@ -1 +1 @@
 
-                TOPPERS/ASPカーネル
-                設計メモ
-
-                対応バージョン: Release 1.9.3
-                最終更新: 2014年4月15日（作成中）
-
-このドキュメントは，TOPPERS/ASPカーネルの設計メモである．作成途中のもの
-であり，網ç¾
-的ではない．
+                TOPPERS/ASPカーネル
+                設計メモ
+
+                対応バージョン: Release 1.9.3
+                最終更新: 2014年4月15日（作成中）
+
+このドキュメントは，TOPPERS/ASPカーネルの設計メモである．作成途中のもの
+であり，網羅的ではない．
 
 ----------------------------------------------------------------------
@@ -18 +17 @@
              Graduate School of Information Science, Nagoya Univ., JAPAN
  
- 上記著作権è€
-は，以下の(1)～(4)ã®æ¡ä»¶ã‚’æº€ãŸã™å ´åˆã«é™ã‚Šï¼Œæœ¬ã‚½ãƒ•ãƒˆã‚¦ã‚§
- ア（本ソフトウェアを改変したものを含む．以下同じ）を使用・複製・改
- 変・再é
-å¸ƒï¼ˆä»¥ä¸‹ï¼Œåˆ©ç”¨ã¨å‘¼ã¶ï¼‰ã™ã‚‹ã“とを無償で許諾する．
- (1) æœ¬ã‚½ãƒ•ãƒˆã‚¦ã‚§ã‚¢ã‚’ã‚½ãƒ¼ã‚¹ã‚³ãƒ¼ãƒ‰ã®å½¢ã§åˆ©ç”¨ã™ã‚‹å ´åˆã«ã¯ï¼Œä¸Šè¨˜ã®è‘—ä½œ
-     権表示，この利用条件および下記の無保証規定が，そのままの形でソー
-     スコード中に含まれていること．
- (2) 本ソフトウェアを，ライブラリ形式など，他のソフトウェア開発に使
-     用できる形で再é
-å¸ƒã™ã‚‹å ´åˆã«ã¯ï¼Œå†é
-å¸ƒã«ä¼´ã†ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆï¼ˆåˆ©ç”¨
-     è€
-マニュアルなど）に，上記の著作権表示，この利用条件および下記
-     の無保証規定を掲載すること．
- (3) 本ソフトウェアを，機器に組み込むなど，他のソフトウェア開発に使
-     用できない形で再é
-å¸ƒã™ã‚‹å ´åˆã«ã¯ï¼Œæ¬¡ã®ã„ずれかの条件を満たすこ
-     と．
-   (a) 再é
-å¸ƒã«ä¼´ã†ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆï¼ˆåˆ©ç”¨è€
-マニュアルなど）に，上記の著
-       作権表示，この利用条件および下記の無保証規定を掲載すること．
-   (b) 再é
-å¸ƒã®å½¢æ
-‹ã‚’，別に定める方法によって，TOPPERSプロジェクトに
-       å ±å‘Šã™ã‚‹ã“ã¨ï¼Ž
- (4) 本ソフトウェアの利用により直接的または間接的に生じるいかなる損
-     害からも，上記著作権è€
-およびTOPPERSプロジェクトをå
-è²¬ã™ã‚‹ã“と．
-     また，本ソフトウェアのユーザまたはエンドユーザからのいかなる理
-     由に基づく請求からも，上記著作権è€
-およびTOPPERSプロジェクトを
-     å
-è²¬ã™ã‚‹ã“と．
+ 上記著作権者は，以下の(1)～(4)の条件を満たす場合に限り，本ソフトウェ
+ ア（本ソフトウェアを改変したものを含む．以下同じ）を使用・複製・改
+ 変・再配布（以下，利用と呼ぶ）することを無償で許諾する．
+ (1) 本ソフトウェアをソースコードの形で利用する場合には，上記の著作
+     権表示，この利用条件および下記の無保証規定が，そのままの形でソー
+     スコード中に含まれていること．
+ (2) 本ソフトウェアを，ライブラリ形式など，他のソフトウェア開発に使
+     用できる形で再配布する場合には，再配布に伴うドキュメント（利用
+     者マニュアルなど）に，上記の著作権表示，この利用条件および下記
+     の無保証規定を掲載すること．
+ (3) 本ソフトウェアを，機器に組み込むなど，他のソフトウェア開発に使
+     用できない形で再配布する場合には，次のいずれかの条件を満たすこ
+     と．
+   (a) 再配布に伴うドキュメント（利用者マニュアルなど）に，上記の著
+       作権表示，この利用条件および下記の無保証規定を掲載すること．
+   (b) 再配布の形態を，別に定める方法によって，TOPPERSプロジェクトに
+       報告すること．
+ (4) 本ソフトウェアの利用により直接的または間接的に生じるいかなる損
+     害からも，上記著作権者およびTOPPERSプロジェクトを免責すること．
+     また，本ソフトウェアのユーザまたはエンドユーザからのいかなる理
+     由に基づく請求からも，上記著作権者およびTOPPERSプロジェクトを
+     免責すること．
  
- 本ソフトウェアは，無保証で提供されているものである．上記著作権è€
-お
- よびTOPPERSプロジェクトは，本ソフトウェアに関して，特定の使用目的
- に対する適合性も含めて，いかなる保証も行わない．また，本ソフトウェ
- アの利用により直接的または間接的に生じたいかなる損害に関しても，そ
- ã®è²¬ä»»ã‚’è² ã‚ãªã„ï¼Ž
+ 本ソフトウェアは，無保証で提供されているものである．上記著作権者お
+ よびTOPPERSプロジェクトは，本ソフトウェアに関して，特定の使用目的
+ に対する適合性も含めて，いかなる保証も行わない．また，本ソフトウェ
+ アの利用により直接的または間接的に生じたいかなる損害に関しても，そ
+ の責任を負わない．
  
  $Id$
 ----------------------------------------------------------------------
 
-○目次
-
-・TOPPERS/ASPカーネルの実è£
-設計方針
-・システム状æ
-‹ã¨ã‚³ãƒ³ãƒ†ã‚­ã‚¹ãƒˆã®å®Ÿè£
-
-        - カーネル動作状æ
-‹ã¨éžå‹•ä½œçŠ¶æ
-‹
-        - タスクコンテキストと非タスクコンテキスト
-        - å
-¨å‰²è¾¼ã¿ãƒ­ãƒƒã‚¯çŠ¶æ
-‹ã¨å
-¨å‰²è¾¼ã¿ãƒ­ãƒƒã‚¯è§£é™¤çŠ¶æ
-‹
-        - CPUロック状æ
-‹ã¨CPUロック解除状æ
-‹
-        - 割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯
-        - ディスパッチ禁止状æ
-‹ã¨ãƒ‡ã‚£ã‚¹ãƒ‘ッチ許可状æ
-‹
-        - ディスパッチ保留状æ
-‹
-・タスク状æ
-‹ã®ç®¡ç†ã¨ã‚¹ã‚±ã‚¸ãƒ¥ãƒ¼ãƒªãƒ³ã‚°
-        - タスク状æ
-‹ã®ç®¡ç†
-        - タスクスケジューラ
-・タスクディスパッチ処理の実è£
-
-        - タスクディスパッチ処理のå¿
-要なタイミング
-        - ã‚¿ã‚¹ã‚¯ãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒãƒ£ã®æ§‹é€ 
-        - タスクの終了時のタスクディスパッチ
-        - reqflgの導å
-¥ç†ç”±
-・タスク例外処理機能の実è£
-
-        - タスク例外処理ルーチンの実行開始条件とシステム状æ
-‹ï¼ˆä»•æ§˜ã®ç¢ºèªï¼‰
-        - タスク例外処理ルーチンの呼出し処理
-        - タスク例外処理ルーチンの実行開始がå¿
-要なタイミング
-        - タスク例外処理ルーチンの実行開始処理
-        - call_texrtnからdispatchを呼び出す処理について
-ãƒ»ã‚¨ãƒ©ãƒ¼ã®ãƒã‚§ãƒƒã‚¯é †åº
-        - エラーの3分類
-        - é™çš„ã‚¨ãƒ©ãƒ¼ã®ãƒã‚§ãƒƒã‚¯é †åº
-        - æº–é™çš„ã‚¨ãƒ©ãƒ¼ã®ãƒã‚§ãƒƒã‚¯é †åº
-・CHECKマクロとgoto文の使用
-        - CHECKマクロの定義とその使用法
-        - 設計意図
-        - CHECKマクロを使用してよい条件
-        - å•é¡Œã‚’ç”Ÿã˜ã‚‹ã“ã¨ãŒãªã„æ ¹æ‹ 
-・ext_tsk，ext_kerの返り値
-ãƒ»ã‚«ãƒ¼ãƒãƒ«ã®ãƒ‡ãƒ¼ã‚¿æ§‹é€ ã«å¯¾ã™ã‚‹volatile宣言について
-・型キャストに伴う警告メッセージ
-・性能評価用システム時刻参ç
-§æ©Ÿèƒ½
-        - å¿
-要性と使途
-        - API仕様
-        - 実è£
-
-・タスク例外処理禁止フラグをenatexで実è£
-している理由
-
-
-○TOPPERS/ASPカーネルの実è£
-設計方針
-
-TOPPERS/ASPカーネル（以下，ASPカーネル）は，TOPPERS新世代カーネルの出発
-点となるリアルタイムカーネルである．TOPPERS新世代カーネル仕様の設計方針
-と，ASPã‚«ãƒ¼ãƒãƒ«ã®é©ç”¨å¯¾è±¡é ˜åŸŸã¨è¨­è¨ˆæ–¹é‡ã«ã¤ã„ã¦ã¯ï¼ŒTOPPERS新世代カーネ
-ル統合仕様書に述べられている．
-
-以下では，ASPカーネルの実è£
-設計方針について述べるが，仕様設計方針とも関
-連しており，明確に分離できない部分もある．
-
-TOPPERS/ASPカーネルの実è£
-設計を行うにあたり，次の方針を設定する．
-
-(1) ã‚½ãƒ¼ã‚¹ã‚³ãƒ¼ãƒ‰ã®èª­ã¿ã‚„ã™ã•ãƒ»æ”¹é€ ã—ã‚„ã™ã•ã‚’é‡è¦–ã™ã‚‹
-
-ソースコードが読みやすいことは，オープンソースソフトウェアの品質を向上
-させる上で最も重要な特性である．ソースコードを理解している技術è€
-が増え
-ることで，問題を早期に発見することができ，サポート体制もå
-
-実させること
-ができる．また，ソースコードが読みやすいことは，シンプルな設計がされて
-ã„ã‚‹ã“ã¨ã‚‚æ„å‘³ã—ã¦ãŠã‚Šï¼Œä¿¡é ¼æ€§å‘ä¸Šã«ã‚‚ã¤ãªãŒã‚‹ï¼Žã•ã‚‰ã«ï¼ŒæŠ€è¡“è€
-教育のた
-めの教材とする観点からも，ソースコードが読みやすいことは重要となる．
-
-æ”¹é€ ã—ã‚„ã™ã„ã“ã¨ã¯ï¼Œã‚·ã‚¹ãƒ†ãƒ æ¯Žã®è¦æ±‚ã«ã‚ã‚ã›ãŸãƒãƒ¥ãƒ¼ãƒ‹ãƒ³ã‚°ãŒè¡Œã„ã‚„ã™ã„
-ことを意味しており，擦り合わせ型の開発を支援する性質である．また，ASPカー
-ネルを基盤としてTOPPERSæ–°ä¸–ä»£ã‚«ãƒ¼ãƒãƒ«ã‚·ãƒªãƒ¼ã‚ºã‚’é–‹ç™ºã—ã¦ã„ãä¸Šã§ã‚‚ï¼Œæ”¹é€ 
-しやすいことはå¿
-é ˆã®æ¡ä»¶ã§ã‚ã‚‹ï¼Ž
-
-(2) æ–°ã—ã„ã‚¿ãƒ¼ã‚²ãƒƒãƒˆã‚·ã‚¹ãƒ†ãƒ ã¸ã®ãƒãƒ¼ãƒ†ã‚£ãƒ³ã‚°ãŒå®¹æ˜“ãªæ§‹é€ ã¨ã™ã‚‹
-
-組込みシステムには多様なハードウェアが用いられるため，それらに容易にポー
-ティングできることは重要な性質である．そのために，実行性能にé
-æ
-®ã—つつ
-ハードウェアを抽象化し，ターゲットシステムに依存する部分（ターゲット依
-存部）と依存しない部分（ターゲット非依存部）を明確に分離する．また，開
-発環境（コンパイラなど）に依存する部分も明確に分離する．
-
-(3) æ¤œè¨¼ãŒå®¹æ˜“ãªæ§‹é€ ã¨ã™ã‚‹
-
-ä¿¡é ¼æ€§ã‚’ç¢ºä¿ã™ã‚‹ãŸã‚ã«ï¼Œæ¤œè¨¼ãŒå®¹æ˜“ãªæ§‹é€ ã¨ã™ã‚‹ï¼Ž
-
-å
-·ä½“的には，サービスコールのほとんどå
-¨ä½“を割込み禁止で実行することとし，
-ã‚µãƒ¼ãƒ“ã‚¹ã‚³ãƒ¼ãƒ«ã®å‡¦ç†é€”ä¸­ã§å‰²è¾¼ã¿ã‚’è¨±å¯ã—ãªã„ï¼Žã“ã®æ§‹é€ ã¯ï¼Œèª­ã¿ã‚„ã™ãæ”¹
-é€ ã—ã‚„ã™ã„ã‚½ãƒ¼ã‚¹ã‚³ãƒ¼ãƒ‰ã«ã™ã‚‹ãŸã‚ã«ã‚‚æœ‰åŠ¹ã§ã‚ã‚‹ï¼Žã“ã‚Œã«ã‚ˆã‚Šå‰²è¾¼ã¿å¿œç­”æ€§
-ãŒçŠ ç‰²ã«ãªã‚‹ãŒï¼Œãã‚Œã«ã‚ˆã£ã¦å•é¡Œã‚’ç”Ÿã˜ã‚‹ã‚¢ãƒ—ãƒªã‚±ãƒ¼ã‚·ãƒ§ãƒ³ã¯å°‘æ•°ã§ã‚ã‚Šï¼Œ
-やむをえないものと考える．
-
-また，条件コンパイル等によりコンフィギュレーションできる箇所を増やすと，
-細かな最適化ができる一方で，検証すべき組合せが増えることから，コンフィ
-ギュレーションできる箇所はå¿
-要最低限とする．
-
-(4) 実行性能とメモリ使用量にé
-æ
-®ã™ã‚‹
-
-上記の方針を満たした上で，高い実行性能と小さいメモリ使用量を達成できる
-ような実è£
-を行う．実行性能を向上させる際には，平均性能の向上よりも，最
-悪時性能の向上を重視する．
-
-ソースコードの読みやすさを重視すると言っても，実行性能の悪いアルゴリズ
-ムを安易に採用することはせず，高い実行性能を達成できるアルゴリズムを用
-いる．ただし，新しいターゲットシステムへのポーティングを容易にするため
-に大部分をC言語で実è£
-ã—ã¦ãŠã‚Šï¼Œã™ã¹ã¦ã‚’ã‚¢ã‚»ãƒ³ãƒ–ãƒªè¨€èªžã§è¨˜è¿°ã—ãŸå ´åˆã«æ¯”
-べて実行性能が落ちるのはやむをえない．
-
-メモリ使用量については，RAMの使用量を削減することに重点を置いた設計を行
-うが，上記の方針および実行性能とのトレードオフを考æ
-®ã—，ぎりぎりまでの
-削減は行わない．
-
-(5) スケーラビリティにé
-æ
-®ã™ã‚‹
-
-様ã€
-ãªè¦æ¨¡ã®ã‚·ã‚¹ãƒ†ãƒ ã«é©ç”¨ã§ãã‚‹ã‚¹ã‚±ãƒ¼ãƒ©ãƒ“ãƒªãƒ†ã‚£ã‚’ã‚‚ã£ãŸæ§‹é€ ã¨ã™ã‚‹ï¼Žç‰¹
-に，小規模なシステムに適用する際に，使用しない機能をカーネルが持ってい
-ã‚‹ã“ã¨ã«ã‚ˆã‚‹ãƒ¡ãƒ¢ãƒªä½¿ç”¨é‡ã®å¢—åŠ ãŒæœ€å°é™ã«ãªã‚‹ã‚ˆã†ã«é
-æ
-®ã™ã‚‹ï¼Ž
-
-å
-·ä½“的には，アプリケーションとカーネルを1つのロードモジュールにリンクす
-る方法（1リンクモデル）を想定し，カーネルを関数単位でライブラリ化して，
-ä½¿ç”¨ã™ã‚‹é–¢æ•°ã®ã¿ã‚’ãƒªãƒ³ã‚¯ã§ãã‚‹æ§‹é€ ã¨ã™ã‚‹ï¼Žã“ã‚Œã¯ä¸€ç¨®ã®ã‚³ãƒ³ãƒ•ã‚£ã‚®ãƒ¥ãƒ¬ãƒ¼
-ションであるが，この方法は，条件コンパイルによるコンフィギュレーション
-とは違い，検証工数に与える影響が小さい．
-
-また，固定的に使用するRAMé ˜åŸŸã‚’æ¸›ã‚‰ã—ï¼Œã‚¹ã‚¿ãƒƒã‚¯ã«ç½®ã‘ã‚‹æƒ
-å ±ã¯ã§ãã‚‹é™ã‚Š
-スタック上に置く．
-
-
-○システム状æ
-‹ã¨ã‚³ãƒ³ãƒ†ã‚­ã‚¹ãƒˆã®å®Ÿè£
-
-
-ã“ã®ç« ã§ã¯ï¼Œã€ŒTOPPERS新世代カーネル統合仕様書」の「2.5 システム状æ
-‹ã¨ã‚³
-ンテキスト」の節に規定されているシステム状æ
-‹ã¨ã‚³ãƒ³ãƒ†ã‚­ã‚¹ãƒˆã®å®Ÿè£
-方法に
-ついて記述する．
-
-●カーネル動作状æ
-‹ã¨éžå‹•ä½œçŠ¶æ
-‹
-
-カーネルの動作状æ
-‹ã‚’管理するために，カーネル動作状æ
-‹ãƒ•ãƒ©ã‚°ï¼ˆkerflg）を
-用意する．kerflgは，スタートアップモジュールでfalse（＝0）に初期化する．
-また，カーネル動作の開始時にtrueにし，カーネル動作の終了時にfalseにする．
+○目次
+
+・TOPPERS/ASPカーネルの実装設計方針
+・システム状態とコンテキストの実装
+        - カーネル動作状態と非動作状態
+        - タスクコンテキストと非タスクコンテキスト
+        - 全割込みロック状態と全割込みロック解除状態
+        - CPUロック状態とCPUロック解除状態
+        - 割込み優先度マスク
+        - ディスパッチ禁止状態とディスパッチ許可状態
+        - ディスパッチ保留状態
+・タスク状態の管理とスケジューリング
+        - タスク状態の管理
+        - タスクスケジューラ
+・タスクディスパッチ処理の実装
+        - タスクディスパッチ処理の必要なタイミング
+        - タスクディスパッチャの構造
+        - タスクの終了時のタスクディスパッチ
+        - reqflgの導入理由
+・タスク例外処理機能の実装
+        - タスク例外処理ルーチンの実行開始条件とシステム状態（仕様の確認）
+        - タスク例外処理ルーチンの呼出し処理
+        - タスク例外処理ルーチンの実行開始が必要なタイミング
+        - タスク例外処理ルーチンの実行開始処理
+        - call_texrtnからdispatchを呼び出す処理について
+・エラーのチェック順序
+        - エラーの3分類
+        - 静的エラーのチェック順序
+        - 準静的エラーのチェック順序
+・CHECKマクロとgoto文の使用
+        - CHECKマクロの定義とその使用法
+        - 設計意図
+        - CHECKマクロを使用してよい条件
+        - 問題を生じることがない根拠
+・ext_tsk，ext_kerの返り値
+・カーネルのデータ構造に対するvolatile宣言について
+・型キャストに伴う警告メッセージ
+・性能評価用システム時刻参照機能
+        - 必要性と使途
+        - API仕様
+        - 実装
+・タスク例外処理禁止フラグをenatexで実装している理由
+
+
+○TOPPERS/ASPカーネルの実装設計方針
+
+TOPPERS/ASPカーネル（以下，ASPカーネル）は，TOPPERS新世代カーネルの出発
+点となるリアルタイムカーネルである．TOPPERS新世代カーネル仕様の設計方針
+と，ASPカーネルの適用対象領域と設計方針については，TOPPERS新世代カーネ
+ル統合仕様書に述べられている．
+
+以下では，ASPカーネルの実装設計方針について述べるが，仕様設計方針とも関
+連しており，明確に分離できない部分もある．
+
+TOPPERS/ASPカーネルの実装設計を行うにあたり，次の方針を設定する．
+
+(1) ソースコードの読みやすさ・改造しやすさを重視する
+
+ソースコードが読みやすいことは，オープンソースソフトウェアの品質を向上
+させる上で最も重要な特性である．ソースコードを理解している技術者が増え
+ることで，問題を早期に発見することができ，サポート体制も充実させること
+ができる．また，ソースコードが読みやすいことは，シンプルな設計がされて
+いることも意味しており，信頼性向上にもつながる．さらに，技術者教育のた
+めの教材とする観点からも，ソースコードが読みやすいことは重要となる．
+
+改造しやすいことは，システム毎の要求にあわせたチューニングが行いやすい
+ことを意味しており，擦り合わせ型の開発を支援する性質である．また，ASPカー
+ネルを基盤としてTOPPERS新世代カーネルシリーズを開発していく上でも，改造
+しやすいことは必須の条件である．
+
+(2) 新しいターゲットシステムへのポーティングが容易な構造とする
+
+組込みシステムには多様なハードウェアが用いられるため，それらに容易にポー
+ティングできることは重要な性質である．そのために，実行性能に配慮しつつ
+ハードウェアを抽象化し，ターゲットシステムに依存する部分（ターゲット依
+存部）と依存しない部分（ターゲット非依存部）を明確に分離する．また，開
+発環境（コンパイラなど）に依存する部分も明確に分離する．
+
+(3) 検証が容易な構造とする
+
+信頼性を確保するために，検証が容易な構造とする．
+
+具体的には，サービスコールのほとんど全体を割込み禁止で実行することとし，
+サービスコールの処理途中で割込みを許可しない．この構造は，読みやすく改
+造しやすいソースコードにするためにも有効である．これにより割込み応答性
+が犠牲になるが，それによって問題を生じるアプリケーションは少数であり，
+やむをえないものと考える．
+
+また，条件コンパイル等によりコンフィギュレーションできる箇所を増やすと，
+細かな最適化ができる一方で，検証すべき組合せが増えることから，コンフィ
+ギュレーションできる箇所は必要最低限とする．
+
+(4) 実行性能とメモリ使用量に配慮する
+
+上記の方針を満たした上で，高い実行性能と小さいメモリ使用量を達成できる
+ような実装を行う．実行性能を向上させる際には，平均性能の向上よりも，最
+悪時性能の向上を重視する．
+
+ソースコードの読みやすさを重視すると言っても，実行性能の悪いアルゴリズ
+ムを安易に採用することはせず，高い実行性能を達成できるアルゴリズムを用
+いる．ただし，新しいターゲットシステムへのポーティングを容易にするため
+に大部分をC言語で実装しており，すべてをアセンブリ言語で記述した場合に比
+べて実行性能が落ちるのはやむをえない．
+
+メモリ使用量については，RAMの使用量を削減することに重点を置いた設計を行
+うが，上記の方針および実行性能とのトレードオフを考慮し，ぎりぎりまでの
+削減は行わない．
+
+(5) スケーラビリティに配慮する
+
+様々な規模のシステムに適用できるスケーラビリティをもった構造とする．特
+に，小規模なシステムに適用する際に，使用しない機能をカーネルが持ってい
+ることによるメモリ使用量の増加が最小限になるように配慮する．
+
+具体的には，アプリケーションとカーネルを1つのロードモジュールにリンクす
+る方法（1リンクモデル）を想定し，カーネルを関数単位でライブラリ化して，
+使用する関数のみをリンクできる構造とする．これは一種のコンフィギュレー
+ションであるが，この方法は，条件コンパイルによるコンフィギュレーション
+とは違い，検証工数に与える影響が小さい．
+
+また，固定的に使用するRAM領域を減らし，スタックに置ける情報はできる限り
+スタック上に置く．
+
+
+○システム状態とコンテキストの実装
+
+この章では，「TOPPERS新世代カーネル統合仕様書」の「2.5 システム状態とコ
+ンテキスト」の節に規定されているシステム状態とコンテキストの実装方法に
+ついて記述する．
+
+●カーネル動作状態と非動作状態
+
+カーネルの動作状態を管理するために，カーネル動作状態フラグ（kerflg）を
+用意する．kerflgは，スタートアップモジュールでfalse（＝0）に初期化する．
+また，カーネル動作の開始時にtrueにし，カーネル動作の終了時にfalseにする．
 
 ----------------------------------------
@@ -266 +189 @@
 ----------------------------------------
 
-kerflgは，sns_kerで参ç
-§ã™ã‚‹ï¼Žã‚«ãƒ¼ãƒãƒ«éžå‹•ä½œçŠ¶æ
-‹ã§sns_ker以外のサービス
-ã‚³ãƒ¼ãƒ«ã‚’å‘¼ã³å‡ºã—ãŸå ´åˆã®å‹•ä½œã¯ä¿è¨¼ã™ã‚‹å¿
-要がないため，他のサービスコー
-ルではkerflgを参ç
-§ã—ない．
-
-●タスクコンテキストと非タスクコンテキスト
-
-タスクコンテキストと非タスクコンテキストの切換えは，ターゲットハードウェ
-アおよびターゲット依存部に委ねる．また，どちらのコンテキストで実行中で
-あるかを判別する関数（sense_context）も，ターゲット依存部で用意すること
-とする．
-
-●å
-¨å‰²è¾¼ã¿ãƒ­ãƒƒã‚¯çŠ¶æ
-‹ã¨å
-¨å‰²è¾¼ã¿ãƒ­ãƒƒã‚¯è§£é™¤çŠ¶æ
-‹
-
-å
-¨å‰²è¾¼ã¿ãƒ­ãƒƒã‚¯ãƒ•ãƒ©ã‚°ã®ç®¡ç†ã¯ã‚¿ãƒ¼ã‚²ãƒƒãƒˆä¾å­˜éƒ¨ã«å§”ね，å
-¨å‰²è¾¼ã¿ãƒ­ãƒƒã‚¯çŠ¶æ
-‹
-に遷移させるマクロ（SIL_LOC_INT）と，å
-ƒã®çŠ¶æ
-‹ã«æˆ»ã™ãƒžã‚¯ãƒ­ï¼ˆSIL_UNL_INT）
-は，SILのターゲット依存部で用意することとする．å
-¨å‰²è¾¼ã¿ãƒ­ãƒƒã‚¯çŠ¶æ
-‹ã§ã‚ã‚‹
-か否かを判別する機能は，å¿
-要がないために用意していない．
-
-å
-¨å‰²è¾¼ã¿ãƒ­ãƒƒã‚¯çŠ¶æ
-‹ã§sns_kerとext_kerä»¥å¤–ã®ã‚µãƒ¼ãƒ“ã‚¹ã‚³ãƒ¼ãƒ«ã‚’å‘¼ã³å‡ºã—ãŸå ´
-合の動作は保証するå¿
-要がないため，サービスコール中でå
-¨å‰²è¾¼ã¿ãƒ­ãƒƒã‚¯çŠ¶æ
-‹
-であることを判別するå¿
-要はない．
-
-●CPUロック状æ
-‹ã¨CPUロック解除状æ
-‹
-
-CPUロックフラグの管理はターゲット依存部に委ね，CPUロック状æ
-‹ã«é·ç§»ã•ã›
-る関数（t_lock_cpu／i_lock_cpu／x_lock_cpu）と，CPUロック解除状æ
-‹ã«é·ç§»
-させる関数（t_unlock_cpu／i_unlock_cpu／x_unlock_cpu）は，ターゲット依
-存部で用意することとする．また，CPUロック状æ
-‹ã§ã‚るか否かを判別する関数
-（t_sense_lock／i_sense_lock／x_sense_lock）も，ターゲット依存部で用意
-することとする．
-
-●割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯
-
-割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ã®ç®¡ç†ã¯ã‚¿ãƒ¼ã‚²ãƒƒãƒˆä¾å­˜éƒ¨ã«å§”ね，割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ã‚’
-設定する関数（t_set_ipm／i_set_ipm／x_set_ipm）と，それを参ç
-§ã™ã‚‹é–¢æ•°
-（t_get_ipm／i_get_ipm／x_get_ipm）は，ターゲット依存部で用意することと
-する．
-
-ただし，タスクコンテキストの実行中に，割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã§ã‚
-ることを効率的に判断するために，割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã§ã‚ること
-を示すフラグ（ipmflg）を用意する．
-
-ipmflgは，カーネルの初期化時にfalseに初期化する．非タスクコンテキストで
-は，割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã«ãªã‚‹ã“とはないため，このフラグを用い
-るå¿
-要はなく，フラグの更新も行わない．
+kerflgは，sns_kerで参照する．カーネル非動作状態でsns_ker以外のサービス
+コールを呼び出した場合の動作は保証する必要がないため，他のサービスコー
+ルではkerflgを参照しない．
+
+●タスクコンテキストと非タスクコンテキスト
+
+タスクコンテキストと非タスクコンテキストの切換えは，ターゲットハードウェ
+アおよびターゲット依存部に委ねる．また，どちらのコンテキストで実行中で
+あるかを判別する関数（sense_context）も，ターゲット依存部で用意すること
+とする．
+
+●全割込みロック状態と全割込みロック解除状態
+
+全割込みロックフラグの管理はターゲット依存部に委ね，全割込みロック状態
+に遷移させるマクロ（SIL_LOC_INT）と，元の状態に戻すマクロ（SIL_UNL_INT）
+は，SILのターゲット依存部で用意することとする．全割込みロック状態である
+か否かを判別する機能は，必要がないために用意していない．
+
+全割込みロック状態でsns_kerとext_ker以外のサービスコールを呼び出した場
+合の動作は保証する必要がないため，サービスコール中で全割込みロック状態
+であることを判別する必要はない．
+
+●CPUロック状態とCPUロック解除状態
+
+CPUロックフラグの管理はターゲット依存部に委ね，CPUロック状態に遷移させ
+る関数（t_lock_cpu／i_lock_cpu／x_lock_cpu）と，CPUロック解除状態に遷移
+させる関数（t_unlock_cpu／i_unlock_cpu／x_unlock_cpu）は，ターゲット依
+存部で用意することとする．また，CPUロック状態であるか否かを判別する関数
+（t_sense_lock／i_sense_lock／x_sense_lock）も，ターゲット依存部で用意
+することとする．
+
+●割込み優先度マスク
+
+割込み優先度マスクの管理はターゲット依存部に委ね，割込み優先度マスクを
+設定する関数（t_set_ipm／i_set_ipm／x_set_ipm）と，それを参照する関数
+（t_get_ipm／i_get_ipm／x_get_ipm）は，ターゲット依存部で用意することと
+する．
+
+ただし，タスクコンテキストの実行中に，割込み優先度マスク全解除状態であ
+ることを効率的に判断するために，割込み優先度マスク全解除状態であること
+を示すフラグ（ipmflg）を用意する．
+
+ipmflgは，カーネルの初期化時にfalseに初期化する．非タスクコンテキストで
+は，割込み優先度マスク全解除状態になることはないため，このフラグを用い
+る必要はなく，フラグの更新も行わない．
 
 ----------------------------------------
@@ -357 +239 @@
 ----------------------------------------
 
-●ディスパッチ禁止状æ
-‹ã¨ãƒ‡ã‚£ã‚¹ãƒ‘ッチ許可状æ
-‹
-
-ディスパッチ禁止フラグを管理するために，フラグ（disdsp）を用意する．
-disdspは，カーネルの初期化時にfalseに初期化する．
+●ディスパッチ禁止状態とディスパッチ許可状態
+
+ディスパッチ禁止フラグを管理するために，フラグ（disdsp）を用意する．
+disdspは，カーネルの初期化時にfalseに初期化する．
 
 ----------------------------------------
@@ -368 +248 @@
 ----------------------------------------
 
-※ disdspではなく，それを論理反転したenadspを用意した方が，ipmflgや
-dspflgとの整合性の観点からは良かった．
-
-●ディスパッチ保留状æ
-‹
-
-ディスパッチ保留状æ
-‹ã¯ï¼Œéžã‚¿ã‚¹ã‚¯ã‚³ãƒ³ãƒ†ã‚­ã‚¹ãƒˆã®å®Ÿè¡Œä¸­ï¼ŒCPUロック状æ
-‹ï¼Œå‰²
-込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ãŒå
-¨è§£é™¤ã§ãªã„状æ
-‹ï¼Œãƒ‡ã‚£ã‚¹ãƒ‘ッチ禁止状æ
-‹ã®ã„ずれか（ま
-たは，それらが重なった状æ
-‹ï¼‰ã§ã‚る．
-
-タスクコンテキストの実行中に，ディスパッチ保留状æ
-‹ã§ãªã„こと（つまり，
-ディスパッチできる状æ
-‹ã§ã‚ること）を効率的に判別するために，割込み優å
-ˆ
-度マスクå
-¨è§£é™¤çŠ¶æ
-‹ã§ã‚り，ディスパッチ許可状æ
-‹ã§ã‚る（ディスパッチ禁止
-状æ
-‹ã§ãªã„）ことを示すフラグ（dspflg）を用意する．すなわち，常に
-「dspflg == (ipmflg && !disdsp)」に設定する．
-
-dspflgは，カーネルの初期化時にtrueに初期化する．また，タスクコンテキス
-トにおいて割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ã®å€¤ãŒå¤‰æ›´ã•ã‚Œã‚‹ã‹ï¼Œå‰²è¾¼ã¿ç¦æ­¢ãƒ•ãƒ©ã‚°ãŒå¤‰æ›´
-される度に更新する．非タスクコンテキストでは，常にディスパッチ保留状æ
-‹
-であるため，このフラグを用いるå¿
-要はなく，フラグの更新も行わない．
+※ disdspではなく，それを論理反転したenadspを用意した方が，ipmflgや
+dspflgとの整合性の観点からは良かった．
+
+●ディスパッチ保留状態
+
+ディスパッチ保留状態は，非タスクコンテキストの実行中，CPUロック状態，割
+込み優先度マスクが全解除でない状態，ディスパッチ禁止状態のいずれか（ま
+たは，それらが重なった状態）である．
+
+タスクコンテキストの実行中に，ディスパッチ保留状態でないこと（つまり，
+ディスパッチできる状態であること）を効率的に判別するために，割込み優先
+度マスク全解除状態であり，ディスパッチ許可状態である（ディスパッチ禁止
+状態でない）ことを示すフラグ（dspflg）を用意する．すなわち，常に
+「dspflg == (ipmflg && !disdsp)」に設定する．
+
+dspflgは，カーネルの初期化時にtrueに初期化する．また，タスクコンテキス
+トにおいて割込み優先度マスクの値が変更されるか，割込み禁止フラグが変更
+される度に更新する．非タスクコンテキストでは，常にディスパッチ保留状態
+であるため，このフラグを用いる必要はなく，フラグの更新も行わない．
 
 ----------------------------------------
@@ -411 +273 @@
 
 
-○タスク状æ
-‹ã®ç®¡ç†ã¨ã‚¹ã‚±ã‚¸ãƒ¥ãƒ¼ãƒªãƒ³ã‚°
+○タスク状態の管理とスケジューリング
         
-●タスク状æ
-‹ã®ç®¡ç†
-
-タスク管理ブロック（TCB）中のタスク状æ
-‹ã‚’管理するフィールド（tstat）で
-は，タスク状æ
-‹ãŒæ¬¡ã®ã„ずれであるかを管理する．
-
-　・実行できる状æ
-‹
-　・休止状æ
-‹
-　・（狭義の）å¾
-ち状æ
-‹
-　・強制å¾
-ち状æ
-‹
-　・二重å¾
-ち状æ
-‹
-
-タスクが実行できる状æ
-‹ã®æ™‚に，実行状æ
-‹ã§ã‚るか実行可能状æ
-‹ã§ã‚るかは，
-このフィールドでは管理せず，実行状æ
-‹ã®ã‚¿ã‚¹ã‚¯ã®TCBを指すポインタ変数
-（p_runtsk）によって判別する．実行状æ
-‹ã®ã‚¿ã‚¹ã‚¯ãŒãªã„å ´åˆã¯ï¼Œp_runtskは
-NULLにする．
+●タスク状態の管理
+
+タスク管理ブロック（TCB）中のタスク状態を管理するフィールド（tstat）で
+は，タスク状態が次のいずれであるかを管理する．
+
+　・実行できる状態
+　・休止状態
+　・（狭義の）待ち状態
+　・強制待ち状態
+　・二重待ち状態
+
+タスクが実行できる状態の時に，実行状態であるか実行可能状態であるかは，
+このフィールドでは管理せず，実行状態のタスクのTCBを指すポインタ変数
+（p_runtsk）によって判別する．実行状態のタスクがない場合は，p_runtskは
+NULLにする．
 
 ----------------------------------------
@@ -450 +295 @@
 ----------------------------------------
 
-p_runtskは，カーネルの初期化時にNULLに初期化し，ディスパッチャにおいて
-更新する．サービスコールの処理の中で自タスクに関するæƒ
-å ±ã‚’å‚ç
-§ã™ã‚‹å ´åˆ
-は，p_runtskを用いる．
-
-●タスクスケジューラ
-
-タスクスケジューラは，実行できる状æ
-‹ã®ã‚¿ã‚¹ã‚¯ã®ä¸­ã‹ã‚‰ï¼Œæœ€ã‚‚優å
-ˆé †ä½ãŒé«˜
-いタスク（これを，最高優å
-ˆé †ä½ã®ã‚¿ã‚¹ã‚¯ã¨å‘¼ã¶ï¼‰ã‚’決定し，そのタスクの
-TCBを指すポインタ変数（p_schedtsk）を設定する．
+p_runtskは，カーネルの初期化時にNULLに初期化し，ディスパッチャにおいて
+更新する．サービスコールの処理の中で自タスクに関する情報を参照する場合
+は，p_runtskを用いる．
+
+●タスクスケジューラ
+
+タスクスケジューラは，実行できる状態のタスクの中から，最も優先順位が高
+いタスク（これを，最高優先順位のタスクと呼ぶ）を決定し，そのタスクの
+TCBを指すポインタ変数（p_schedtsk）を設定する．
 
 ----------------------------------------
@@ -469 +309 @@
 ----------------------------------------
 
-タスクスケジューラに対しては，どのタスクが実行できる状æ
-‹ã§ã‚るかを知ら
-せるå¿
-要がある．そのため，タスクスケジューラは，次の2つの関数を用意する．
-
-　・タスクが実行できる状æ
-‹ã«é·ç§»ã—たことを知らせる関数（make_runnable）
-　・タスクが実行できる状æ
-‹ã‹ã‚‰ä»–の状æ
-‹ã¸é·ç§»ã—たことを知らせる関数
-        （make_non_runnable）
-
-また，処理の効率化のために，上の2つの関数を用いずにレディキューを直接操
-作してタスクスケジュールを行う関数として，次の2つの関数を用意する．
-
-　・タスクの優å
-ˆåº¦ã®å¤‰æ›´ï¼ˆchange_priority）
-　・レディキューの回転（rotate_ready_queue）
-
-
-○タスクディスパッチ処理の実è£
-
-
-●タスクディスパッチ処理のå¿
-要なタイミング
-
-タスクディスパッチは，実行状æ
-‹ã®ã‚¿ã‚¹ã‚¯ï¼ˆp_runtsk）と最高優å
-ˆé †ä½ã®ã‚¿ã‚¹
-ク（p_schedtsk）が一致しておらず，ディスパッチ保留状æ
-‹ã§ãªã„å ´åˆã«è¡Œã†ï¼Ž
-このことから，タスクディスパッチ処理を行うå¿
-要があるのは，次の3ã¤ã®å ´åˆ
-である．
-
-(1) 実行状æ
-‹ã®ã‚¿ã‚¹ã‚¯ãŒå®Ÿè¡Œã§ãã‚‹çŠ¶æ
-‹ã§ãªããªã‚‹
-
-自タスクを広義のå¾
-ち状æ
-‹ã«é·ç§»ã•ã›ã‚‹ã‚µãƒ¼ãƒ“スコールや，自タスクを終了さ
-せるサービスコールにおいて，タスクディスパッチ処理を行うå¿
-要がある．
-
-(2) 最高優å
-ˆé †ä½ã®ã‚¿ã‚¹ã‚¯ãŒå¤‰åŒ–する
-
-タスクの起動，タスクのå¾
-ち解除，タスクの強制å¾
-ちからの再開，タスクの優
-å
-ˆåº¦ã®å¤‰æ›´ï¼Œã‚¿ã‚¹ã‚¯ã®å„ªå
-ˆé †ä½ã®å›žè»¢ã‚’行うサービスコールにおいて，最高優
-å
-ˆé †ä½ã®ã‚¿ã‚¹ã‚¯ãŒå¤‰åŒ–し，ディスパッチ保留状æ
-‹ã§ãªã„å ´åˆã«ã¯ï¼Œã‚¿ã‚¹ã‚¯ãƒ‡ã‚£
-スパッチ処理を行うå¿
-要がある．
-
-(3) ディスパッチ保留状æ
-‹ãŒè§£é™¤ã•ã‚Œã‚‹
-
-ディスパッチ保留状æ
-‹ã¨ã¯ï¼Œéžã‚¿ã‚¹ã‚¯ã‚³ãƒ³ãƒ†ã‚­ã‚¹ãƒˆã®å®Ÿè¡Œä¸­ï¼ŒCPUロック状æ
-‹ï¼Œ
-割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ãŒå
-¨è§£é™¤ã§ãªã„状æ
-‹ï¼Œãƒ‡ã‚£ã‚¹ãƒ‘ッチ禁止状æ
-‹ã®ç·ç§°ã§ã‚ã‚‹
-ため，これらの状æ
-‹ã®ã„ずれかが遷移するタイミングで，タスクディスパッチ
-処理を行うå¿
-要がある．å
-·ä½“的には，次のタイミングが該当する．
-
-(3-1) 非タスクコンテキストからタスクコンテキストに遷移する
-
-割込みハンドラまたはCPU例外ハンドラからタスクにリターンする際に，タスク
-ディスパッチ処理を行うå¿
-要がある．
-
-(3-2) CPUロック状æ
-‹ãŒè§£é™¤ã•ã‚Œã‚‹
-
-CPUロック状æ
-‹ã«ãŠã„ては，上記の(1)や(2)の状況を作り出すサービスコールを
-呼び出すことができない．そのため，CPUロック状æ
-‹ã®è§£é™¤æ™‚には，タスクディ
-スパッチ処理を行うå¿
-要がない．
-
-(3-3) 割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ãŒå
-¨è§£é™¤ã•ã‚Œã‚‹
-
-割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ã®å¤‰æ›´ï¼ˆchg_ipm）により割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ãŒå
-¨è§£é™¤ã•ã‚Œ
-ã‚‹å ´åˆã«ï¼Œã‚¿ã‚¹ã‚¯ãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒå‡¦ç†ã‚’è¡Œã†å¿
-要がある．
-
-また，タスクの終了，タスク例外処理ルーチンからのリターン，割込みハンド
-ラからのリターン，割込みサービスルーチンからのリターン，タイムイベント
-ハンドラからのリターン，CPU例外ハンドラからのリターンによって，割込み優
-å
-ˆåº¦ãƒžã‚¹ã‚¯ãŒå
-¨è§£é™¤ã•ã‚Œã‚‹å ´åˆãŒã‚ã‚Šï¼Œãã®å ´åˆã«ã¯ï¼Œã‚¿ã‚¹ã‚¯ãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒå‡¦
-理を行うå¿
-要がある．ただし，割込みサービスルーチンおよびタイムイベント
-ハンドラからのリターンについては，リターン後も非タスクコンテキストであ
-り，タスクディスパッチ保留状æ
-‹ãŒç¶™ç¶šã™ã‚‹ã“とから，タスクディスパッチ処
-理を行うå¿
-要がない．
-
-(3-4) ディスパッチ許可状æ
-‹ã«ãªã‚‹
-
-ディスパッチの許可（ena_dsp）において，タスクディスパッチ処理を行うå¿
-要
-がある．
-
-また，タスクの終了とタスク例外処理ルーチンからのリターンによって，ディ
-スパッチ許可状æ
-‹ã«ãªã‚‹å ´åˆãŒã‚ã‚Šï¼Œãã®å ´åˆã«ã¯ï¼Œã‚¿ã‚¹ã‚¯ãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒå‡¦ç†
-を行うå¿
-要がある．
-
-ä»¥ä¸Šã«åŠ ãˆã¦ï¼Œã‚«ãƒ¼ãƒãƒ«ã®å‹•ä½œé–‹å§‹æ™‚ã«ã‚‚ï¼Œã‚¿ã‚¹ã‚¯ãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒå‡¦ç†ã‚’å‘¼ã³å‡º
-す．
-
-â—ã‚¿ã‚¹ã‚¯ãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒãƒ£ã®æ§‹é€ 
-
-タスクディスパッチャの主な機能は，切換え前のタスクのコンテキスト（プロ
-セッサの汎用レジスタ等）をメモリ上に保存し，切換え後のタスクのコンテキ
-ストをメモリ上から復帰することである．ここで，保存／復帰しなければなら
-ないレジスタは，タスクディスパッチャが実行される状況によって，次のよう
-な違いがある．
-
-・タスクが割込み（または，CPUä¾‹å¤–ï¼‰ã«ã‚ˆã‚Šãƒ—ãƒªã‚¨ãƒ³ãƒ—ãƒˆã•ã‚Œã‚‹å ´åˆã«ã¯ï¼Œã™
-　べてのレジスタを保存しなければならない．また，その状æ
-‹ã‹ã‚‰å®Ÿè¡Œå†é–‹ã™
-ã€€ã‚‹å ´åˆã«ã¯ï¼Œã™ã¹ã¦ã®ãƒ¬ã‚¸ã‚¹ã‚¿ã‚’å¾©å¸°ã—ãªã‘ã‚Œã°ãªã‚‰ãªã„ï¼Ž
-
-ãƒ»ã‚¿ã‚¹ã‚¯ãŒè‡ªç™ºçš„ã«ã‚¿ã‚¹ã‚¯ãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒãƒ£ã‚’å‘¼ã³å‡ºã™å ´åˆã«ã¯ï¼Œã‚¹ã‚¯ãƒ©ãƒƒãƒãƒ¬
-　ジスタ（caller saved register）以外のレジスタを保存すればよい．また，
-　その状æ
-‹ã‹ã‚‰å®Ÿè¡Œå†é–‹ã™ã‚‹å ´åˆã«ã¯ï¼Œã‚¹ã‚¯ãƒ©ãƒƒãƒãƒ¬ã‚¸ã‚¹ã‚¿ä»¥å¤–のレジスタを
-　復帰すればよい．
-
-ãƒ»ã‚¿ã‚¹ã‚¯ãŒçµ‚äº†ã™ã‚‹å ´åˆã«ã¯ï¼Œã©ã®ãƒ¬ã‚¸ã‚¹ã‚¿ã‚‚ä¿å­˜ã™ã‚‹å¿
-要がない．
-
-ãƒ»ã‚¿ã‚¹ã‚¯ãŒå®Ÿè¡Œé–‹å§‹ã™ã‚‹å ´åˆã«ã¯ï¼Œã©ã®ãƒ¬ã‚¸ã‚¹ã‚¿ã‚‚å¾©å¸°ã™ã‚‹å¿
-要がない．
-
-そこで，それぞれの状況でå¿
-要最低限のレジスタのみを保存／復帰するために，
-タスクディスパッチ処理を，(a) コンテキストの保存処理，(b) 実行するタス
-クの選択処理，(c) コンテキストの復帰処理の3つのステップで構成し，(a)と
-(c)のステップについては，タスクディスパッチャが実行される状況毎に用意す
-る．å
-·ä½“的には，次の各処理を行うルーチンを用意する．
-
-(a) コンテキストの保存処理
-        (a-1) ã‚¿ã‚¹ã‚¯ãŒè‡ªç™ºçš„ã«å‘¼ã³å‡ºã—ãŸå ´åˆã®ä¿å­˜å‡¦ç†ï¼ˆdispatch）
-        (a-2) å‰²è¾¼ã¿ãƒãƒ³ãƒ‰ãƒ©ã®å‡ºå£ã§å‘¼ã³å‡ºã•ã‚ŒãŸå ´åˆã®ä¿å­˜å‡¦ç†ï¼ˆret_int）
-        (a-3) CPUä¾‹å¤–ãƒãƒ³ãƒ‰ãƒ©ã®å‡ºå£ã§å‘¼ã³å‡ºã•ã‚ŒãŸå ´åˆã®ä¿å­˜å‡¦ç†ï¼ˆret_exc）
-        (a-4) タスクの終了時の処理（exit_and_dispatch）
-        (a-5) カーネルの動作開始時の処理（start_dispatch）
-(b) 実行するタスクの選択（ディスパッチャ本体，dispatcher）
-(c) コンテキストの復帰処理
-        (c-1) ã‚¿ã‚¹ã‚¯ãŒè‡ªç™ºçš„ã«å‘¼ã³å‡ºã—ãŸå ´åˆã®å¾©å¸°å‡¦ç†ï¼ˆdispatch_r）
-        (c-2) å‰²è¾¼ã¿ãƒãƒ³ãƒ‰ãƒ©ã®å‡ºå£ã§å‘¼ã³å‡ºã•ã‚ŒãŸå ´åˆã®å¾©å¸°å‡¦ç†ï¼ˆret_int_r）
-        (c-3) CPUä¾‹å¤–ãƒãƒ³ãƒ‰ãƒ©ã®å‡ºå£ã§å‘¼ã³å‡ºã•ã‚ŒãŸå ´åˆã®å¾©å¸°å‡¦ç†ï¼ˆret_exc_r）
-        (c-4) タスクの実行開始時の処理（start_r）
-
-●タスクの終了時のタスクディスパッチ
-
-ext_tskによるタスクの終了時に，起動要求がキューイングされていると，同じ
-ã‚¿ã‚¹ã‚¯ãŒã™ãã«èµ·å‹•ã•ã‚Œã‚‹ï¼Žã“ã®å ´åˆï¼Œã‚¿ã‚¹ã‚¯ãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒãƒ£ã«ã¨ã£ã¦ã¯ï¼ŒåŒ
-じタスクへの切換えに見え，タスクディスパッチ処理をスキップ可能に思える
-が，実際には，同じタスクの異なるインスタンスへの切換えであるため，タス
-クディスパッチ処理をスキップしてはならない．
-
-ä¸Šè¿°ã®ã‚¿ã‚¹ã‚¯ãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒãƒ£ã®æ§‹é€ ã«ã‚ˆã‚Šï¼Œã‚¿ã‚¹ã‚¯ã®çµ‚äº†æ™‚ã«ã¯ï¼Œãã‚Œå°‚ç”¨ã®
-処理（exit_and_dispatch）を呼び出す．この処理では，実行状æ
-‹ã®ã‚¿ã‚¹ã‚¯ã‚’参
-ç
-§ã›ãšï¼Œã‚³ãƒ³ãƒ†ã‚­ã‚¹ãƒˆã®ä¿å­˜ã‚‚行わずに，次に事é 
-するタスクの選択処理を行
-うため，タスクディスパッチ処理がスキップされることはない．
-
-なお，ter_tskによって実行状æ
-‹ã®ã‚¿ã‚¹ã‚¯ã‚’終了させることはできないため，
-ter_tskではこのような状況は起こらない．
-
-●reqflgの導å
-¥ç†ç”±
-
-割込みハンドラ／CPU例外ハンドラの出口処理に，タスクディスパッチまたはタ
-スク例外処理ルーチンの実行開始を要求することを示すフラグとして，reqflg
-を用意している．非タスクコンテキストにおいて，タスクディスパッチがå¿
-要
-ã«ãªã£ãŸå ´åˆã‚„ï¼Œã‚¿ã‚¹ã‚¯ä¾‹å¤–å‡¦ç†ãƒ«ãƒ¼ãƒãƒ³ã®å®Ÿè¡Œé–‹å§‹ãŒå¿
-è¦ã«ãªã£ãŸå ´åˆã«ã¯ï¼Œ
-このフラグをセットする．
-
-reqflgを導å
-¥ã—た理由は，割込みハンドラ／CPU例外ハンドラの出口処理のå
-¸åž‹
-的なケース（タスクディスパッチもタスク例外処理ルーチンの実行開始もå¿
-要
-ãªã„å ´åˆï¼‰ã‚’é«˜é€ŸåŒ–ã™ã‚‹ãŸã‚ã§ã‚ã‚‹ï¼Žã¾ãŸï¼Œãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒãƒ£æœ¬ä½“ï¼ˆdispatcher）
-のアイドル処理も高速化できる．
-
-しかし，割込みハンドラ／CPU例外ハンドラの出口処理å
-¨ä½“のオーバヘッドを考
-えると，reqflgによる高速化の効果はそれほど大きくないものと思われる．
-
-
-○タスク例外処理機能の実è£
-
-
-●タスク例外処理ルーチンの実行開始条件とシステム状æ
-‹ï¼ˆä»•æ§˜ã®ç¢ºèªï¼‰
-
-タスク例外処理ルーチンは，次の6ã¤ã®æ¡ä»¶ãŒæƒã£ãŸå ´åˆã«å®Ÿè¡ŒãŒé–‹å§‹ã•ã‚Œã‚‹ï¼Ž
-
-　・タスク例外処理許可状æ
-‹ã§ã‚ã‚‹
-ã€€ãƒ»ä¿ç•™ä¾‹å¤–è¦å› ãŒ0でない
-　・タスクが実行状æ
-‹ã§ã‚ã‚‹
-　・タスクコンテキストが実行されている
-　・割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã§ã‚ã‚‹
-　・CPUロック状æ
-‹ã§ãªã„
-
-また，タスク例外処理ルーチンの実行開始／リターン時のシステム状æ
-‹ã«é–¢ã™
-る仕様は次の通りである．
-
-                                CPUロック            割込み優å
-ˆåº¦    ディスパッチ
-                                フラグ                       マスク                       禁止フラグ
+タスクスケジューラに対しては，どのタスクが実行できる状態であるかを知ら
+せる必要がある．そのため，タスクスケジューラは，次の2つの関数を用意する．
+
+　・タスクが実行できる状態に遷移したことを知らせる関数（make_runnable）
+　・タスクが実行できる状態から他の状態へ遷移したことを知らせる関数
+        （make_non_runnable）
+
+また，処理の効率化のために，上の2つの関数を用いずにレディキューを直接操
+作してタスクスケジュールを行う関数として，次の2つの関数を用意する．
+
+　・タスクの優先度の変更（change_priority）
+　・レディキューの回転（rotate_ready_queue）
+
+
+○タスクディスパッチ処理の実装
+
+●タスクディスパッチ処理の必要なタイミング
+
+タスクディスパッチは，実行状態のタスク（p_runtsk）と最高優先順位のタス
+ク（p_schedtsk）が一致しておらず，ディスパッチ保留状態でない場合に行う．
+このことから，タスクディスパッチ処理を行う必要があるのは，次の3つの場合
+である．
+
+(1) 実行状態のタスクが実行できる状態でなくなる
+
+自タスクを広義の待ち状態に遷移させるサービスコールや，自タスクを終了さ
+せるサービスコールにおいて，タスクディスパッチ処理を行う必要がある．
+
+(2) 最高優先順位のタスクが変化する
+
+タスクの起動，タスクの待ち解除，タスクの強制待ちからの再開，タスクの優
+先度の変更，タスクの優先順位の回転を行うサービスコールにおいて，最高優
+先順位のタスクが変化し，ディスパッチ保留状態でない場合には，タスクディ
+スパッチ処理を行う必要がある．
+
+(3) ディスパッチ保留状態が解除される
+
+ディスパッチ保留状態とは，非タスクコンテキストの実行中，CPUロック状態，
+割込み優先度マスクが全解除でない状態，ディスパッチ禁止状態の総称である
+ため，これらの状態のいずれかが遷移するタイミングで，タスクディスパッチ
+処理を行う必要がある．具体的には，次のタイミングが該当する．
+
+(3-1) 非タスクコンテキストからタスクコンテキストに遷移する
+
+割込みハンドラまたはCPU例外ハンドラからタスクにリターンする際に，タスク
+ディスパッチ処理を行う必要がある．
+
+(3-2) CPUロック状態が解除される
+
+CPUロック状態においては，上記の(1)や(2)の状況を作り出すサービスコールを
+呼び出すことができない．そのため，CPUロック状態の解除時には，タスクディ
+スパッチ処理を行う必要がない．
+
+(3-3) 割込み優先度マスクが全解除される
+
+割込み優先度マスクの変更（chg_ipm）により割込み優先度マスクが全解除され
+る場合に，タスクディスパッチ処理を行う必要がある．
+
+また，タスクの終了，タスク例外処理ルーチンからのリターン，割込みハンド
+ラからのリターン，割込みサービスルーチンからのリターン，タイムイベント
+ハンドラからのリターン，CPU例外ハンドラからのリターンによって，割込み優
+先度マスクが全解除される場合があり，その場合には，タスクディスパッチ処
+理を行う必要がある．ただし，割込みサービスルーチンおよびタイムイベント
+ハンドラからのリターンについては，リターン後も非タスクコンテキストであ
+り，タスクディスパッチ保留状態が継続することから，タスクディスパッチ処
+理を行う必要がない．
+
+(3-4) ディスパッチ許可状態になる
+
+ディスパッチの許可（ena_dsp）において，タスクディスパッチ処理を行う必要
+がある．
+
+また，タスクの終了とタスク例外処理ルーチンからのリターンによって，ディ
+スパッチ許可状態になる場合があり，その場合には，タスクディスパッチ処理
+を行う必要がある．
+
+以上に加えて，カーネルの動作開始時にも，タスクディスパッチ処理を呼び出
+す．
+
+●タスクディスパッチャの構造
+
+タスクディスパッチャの主な機能は，切換え前のタスクのコンテキスト（プロ
+セッサの汎用レジスタ等）をメモリ上に保存し，切換え後のタスクのコンテキ
+ストをメモリ上から復帰することである．ここで，保存／復帰しなければなら
+ないレジスタは，タスクディスパッチャが実行される状況によって，次のよう
+な違いがある．
+
+・タスクが割込み（または，CPU例外）によりプリエンプトされる場合には，す
+　べてのレジスタを保存しなければならない．また，その状態から実行再開す
+　る場合には，すべてのレジスタを復帰しなければならない．
+
+・タスクが自発的にタスクディスパッチャを呼び出す場合には，スクラッチレ
+　ジスタ（caller saved register）以外のレジスタを保存すればよい．また，
+　その状態から実行再開する場合には，スクラッチレジスタ以外のレジスタを
+　復帰すればよい．
+
+・タスクが終了する場合には，どのレジスタも保存する必要がない．
+
+・タスクが実行開始する場合には，どのレジスタも復帰する必要がない．
+
+そこで，それぞれの状況で必要最低限のレジスタのみを保存／復帰するために，
+タスクディスパッチ処理を，(a) コンテキストの保存処理，(b) 実行するタス
+クの選択処理，(c) コンテキストの復帰処理の3つのステップで構成し，(a)と
+(c)のステップについては，タスクディスパッチャが実行される状況毎に用意す
+る．具体的には，次の各処理を行うルーチンを用意する．
+
+(a) コンテキストの保存処理
+        (a-1) タスクが自発的に呼び出した場合の保存処理（dispatch）
+        (a-2) 割込みハンドラの出口で呼び出された場合の保存処理（ret_int）
+        (a-3) CPU例外ハンドラの出口で呼び出された場合の保存処理（ret_exc）
+        (a-4) タスクの終了時の処理（exit_and_dispatch）
+        (a-5) カーネルの動作開始時の処理（start_dispatch）
+(b) 実行するタスクの選択（ディスパッチャ本体，dispatcher）
+(c) コンテキストの復帰処理
+        (c-1) タスクが自発的に呼び出した場合の復帰処理（dispatch_r）
+        (c-2) 割込みハンドラの出口で呼び出された場合の復帰処理（ret_int_r）
+        (c-3) CPU例外ハンドラの出口で呼び出された場合の復帰処理（ret_exc_r）
+        (c-4) タスクの実行開始時の処理（start_r）
+
+●タスクの終了時のタスクディスパッチ
+
+ext_tskによるタスクの終了時に，起動要求がキューイングされていると，同じ
+タスクがすぐに起動される．この場合，タスクディスパッチャにとっては，同
+じタスクへの切換えに見え，タスクディスパッチ処理をスキップ可能に思える
+が，実際には，同じタスクの異なるインスタンスへの切換えであるため，タス
+クディスパッチ処理をスキップしてはならない．
+
+上述のタスクディスパッチャの構造により，タスクの終了時には，それ専用の
+処理（exit_and_dispatch）を呼び出す．この処理では，実行状態のタスクを参
+照せず，コンテキストの保存も行わずに，次に事項するタスクの選択処理を行
+うため，タスクディスパッチ処理がスキップされることはない．
+
+なお，ter_tskによって実行状態のタスクを終了させることはできないため，
+ter_tskではこのような状況は起こらない．
+
+●reqflgの導入理由
+
+割込みハンドラ／CPU例外ハンドラの出口処理に，タスクディスパッチまたはタ
+スク例外処理ルーチンの実行開始を要求することを示すフラグとして，reqflg
+を用意している．非タスクコンテキストにおいて，タスクディスパッチが必要
+になった場合や，タスク例外処理ルーチンの実行開始が必要になった場合には，
+このフラグをセットする．
+
+reqflgを導入した理由は，割込みハンドラ／CPU例外ハンドラの出口処理の典型
+的なケース（タスクディスパッチもタスク例外処理ルーチンの実行開始も必要
+ない場合）を高速化するためである．また，ディスパッチャ本体（dispatcher）
+のアイドル処理も高速化できる．
+
+しかし，割込みハンドラ／CPU例外ハンドラの出口処理全体のオーバヘッドを考
+えると，reqflgによる高速化の効果はそれほど大きくないものと思われる．
+
+
+○タスク例外処理機能の実装
+
+●タスク例外処理ルーチンの実行開始条件とシステム状態（仕様の確認）
+
+タスク例外処理ルーチンは，次の6つの条件が揃った場合に実行が開始される．
+
+　・タスク例外処理許可状態である
+　・保留例外要因が0でない
+　・タスクが実行状態である
+　・タスクコンテキストが実行されている
+　・割込み優先度マスク全解除状態である
+　・CPUロック状態でない
+
+また，タスク例外処理ルーチンの実行開始／リターン時のシステム状態に関す
+る仕様は次の通りである．
+
+                                CPUロック          割込み優先度  ディスパッチ
+                                フラグ                     マスク                     禁止フラグ
 ------------------------------------------------------------
-【タスク例外処理ルーチン】
-実行開始条件      解除                  å
-¨è§£é™¤                 任意
-実行開始時処理   そのまま            そのまま            そのまま
-リターン前         原則解除(*1)        原則å
-¨è§£é™¤(*1)     å
-ƒã«æˆ»ã™
-リターン時処理   解除する            å
-¨è§£é™¤ã™ã‚‹           å
-ƒã«æˆ»ã™(*4)
+【タスク例外処理ルーチン】
+実行開始条件  解除                      全解除                     任意
+実行開始時処理 そのまま            そのまま            そのまま
+リターン前           原則解除(*1)        原則全解除(*1)       元に戻す
+リターン時処理 解除する            全解除する           元に戻す(*4)
 ------------------------------------------------------------
 
-●タスク例外処理ルーチンの呼出し処理
-
-タスク例外処理ルーチンを呼び出す処理は，次の流れとなる．この関数は，
-CPUロック状æ
-‹ã§å‘¼ã³å‡ºã™ã“とを想定している．
+●タスク例外処理ルーチンの呼出し処理
+
+タスク例外処理ルーチンを呼び出す処理は，次の流れとなる．この関数は，
+CPUロック状態で呼び出すことを想定している．
 
 ----------------------------------------
@@ -749 +501 @@
         p_runtsk->texptn = 0U;
 
-        タスク例外処理禁止状æ
-‹ã«ã™ã‚‹
-        ディスパッチ禁止フラグを保存する
-
-        CPUロック解除状æ
-‹ã«ã™ã‚‹
-        タスク例外処理ルーチンを呼び出す
-        CPUロック状æ
-‹ã«ã™ã‚‹
-
-        割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã«ã™ã‚‹
-        ディスパッチ禁止フラグをå
-ƒã«æˆ»ã™
-        タスク例外処理禁止状æ
-‹ã«ã™ã‚‹ … (*2)
-
-        å¿
-è¦ãªå ´åˆã«ã¯ãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒã‚’è¡Œã† … (*1)
-
-        タスク例外処理許可状æ
-‹ã«ã™ã‚‹
+        タスク例外処理禁止状態にする
+        ディスパッチ禁止フラグを保存する
+
+        CPUロック解除状態にする
+        タスク例外処理ルーチンを呼び出す
+        CPUロック状態にする
+
+        割込み優先度マスク全解除状態にする
+        ディスパッチ禁止フラグを元に戻す
+        タスク例外処理禁止状態にする … (*2)
+
+        必要な場合にはディスパッチを行う … (*1)
+
+        タスク例外処理許可状態にする
 }
 ----------------------------------------
 
-(*1)において，å¿
-è¦ãªå ´åˆã«ã‚¿ã‚¹ã‚¯åˆ‡æ›ãˆã‚’è¡Œã†ã®ã¯ï¼Œå‰²è¾¼ã¿å„ªå
-ˆåº¦ãƒžã‚¹ã‚¯ã‚’
-å
-¨è§£é™¤ã«ã—，ディスパッチ禁止フラグをå
-ƒã«æˆ»ã—た結果，ディスパッチ保留状
-æ
-‹ãŒè§£é™¤ã•ã‚Œï¼Œãƒ‡ã‚£ã‚¹ãƒ‘ッチがå¿
-è¦ã«ãªã‚‹å ´åˆãŒã‚ã‚‹ãŸã‚ã§ã‚ã‚‹ï¼Ž
-
-また，ディスパッチを行う前にタスク例外処理禁止状æ
-‹ã«ã™ã‚‹(*2)理由につい
-ては，「call_texrtnからdispatchを呼び出す処理について」の節を参ç
-§ã™ã‚‹ã“
-と．
-
-●タスク例外処理ルーチンの実行開始がå¿
-要なタイミング
-
-タスク例外処理ルーチンは，前述の6ã¤ã®æ¡ä»¶ãŒæƒã£ãŸå ´åˆã«å®Ÿè¡Œé–‹å§‹ã™ã¹ãã§
-あるため，6つの条件のいずれかを新たに満たすようになる可能性のあるタイミ
-ングで，タスク例外処理ルーチンの実行開始がå¿
-要になる．
-
-以下では，6つの条件のいずれかを新たに満たすようになるタイミングについて
-検討する．
-
-(1) タスク例外処理許可状æ
-‹ã§ã‚ã‚‹
-
-タスク例外処理の許可（ena_tex）によって，タスク例外処理許可状æ
-‹ã«ãªã‚‹ï¼Ž
-また，タスク例外処理ルーチンからのリターンによっても，タスク例外処理許
-可状æ
-‹ã«ãªã‚‹ï¼Ž
-
-(2) ä¿ç•™ä¾‹å¤–è¦å› ãŒ0でない
-
-タスク例外処理の要求（ras_tex，iras_texï¼‰ã«ã‚ˆã£ã¦ï¼Œã‚¿ã‚¹ã‚¯ã®ä¿ç•™ä¾‹å¤–è¦å› 
-が0でなくなる．ただし，非タスクコンテキストからのタスク例外処理の要求
-（iras_tex）では，(4)の条件が満たされないため，タスク例外処理ルーチンの
-実行開始はå¿
-要ない．
-
-(3) タスクが実行状æ
-‹ã§ã‚ã‚‹
-
-タスクディスパッチャにより，切換え後のタスクが実行状æ
-‹ã«ãªã‚‹ï¼Ž
-
-(4) タスクコンテキストが実行されている
-
-割込みハンドラおよびCPU例外ハンドラからのリターンによって，タスクコンテ
-ã‚­ã‚¹ãƒˆã«æˆ»ã‚‹å ´åˆãŒã‚ã‚‹ï¼Ž
-
-(5) 割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã§ã‚ã‚‹
-
-割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ã®å¤‰æ›´ï¼ˆchg_ipm）によって，割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ãŒå
-¨è§£é™¤
-になる．
-
-また，タスクの終了，タスク例外処理ルーチンからのリターン，割込みハンド
-ラからのリターン，CPU例外ハンドラからのリターンによっても，割込み優å
-ˆåº¦
-マスクがå
-¨è§£é™¤ã•ã‚Œã‚‹å ´åˆã‚‚ある．
-
-ただし，タスクの終了時については，タスクの終了後は別のタスクへ切り換わ
-るため，切り換わった後のタスクに対するタスク例外処理ルーチンの実行開始
-を，タスクディスパッチ後の処理で行えばよい．
-
-(6) CPUロック状æ
-‹ã§ãªã„
-
-CPUロック状æ
-‹ã®è§£é™¤ï¼ˆunl_cpu，iunl_cpu）によって，CPUロック状æ
-‹ã§ãªããª
-る．ただし，非タスクコンテキストでのCPUロック状æ
-‹ã®è§£é™¤ï¼ˆiunl_cpu）では，
-(4)の条件が満たされないため，タスク例外処理ルーチンの実行開始はå¿
-要ない．
-
-また，タスクの終了，タスク例外処理ルーチンからのリターン，割込みハンド
-ラからのリターン，割込みサービスルーチンからのリターン，タイムイベント
-ハンドラからのリターン，CPU例外ハンドラからのリターンによって，CPUロッ
-ク状æ
-‹ã§ãªããªã‚‹å ´åˆã‚‚ある．
-
-ただし，割込みサービスルーチンおよびタイムイベントハンドラからのリター
-ンについては，リターン後も非タスクコンテキストの実行が続き，(4)の条件が
-満たされないため，タスク例外処理ルーチンの実行開始はå¿
-要ない．
-
-タスクの終了時については，タスクの終了後は別のタスクへ切り換わるため，
-切り換わった後のタスクに対するタスク例外処理ルーチンの実行開始を，タス
-クディスパッチ後の処理で行えばよい．
-
-以上より，重複するケースを考æ
-®ã™ã‚‹ã¨ï¼Œã‚¿ã‚¹ã‚¯ä¾‹å¤–処理ルーチンの実行開始
-がå¿
-要になる可能性があるのは，以下の処理である．
-
-(a) タスク例外処理の許可（ena_tex）… (1)
-(b) タスク例外処理ルーチンの出口処理 … (1)(5)(6)
-(c) タスク例外処理の要求（ras_tex）… (2)
-(d) タスクディスパッチ後の処理 … (3)(5)(6)
+(*1)において，必要な場合にタスク切換えを行うのは，割込み優先度マスクを
+全解除にし，ディスパッチ禁止フラグを元に戻した結果，ディスパッチ保留状
+態が解除され，ディスパッチが必要になる場合があるためである．
+
+また，ディスパッチを行う前にタスク例外処理禁止状態にする(*2)理由につい
+ては，「call_texrtnからdispatchを呼び出す処理について」の節を参照するこ
+と．
+
+●タスク例外処理ルーチンの実行開始が必要なタイミング
+
+タスク例外処理ルーチンは，前述の6つの条件が揃った場合に実行開始すべきで
+あるため，6つの条件のいずれかを新たに満たすようになる可能性のあるタイミ
+ングで，タスク例外処理ルーチンの実行開始が必要になる．
+
+以下では，6つの条件のいずれかを新たに満たすようになるタイミングについて
+検討する．
+
+(1) タスク例外処理許可状態である
+
+タスク例外処理の許可（ena_tex）によって，タスク例外処理許可状態になる．
+また，タスク例外処理ルーチンからのリターンによっても，タスク例外処理許
+可状態になる．
+
+(2) 保留例外要因が0でない
+
+タスク例外処理の要求（ras_tex，iras_tex）によって，タスクの保留例外要因
+が0でなくなる．ただし，非タスクコンテキストからのタスク例外処理の要求
+（iras_tex）では，(4)の条件が満たされないため，タスク例外処理ルーチンの
+実行開始は必要ない．
+
+(3) タスクが実行状態である
+
+タスクディスパッチャにより，切換え後のタスクが実行状態になる．
+
+(4) タスクコンテキストが実行されている
+
+割込みハンドラおよびCPU例外ハンドラからのリターンによって，タスクコンテ
+キストに戻る場合がある．
+
+(5) 割込み優先度マスク全解除状態である
+
+割込み優先度マスクの変更（chg_ipm）によって，割込み優先度マスクが全解除
+になる．
+
+また，タスクの終了，タスク例外処理ルーチンからのリターン，割込みハンド
+ラからのリターン，CPU例外ハンドラからのリターンによっても，割込み優先度
+マスクが全解除される場合もある．
+
+ただし，タスクの終了時については，タスクの終了後は別のタスクへ切り換わ
+るため，切り換わった後のタスクに対するタスク例外処理ルーチンの実行開始
+を，タスクディスパッチ後の処理で行えばよい．
+
+(6) CPUロック状態でない
+
+CPUロック状態の解除（unl_cpu，iunl_cpu）によって，CPUロック状態でなくな
+る．ただし，非タスクコンテキストでのCPUロック状態の解除（iunl_cpu）では，
+(4)の条件が満たされないため，タスク例外処理ルーチンの実行開始は必要ない．
+
+また，タスクの終了，タスク例外処理ルーチンからのリターン，割込みハンド
+ラからのリターン，割込みサービスルーチンからのリターン，タイムイベント
+ハンドラからのリターン，CPU例外ハンドラからのリターンによって，CPUロッ
+ク状態でなくなる場合もある．
+
+ただし，割込みサービスルーチンおよびタイムイベントハンドラからのリター
+ンについては，リターン後も非タスクコンテキストの実行が続き，(4)の条件が
+満たされないため，タスク例外処理ルーチンの実行開始は必要ない．
+
+タスクの終了時については，タスクの終了後は別のタスクへ切り換わるため，
+切り換わった後のタスクに対するタスク例外処理ルーチンの実行開始を，タス
+クディスパッチ後の処理で行えばよい．
+
+以上より，重複するケースを考慮すると，タスク例外処理ルーチンの実行開始
+が必要になる可能性があるのは，以下の処理である．
+
+(a) タスク例外処理の許可（ena_tex）… (1)
+(b) タスク例外処理ルーチンの出口処理 … (1)(5)(6)
+(c) タスク例外処理の要求（ras_tex）… (2)
+(d) タスクディスパッチ後の処理 … (3)(5)(6)
         (d-1) dispatch_r
         (d-2) ret_int_r
         (d-3) ret_exc_r
         (d-4) start_r
-(e) 割込みハンドラの出口処理 … (4)(5)(6)
-(f) CPU例外ハンドラの出口処理 … (4)(5)(6)
-(g) 割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ã®å¤‰æ›´ï¼ˆchg_ipm）… (5)
-(h) CPUロック状æ
-‹ã®è§£é™¤ï¼ˆunl_cpu）… (6)
-
-この中で(d-4)に関しては，タスクの実行開始直後はタスク例外処理禁止状æ
-‹ã§
-あり（自タスクがena_texするまでは，タスク例外が許可されない），(1)の条
-件が満たされないため，タスク例外処理ルーチンの実行開始はå¿
-要ない．
-
-また(h)に関しては，次に述べる理由により，CPUロック状æ
-‹ãŒç¶™ç¶šã—ている間
-に他の5つの条件が新たに満たされることはないため，タスク例外処理ルーチン
-の実行開始はå¿
-要ない．
-
-CPUロック状æ
-‹ã§ã¯ï¼Œã¾ãšï¼Œã‚¿ã‚¹ã‚¯ä¾‹å¤–処理の許可（ena_tex），タスク例外処
-理の要求（ras_tex，iras_tex），割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ã®å¤‰æ›´ï¼ˆchg_ipm）を行
-うことはできず，タスクディスパッチも起こらない．CPUロック状æ
-‹ã§ã‚¿ã‚¹ã‚¯ä¾‹
-å¤–å‡¦ç†ãƒ«ãƒ¼ãƒãƒ³ã‹ã‚‰ãƒªã‚¿ãƒ¼ãƒ³ã™ã‚‹ã“ã¨ã¯ã§ãã‚‹ãŒï¼Œã“ã®å ´åˆã¯CPUロック状æ
-‹ã‚‚
-解除され，CPUロック状æ
-‹ãŒç¶™ç¶šã—ない．CPUロック状æ
-‹ã§å‰²è¾¼ã¿ãƒãƒ³ãƒ‰ãƒ©ã‹ã‚‰
-ãƒªã‚¿ãƒ¼ãƒ³ã—ãŸå ´åˆã‚‚ï¼Œã“ã‚Œã¨åŒæ§˜ã§ã‚ã‚‹ï¼Ž
-
-最後に，CPUロック状æ
-‹ã§CPUä¾‹å¤–ãƒãƒ³ãƒ‰ãƒ©ã‹ã‚‰ãƒªã‚¿ãƒ¼ãƒ³ã—ãŸå ´åˆãŒå•é¡Œã«ãªã‚‹ï¼Ž
-これについては，CPU例外が発生した時に，CPUロック状æ
-‹ã§ã‚ã£ãŸå ´åˆã¨ï¼Œ
-CPUロック解除状æ
-‹ã§ã‚ã£ãŸå ´åˆã«åˆ†ã‘ã¦è€ƒãˆã‚‹ï¼ŽCPUロック解除状æ
-‹ã§ã‚った
-å ´åˆã«ã¯ï¼ŒCPU例外ハンドラからのリターンにより，CPUロック状æ
-‹ãŒè§£é™¤ã•ã‚Œ
-ã‚‹ãŸã‚ï¼Œå‰²è¾¼ã¿ãƒãƒ³ãƒ‰ãƒ©ã‹ã‚‰ãƒªã‚¿ãƒ¼ãƒ³ã—ãŸå ´åˆã¨åŒæ§˜ã§ã‚ã‚‹ï¼ŽCPUロック状æ
-‹ã§
-ã‚ã£ãŸå ´åˆã«ã¯ï¼Œèµ·å‹•ã•ã‚Œã‚‹CPU例外ハンドラはカーネル管理外のCPU例外ハン
-ドラであるため，その中で(1)～(3)と(5)の条件が新たに満たされることはない．
-CPU例外ハンドラの実行前後で(4)の条件は保存されることから，CPU例外ハンド
-ラからのリターンによって，(1)～(5)の条件はCPU例外の発生前に戻り，新たに
-満たされることはない．
-
-●タスク例外処理ルーチンの実行開始処理
-
-ここでは，前の節で検討したタスク例外処理ルーチンの実行開始がå¿
-要なタイ
-ミングのそれぞれについて，実行開始処理の実è£
-方法について述べる．
-
-(a) タスク例外処理の許可（ena_tex）
-
-ena_texãŒã‚¿ã‚¹ã‚¯ã‹ã‚‰å‘¼ã³å‡ºã•ã‚ŒãŸå ´åˆã«ã¯ï¼Œè‡ªã‚¿ã‚¹ã‚¯ã«å¯¾ã—ã¦ã€Œã‚¿ã‚¹ã‚¯ãŒå®Ÿè¡Œ
-状æ
-‹ã§ã‚る」「タスクコンテキストが実行されている」の2条件は満たされてお
-り，「タスク例外処理許可状æ
-‹ã§ã‚る」の条件はena_texの処理により満たされ
-る．また，「CPUロック状æ
-‹ã§ãªã„」の条件はena_texのå
-¥å£ã§ãƒã‚§ãƒƒã‚¯ã—てい
-ã‚‹ï¼Žãã®ãŸã‚ï¼Œã€Œä¿ç•™ä¾‹å¤–è¦å› ãŒ0でない」と「割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹
-である」の2æ¡ä»¶ãŒæº€ãŸã•ã‚Œã¦ã„ã‚‹å ´åˆã«ã¯ï¼Œã‚¿ã‚¹ã‚¯ä¾‹å¤–å‡¦ç†ãƒ«ãƒ¼ãƒãƒ³ã‚’å‘¼ã³å‡º
-す．
-
-ena_texの本体の処理（エラー処理を除く）は次の通り．
+(e) 割込みハンドラの出口処理 … (4)(5)(6)
+(f) CPU例外ハンドラの出口処理 … (4)(5)(6)
+(g) 割込み優先度マスクの変更（chg_ipm）… (5)
+(h) CPUロック状態の解除（unl_cpu）… (6)
+
+この中で(d-4)に関しては，タスクの実行開始直後はタスク例外処理禁止状態で
+あり（自タスクがena_texするまでは，タスク例外が許可されない），(1)の条
+件が満たされないため，タスク例外処理ルーチンの実行開始は必要ない．
+
+また(h)に関しては，次に述べる理由により，CPUロック状態が継続している間
+に他の5つの条件が新たに満たされることはないため，タスク例外処理ルーチン
+の実行開始は必要ない．
+
+CPUロック状態では，まず，タスク例外処理の許可（ena_tex），タスク例外処
+理の要求（ras_tex，iras_tex），割込み優先度マスクの変更（chg_ipm）を行
+うことはできず，タスクディスパッチも起こらない．CPUロック状態でタスク例
+外処理ルーチンからリターンすることはできるが，この場合はCPUロック状態も
+解除され，CPUロック状態が継続しない．CPUロック状態で割込みハンドラから
+リターンした場合も，これと同様である．
+
+最後に，CPUロック状態でCPU例外ハンドラからリターンした場合が問題になる．
+これについては，CPU例外が発生した時に，CPUロック状態であった場合と，
+CPUロック解除状態であった場合に分けて考える．CPUロック解除状態であった
+場合には，CPU例外ハンドラからのリターンにより，CPUロック状態が解除され
+るため，割込みハンドラからリターンした場合と同様である．CPUロック状態で
+あった場合には，起動されるCPU例外ハンドラはカーネル管理外のCPU例外ハン
+ドラであるため，その中で(1)～(3)と(5)の条件が新たに満たされることはない．
+CPU例外ハンドラの実行前後で(4)の条件は保存されることから，CPU例外ハンド
+ラからのリターンによって，(1)～(5)の条件はCPU例外の発生前に戻り，新たに
+満たされることはない．
+
+●タスク例外処理ルーチンの実行開始処理
+
+ここでは，前の節で検討したタスク例外処理ルーチンの実行開始が必要なタイ
+ミングのそれぞれについて，実行開始処理の実装方法について述べる．
+
+(a) タスク例外処理の許可（ena_tex）
+
+ena_texがタスクから呼び出された場合には，自タスクに対して「タスクが実行
+状態である」「タスクコンテキストが実行されている」の2条件は満たされてお
+り，「タスク例外処理許可状態である」の条件はena_texの処理により満たされ
+る．また，「CPUロック状態でない」の条件はena_texの入口でチェックしてい
+る．そのため，「保留例外要因が0でない」と「割込み優先度マスク全解除状態
+である」の2条件が満たされている場合には，タスク例外処理ルーチンを呼び出
+す．
+
+ena_texの本体の処理（エラー処理を除く）は次の通り．
 
 ----------------------------------------
@@ -973 +655 @@
 ----------------------------------------
 
-(b) タスク例外処理ルーチンの出口処理
-
-タスク例外処理ルーチンの出口処理（call_texrtnの後半）では，自タスクに対
-して「タスクが実行状æ
-‹ã§ã‚る」「タスクコンテキストが実行されている」の
-2条件は満たされており，「タスク例外処理許可状æ
-‹ã§ã‚る」「割込み優å
-ˆåº¦ãƒž
-スクå
-¨è§£é™¤çŠ¶æ
-‹ã§ã‚る」「CPUロック状æ
-‹ã§ãªã„」の3条件が出口処理で満たさ
-ã‚Œã‚‹ï¼Žãã®ãŸã‚ï¼Œã€Œä¿ç•™ä¾‹å¤–è¦å› ãŒ0ã§ãªã„ã€ãŒæº€ãŸã•ã‚Œã¦ã„ã‚‹å ´åˆã«ã¯ï¼Œã‚¿ã‚¹
-ク例外処理ルーチンを呼び出すå¿
-要がある．
-
-ただし，タスク例外処理ルーチンの出口処理で単純にcall_texrtnを呼び出すと，
-call_texrtnの中からcall_texrtnを呼び出すことになり，タスク例外処理が繰
-ã‚Šè¿”ã—è¦æ±‚ã•ã‚ŒãŸå ´åˆã«ï¼Œã‚¹ã‚¿ãƒƒã‚¯ã®ä½¿ç”¨é‡ã«ä¸Šé™ãŒãªããªã‚‹ï¼Žãã“ã§ï¼Œã‚¿ã‚¹
-ã‚¯ä¾‹å¤–å‡¦ç†ãƒ«ãƒ¼ãƒãƒ³ã®å‡ºå£å‡¦ç†ã§ã€Œä¿ç•™ä¾‹å¤–è¦å› ãŒ0ã§ãªã„ã€å ´åˆã«ã¯ï¼Œ
-call_texrtnの中でループさせる．
-
-修正したcall_texrtnの流れは次の通り．
+(b) タスク例外処理ルーチンの出口処理
+
+タスク例外処理ルーチンの出口処理（call_texrtnの後半）では，自タスクに対
+して「タスクが実行状態である」「タスクコンテキストが実行されている」の
+2条件は満たされており，「タスク例外処理許可状態である」「割込み優先度マ
+スク全解除状態である」「CPUロック状態でない」の3条件が出口処理で満たさ
+れる．そのため，「保留例外要因が0でない」が満たされている場合には，タス
+ク例外処理ルーチンを呼び出す必要がある．
+
+ただし，タスク例外処理ルーチンの出口処理で単純にcall_texrtnを呼び出すと，
+call_texrtnの中からcall_texrtnを呼び出すことになり，タスク例外処理が繰
+り返し要求された場合に，スタックの使用量に上限がなくなる．そこで，タス
+ク例外処理ルーチンの出口処理で「保留例外要因が0でない」場合には，
+call_texrtnの中でループさせる．
+
+修正したcall_texrtnの流れは次の通り．
 
 ----------------------------------------
@@ -1003 +678 @@
         TEXPTN  texptn;
 
-        ディスパッチ禁止フラグを保存する … (*3)
-        タスク例外処理禁止状æ
-‹ã«ã™ã‚‹ … (*6)
+        ディスパッチ禁止フラグを保存する … (*3)
+        タスク例外処理禁止状態にする … (*6)
 
         do {
@@ -1011 +685 @@
                 p_runtsk->texptn = 0U;
 
-                CPUロック解除状æ
-‹ã«ã™ã‚‹
-                タスク例外処理ルーチンを呼び出す
-                CPUロック状æ
-‹ã«ã™ã‚‹
-
-                割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã«ã™ã‚‹
-                ディスパッチ禁止フラグをå
-ƒã«æˆ»ã™ … (*4)
-                タスク例外処理禁止状æ
-‹ã«ã™ã‚‹ … (*2)
-
-                å¿
-è¦ãªå ´åˆã«ã¯ãƒ‡ã‚£ã‚¹ãƒ‘ãƒƒãƒã‚’è¡Œã† … (*1)
+                CPUロック解除状態にする
+                タスク例外処理ルーチンを呼び出す
+                CPUロック状態にする
+
+                割込み優先度マスク全解除状態にする
+                ディスパッチ禁止フラグを元に戻す … (*4)
+                タスク例外処理禁止状態にする … (*2)
+
+                必要な場合にはディスパッチを行う … (*1)
         }  while (p_runtsk->texptn != 0U);
 
-        タスク例外処理許可状æ
-‹ã«ã™ã‚‹ … (*5)
+        タスク例外処理許可状態にする … (*5)
 }
 ----------------------------------------
 
-タスク例外処理ルーチンの呼出し前にディスパッチ禁止フラグを保存する処理
-は，(*4)においてå
-ƒã®çŠ¶æ
-‹ã«æˆ»ã™ã“とから，ループの外(*3)で行うのが効率が
-よい．
-
-タスク例外処理ルーチンの呼出し前にタスク例外処理禁止状æ
-‹ã«ã™ã‚‹å‡¦ç†ã¯ï¼Œ
-(*2)においてタスク例外処理禁止状æ
-‹ã«ã™ã‚‹ã“とから，ループ外(*6)で行うの
-が効率がよい．また，タスク例外処理ルーチンの呼出し後にタスク例外処理許
-可状æ
-‹ã«ã™ã‚‹å‡¦ç†ã‚‚，ループの外(*5)で行う方が効率がよい．
-
-(c) タスク例外処理の要求（ras_tex）
-
-ras_texãŒã‚¿ã‚¹ã‚¯ã‹ã‚‰å‘¼ã³å‡ºã•ã‚ŒãŸå ´åˆã§ï¼Œå¯¾è±¡ã‚¿ã‚¹ã‚¯ãŒè‡ªã‚¿ã‚¹ã‚¯ã®å ´åˆã«ã¯ï¼Œ
-自タスクに対して「タスクが実行状æ
-‹ã§ã‚る」「タスクコンテキストが実行さ
-れている」の2æ¡ä»¶ã¯æº€ãŸã•ã‚Œã¦ãŠã‚Šï¼Œã€Œä¿ç•™ä¾‹å¤–è¦å› ãŒ0でない」の条件は
-ras_texの処理により満たされる（ras_texのパラメータrasptnが0ã®å ´åˆã¯ã‚¨ãƒ©ãƒ¼
-となるため）．また，「CPUロック状æ
-‹ã§ãªã„」の条件はras_texのå
-¥å£ã§ãƒã‚§ãƒƒ
-クしている．そのため，対象タスクが自タスクであり，「タスク例外処理許可
-状æ
-‹ã§ã‚る」と「割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã§ã‚る」の2条件が満たされて
-ã„ã‚‹å ´åˆã«ã¯ï¼Œã‚¿ã‚¹ã‚¯ä¾‹å¤–å‡¦ç†ãƒ«ãƒ¼ãƒãƒ³ã‚’å‘¼ã³å‡ºã™ï¼Ž
-
-ras_texの本体の処理（エラー処理を除く）は次の通り．
+タスク例外処理ルーチンの呼出し前にディスパッチ禁止フラグを保存する処理
+は，(*4)において元の状態に戻すことから，ループの外(*3)で行うのが効率が
+よい．
+
+タスク例外処理ルーチンの呼出し前にタスク例外処理禁止状態にする処理は，
+(*2)においてタスク例外処理禁止状態にすることから，ループ外(*6)で行うの
+が効率がよい．また，タスク例外処理ルーチンの呼出し後にタスク例外処理許
+可状態にする処理も，ループの外(*5)で行う方が効率がよい．
+
+(c) タスク例外処理の要求（ras_tex）
+
+ras_texがタスクから呼び出された場合で，対象タスクが自タスクの場合には，
+自タスクに対して「タスクが実行状態である」「タスクコンテキストが実行さ
+れている」の2条件は満たされており，「保留例外要因が0でない」の条件は
+ras_texの処理により満たされる（ras_texのパラメータrasptnが0の場合はエラー
+となるため）．また，「CPUロック状態でない」の条件はras_texの入口でチェッ
+クしている．そのため，対象タスクが自タスクであり，「タスク例外処理許可
+状態である」と「割込み優先度マスク全解除状態である」の2条件が満たされて
+いる場合には，タスク例外処理ルーチンを呼び出す．
+
+ras_texの本体の処理（エラー処理を除く）は次の通り．
 
 ----------------------------------------
@@ -1078 +731 @@
 (d-1) dispatch_r
 
-dispatch_rにおいては，dispatch_rからのリターンå
-ˆã®ã‚¿ã‚¹ã‚¯ã«å¯¾ã—て，「タ
-スクが実行状æ
-‹ã§ã‚る」「タスクコンテキストが実行されている」の2条件は満
-たされている．また，CPUロック状æ
-‹ã§dispatch_rに来ることはないため，
-「CPUロック状æ
-‹ã§ãªã„」の条件も成立している．そのため，「タスク例外処理
-許可状æ
-‹ã§ã‚ã‚‹ã€ã€Œä¿ç•™ä¾‹å¤–è¦å› が0でない」「割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹
-である」の3æ¡ä»¶ãŒæº€ãŸã•ã‚Œã¦ã„ã‚‹å ´åˆã«ã¯ï¼Œã‚¿ã‚¹ã‚¯ä¾‹å¤–å‡¦ç†ãƒ«ãƒ¼ãƒãƒ³ã‚’å‘¼ã³å‡º
-すå¿
-要がある．
-
-これを実現するために，タスクコンテキストからのディスパッチ処理を次のよ
-うに修正する．
+dispatch_rにおいては，dispatch_rからのリターン先のタスクに対して，「タ
+スクが実行状態である」「タスクコンテキストが実行されている」の2条件は満
+たされている．また，CPUロック状態でdispatch_rに来ることはないため，
+「CPUロック状態でない」の条件も成立している．そのため，「タスク例外処理
+許可状態である」「保留例外要因が0でない」「割込み優先度マスク全解除状態
+である」の3条件が満たされている場合には，タスク例外処理ルーチンを呼び出
+す必要がある．
+
+これを実現するために，タスクコンテキストからのディスパッチ処理を次のよ
+うに修正する．
 
 ----------------------------------------
@@ -1102 +746 @@
 dispatch(void)
 {
-        ………
+        ………
 
   dispatch_r:
-        スクラッチレジスタを除くすべてのレジスタをスタックから復帰する
+        スクラッチレジスタを除くすべてのレジスタをスタックから復帰する
         calltex();
 }
 ----------------------------------------
 
-ここでcalltexは，「タスク例外処理許可状æ
-‹ã§ã‚ã‚‹ã€ã€Œä¿ç•™ä¾‹å¤–è¦å› が0でな
-い」「割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã§ã‚る」の3æ¡ä»¶ãŒæº€ãŸã•ã‚Œã¦ã„ã‚‹å ´åˆã«
-call_texrtnを呼び出す関数である．
+ここでcalltexは，「タスク例外処理許可状態である」「保留例外要因が0でな
+い」「割込み優先度マスク全解除状態である」の3条件が満たされている場合に
+call_texrtnを呼び出す関数である．
 
 ----------------------------------------
@@ -1130 +770 @@
 (d-2) ret_int_r
 
-ret_int_rは，割込みハンドラの出口処理でディスパッチを行ったタスクが，実
-行を再開する際の処理である．そのため，ret_int_rからのリターンå
-ˆã®ã‚¿ã‚¹ã‚¯
-に対して，「タスクが実行状æ
-‹ã§ã‚る」「タスクコンテキストが実行されてい
-る」の2条件は満たされている．また，CPUロック状æ
-‹ã§ret_int_rに来ることは
-ないため，「CPUロック状æ
-‹ã§ãªã„」の条件も成立している．そのため，「タス
-ク例外処理許可状æ
-‹ã§ã‚ã‚‹ã€ã€Œä¿ç•™ä¾‹å¤–è¦å› が0でない」「（割込みハンドラか
-らのリターン後に）割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã§ã‚る」の3条件が満たされ
-ã¦ã„ã‚‹å ´åˆã«ã¯ï¼Œã‚¿ã‚¹ã‚¯ä¾‹å¤–å‡¦ç†ãƒ«ãƒ¼ãƒãƒ³ã‚’å‘¼ã³å‡ºã™å¿
-要がある．
-
-これを実現するために，割込みハンドラの出å
-¥å£å‡¦ç†ã‚’次のように修正する．
+ret_int_rは，割込みハンドラの出口処理でディスパッチを行ったタスクが，実
+行を再開する際の処理である．そのため，ret_int_rからのリターン先のタスク
+に対して，「タスクが実行状態である」「タスクコンテキストが実行されてい
+る」の2条件は満たされている．また，CPUロック状態でret_int_rに来ることは
+ないため，「CPUロック状態でない」の条件も成立している．そのため，「タス
+ク例外処理許可状態である」「保留例外要因が0でない」「（割込みハンドラか
+らのリターン後に）割込み優先度マスク全解除状態である」の3条件が満たされ
+ている場合には，タスク例外処理ルーチンを呼び出す必要がある．
+
+これを実現するために，割込みハンドラの出入口処理を次のように修正する．
 
 ----------------------------------------
 void
-<割込みの出å
-¥å£å‡¦ç†>(void)
+<割込みの出入口処理>(void)
 {
-                ………
+                ………
 
                           ret_int_r:
-                                スクラッチレジスタを除くすべてのレジスタをスタックから復帰する
+                                スクラッチレジスタを除くすべてのレジスタをスタックから復帰する
                                 calltex();
                         }
-                ………
+                ………
 }
 ----------------------------------------
@@ -1168 +797 @@
 (d-3) ret_exc_r
 
-ret_exc_rは，CPU例外ハンドラの出口処理でディスパッチを行ったタスクが，
-実行を再開する際の処理である．
-
-カーネル管理のCPU例外ハンドラの出口処理（ret_exc）は，割込みハンドラの
-出口処理（ret_int）と同様である．これは，CPUロック状æ
-‹ã§CPU例外が発生し
-ãŸå ´åˆã«ã¯ï¼Œã‚«ãƒ¼ãƒãƒ«ç®¡ç†å¤–ã®CPU例外ハンドラとなり，CPU例外ハンドラの出
-口処理でディスパッチを行うことはなく，ret_excにも来ないためである．その
-ため，ret_exc_rからのリターンå
-ˆã®ã‚¿ã‚¹ã‚¯ã«å¯¾ã—て，「CPUロック状æ
-‹ã§ãªã„」
-の条件が成立している．
-
-このことから，CPU例外ハンドラの出å
-¥å£å‡¦ç†ã«ã¤ã„ても，割込みハンドラの出
-å
-¥å£å‡¦ç†ã¨åŒæ§˜ã«ï¼Œæ¬¡ã®ã‚ˆã†ã«ä¿®æ­£ã™ã‚Œã°ã‚ˆã„．
+ret_exc_rは，CPU例外ハンドラの出口処理でディスパッチを行ったタスクが，
+実行を再開する際の処理である．
+
+カーネル管理のCPU例外ハンドラの出口処理（ret_exc）は，割込みハンドラの
+出口処理（ret_int）と同様である．これは，CPUロック状態でCPU例外が発生し
+た場合には，カーネル管理外のCPU例外ハンドラとなり，CPU例外ハンドラの出
+口処理でディスパッチを行うことはなく，ret_excにも来ないためである．その
+ため，ret_exc_rからのリターン先のタスクに対して，「CPUロック状態でない」
+の条件が成立している．
+
+このことから，CPU例外ハンドラの出入口処理についても，割込みハンドラの出
+入口処理と同様に，次のように修正すればよい．
 
 ----------------------------------------
 void
-<CPU例外の出å
-¥å£å‡¦ç†>(void)
+<CPU例外の出入口処理>(void)
 {
-                        ………
+                        ………
 
                                   ret_exc_r:
-                                        スクラッチレジスタを除くすべてのレジスタを
-                                                                                                スタックから復帰する
+                                        スクラッチレジスタを除くすべてのレジスタを
+                                                                                                スタックから復帰する
                                         calltex();
                                 }
-                        ………
+                        ………
 }
 ----------------------------------------
 
-(e) 割込みハンドラの出口処理
-
-å‰²è¾¼ã¿ãƒãƒ³ãƒ‰ãƒ©ã‹ã‚‰ã‚¿ã‚¹ã‚¯ã¸ãƒªã‚¿ãƒ¼ãƒ³ã™ã‚‹å ´åˆã«ã¯ï¼Œãƒªã‚¿ãƒ¼ãƒ³å
-ˆã®ã‚¿ã‚¹ã‚¯ã«å¯¾
-して，「タスクが実行状æ
-‹ã§ã‚る」「タスクコンテキストが実行されている」
-の2条件は満たされている．また，CPUロック状æ
-‹ã§å‰²è¾¼ã¿ãƒãƒ³ãƒ‰ãƒ©ãŒå®Ÿè¡Œã•ã‚Œ
-ることはないため，「CPUロック状æ
-‹ã§ãªã„」の条件も成立している．そのため，
-「タスク例外処理許可状æ
-‹ã§ã‚ã‚‹ã€ã€Œä¿ç•™ä¾‹å¤–è¦å› が0でない」「（割込みハン
-ドラからのリターン後に）割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã§ã‚る」の3条件が満
-ãŸã•ã‚Œã¦ã„ã‚‹å ´åˆã«ã¯ï¼Œã‚¿ã‚¹ã‚¯ä¾‹å¤–å‡¦ç†ãƒ«ãƒ¼ãƒãƒ³ã‚’å‘¼ã³å‡ºã™å¿
-要がある．
-
-割込みハンドラの呼出し前と呼出し後でこれらの条件が変化するのは，実行状
-æ
-‹ã®ã‚¿ã‚¹ã‚¯ãŒå¤‰åŒ–した時と，割込みハンドラ中でiras_texãŒå‘¼ã³å‡ºã•ã‚ŒãŸå ´åˆ
-である．割込みハンドラからはena_texとchg_ipmは呼び出せないため，「タス
-ク例外処理許可状æ
-‹ã§ã‚る」と「（割込みハンドラからのリターン後に）割込
-み優å
-ˆåº¦ãƒžã‚¹ã‚¯å
-¨è§£é™¤çŠ¶æ
-‹ã§ã‚る」の2条件が変化することはない．
-
-この2つの状況のå†
-，実行状æ
-‹ã®ã‚¿ã‚¹ã‚¯ãŒå¤‰åŒ–するケースは，ret_int_rで考æ
-®
-済みである．割込みハンドラ中でiras_texãŒå‘¼ã³å‡ºã•ã‚ŒãŸå ´åˆã«ã¯ï¼Œreqflgが
-trueになるため，タスク例外処理ルーチンの実行開始処理は，reqflgがtrueの
-時にのみ行えばよい．
-
-これを実現するために，上で修正した割込みハンドラの出å
-¥å£å‡¦ç†ã‚’，さらに
-次のように修正する．
+(e) 割込みハンドラの出口処理
+
+割込みハンドラからタスクへリターンする場合には，リターン先のタスクに対
+して，「タスクが実行状態である」「タスクコンテキストが実行されている」
+の2条件は満たされている．また，CPUロック状態で割込みハンドラが実行され
+ることはないため，「CPUロック状態でない」の条件も成立している．そのため，
+「タスク例外処理許可状態である」「保留例外要因が0でない」「（割込みハン
+ドラからのリターン後に）割込み優先度マスク全解除状態である」の3条件が満
+たされている場合には，タスク例外処理ルーチンを呼び出す必要がある．
+
+割込みハンドラの呼出し前と呼出し後でこれらの条件が変化するのは，実行状
+態のタスクが変化した時と，割込みハンドラ中でiras_texが呼び出された場合
+である．割込みハンドラからはena_texとchg_ipmは呼び出せないため，「タス
+ク例外処理許可状態である」と「（割込みハンドラからのリターン後に）割込
+み優先度マスク全解除状態である」の2条件が変化することはない．
+
+この2つの状況の内，実行状態のタスクが変化するケースは，ret_int_rで考慮
+済みである．割込みハンドラ中でiras_texが呼び出された場合には，reqflgが
+trueになるため，タスク例外処理ルーチンの実行開始処理は，reqflgがtrueの
+時にのみ行えばよい．
+
+これを実現するために，上で修正した割込みハンドラの出入口処理を，さらに
+次のように修正する．
 
 ----------------------------------------
 void
-<割込みの出å
-¥å£å‡¦ç†>(void)
+<割込みの出入口処理>(void)
 {
-        ………
-
-        if (タスクコンテキストで割込み発生) {
-                ………
+        ………
+
+        if (タスクコンテキストで割込み発生) {
+                ………
                 if (reqflg) {
-                        ………
+                        ………
 
                           ret_int_r:
-                                スクラッチレジスタを除くすべてのレジスタをスタックから復帰する
+                                スクラッチレジスタを除くすべてのレジスタをスタックから復帰する
                         }
                         calltex();
                 }
         }
-        ………
+        ………
 }
 ----------------------------------------
 
-(f) CPU例外ハンドラの出口処理
-
-カーネル管理のCPU例外ハンドラの出口処理は，割込みハンドラの出口処理と同
-様である．
-
-カーネル管理外のCPU例外ハンドラの中では，実行状æ
-‹ã®ã‚¿ã‚¹ã‚¯ãŒå¤‰åŒ–すること
-はなく，iras_texやena_texを呼び出すこともできないため，タスク例外処理ルー
-チンの実行開始条件が新たに満たされることはなく，タスク例外処理ルーチン
-の実行開始はå¿
-要ない．
-
-このことから，CPU例外ハンドラの出å
-¥å£å‡¦ç†ã«ã¤ã„ても，割込みハンドラの出
-å
-¥å£å‡¦ç†ã¨åŒæ§˜ã«ï¼Œæ¬¡ã®ã‚ˆã†ã«ä¿®æ­£ã™ã‚Œã°ã‚ˆã„．
+(f) CPU例外ハンドラの出口処理
+
+カーネル管理のCPU例外ハンドラの出口処理は，割込みハンドラの出口処理と同
+様である．
+
+カーネル管理外のCPU例外ハンドラの中では，実行状態のタスクが変化すること
+はなく，iras_texやena_texを呼び出すこともできないため，タスク例外処理ルー
+チンの実行開始条件が新たに満たされることはなく，タスク例外処理ルーチン
+の実行開始は必要ない．
+
+このことから，CPU例外ハンドラの出入口処理についても，割込みハンドラの出
+入口処理と同様に，次のように修正すればよい．
 
 ----------------------------------------
 void
-<CPU例外の出å
-¥å£å‡¦ç†>(void)
+<CPU例外の出入口処理>(void)
 {
-                ………
-                if (タスクコンテキストでCPU例外発生) {
-                ………
+                ………
+                if (タスクコンテキストでCPU例外発生) {
+                ………
                         if (reqflg) {
 
                                   ret_exc_r:
-                                        スクラッチレジスタを除くすべてのレジスタを
-                                                                                                スタックから復帰する
+                                        スクラッチレジスタを除くすべてのレジスタを
+                                                                                                スタックから復帰する
                                 }
                                 calltex();
                         }
                 }
-                ………
+                ………
 }
 ----------------------------------------
 
-(g) 割込み優å
-ˆåº¦ãƒžã‚¹ã‚¯ã®å¤‰æ›´
-
-chg_ipmãŒã‚¿ã‚¹ã‚¯ã‹ã‚‰å‘¼ã³å‡ºã•ã‚ŒãŸå ´åˆã«ã¯ï¼Œè‡ªã‚¿ã‚¹ã‚¯ã«å¯¾ã—ã¦ã€Œã‚¿ã‚¹ã‚¯ãŒå®Ÿè¡Œ
-状æ
-‹ã§ã‚る」「タスクコンテキストが実行されている」の2条件は満たされてい
-る．また，「CPUロック状æ
-‹ã§ãªã„」の条件はchg_ipmのå
-¥å£ã§ãƒã‚§ãƒƒã‚¯ã—てい
-る．そのため，パラメータintpriがTIPM_ENAALLであり，「タスク例外処理許可
-状æ
-‹ã§ã‚ã‚‹ã€ã€Œä¿ç•™ä¾‹å¤–è¦å› が0でない」の2æ¡ä»¶ãŒæº€ãŸã•ã‚Œã¦ã„ã‚‹å ´åˆã«ã¯ï¼Œ
-タスク例外処理ルーチンを呼び出す．
-
-chg_ipmの関連部分の処理は次の通り．
+(g) 割込み優先度マスクの変更
+
+chg_ipmがタスクから呼び出された場合には，自タスクに対して「タスクが実行
+状態である」「タスクコンテキストが実行されている」の2条件は満たされてい
+る．また，「CPUロック状態でない」の条件はchg_ipmの入口でチェックしてい
+る．そのため，パラメータintpriがTIPM_ENAALLであり，「タスク例外処理許可
+状態である」「保留例外要因が0でない」の2条件が満たされている場合には，
+タスク例外処理ルーチンを呼び出す．
+
+chg_ipmの関連部分の処理は次の通り．
 
 ----------------------------------------
@@ -1324 +918 @@
         if (intpri == TIPM_ENAALL) {
                 ipmflg = true;
-                ここにタスク切換え処理がå
-¥ã‚‹
+                ここにタスク切換え処理が入る
                 if (p_runtsk->enatex && p_runtsk->texptn != 0U) {
                         call_texrtn();
@@ -1332 +925 @@
 ----------------------------------------
 
-dispatchã‚’å‘¼ã³å‡ºã—ã¦ã‚¿ã‚¹ã‚¯åˆ‡æ›ãˆã‚’è¡Œã†å ´åˆã«ã¯ï¼Œdispatchの出口でタスク
-例外処理ルーチンを呼び出すためここで呼出し処理を行うå¿
-要はないが，コー
-ドが複雑になるため，dispatchã‚’å‘¼ã³å‡ºã—ãŸå ´åˆã‚‚ã“ã“ã§ã‚¿ã‚¹ã‚¯ä¾‹å¤–å‡¦ç†ãƒ«ãƒ¼
-チンの呼出し処理を行っている．
-
-●call_texrtnからdispatchを呼び出す処理について
-
-dispatch_rから（ターゲットによってはcalltexを経由して）call_texrtnを呼
-び出し，call_texrtnからdispatchを呼び出すため，この2つの関数は相互再帰
-呼出しをしている．ここでは，この実è£
-で支障のない理由を説明する．
-
-call_texrtnからdispatchを呼び出すのは，ディスパッチが保留されていない状
-æ
-‹ã§å‘¼ã³å‡ºã•ã‚ŒãŸã‚¿ã‚¹ã‚¯ä¾‹å¤–処理ルーチンが，その実行中にディスパッチ保留
-状æ
-‹ã«é·ç§»ã—，さらにタスクディスパッチをå¿
-要とする処理を行い，ディスパッ
-チ保留状æ
-‹ã‚’è§£é™¤ã—ãªã„ã¾ã¾ãƒªã‚¿ãƒ¼ãƒ³ã—ãŸå ´åˆã§ã‚ã‚‹ï¼Žã“ã®å ´åˆï¼Œcall_texrtn
-の中でディスパッチ保留状æ
-‹ã‚’解除した後に，dispatchを呼び出してタスクディ
-スパッチを行う．つまり，call_texrtnからdispatchを呼び出す処理は，タスク
-例外処理ルーチンの中でディスパッチ保留状æ
-‹ã‚’解除すべきであったのを，解
-é™¤ã›ãšã«ãƒªã‚¿ãƒ¼ãƒ³ã—ãŸå ´åˆã‚’æ•‘æ¸ˆã™ã‚‹ãŸã‚ã®ã‚‚ã®ã§ã‚ã‚‹ï¼Žä»¥ä¸‹ï¼Œã“ã®æŒ¯èˆžã„ã‚’
-「救済ケース」と呼ぶ．
-
-そこで，比較のために，タスク例外処理ルーチンの最後で，正しくディスパッ
-チ保留状æ
-‹ã‚’è§£é™¤ã—ã¦ã‹ã‚‰ãƒªã‚¿ãƒ¼ãƒ³ã—ãŸå ´åˆã®æŒ¯èˆžã„ã‚’è€ƒãˆã‚‹ï¼Žã“ã®å ´åˆã«ã¯ï¼Œ
-ディスパッチ保留状æ
-‹ã‚’解除するサービスコール（ena_dsp，chg_ipm）の中で，
-dispatchが呼び出されてタスクディスパッチが起こる．以下，この振舞いを
-「正常ケース」と呼ぶ．
-
-正常ケースと救済ケースを比較すると，call_texrtn→タスク例外処理ルーチン
-→サービスコール→dispatchã®é †ã§dispatchが呼び出されるか，call_texrtnか
-ら直接dispatchが呼び出されるかの違いということになり，救済ケースの方が
-ã‚¹ã‚¿ãƒƒã‚¯ã®ä½¿ç”¨é‡ã¯å°‘ãªã„ï¼Žã¤ã¾ã‚Šï¼Œæ­£å¸¸ã‚±ãƒ¼ã‚¹ã®å‹•ãã‚’æƒ³å®šã—ã¦ã‚¹ã‚¿ãƒƒã‚¯é ˜
-域が用意してあれば，救済ケースでも問題なく動作することになる．
-
-ここで，正常ケースと救済ケースで，上記以外に違いがないことが重要である．
-å
-·ä½“的には，call_texrtnの中で，タスク例外処理許可状æ
-‹ã«ã™ã‚‹ï¼ˆp_runtsk
-->enatexをtrueにする）前に，dispatchを呼び出すことが重要である．タスク
-例外処理許可状æ
-‹ã«ã—た後にdispatchを呼び出すと，出口のdispatch_rで，再
-びタスク例外処理ルーチンを実行してしまう可能性があり，救済ケースの方が
-スタックの使用量が増えてしまう．
-
-タスク例外処理ルーチンの中で，タスク例外処理許可状æ
-‹ã«ã—たままリターン
-ã—ãŸå ´åˆã«ã¯ï¼Œcall_texrtnから呼び出したdispatchの出口のdispatch_rで再び
-ã‚¿ã‚¹ã‚¯ä¾‹å¤–å‡¦ç†ãƒ«ãƒ¼ãƒãƒ³ã‚’å®Ÿè¡Œã—ã¦ã—ã¾ã†å¯èƒ½æ€§ãŒã‚ã‚‹ï¼Žã“ã®å ´åˆã‚‚ï¼Œã‚¿ã‚¹ã‚¯
-例外処理ルーチンの最後で，ディスパッチ保留状æ
-‹ã‚’解除してからリターンし
-ãŸå ´åˆã‚ˆã‚Šã¯ã‚¹ã‚¿ãƒƒã‚¯ã®ä½¿ç”¨é‡ãŒå°‘ãªã„ãŒï¼Œã‚¿ã‚¹ã‚¯ä¾‹å¤–å‡¦ç†ç¦æ­¢çŠ¶æ
-‹ã«ã—た後
-にディスパッチ保留状æ
-‹ã‚’è§£é™¤ã—ã¦ãƒªã‚¿ãƒ¼ãƒ³ã—ãŸå ´åˆã‚ˆã‚Šã¯ï¼Œã‚¹ã‚¿ãƒƒã‚¯ã®ä½¿ç”¨
-é‡ãŒå¢—ãˆã‚‹å ´åˆãŒã‚ã‚‹ï¼Žãã“ã§ï¼Œã“ã®ã‚ˆã†ãªçŠ¶æ³ãŒèµ·ã“ã‚‰ãªã„ã‚ˆã†ã«ï¼Œ
-dispatchを呼ぶ前にp_runtsk->enatexをfalseにする．
-
-
-â—‹ã‚¨ãƒ©ãƒ¼ã®ãƒã‚§ãƒƒã‚¯é †åº
-
-サービスコールå†
-ã«ãŠã‘ã‚‹ã‚¨ãƒ©ãƒ¼ãƒã‚§ãƒƒã‚¯ã¯ï¼Œä»¥ä¸‹ã®é †åºã§è¡Œã†ã“ã¨ã‚’åŽŸå‰‡ã¨
-する．なお，この節には，保護機能対応カーネルに関する記述が含まれている
-が，それらの記述は将来的にはより適切なドキュメントに移動する予定である．
-
-●エラーの3分類
-
-サービスコールのエラーは，大きく以下の3つに分類することができる．
-
-(a) 静的エラー
-
-対象のカーネルオブジェクトが登録されているか否かや，その状æ
-‹ã«ä¾å­˜ã›ãš
-に，チェックすることができるエラー．
-
-(b) 準静的エラー
-
-対象のカーネルオブジェクトが登録されていれば，その状æ
-‹ã«ä¾å­˜ã›ãšã«ãƒã‚§ãƒƒ
-クすることができるエラー．
-
-(c) 動的エラー
-
-対象のカーネルオブジェクトの状æ
-‹ã«ä¾å­˜ã™ã‚‹ã‚¨ãƒ©ãƒ¼ï¼Ž
-
-ASPカーネルにおいては，(a)と(b)のエラーはクリティカルセクションの外側で，
-ã“ã®é †åºã§ãƒã‚§ãƒƒã‚¯ã—ï¼Œ(c)のエラーはクリティカルセクションのå†
-側でチェッ
-クする．ただし，動的生成機能拡張パッケージでは，(b)のエラー（の一部）は
-クリティカルセクションのå†
-側で実施するå¿
-要がある．
-
-â—é™çš„ã‚¨ãƒ©ãƒ¼ã®ãƒã‚§ãƒƒã‚¯é †åº
-
-静的エラーには，実行コンテキストのエラー（ディスパッチ保留状æ
-‹ã‹ã‚‰ã®å‘¼
-出しエラーも含む），パラメータの範囲等のエラー（対象のカーネルオブジェ
-クトに依存せずにチェックできるもの）が含まれる．
-
-サービスコール中では，最初に実行コンテキストのエラーをチェックし，その
-å¾Œï¼Œãƒ‘ãƒ©ãƒ¡ãƒ¼ã‚¿ã®ä¸¦ã³é †ã«ï¼Œç¯„å›²ç­‰ã®ã‚¨ãƒ©ãƒ¼ã‚’ãƒã‚§ãƒƒã‚¯ã™ã‚‹ï¼Ž
-
-ä¿è­·æ©Ÿèƒ½å¯¾å¿œã‚«ãƒ¼ãƒãƒ«ã§ã¯ï¼Œãƒ‘ãƒ©ãƒ¡ãƒ¼ã‚¿ãŒãƒã‚¤ãƒ³ã‚¿ã§ã‚ã‚‹å ´åˆã«ï¼Œãƒã‚¤ãƒ³ã‚¿ã®
-æŒ‡ã™ãƒ¡ãƒ¢ãƒªé ˜åŸŸãŒã‚¢ã‚¯ã‚»ã‚¹å¯èƒ½ã§ã‚ã‚‹ã‹ã‚’ãƒã‚§ãƒƒã‚¯ã™ã‚‹å¿
-要があるが，メモリ
-é ˜åŸŸã®è¨­å®šãŒé™çš„ã§ã‚ã‚‹å ´åˆã«ã¯ï¼Œã“ã®ã‚¨ãƒ©ãƒ¼ãƒã‚§ãƒƒã‚¯ã‚‚ã“ã“ã§å®Ÿæ–½ã™ã‚‹ï¼ŽãŸ
-ã ã—ï¼Œãƒ¡ãƒ¢ãƒªé ˜åŸŸã®è¨­å®šãŒé™çš„ã§ãªã„å ´åˆã«ã¯ï¼Œã“ã®ã‚¨ãƒ©ãƒ¼ãƒã‚§ãƒƒã‚¯ã¯ã‚¯ãƒªãƒ†ã‚£
-カルセクションのå†
-側で行うå¿
-要がある．
-
-â—å‡†é™çš„ã‚¨ãƒ©ãƒ¼ã®ãƒã‚§ãƒƒã‚¯é †åº
-
-准静的エラーのチェックの前に，対象のカーネルオブジェクトの管理ブロック
-のå
-ˆé ­ç•ªåœ°ã‚’，ローカル変数に代å
-¥ã™ã‚‹ï¼Ž
-
-保護機能対応カーネルでは，この次に，対象のカーネルオブジェクトがアクセ
-ス可能であるかをチェックする処理を行う．当該サービスコールの呼出しが，
-システム状æ
-‹ã«å¯¾ã™ã‚‹ã‚¢ã‚¯ã‚»ã‚¹è¨±å¯ãƒ™ã‚¯ã‚¿ã§ä¿è­·ã•ã‚Œã¦ã„ã‚‹å ´åˆã«ã‚‚ï¼Œã“ã®æ®µ
-階でチェックを実施する．
-
-その後で，パラメータの範囲等のエラーの中で，対象のカーネルオブジェクト
-の登録æƒ
-å ±ï¼ˆåˆæœŸåŒ–ãƒ–ãƒ­ãƒƒã‚¯ã«å«ã¾ã‚Œã¦ã„ã‚‹æƒ
-å ±ï¼‰ã«ä¾å­˜ã—ã¦ãƒã‚§ãƒƒã‚¯ã™ã¹ã
-ã‚‚ã®ã®ãƒã‚§ãƒƒã‚¯ã‚’ï¼Œãƒ‘ãƒ©ãƒ¡ãƒ¼ã‚¿ã®ä¸¦ã³é †ã§å®Ÿæ–½ã™ã‚‹ï¼Ž
-
-
-○CHECKマクロとgoto文の使用
-
-ASPカーネルの実è£
-においては，サービスコールの静的なエラーをチェックする
-ために，名称が"CHECK_"で始まる一連のマクロ（これらを，CHECKマクロと総称
-する）を用いている．
-
-CHECKマクロの定義中にはgoto文を含んでいるが，MISRA-Cなどのコーディング
-ルールではgoto文の使用を禁止しており，goto文を使うべきではないという意
-見も多い．また，マクロの定義中にgoto文を使用することが問題であるという
-意見もある．
-
-ここでは，定義中にgoto文を含むCHECKマクロを用いる設計意図とそれを使用し
-てよい条件，CHECKãƒžã‚¯ãƒ­ã®ä½¿ç”¨ã«ã‚ˆã‚Šã‚½ãƒ•ãƒˆã‚¦ã‚§ã‚¢ã®ä¿¡é ¼æ€§ã«å•é¡ŒãŒç”Ÿã˜ã‚‹ã“
-とがないことを論証する．
-
-なお，ASPカーネルのカーネル本体の実è£
-では，CHECKマクロ以外にgoto文を用
-いている箇所はない（一部のシステムサービスでは，これ以外の方法でgoto文
-を用いている）．
-
-●CHECKマクロの定義とその使用法
-
-kernel/check.hには，25個のCHECKマクロが定義されているが，いずれも次のパ
-ターンで定義されている．ここでXXXXXには，チェックしたいエラーの種類を表
-す文字列がå
-¥ã‚‹ï¼Ž
-
-----------------------------------------
-#define CHECK_XXXXX(<……>) {                         \
-        if (<エラー条件>) {                                                \
-                ercd = <エラーコード>;                            \
+dispatchを呼び出してタスク切換えを行う場合には，dispatchの出口でタスク
+例外処理ルーチンを呼び出すためここで呼出し処理を行う必要はないが，コー
+ドが複雑になるため，dispatchを呼び出した場合もここでタスク例外処理ルー
+チンの呼出し処理を行っている．
+
+●call_texrtnからdispatchを呼び出す処理について
+
+dispatch_rから（ターゲットによってはcalltexを経由して）call_texrtnを呼
+び出し，call_texrtnからdispatchを呼び出すため，この2つの関数は相互再帰
+呼出しをしている．ここでは，この実装で支障のない理由を説明する．
+
+call_texrtnからdispatchを呼び出すのは，ディスパッチが保留されていない状
+態で呼び出されたタスク例外処理ルーチンが，その実行中にディスパッチ保留
+状態に遷移し，さらにタスクディスパッチを必要とする処理を行い，ディスパッ
+チ保留状態を解除しないままリターンした場合である．この場合，call_texrtn
+の中でディスパッチ保留状態を解除した後に，dispatchを呼び出してタスクディ
+スパッチを行う．つまり，call_texrtnからdispatchを呼び出す処理は，タスク
+例外処理ルーチンの中でディスパッチ保留状態を解除すべきであったのを，解
+除せずにリターンした場合を救済するためのものである．以下，この振舞いを
+「救済ケース」と呼ぶ．
+
+そこで，比較のために，タスク例外処理ルーチンの最後で，正しくディスパッ
+チ保留状態を解除してからリターンした場合の振舞いを考える．この場合には，
+ディスパッチ保留状態を解除するサービスコール（ena_dsp，chg_ipm）の中で，
+dispatchが呼び出されてタスクディスパッチが起こる．以下，この振舞いを
+「正常ケース」と呼ぶ．
+
+正常ケースと救済ケースを比較すると，call_texrtn→タスク例外処理ルーチン
+→サービスコール→dispatchの順でdispatchが呼び出されるか，call_texrtnか
+ら直接dispatchが呼び出されるかの違いということになり，救済ケースの方が
+スタックの使用量は少ない．つまり，正常ケースの動きを想定してスタック領
+域が用意してあれば，救済ケースでも問題なく動作することになる．
+
+ここで，正常ケースと救済ケースで，上記以外に違いがないことが重要である．
+具体的には，call_texrtnの中で，タスク例外処理許可状態にする（p_runtsk
+->enatexをtrueにする）前に，dispatchを呼び出すことが重要である．タスク
+例外処理許可状態にした後にdispatchを呼び出すと，出口のdispatch_rで，再
+びタスク例外処理ルーチンを実行してしまう可能性があり，救済ケースの方が
+スタックの使用量が増えてしまう．
+
+タスク例外処理ルーチンの中で，タスク例外処理許可状態にしたままリターン
+した場合には，call_texrtnから呼び出したdispatchの出口のdispatch_rで再び
+タスク例外処理ルーチンを実行してしまう可能性がある．この場合も，タスク
+例外処理ルーチンの最後で，ディスパッチ保留状態を解除してからリターンし
+た場合よりはスタックの使用量が少ないが，タスク例外処理禁止状態にした後
+にディスパッチ保留状態を解除してリターンした場合よりは，スタックの使用
+量が増える場合がある．そこで，このような状況が起こらないように，
+dispatchを呼ぶ前にp_runtsk->enatexをfalseにする．
+
+
+○エラーのチェック順序
+
+サービスコール内におけるエラーチェックは，以下の順序で行うことを原則と
+する．なお，この節には，保護機能対応カーネルに関する記述が含まれている
+が，それらの記述は将来的にはより適切なドキュメントに移動する予定である．
+
+●エラーの3分類
+
+サービスコールのエラーは，大きく以下の3つに分類することができる．
+
+(a) 静的エラー
+
+対象のカーネルオブジェクトが登録されているか否かや，その状態に依存せず
+に，チェックすることができるエラー．
+
+(b) 準静的エラー
+
+対象のカーネルオブジェクトが登録されていれば，その状態に依存せずにチェッ
+クすることができるエラー．
+
+(c) 動的エラー
+
+対象のカーネルオブジェクトの状態に依存するエラー．
+
+ASPカーネルにおいては，(a)と(b)のエラーはクリティカルセクションの外側で，
+この順序でチェックし，(c)のエラーはクリティカルセクションの内側でチェッ
+クする．ただし，動的生成機能拡張パッケージでは，(b)のエラー（の一部）は
+クリティカルセクションの内側で実施する必要がある．
+
+●静的エラーのチェック順序
+
+静的エラーには，実行コンテキストのエラー（ディスパッチ保留状態からの呼
+出しエラーも含む），パラメータの範囲等のエラー（対象のカーネルオブジェ
+クトに依存せずにチェックできるもの）が含まれる．
+
+サービスコール中では，最初に実行コンテキストのエラーをチェックし，その
+後，パラメータの並び順に，範囲等のエラーをチェックする．
+
+保護機能対応カーネルでは，パラメータがポインタである場合に，ポインタの
+指すメモリ領域がアクセス可能であるかをチェックする必要があるが，メモリ
+領域の設定が静的である場合には，このエラーチェックもここで実施する．た
+だし，メモリ領域の設定が静的でない場合には，このエラーチェックはクリティ
+カルセクションの内側で行う必要がある．
+
+●准静的エラーのチェック順序
+
+准静的エラーのチェックの前に，対象のカーネルオブジェクトの管理ブロック
+の先頭番地を，ローカル変数に代入する．
+
+保護機能対応カーネルでは，この次に，対象のカーネルオブジェクトがアクセ
+ス可能であるかをチェックする処理を行う．当該サービスコールの呼出しが，
+システム状態に対するアクセス許可ベクタで保護されている場合にも，この段
+階でチェックを実施する．
+
+その後で，パラメータの範囲等のエラーの中で，対象のカーネルオブジェクト
+の登録情報（初期化ブロックに含まれている情報）に依存してチェックすべき
+もののチェックを，パラメータの並び順で実施する．
+
+
+○CHECKマクロとgoto文の使用
+
+ASPカーネルの実装においては，サービスコールの静的なエラーをチェックする
+ために，名称が"CHECK_"で始まる一連のマクロ（これらを，CHECKマクロと総称
+する）を用いている．
+
+CHECKマクロの定義中にはgoto文を含んでいるが，MISRA-Cなどのコーディング
+ルールではgoto文の使用を禁止しており，goto文を使うべきではないという意
+見も多い．また，マクロの定義中にgoto文を使用することが問題であるという
+意見もある．
+
+ここでは，定義中にgoto文を含むCHECKマクロを用いる設計意図とそれを使用し
+てよい条件，CHECKマクロの使用によりソフトウェアの信頼性に問題が生じるこ
+とがないことを論証する．
+
+なお，ASPカーネルのカーネル本体の実装では，CHECKマクロ以外にgoto文を用
+いている箇所はない（一部のシステムサービスでは，これ以外の方法でgoto文
+を用いている）．
+
+●CHECKマクロの定義とその使用法
+
+kernel/check.hには，25個のCHECKマクロが定義されているが，いずれも次のパ
+ターンで定義されている．ここでXXXXXには，チェックしたいエラーの種類を表
+す文字列が入る．
+
+----------------------------------------
+#define CHECK_XXXXX(<……>) {                             \
+        if (<エラー条件>) {                                          \
+                ercd = <エラーコード>;                                \
                 goto error_exit;                                        \
         }                                                                               \
@@ -1511 +1068 @@
 ----------------------------------------
 
-これらのCHECKマクロは，多くのサービスコールの処理関数中で，次のように使
-用されている．
+これらのCHECKマクロは，多くのサービスコールの処理関数中で，次のように使
+用されている．
 
 ----------------------------------------
 ER
-<サービスコール名>(……)
+<サービスコール名>(……)
 {
-        <ローカル変数の宣言>
+        <ローカル変数の宣言>
         ER              ercd;
 
-        LOG_XXX_YYY_ENTER(……);
-        CHECK_XXXXX(……);
-        CHECK_YYYYY(……);
-
-        <サービスコール処理本体>
+        LOG_XXX_YYY_ENTER(……);
+        CHECK_XXXXX(……);
+        CHECK_YYYYY(……);
+
+        <サービスコール処理本体>
 
   error_exit:
-        LOG_XXX_YYY_LEAVE(……);
+        LOG_XXX_YYY_LEAVE(……);
         return(ercd);
 }
 ----------------------------------------
 
-この例では，CHECKマクロを2つ使用しているが，1ã¤ã®ã¿ä½¿ç”¨ã—ã¦ã„ã‚‹å ´åˆã‚‚ã‚
-れば，3ã¤ä»¥ä¸Šä½¿ç”¨ã—ã¦ã„ã‚‹å ´åˆã‚‚ã‚ã‚‹ï¼Žã¾ãŸï¼Œè¤‡æ•°ã®CHECKマクロの間に，ロー
-カル変数への代å
-¥æ–‡ãŒå
-¥ã‚‹å ´åˆã‚‚ある（例えば，ter_tskの処理関数）．
-
-●設計意図
-
-CHECKマクロを使用する意図は，ほとんどのサービスコールでå¿
-要な静的エラー
-のチェックコードをパターン化し，ソースコードの簡潔さを保つことで読みや
-すさを向上させるとともに，記述ミスの可能性を減らすことである．
-
-ちなみに，CHECKãƒžã‚¯ãƒ­ã‚’ä½¿ç”¨ã—ãªã„å ´åˆï¼Œä¸Šã«ç¤ºã—ãŸã‚µãƒ¼ãƒ“ã‚¹ã‚³ãƒ¼ãƒ«ã®å‡¦ç†é–¢
-数は，次のように記述することになる．
+この例では，CHECKマクロを2つ使用しているが，1つのみ使用している場合もあ
+れば，3つ以上使用している場合もある．また，複数のCHECKマクロの間に，ロー
+カル変数への代入文が入る場合もある（例えば，ter_tskの処理関数）．
+
+●設計意図
+
+CHECKマクロを使用する意図は，ほとんどのサービスコールで必要な静的エラー
+のチェックコードをパターン化し，ソースコードの簡潔さを保つことで読みや
+すさを向上させるとともに，記述ミスの可能性を減らすことである．
+
+ちなみに，CHECKマクロを使用しない場合，上に示したサービスコールの処理関
+数は，次のように記述することになる．
 
 ----------------------------------------
 ER
-<サービスコール名>(……)
+<サービスコール名>(……)
 {
-        <ローカル変数の宣言>
+        <ローカル変数の宣言>
         ER              ercd;
 
-        LOG_XXX_YYY_ENTER(……);
-        if (<XXXXXのエラー条件>) {
-                ercd = <XXXXXのエラーコード>;
+        LOG_XXX_YYY_ENTER(……);
+        if (<XXXXXのエラー条件>) {
+                ercd = <XXXXXのエラーコード>;
         }
         else {
-                if (<YYYYYのエラー条件>) {
-                        ercd = <YYYYYのエラーコード>;
+                if (<YYYYYのエラー条件>) {
+                        ercd = <YYYYYのエラーコード>;
                 }
                 else {
 
-                        <サービスコール処理本体>
+                        <サービスコール処理本体>
 
                 }
         }
-        LOG_XXX_YYY_LEAVE(……);
+        LOG_XXX_YYY_LEAVE(……);
         return(ercd);
 }
 ----------------------------------------
 
-CHECKマクロのå†
-容を知っているという前提の下では，å
-ƒã®ã‚½ãƒ¼ã‚¹ã‚³ãƒ¼ãƒ‰ã®æ–¹ãŒ
-読みやすいのは明らかである．
-
-なお，このようなCHECKマクロの定義には，goto文の使用が不可避である．
-
-●CHECKマクロを使用してよい条件
-
-CHECKマクロは，次の条件を満たすように使用しなければならない．
-
-(1) CHECKマクロは，サービスコール処理関数のå
-ˆé ­éƒ¨åˆ†ã§ï¼Œã‚µãƒ¼ãƒ“スコールå
-¥
-　　口のログを出した後，クリティカルセクションにå
-¥ã‚‹å‰ã¾ã§ã«ï¼Œå‡¦ç†é–¢æ•°
-　　のトップレベルで用いる．
-
-(2) サービスコール処理関数の末尾部分で，クリティカルセクションを抜けた
-　　後，サービスコール出口のログを出す前に，処理関数のトップレベルに，
-　　error_exitラベルを置く．
-
-â—å•é¡Œã‚’ç”Ÿã˜ã‚‹ã“ã¨ãŒãªã„æ ¹æ‹ 
-
-このような方法でgotoæ–‡ã‚’ä½¿ç”¨ã—ã¦ã‚‚ï¼Œã‚½ãƒ•ãƒˆã‚¦ã‚§ã‚¢ã®ä¿¡é ¼æ€§ã«å•é¡ŒãŒç”Ÿã˜ã‚‹
-ことがないことを主張するには，そもそも，MISRA-Cなどのコーディングルール
-でgotoæ–‡ã®ä½¿ç”¨ã‚’ç¦æ­¢ã—ã¦ã„ã‚‹æ ¹æ‹ ï¼Œè¨€ã„æ›ãˆã‚‹ã¨ï¼Œgoto文の使用によりソフ
-ãƒˆã‚¦ã‚§ã‚¢ã®ä¿¡é ¼æ€§ã«å•é¡ŒãŒç”Ÿã˜ã‚‹å¯èƒ½æ€§ã®ã‚ã‚‹ç†ç”±ã‚’æ˜Žã‚‰ã‹ã«ã™ã‚‹å¿
-要がある．
-
-MISRA-Cのドキュメントでは，gotoæ–‡ã®ä½¿ç”¨ã‚’ç¦æ­¢ã™ã‚‹æ ¹æ‹ ã«ã¤ã„ã¦ã‚ã¾ã‚Šæ˜Žç¢º
-ã«ãªã£ã¦ãŠã‚‰ãšï¼Œã“ã“ã§ã¯ãã®æ ¹æ‹ ã‚’æ¬¡ã®ã‚ˆã†ã«æŽ¨æ¸¬ã™ã‚‹ï¼Ž
-
-・処理の流れが複雑になり，プログラムの意図が読みにくくなる（いわゆる，
-　スパゲッティプログラムになる）．
-
-CHECKãƒžã‚¯ãƒ­ã®å ´åˆã«ã¯ï¼Œgoto文をエラー発生時の強制脱出に用いており，ラベ
-ルもerror_exitとするなど，プログラムの意図は明らかである．一方，このよ
-うにgotoæ–‡ã‚’ã‚¨ãƒ©ãƒ¼æ™‚ã®å¼·åˆ¶è„±å‡ºã«ç”¨ã„ã‚‹å ´åˆã«ã¯ï¼Œæ¬¡ã®ç‚¹ã‚‚goto文の使用を
-ç¦æ­¢ã™ã‚‹æ ¹æ‹ ã«ãªã‚Šã†ã‚‹ï¼Ž
-
-・goto文で強制脱出することにより，脱出時に行わなければならない後処理が
-　飛ばされるおそれがある．
-
-ただしこの点についても，CHECKマクロを上記の使用条件を満たして使う限りは，
-脱出時に行わなければならない後処理はなく，CHECKマクロの使用によりソフト
-ã‚¦ã‚§ã‚¢ã®ä¿¡é ¼æ€§ã«å•é¡ŒãŒç”Ÿã˜ã‚‹ã“ã¨ã¯ãªã„ï¼Ž
-
-問題を生じることがないことを論証するもう1つ方法は，コーディングルールに
-合致しないプログラムが，コーディングルールに合致したプログラムと等価で
-あることを示す方法である．
-
-すでに「設計意図」の節で述べたように，CHECKマクロを使用したプログラムは，
-goto文を使用しない等価なプログラムに書き換えることができるが，より一般
-的には，次のことが言える．
-
-else部を持たないif文のthen部の最後に，if文より下（前方）にあり，if文と
-同じブロックå†
-の同じ階層のラベルへ分岐するgotoæ–‡ãŒã‚ã‚‹å ´åˆã«ã¯ï¼Œif文と
-ラベルの間の文をelse部にすることにより，goto文を使わない等価なプログラ
-ムに書き換えることができる．
-
-例として，goto文を使った次のプログラムを考える．
+CHECKマクロの内容を知っているという前提の下では，元のソースコードの方が
+読みやすいのは明らかである．
+
+なお，このようなCHECKマクロの定義には，goto文の使用が不可避である．
+
+●CHECKマクロを使用してよい条件
+
+CHECKマクロは，次の条件を満たすように使用しなければならない．
+
+(1) CHECKマクロは，サービスコール処理関数の先頭部分で，サービスコール入
+　　口のログを出した後，クリティカルセクションに入る前までに，処理関数
+　　のトップレベルで用いる．
+
+(2) サービスコール処理関数の末尾部分で，クリティカルセクションを抜けた
+　　後，サービスコール出口のログを出す前に，処理関数のトップレベルに，
+　　error_exitラベルを置く．
+
+●問題を生じることがない根拠
+
+このような方法でgoto文を使用しても，ソフトウェアの信頼性に問題が生じる
+ことがないことを主張するには，そもそも，MISRA-Cなどのコーディングルール
+でgoto文の使用を禁止している根拠，言い換えると，goto文の使用によりソフ
+トウェアの信頼性に問題が生じる可能性のある理由を明らかにする必要がある．
+
+MISRA-Cのドキュメントでは，goto文の使用を禁止する根拠についてあまり明確
+になっておらず，ここではその根拠を次のように推測する．
+
+・処理の流れが複雑になり，プログラムの意図が読みにくくなる（いわゆる，
+　スパゲッティプログラムになる）．
+
+CHECKマクロの場合には，goto文をエラー発生時の強制脱出に用いており，ラベ
+ルもerror_exitとするなど，プログラムの意図は明らかである．一方，このよ
+うにgoto文をエラー時の強制脱出に用いる場合には，次の点もgoto文の使用を
+禁止する根拠になりうる．
+
+・goto文で強制脱出することにより，脱出時に行わなければならない後処理が
+　飛ばされるおそれがある．
+
+ただしこの点についても，CHECKマクロを上記の使用条件を満たして使う限りは，
+脱出時に行わなければならない後処理はなく，CHECKマクロの使用によりソフト
+ウェアの信頼性に問題が生じることはない．
+
+問題を生じることがないことを論証するもう1つ方法は，コーディングルールに
+合致しないプログラムが，コーディングルールに合致したプログラムと等価で
+あることを示す方法である．
+
+すでに「設計意図」の節で述べたように，CHECKマクロを使用したプログラムは，
+goto文を使用しない等価なプログラムに書き換えることができるが，より一般
+的には，次のことが言える．
+
+else部を持たないif文のthen部の最後に，if文より下（前方）にあり，if文と
+同じブロック内の同じ階層のラベルへ分岐するgoto文がある場合には，if文と
+ラベルの間の文をelse部にすることにより，goto文を使わない等価なプログラ
+ムに書き換えることができる．
+
+例として，goto文を使った次のプログラムを考える．
 
 ----------------------------------------
         {
-                /* if文の前の文 */
+                /* if文の前の文 */
                 if (....) {
-                        /* then部の文 */
-                        goto <ラベル>;
+                        /* then部の文 */
+                        goto <ラベル>;
                 }
-                /* if文とラベルの間の文 */
-          <ラベル>:
-                /* ラベルより後ろの文 */
+                /* if文とラベルの間の文 */
+          <ラベル>:
+                /* ラベルより後ろの文 */
         }
 ----------------------------------------
 
-このプログラムは，goto文を使わない次のプログラムと等価である．
+このプログラムは，goto文を使わない次のプログラムと等価である．
 
 ----------------------------------------
         {
-                /* if文の前の文 */
+                /* if文の前の文 */
                 if (....) {
-                        /* then部の文 */
+                        /* then部の文 */
                 }
                 else {
-                        /* if文とラベルの間の文 */
+                        /* if文とラベルの間の文 */
                 }
-                /* ラベルより後ろの文 */
+                /* ラベルより後ろの文 */
         }
 ----------------------------------------
 
-この条件に合致するgotoæ–‡ãŒè¤‡æ•°ã‚ã‚‹å ´åˆã«ã¯ï¼Œä¸‹ã«ã‚ã‚‹gotoæ–‡ã‹ã‚‰é †ã«ä¸Šè¨˜
-の方法によって書き換えることで，goto文を使わない等価なプログラムに書き
-換えることができる．
-
-CHECKマクロの使用方法は，上記のgoto文の使用方法に合致するため，goto文を
-使用しない等価なプログラムに書き換えることができる．よって，このCHECKマ
-クロにより問題を生じることはない．
-
-
-○ext_tsk，ext_kerの返り値
-
-μITRON4.0仕様では，ext_tskはリターンすることのないサービスコールとなっ
-ているが，TOPPERS新世代カーネルにおいては，このサービスコールの返り値を
-ERåž‹ã«å¤‰æ›´ã—ï¼Œéžã‚¿ã‚¹ã‚¯ã‚³ãƒ³ãƒ†ã‚­ã‚¹ãƒˆã‹ã‚‰å‘¼ã°ã‚ŒãŸå ´åˆã«ã¯ï¼ŒE_CTXエラーを返
-り値としてリターンすることとする．
-
-この仕様に対するいくつかの対案を検討したが，以下の理由で採用しない．
-
-・JSPカーネルのように，危険の可能性を検出しながら実行を継続する方法は，
-ã€€ä¿¡é ¼æ€§ãƒ»å®‰å
-¨æ€§ã‚’é‡è¦–ã™ã‚‹ã‚·ã‚¹ãƒ†ãƒ ã§ã¯æœ›ã¾ã—ããªã„ï¼Žä¿¡é ¼æ€§ãƒ»å®‰å
-¨æ€§ã‚’重
-　視するシステムでは，危険の可能性を検出したら，早期にリカバリをすべき
-　である．
-
-・ASPカーネルの当初案のカーネルをダウンさせる方法は，アプリケーション側
-　で回復する余地をなくすという意味で望ましくない．
-
-・過去の互換性を保つために，型をvoidとしたまま，非タスクコンテキストか
-ã€€ã‚‰å‘¼ã°ã‚ŒãŸå ´åˆã«ã¯ãƒªã‚¿ãƒ¼ãƒ³ã™ã‚‹ã¨ã™ã‚‹æ–¹æ³•ã¯ï¼Œã‚«ãƒ¼ãƒãƒ«ã®ä»•æ§˜å¤‰æ›´ã«æ°—ã¥
-　きにくくなるという意味で望ましくない．また，他のエラーコード（例えば
-　E_NOSPT）を返す余地をなくしている．
-
-・一種のCPU例外を呼び出すことにする方法は，カーネル仕様å
-¨ä½“の整合性を考
-　えて採用しなかった．ここで一種のCPU例外を導å
-¥ã™ã‚‹ã‚ˆã‚Šã‚‚，サービスコー
-ã€€ãƒ«ãŒã‚¨ãƒ©ãƒ¼ã‚’è¿”ã—ãŸå ´åˆã«å‘¼ã°ã‚Œã‚‹OSEK/VDX OS仕様のエラーフックに相当す
-　る機能を導å
-¥ã—た方が有用性が高いと思われるためである．
-
-この変更により，さらに，CPUロック状æ
-‹ã‚„ディスパッチ禁止状æ
-‹ã§ext_tskが
-å‘¼ã°ã‚ŒãŸå ´åˆã«ã‚‚ã‚¨ãƒ©ãƒ¼ãƒªã‚¿ãƒ¼ãƒ³ã™ã‚‹æ–¹æ³•ãŒè€ƒãˆã‚‰ã‚Œã‚‹ãŒï¼Œã‚¿ã‚¹ã‚¯ã®ãƒ¡ã‚¤ãƒ³ãƒ«ãƒ¼
-チンからのリターンとext_tskが等価にならないため，採用しない．また，他の
-処理単位からのリターン方法と整合させる意味もある（例えば，割込みハンド
-ラからCPUロック状æ
-‹ã®ã¾ã¾ãƒªã‚¿ãƒ¼ãƒ³ã—ãŸå ´åˆã®æ‰±ã„ï¼‰ï¼Ž
-
-これにあわせて，ext_kerについても，返り値をER型に変更する．ASPカーネル
-では，ext_kerがエラーを返すことはないが，HRPカーネルでは，E_OACVエラー
-ã‚’è¿”ã™å ´åˆãŒã‚ã‚‹ï¼Ž
-
-なお，μITRON4.0仕様では，exd_tskもリターンすることのないサービスコール
-となっているが，TOPPERS新世代カーネルでは，exd_tskはサポートしていない．
-
-
-â—‹ã‚«ãƒ¼ãƒãƒ«ã®ãƒ‡ãƒ¼ã‚¿æ§‹é€ ã«å¯¾ã™ã‚‹volatile宣言について（クリティカルセクショ
-ンの出å
-¥å‡¦ç†ã®å®Ÿç¾ã«é–¢ã™ã‚‹åˆ¶ç´„）
-
-カーネルå†
-ã®ãƒ‡ãƒ¼ã‚¿æ§‹é€ ã¯ï¼Œä¸¦è¡Œå®Ÿè¡Œã•ã‚Œã‚‹ä»–ã®å‡¦ç†å˜ä½ï¼ˆå‰²è¾¼ã¿ãƒãƒ³ãƒ‰ãƒ©ã‚„
-タスク）からもアクセスされる可能性があるため，volatile宣言がå¿
-要ではな
-いかと考えられる．実際，クリティカルセクションå†
-でカーネル変数を読むコー
-ドが，コンパイラの最適化によりクリティカルセクション外に移動され，それ
-ãŒåŽŸå› ã¨ãªã£ãŸå•é¡Œäº‹ä¾‹ã‚‚å ±å‘Šã•ã‚Œã¦ã„ã‚‹ï¼Ž
-
-カーネルå†
-ã®ã™ã¹ã¦ã®ãƒ‡ãƒ¼ã‚¿æ§‹é€ ã«volatile宣言をつける方法は，安å
-¨ã§ã¯ã‚
-るが，最適化が抑止されるために，カーネルのサイズや性能には悪影響を与え
-る．そこでASPカーネルでは，次の方法でvolatile宣言のå¿
-要性をなくすことと
-する．
-
-ASPカーネルにおいては，並行実行される他の処理単位から書き換えられる可能
-æ€§ã®ã‚ã‚‹ãƒ‡ãƒ¼ã‚¿æ§‹é€ ã¯ï¼Œã™ã¹ã¦ï¼ŒCPUロック状æ
-‹ã¾ãŸã¯å
-¨å‰²è¾¼ã¿ãƒ­ãƒƒã‚¯çŠ¶æ
-‹ã«ã‚ˆ
-るクリティカルセクションå†
-でアクセスしている．クリティカルセクションå†
-
-ã§ã®ãƒ‡ãƒ¼ã‚¿æ§‹é€ ã®ã‚¢ã‚¯ã‚»ã‚¹ãŒï¼Œã‚³ãƒ³ãƒ‘ã‚¤ãƒ©ã®æœ€é©åŒ–ã«ã‚ˆã‚Šã‚¯ãƒªãƒ†ã‚£ã‚«ãƒ«ã‚»ã‚¯ã‚·ãƒ§
-ン外に移動されないようにするには，コンパイラに対して，クリティカルセク
-ションの出å
-¥å‡¦ç†ã«ã‚ˆã‚Šï¼Œãƒ¡ãƒ¢ãƒªä¸Šã®ãƒ‡ãƒ¼ã‚¿æ§‹é€ が書き変わる可能性があるこ
-とを知らせればよい．
-
-å
-·ä½“的には，クリティカルセクションの出å
-¥å‡¦ç†ã‚’関数によって実現すれば，
-このような最適化を抑止することができる．しかし，ASPカーネルの多くのター
-ゲット依存部において，クリティカルセクションの出å
-¥å‡¦ç†ã¯ãƒžã‚¯ãƒ­ã‚„インラ
-イン関数により実è£
-されており，上のような最適化を抑止できない．
-
-そこで，クリティカルセクションの出å
-¥å‡¦ç†ã‚’å®Ÿç¾ã™ã‚‹å ´åˆã«ã¯ï¼Œãƒ¡ãƒ¢ãƒªä¸Šã®
-ãƒ‡ãƒ¼ã‚¿æ§‹é€ ãŒæ›¸ãå¤‰ã‚ã‚‹å¯èƒ½æ€§ãŒã‚ã‚‹ã“ã¨ã‚’ï¼Œä½•ã‚‰ã‹ã®æ–¹æ³•ã§ã‚³ãƒ³ãƒ‘ã‚¤ãƒ©ã«çŸ¥
-らせなければならないという制約を設ける．GNU開発環境では，次のいずれかの
-方法でこの制約を満たすことができる．
-
-(a) クリティカルセクションの出å
-¥å‡¦ç†ã®å
-¨ä½“または出å
-¥å‡¦ç†ã®æœ¬è³ªçš„な部分
-        （å
-·ä½“的には，割込み禁止／許可する処理）を（インラインでない）通常
-        の関数により実現する．
-
-(b) クリティカルセクションの出å
-¥å‡¦ç†ã®æœ¬è³ªçš„な部分をインラインアセンブ
-        ãƒ©ã«ã‚ˆã£ã¦å®Ÿç¾ã—ã¦ã„ã‚‹å ´åˆã«ã¯ï¼Œãã®ã‚¤ãƒ³ãƒ©ã‚¤ãƒ³ã‚¢ã‚»ãƒ³ãƒ–ãƒ©ã®clobber変
-        数リストに"memory"ã‚’è¿½åŠ ã™ã‚‹ï¼Ž
-
-(c) クリティカルセクションの出å
-¥å‡¦ç†ã®æœ¬è³ªçš„な部分が，マクロやインライ
-        ãƒ³é–¢æ•°å‘¼å‡ºã—ã§å®Ÿç¾ã—ã¦ã„ã‚‹å ´åˆã«ã¯ï¼Œã‚¯ãƒªãƒ†ã‚£ã‚«ãƒ«ã‚»ã‚¯ã‚·ãƒ§ãƒ³ã«å
-¥ã‚‹å‡¦
-        理の最後と出る処理のå
-ˆé ­ã«ï¼ŒAsm("":::"memory")という記述をå
-¥ã‚Œã‚‹ï¼Ž
-
-なお，この制約が適用されるクリティカルセクションの出å
-¥å‡¦ç†ã¯ï¼Œä»¥ä¸‹ã®ã‚‚
-のである．
+この条件に合致するgoto文が複数ある場合には，下にあるgoto文から順に上記
+の方法によって書き換えることで，goto文を使わない等価なプログラムに書き
+換えることができる．
+
+CHECKマクロの使用方法は，上記のgoto文の使用方法に合致するため，goto文を
+使用しない等価なプログラムに書き換えることができる．よって，このCHECKマ
+クロにより問題を生じることはない．
+
+
+○ext_tsk，ext_kerの返り値
+
+μITRON4.0仕様では，ext_tskはリターンすることのないサービスコールとなっ
+ているが，TOPPERS新世代カーネルにおいては，このサービスコールの返り値を
+ER型に変更し，非タスクコンテキストから呼ばれた場合には，E_CTXエラーを返
+り値としてリターンすることとする．
+
+この仕様に対するいくつかの対案を検討したが，以下の理由で採用しない．
+
+・JSPカーネルのように，危険の可能性を検出しながら実行を継続する方法は，
+　信頼性・安全性を重視するシステムでは望ましくない．信頼性・安全性を重
+　視するシステムでは，危険の可能性を検出したら，早期にリカバリをすべき
+　である．
+
+・ASPカーネルの当初案のカーネルをダウンさせる方法は，アプリケーション側
+　で回復する余地をなくすという意味で望ましくない．
+
+・過去の互換性を保つために，型をvoidとしたまま，非タスクコンテキストか
+　ら呼ばれた場合にはリターンするとする方法は，カーネルの仕様変更に気づ
+　きにくくなるという意味で望ましくない．また，他のエラーコード（例えば
+　E_NOSPT）を返す余地をなくしている．
+
+・一種のCPU例外を呼び出すことにする方法は，カーネル仕様全体の整合性を考
+　えて採用しなかった．ここで一種のCPU例外を導入するよりも，サービスコー
+　ルがエラーを返した場合に呼ばれるOSEK/VDX OS仕様のエラーフックに相当す
+　る機能を導入した方が有用性が高いと思われるためである．
+
+この変更により，さらに，CPUロック状態やディスパッチ禁止状態でext_tskが
+呼ばれた場合にもエラーリターンする方法が考えられるが，タスクのメインルー
+チンからのリターンとext_tskが等価にならないため，採用しない．また，他の
+処理単位からのリターン方法と整合させる意味もある（例えば，割込みハンド
+ラからCPUロック状態のままリターンした場合の扱い）．
+
+これにあわせて，ext_kerについても，返り値をER型に変更する．ASPカーネル
+では，ext_kerがエラーを返すことはないが，HRPカーネルでは，E_OACVエラー
+を返す場合がある．
+
+なお，μITRON4.0仕様では，exd_tskもリターンすることのないサービスコール
+となっているが，TOPPERS新世代カーネルでは，exd_tskはサポートしていない．
+
+
+○カーネルのデータ構造に対するvolatile宣言について（クリティカルセクショ
+ンの出入処理の実現に関する制約）
+
+カーネル内のデータ構造は，並行実行される他の処理単位（割込みハンドラや
+タスク）からもアクセスされる可能性があるため，volatile宣言が必要ではな
+いかと考えられる．実際，クリティカルセクション内でカーネル変数を読むコー
+ドが，コンパイラの最適化によりクリティカルセクション外に移動され，それ
+が原因となった問題事例も報告されている．
+
+カーネル内のすべてのデータ構造にvolatile宣言をつける方法は，安全ではあ
+るが，最適化が抑止されるために，カーネルのサイズや性能には悪影響を与え
+る．そこでASPカーネルでは，次の方法でvolatile宣言の必要性をなくすことと
+する．
+
+ASPカーネルにおいては，並行実行される他の処理単位から書き換えられる可能
+性のあるデータ構造は，すべて，CPUロック状態または全割込みロック状態によ
+るクリティカルセクション内でアクセスしている．クリティカルセクション内
+でのデータ構造のアクセスが，コンパイラの最適化によりクリティカルセクショ
+ン外に移動されないようにするには，コンパイラに対して，クリティカルセク
+ションの出入処理により，メモリ上のデータ構造が書き変わる可能性があるこ
+とを知らせればよい．
+
+具体的には，クリティカルセクションの出入処理を関数によって実現すれば，
+このような最適化を抑止することができる．しかし，ASPカーネルの多くのター
+ゲット依存部において，クリティカルセクションの出入処理はマクロやインラ
+イン関数により実装されており，上のような最適化を抑止できない．
+
+そこで，クリティカルセクションの出入処理を実現する場合には，メモリ上の
+データ構造が書き変わる可能性があることを，何らかの方法でコンパイラに知
+らせなければならないという制約を設ける．GNU開発環境では，次のいずれかの
+方法でこの制約を満たすことができる．
+
+(a) クリティカルセクションの出入処理の全体または出入処理の本質的な部分
+        （具体的には，割込み禁止／許可する処理）を（インラインでない）通常
+        の関数により実現する．
+
+(b) クリティカルセクションの出入処理の本質的な部分をインラインアセンブ
+        ラによって実現している場合には，そのインラインアセンブラのclobber変
+        数リストに"memory"を追加する．
+
+(c) クリティカルセクションの出入処理の本質的な部分が，マクロやインライ
+        ン関数呼出しで実現している場合には，クリティカルセクションに入る処
+        理の最後と出る処理の先頭に，Asm("":::"memory")という記述を入れる．
+
+なお，この制約が適用されるクリティカルセクションの出入処理は，以下のも
+のである．
 
         SIL_LOC_INT
@@ -1806 +1317 @@
 
 
-○型キャストに伴う警告メッセージ
-
-GCCで-O2ã‚ªãƒ—ã‚·ãƒ§ãƒ³ã‚’ã¤ã‘ã¦ã‚³ãƒ³ãƒ‘ã‚¤ãƒ«ã—ãŸå ´åˆã«ï¼Œã‚«ãƒ¼ãƒãƒ«ã®ã‚½ãƒ¼ã‚¹ã‚³ãƒ¼ãƒ‰
-中の数箇所で，次の警告メッセージが出る（GCCのバージョンにもよる）．
+○型キャストに伴う警告メッセージ
+
+GCCで-O2オプションをつけてコンパイルした場合に，カーネルのソースコード
+中の数箇所で，次の警告メッセージが出る（GCCのバージョンにもよる）．
 
 warning: dereferencing type-punned pointer will break strict-aliasing rules
 
-これは，GCCに-O2オプションをつけると，コンパイラがC言語のstrict
-aliasing ruleを前提とするためである．コンパイラにstrict aliasing ruleを
-適用させないためには，GCCのオプションに-fno-strict-aliasingを指定すれば
-よい．これにより，警告メッセージは抑止されるが，strict aliasing ruleを
-前提とした最適化は行われなくなる．
-
-ASPカーネルに実è£
-においては，strict aliasing ruleを前提とした最適化を行っ
-てもよく，この警告メッセージを無視しても差し支えない．以下では，この警
-告メッセージを無視しても差し支えない理由を述べる．
-
-警告メッセージが出る例として，semaphore.c中の次の行について検討する．
+これは，GCCに-O2オプションをつけると，コンパイラがC言語のstrict
+aliasing ruleを前提とするためである．コンパイラにstrict aliasing ruleを
+適用させないためには，GCCのオプションに-fno-strict-aliasingを指定すれば
+よい．これにより，警告メッセージは抑止されるが，strict aliasing ruleを
+前提とした最適化は行われなくなる．
+
+ASPカーネルに実装においては，strict aliasing ruleを前提とした最適化を行っ
+てもよく，この警告メッセージを無視しても差し支えない．以下では，この警
+告メッセージを無視しても差し支えない理由を述べる．
+
+警告メッセージが出る例として，semaphore.c中の次の行について検討する．
 
         wobj_make_wait((WOBJCB *) p_semcb, (WINFO_WOBJ *) &winfo_sem);
 
-ã“ã®è­¦å‘Šãƒ¡ãƒƒã‚»ãƒ¼ã‚¸ã®åŽŸå› ã¯ï¼Œç›´æŽ¥çš„ã«ã¯ï¼Œ&winfo_semを(WINFO_WOBJ *)にキャ
-ã‚¹ãƒˆã—ã¦ã„ã‚‹ã“ã¨ã§ã‚ã‚‹ãŒï¼Œæœ¬è³ªçš„ãªåŽŸå› ã¯ï¼Œã“ã®ã‚³ãƒ¼ãƒ‰ãŒC言語のstrict
-aliasing ruleに従わない代å
-¥æ–‡ã®åŽŸå› になる可能性があり，このルールに依存
-した最適化が誤った結果を引き起こす可能性があることである．
-
-C言語のstrict aliasing ruleは，互換性のない異なる型を通して，オーバラッ
-ãƒ—ã™ã‚‹ãƒ¡ãƒ¢ãƒªé ˜åŸŸã‚’ã‚¢ã‚¯ã‚»ã‚¹ã™ã‚‹ä»£å
-¥æ–‡ã‚’使用してはならないというものであ
-ã‚‹ï¼ˆä½¿ç”¨ã—ãŸå ´åˆã®æŒ¯èˆžã„ã¯æœªå®šç¾©ã«ãªã‚‹ï¼‰ï¼Žã“ã®ã‚±ãƒ¼ã‚¹ã§ã¯ï¼Œ(WINFO_SEM
-*)型のポインタ経由と(WINFO_WOBJ *)型のポインタ経由で，オーバラップする
-ãƒ¡ãƒ¢ãƒªé ˜åŸŸã‚’ã‚¢ã‚¯ã‚»ã‚¹ã™ã‚‹ä»£å
-¥æ–‡ã‚’使用してはならないことになる．また，警
-å‘Šãƒ¡ãƒƒã‚»ãƒ¼ã‚¸ã®åŽŸå› ã«ãªã£ã¦ã¯ã„ãªã„ãŒï¼Œ(SEMCB *)型のポインタ経由と
-(WOBJCB *)åž‹ã®ãƒã‚¤ãƒ³ã‚¿çµŒç”±ã§ï¼Œã‚ªãƒ¼ãƒãƒ©ãƒƒãƒ—ã™ã‚‹ãƒ¡ãƒ¢ãƒªé ˜åŸŸã‚’ã‚¢ã‚¯ã‚»ã‚¹ã™ã‚‹
-代å
-¥æ–‡ã‚’使用してはならない．
-
-ASPカーネルの実è£
-においては，semaphore.c中の関数においては，(SEMCB *)型
-および(WINFO_SEM *)型のポインタを使用しており，(WOBJCB *)型および
-(WINFO_WOBJ *)åž‹ã®ãƒã‚¤ãƒ³ã‚¿çµŒç”±ã§ãƒ¡ãƒ¢ãƒªé ˜åŸŸã‚’ã‚¢ã‚¯ã‚»ã‚¹ã™ã‚‹ã“ã¨ã¯ãªã„ï¼Žä¸€
-方，そこから呼び出されるwait.c中の関数においては，(WOBJCB *)型および
-(WINFO_WOBJ *)型のポインタを使用しており，(SEMCB *)型および(WINFO_SEM
-*)åž‹ã®ãƒã‚¤ãƒ³ã‚¿çµŒç”±ã§ãƒ¡ãƒ¢ãƒªé ˜åŸŸã‚’ã‚¢ã‚¯ã‚»ã‚¹ã™ã‚‹ã“ã¨ã¯ãªã„ï¼Ž
-
-strict aliasing ruleに従わない代å
-¥æ–‡ã®å•é¡Œç‚¹ã¯ï¼Œã“のルールに依存した最
-適化が誤った結果を引き起こす可能性があることであるが，異なるコンパイル
-単位をまたいで最適化が行われることはないため，これにより問題が起こるこ
-とはないと言うことができる．
-
-同じ議論は，他のソースファイル（eventflag.c，dataqueue.c，pridataq.c，
-mailbox.c，mempfix.c）中の警告メッセージについても，そのまま当てはまる．
-
-
-○性能評価用システム時刻参ç
-§æ©Ÿèƒ½
-
-●å¿
-要性と使途
-
-ASPカーネルには，ASPカーネル上で動作するタスクやASPカーネル自身の性能を
-計測するために，システム時刻より精度の高い性能評価用システム時刻を読み
-出す機能をサポートする．性能評価用システム時刻は，マイクロ秒単位で表現
-されるが，実際の精度はターゲット依存である．
-
-この機能を用いてあるプログラムの実行時間を計測するには，その実行直前と
-実行直後に性能評価用システム時刻を読み出し，その差を求める．そのため，
-性能評価用システム時刻は常に相対値を使用し，性能評価用システム時刻の絶
-対値を使用することは想定していない．
-
-●API仕様
-
-性能評価用システム時刻参ç
-§æ©Ÿèƒ½ã§ã¯ï¼Œæ¬¡ã®ãƒ‡ãƒ¼ã‚¿åž‹ã‚’用いる．
-
-        SYSUTM          性能評価用システム時刻（符号無し整数，単位はマイクロ秒，
-                                32ビット以上）
-
-SYSUTM型は，ターゲット非依存部においてulong_t型（すなわち，unsigned
-long型）に定義されており，そのサイズは，32ビット以上で，ターゲット定義
-である．
-
-性能評価用システム時刻がSYSUTM型で表現できる範囲をè¶
-えた（つまり，オー
-ãƒãƒ•ãƒ­ãƒ¼ã—ãŸï¼‰å ´åˆï¼Œæ€§èƒ½è©•ä¾¡ç”¨ã‚·ã‚¹ãƒ†ãƒ æ™‚åˆ»ã¯0に戻る．評価対象プログラム
-ã®å®Ÿè¡Œå‰å¾Œã®æ€§èƒ½è©•ä¾¡ç”¨ã‚·ã‚¹ãƒ†ãƒ æ™‚åˆ»ã®å·®ã‚’æ±‚ã‚ã‚‹å ´åˆã«ã¯ï¼Œè¨ˆæ¸¬ã™ã‚‹æ™‚é–“ãŒ
-SYSUTM型で表現できる範囲である限り，0に戻ることを特別に考æ
-®ã™ã‚‹å¿
-要はな
-い．
-
-SYSUTM型が32ãƒ“ãƒƒãƒˆã®å ´åˆï¼Œæ€§èƒ½è©•ä¾¡ç”¨ã‚·ã‚¹ãƒ†ãƒ æ™‚åˆ»ã¯ç´„71分でオーバフロー
-する．そのため，この機能を71åˆ†ã‚’è¶Šãˆã‚‹æ™‚é–“ã®æ¸¬å®šã«ä½¿ã£ãŸå ´åˆã®å‹•ä½œã¯ä¿
-証されない．
-
-性能評価用システム時刻参ç
-§æ©Ÿèƒ½ã®ãŸã‚ã®ã‚µãƒ¼ãƒ“スコールの仕様については，
-「TOPPERS新世代カーネル統合仕様書」の「4.6.1 システム時刻管理」の節を参
-ç
-§ã™ã‚‹ã“と．
-
-●実è£
-
-
-時刻をマイクロ秒単位で取得するために，周期的なタイムティックを供給する
-タイマの現在値（タイマはカウントアップするものと仮定する）を読み出し，
-それをマイクロ秒単位に換算した値に，現在のシステム時刻（ミリ秒単位で表
-現される）を1000å€ã—ãŸå€¤ã‚’åŠ ãˆãŸã‚‚ã®ã‚’æ€§èƒ½è©•ä¾¡ç”¨ã‚·ã‚¹ãƒ†ãƒ æ™‚åˆ»ã¨ã™ã‚‹ï¼Žç¾
-在のシステム時刻を1000倍する際に，オーバフローが発生する可能性があるが，
-無視してかまわない．
-
-ただし，システム時刻の現在値とタイマの現在値を一貫した状æ
-‹ã§èª­ã¿å‡ºã™ã®
-ã¯å®¹æ˜“ã§ã¯ãªã„ï¼Žä¸¡æ–¹ã®å€¤ã‚’é †ã«èª­ã¿å‡ºã™ã¨ï¼Œèª­å‡ºã—ã®é–“ã«ã‚¿ã‚¤ãƒžãŒã‚ªãƒ¼ãƒãƒ•
-ãƒ­ãƒ¼ã—ã¦å‰²è¾¼ã¿è¦æ±‚ãŒç™ºç”Ÿã—ãŸå ´åˆã«ï¼Œç‰‡æ–¹ã¯ã‚ªãƒ¼ãƒãƒ•ãƒ­ãƒ¼å‰ã®å€¤ï¼Œã‚‚ã†ç‰‡æ–¹
-はオーバフロー後の値を読んでしまい，誤った性能評価用システム時刻を取得
-してしまう．
-
-この問題を解決する方法はいくつか考えられるが，どの方法を採用するの決定
-にあたり，次の要求事é 
-を設定した．
-
-(1) 多くのターゲットシステムで実現できること．
-
-(2) サービスコールの実行時間が可能な限り一定となること．言い換えると，
-    条件によってサービスコールの実行時間が大きく変動しないこと．
-
-(3) サービスコール中の可能な限り同じタイミングの時刻を返すこと．言い換
-    えると，条件によって時刻を読み取るタイミングが変動しないこと．
-
-(4) 調整するå¿
-要のあるパラメータを最小限とすること．
-
-これらの要求事é 
-を満たす方法として，次の方法を用いることにした．
-
-まず，NMIを除くすべての割込みを禁止した状æ
-‹ã§ï¼Œã‚·ã‚¹ãƒ†ãƒ 時刻の現在値，タ
-イマの現在値（1回目），タイマ割込み要求の有無，タイマの現在値（2回目）
-ã‚’ï¼Œã“ã®é †ã§èª­ã¿å‡ºã™ï¼Žå‰²è¾¼ã¿ã‚’ç¦æ­¢ã—ã¦ã„ã‚‹ãŸã‚ï¼Œã“ã®é–“ã«ã‚·ã‚¹ãƒ†ãƒ æ™‚åˆ»ã®
-ç¾åœ¨å€¤ãŒå¤‰åŒ–ã™ã‚‹ã“ã¨ã¯ãªãï¼Œã‚·ã‚¹ãƒ†ãƒ æ™‚åˆ»ã®ç¾åœ¨å€¤ã‚’èª­ã¿å‡ºã™é †ç•ªã¯ã©ã“ã§
-もよい．また，タイマの現在値の2回目の読出しは，タイマ割込み要求があった
-å ´åˆã«ã®ã¿å¿
-要となるが，(2)の要求から，タイマ割込み要求の有無によらず読
-み出すこととする．
-
-これらの値を読み出した後，割込み禁止を解除し，次の処理を行う．まず，タ
-ã‚¤ãƒžå‰²è¾¼ã¿è¦æ±‚ãŒãªã‹ã£ãŸå ´åˆã«ã¯ï¼Œã‚·ã‚¹ãƒ†ãƒ æ™‚åˆ»ã®ç¾åœ¨å€¤ã¨ï¼Œ1回目に読んだ
-タイマの現在値は一貫した値であることが保証できるため，これらの値から性
-能評価用システム時刻の現在値を求める．
-
-æ¬¡ã«ã‚¿ã‚¤ãƒžå‰²è¾¼ã¿è¦æ±‚ãŒã‚ã£ãŸå ´åˆã«ã¯ï¼Œ1回目に読んだタイマの現在値が，タ
-ã‚¤ãƒžå‰²è¾¼ã¿è¦æ±‚ç™ºç”Ÿå‰ã®å€¤ï¼ˆã‚ªãƒ¼ãƒãƒ•ãƒ­ãƒ¼å‰ã®å€¤ï¼‰ã§ã‚ã‚‹å ´åˆã¨ï¼Œç™ºç”Ÿå¾Œã®å€¤
-ï¼ˆã‚ªãƒ¼ãƒãƒ•ãƒ­ãƒ¼å¾Œã®å€¤ï¼‰ã§ã‚ã‚‹å ´åˆã®ä¸¡æ–¹ã®å¯èƒ½æ€§ãŒè€ƒãˆã‚‰ã‚Œã‚‹ï¼Žã“ã®ã©ã¡ã‚‰
-ã®å ´åˆã§ã‚ã£ãŸã‹ã‚’ï¼Œ2回目に読んだタイマの現在値を使って，次のように決定
-する．2回目の値は，タイマ割込み要求発生後の値（オーバフロー後の値）であ
-ることが保証できるため，1回目の値が2å›žç›®ã®å€¤ã‚ˆã‚Šã‚‚å¤§ãã„å ´åˆã«ã¯ï¼Œãã®
-間にオーバフローがあったものと推測できる．つまり，1回目の値はオーバフロー
-前の値ということになり，システム時刻の現在値と一貫した値であるとして性
-能評価用システム時刻の現在値を求める．逆に，1回目の値が2回目の値と同じ
-ã‹ãã‚Œã‚ˆã‚Šå°ã•ã„å ´åˆã«ã¯ï¼Œ1回目の値はオーバフロー後の値であると推測でき
-ã‚‹ï¼Žã“ã®å ´åˆã«ã¯ï¼Œæ¬¡ã®ã‚¿ã‚¤ãƒ ãƒ†ã‚£ãƒƒã‚¯ã®ã‚·ã‚¹ãƒ†ãƒ æ™‚åˆ»ã‚’æ±‚ã‚ï¼Œãã®å€¤ã¨1回目
-の値が一貫した値であるとして性能評価用システム時刻の現在値を求める．
-
-ã“ã“ã§ï¼Œã‚¿ã‚¤ãƒžå‰²è¾¼ã¿è¦æ±‚ãŒã‚ã£ãŸå ´åˆã«ã¯ï¼Œ2回目に読んだタイマの現在値を
-用いる方法が考えられるが，(3)の要求を満たさなくなるために採用しなかった．
-また，JSPカーネルと同様の方法は，(4)の要求を満たさないために採用しなかっ
-た．
-
-上で「推測できる」としたのは，この推測が成り立たなくなるケースがあるた
-めである．この推測が成り立たなくなるケースは，次の2ã¤ã®å ´åˆã«åˆ†ã‘ã¦åˆ†æž
-することができる．
-
-(a) 1回目の値がオーバフロー後の値であるにもかかわらず，1回目の値が2回目
-    ã®å€¤ã‚ˆã‚Šã‚‚å¤§ãããªã‚‹å ´åˆ
-
-このようなケースは，タイマ割込みが要求されているにもかかわらずサービス
-されない状æ
-‹ãŒé•·æ™‚間続くか，タイマの現在値を1回目に読んでから2回目に読
-むまでの間に長い時間がかかった結果，その間に（再度）オーバフローが発生
-ã—ãŸå ´åˆã«èµ·ã“ã‚‹ï¼Žã¤ã¾ã‚Šï¼Œã‚¿ã‚¤ãƒžå‰²è¾¼ã¿ãŒã‚µãƒ¼ãƒ“ã‚¹ã•ã‚Œãªã„æ™‚é–“ãŒï¼Œã‚¿ã‚¤ãƒ 
-ãƒ†ã‚£ãƒƒã‚¯ã®å‘¨æœŸã‚ˆã‚Šã‚‚é•·ããªã£ãŸå ´åˆã§ã‚ã‚‹ï¼Žã“ã®ã‚ˆã†ãªå ´åˆã«ã¯ï¼Œã‚·ã‚¹ãƒ†ãƒ 
-時刻の更新も正しく行われなくなる．
-
-(b) 1回目の値がオーバフロー前の値であるにもかかわらず，1回目の値が2回目
-    ã®å€¤ã¨åŒã˜ã‹ãã‚Œã‚ˆã‚Šã‚‚å°ã•ããªã‚‹å ´åˆ
-
-このようなケースは，タイマの現在値を1回目に読んでから2回目に読むまでの
-間に，タイマがほぼ1å‘¨åˆ†ã‚«ã‚¦ãƒ³ãƒˆã‚¢ãƒƒãƒ—ã—ãŸå ´åˆã«èµ·ã“ã‚‹ï¼Žã“ã®å ´åˆã‚‚ï¼Œã‚¿ã‚¤
-マ割込みが禁止されている時間が，タイムティックの周期よりも長かったこと
-になり，システム時刻の更新が正しく行えなくなる．
-
-いずれのケースも，タイマ割込みが長時間禁止されている，タイマ割込みより
-も優å
-ˆåº¦ã®é«˜ã„割込み処理が長時間続けて実行された，シミュレーション環境
-においてシミュレータのプロセスが長時間スケジュールされなかったなどの理
-由で，システム時刻の更新が正しく行えない状況に相当する．そこでこの状況
-を，サービスコール使用上の注意事é 
-に盛り込む．
-
-実際のコードにおいては，システム時刻の現在値は変数に保持されていないた
-め（上位桁はcurrent_timeに保持されているが，下位桁を保持する変数がな
-い），次のタイムティックのシステム時刻を用いて計算している．そのため，
-ã‚¿ã‚¤ãƒžã®ç¾åœ¨å€¤ãŒã‚ªãƒ¼ãƒãƒ•ãƒ­ãƒ¼å¾Œã®å€¤ã§ã‚ã‚‹ã¨åˆ¤æ–­ã—ãŸå ´åˆã‚’é™¤ã„ã¦ã¯ï¼Œã‚¿ã‚¤
-ムティックの周期時間を，求めた性能評価用システム時刻から減算する．この
-処理により，サービスコールの実行時間が変動することになるが，if文のå†
-容
-が（コンパイラの最適化を仮定すると）定数値の減算1回なので，変動はわずか
-である．
-
-このサービスコールは，任意の状æ
-‹ã‹ã‚‰å‘¼ã³å‡ºã™ã“とができるため，SILのå
-¨å‰²
-込みロック機能を用いて，サービスコールå†
-部のクリティカルセクションを実
-現する．
-
-
-○タスク例外処理禁止フラグをenatexで実è£
-している理由
-
-タスク例外処理禁止フラグは，TCB中のenatexフィールド（タスク例外処理許可
-状æ
-‹ã§ã‚ることを示す）の形で保持している．このフィールドをdistexとせず
-enatexとしたのは，JSPカーネルにおいてタスクディスパッチ禁止フラグを
-enadspの形で保持したのと整合させたためである．
-
-ASPカーネルでは，enadspはdisdspに変更になったことから，enatexもdistexに
-変更した方が良かったと思われる．
-
-以上
+この警告メッセージの原因は，直接的には，&winfo_semを(WINFO_WOBJ *)にキャ
+ストしていることであるが，本質的な原因は，このコードがC言語のstrict
+aliasing ruleに従わない代入文の原因になる可能性があり，このルールに依存
+した最適化が誤った結果を引き起こす可能性があることである．
+
+C言語のstrict aliasing ruleは，互換性のない異なる型を通して，オーバラッ
+プするメモリ領域をアクセスする代入文を使用してはならないというものであ
+る（使用した場合の振舞いは未定義になる）．このケースでは，(WINFO_SEM
+*)型のポインタ経由と(WINFO_WOBJ *)型のポインタ経由で，オーバラップする
+メモリ領域をアクセスする代入文を使用してはならないことになる．また，警
+告メッセージの原因になってはいないが，(SEMCB *)型のポインタ経由と
+(WOBJCB *)型のポインタ経由で，オーバラップするメモリ領域をアクセスする
+代入文を使用してはならない．
+
+ASPカーネルの実装においては，semaphore.c中の関数においては，(SEMCB *)型
+および(WINFO_SEM *)型のポインタを使用しており，(WOBJCB *)型および
+(WINFO_WOBJ *)型のポインタ経由でメモリ領域をアクセスすることはない．一
+方，そこから呼び出されるwait.c中の関数においては，(WOBJCB *)型および
+(WINFO_WOBJ *)型のポインタを使用しており，(SEMCB *)型および(WINFO_SEM
+*)型のポインタ経由でメモリ領域をアクセスすることはない．
+
+strict aliasing ruleに従わない代入文の問題点は，このルールに依存した最
+適化が誤った結果を引き起こす可能性があることであるが，異なるコンパイル
+単位をまたいで最適化が行われることはないため，これにより問題が起こるこ
+とはないと言うことができる．
+
+同じ議論は，他のソースファイル（eventflag.c，dataqueue.c，pridataq.c，
+mailbox.c，mempfix.c）中の警告メッセージについても，そのまま当てはまる．
+
+
+○性能評価用システム時刻参照機能
+
+●必要性と使途
+
+ASPカーネルには，ASPカーネル上で動作するタスクやASPカーネル自身の性能を
+計測するために，システム時刻より精度の高い性能評価用システム時刻を読み
+出す機能をサポートする．性能評価用システム時刻は，マイクロ秒単位で表現
+されるが，実際の精度はターゲット依存である．
+
+この機能を用いてあるプログラムの実行時間を計測するには，その実行直前と
+実行直後に性能評価用システム時刻を読み出し，その差を求める．そのため，
+性能評価用システム時刻は常に相対値を使用し，性能評価用システム時刻の絶
+対値を使用することは想定していない．
+
+●API仕様
+
+性能評価用システム時刻参照機能では，次のデータ型を用いる．
+
+        SYSUTM          性能評価用システム時刻（符号無し整数，単位はマイクロ秒，
+                                32ビット以上）
+
+SYSUTM型は，ターゲット非依存部においてulong_t型（すなわち，unsigned
+long型）に定義されており，そのサイズは，32ビット以上で，ターゲット定義
+である．
+
+性能評価用システム時刻がSYSUTM型で表現できる範囲を超えた（つまり，オー
+バフローした）場合，性能評価用システム時刻は0に戻る．評価対象プログラム
+の実行前後の性能評価用システム時刻の差を求める場合には，計測する時間が
+SYSUTM型で表現できる範囲である限り，0に戻ることを特別に考慮する必要はな
+い．
+
+SYSUTM型が32ビットの場合，性能評価用システム時刻は約71分でオーバフロー
+する．そのため，この機能を71分を越える時間の測定に使った場合の動作は保
+証されない．
+
+性能評価用システム時刻参照機能のためのサービスコールの仕様については，
+「TOPPERS新世代カーネル統合仕様書」の「4.6.1 システム時刻管理」の節を参
+照すること．
+
+●実装
+
+時刻をマイクロ秒単位で取得するために，周期的なタイムティックを供給する
+タイマの現在値（タイマはカウントアップするものと仮定する）を読み出し，
+それをマイクロ秒単位に換算した値に，現在のシステム時刻（ミリ秒単位で表
+現される）を1000倍した値を加えたものを性能評価用システム時刻とする．現
+在のシステム時刻を1000倍する際に，オーバフローが発生する可能性があるが，
+無視してかまわない．
+
+ただし，システム時刻の現在値とタイマの現在値を一貫した状態で読み出すの
+は容易ではない．両方の値を順に読み出すと，読出しの間にタイマがオーバフ
+ローして割込み要求が発生した場合に，片方はオーバフロー前の値，もう片方
+はオーバフロー後の値を読んでしまい，誤った性能評価用システム時刻を取得
+してしまう．
+
+この問題を解決する方法はいくつか考えられるが，どの方法を採用するの決定
+にあたり，次の要求事項を設定した．
+
+(1) 多くのターゲットシステムで実現できること．
+
+(2) サービスコールの実行時間が可能な限り一定となること．言い換えると，
+    条件によってサービスコールの実行時間が大きく変動しないこと．
+
+(3) サービスコール中の可能な限り同じタイミングの時刻を返すこと．言い換
+    えると，条件によって時刻を読み取るタイミングが変動しないこと．
+
+(4) 調整する必要のあるパラメータを最小限とすること．
+
+これらの要求事項を満たす方法として，次の方法を用いることにした．
+
+まず，NMIを除くすべての割込みを禁止した状態で，システム時刻の現在値，タ
+イマの現在値（1回目），タイマ割込み要求の有無，タイマの現在値（2回目）
+を，この順で読み出す．割込みを禁止しているため，この間にシステム時刻の
+現在値が変化することはなく，システム時刻の現在値を読み出す順番はどこで
+もよい．また，タイマの現在値の2回目の読出しは，タイマ割込み要求があった
+場合にのみ必要となるが，(2)の要求から，タイマ割込み要求の有無によらず読
+み出すこととする．
+
+これらの値を読み出した後，割込み禁止を解除し，次の処理を行う．まず，タ
+イマ割込み要求がなかった場合には，システム時刻の現在値と，1回目に読んだ
+タイマの現在値は一貫した値であることが保証できるため，これらの値から性
+能評価用システム時刻の現在値を求める．
+
+次にタイマ割込み要求があった場合には，1回目に読んだタイマの現在値が，タ
+イマ割込み要求発生前の値（オーバフロー前の値）である場合と，発生後の値
+（オーバフロー後の値）である場合の両方の可能性が考えられる．このどちら
+の場合であったかを，2回目に読んだタイマの現在値を使って，次のように決定
+する．2回目の値は，タイマ割込み要求発生後の値（オーバフロー後の値）であ
+ることが保証できるため，1回目の値が2回目の値よりも大きい場合には，その
+間にオーバフローがあったものと推測できる．つまり，1回目の値はオーバフロー
+前の値ということになり，システム時刻の現在値と一貫した値であるとして性
+能評価用システム時刻の現在値を求める．逆に，1回目の値が2回目の値と同じ
+かそれより小さい場合には，1回目の値はオーバフロー後の値であると推測でき
+る．この場合には，次のタイムティックのシステム時刻を求め，その値と1回目
+の値が一貫した値であるとして性能評価用システム時刻の現在値を求める．
+
+ここで，タイマ割込み要求があった場合には，2回目に読んだタイマの現在値を
+用いる方法が考えられるが，(3)の要求を満たさなくなるために採用しなかった．
+また，JSPカーネルと同様の方法は，(4)の要求を満たさないために採用しなかっ
+た．
+
+上で「推測できる」としたのは，この推測が成り立たなくなるケースがあるた
+めである．この推測が成り立たなくなるケースは，次の2つの場合に分けて分析
+することができる．
+
+(a) 1回目の値がオーバフロー後の値であるにもかかわらず，1回目の値が2回目
+    の値よりも大きくなる場合
+
+このようなケースは，タイマ割込みが要求されているにもかかわらずサービス
+されない状態が長時間続くか，タイマの現在値を1回目に読んでから2回目に読
+むまでの間に長い時間がかかった結果，その間に（再度）オーバフローが発生
+した場合に起こる．つまり，タイマ割込みがサービスされない時間が，タイム
+ティックの周期よりも長くなった場合である．このような場合には，システム
+時刻の更新も正しく行われなくなる．
+
+(b) 1回目の値がオーバフロー前の値であるにもかかわらず，1回目の値が2回目
+    の値と同じかそれよりも小さくなる場合
+
+このようなケースは，タイマの現在値を1回目に読んでから2回目に読むまでの
+間に，タイマがほぼ1周分カウントアップした場合に起こる．この場合も，タイ
+マ割込みが禁止されている時間が，タイムティックの周期よりも長かったこと
+になり，システム時刻の更新が正しく行えなくなる．
+
+いずれのケースも，タイマ割込みが長時間禁止されている，タイマ割込みより
+も優先度の高い割込み処理が長時間続けて実行された，シミュレーション環境
+においてシミュレータのプロセスが長時間スケジュールされなかったなどの理
+由で，システム時刻の更新が正しく行えない状況に相当する．そこでこの状況
+を，サービスコール使用上の注意事項に盛り込む．
+
+実際のコードにおいては，システム時刻の現在値は変数に保持されていないた
+め（上位桁はcurrent_timeに保持されているが，下位桁を保持する変数がな
+い），次のタイムティックのシステム時刻を用いて計算している．そのため，
+タイマの現在値がオーバフロー後の値であると判断した場合を除いては，タイ
+ムティックの周期時間を，求めた性能評価用システム時刻から減算する．この
+処理により，サービスコールの実行時間が変動することになるが，if文の内容
+が（コンパイラの最適化を仮定すると）定数値の減算1回なので，変動はわずか
+である．
+
+このサービスコールは，任意の状態から呼び出すことができるため，SILの全割
+込みロック機能を用いて，サービスコール内部のクリティカルセクションを実
+現する．
+
+
+○タスク例外処理禁止フラグをenatexで実装している理由
+
+タスク例外処理禁止フラグは，TCB中のenatexフィールド（タスク例外処理許可
+状態であることを示す）の形で保持している．このフィールドをdistexとせず
+enatexとしたのは，JSPカーネルにおいてタスクディスパッチ禁止フラグを
+enadspの形で保持したのと整合させたためである．
+
+ASPカーネルでは，enadspはdisdspに変更になったことから，enatexもdistexに
+変更した方が良かったと思われる．
+
+以上