ITRON・ ITRON
標準ハンドブック坂村 健 監修

IT
R
O
N

パーソナルメディア

TRON Architecture
Designed by
Ken Sakamura

ITRON・μITRON標準ハンドブック
本書の著作権は、社団法人トロン協会に属しています。
本書の内容の転載、一部複製等には、トロン協会の許諾が必要です。
本仕様書に記載されている内容は、今後改良等の理由でお断りなしに変更することがあります。
仕様に関しては下記にお問い合わせください。
社団法人 トロン協会〒105 東京都 港区 虎ノ門3 -8 - 27
巴町 アネックス 2号館 5F
電話 (03) 433 -6741
TRON仕様の原著作権は、坂村 健 氏に属しています。
TRONは、The Realtime Operating system Nucleusの略称です。

ITRONは、

Industrial TRONの略称です。

BTRONは、Business TRONの略称です。

CTRONは、Central and Communication TRONの略称です。

MTRONは、Macro TRONの略称です。

監修のことば来たるべき21世紀には、社会を構成するあらゆる要素がコンピュータ化
され、ネットワークで結ばれることになるであろう。TRONプロジェクト
は、このような電脳社会を構築するための基礎を固めようとして始められたプロジェクトである。
TRONプロジェクトでは、コンピュータとセンサ、アクチュエータが一体となって組み込まれ、電脳社会の構成要素となるものをインテリジェントオブ
ジェクト（知的物体）と呼んでいる。TRONプロジェクトを進める上では、今後社会のインテリジェントオブジェクト化が進むであろうということと、これらのインテリジェントオブジェクトがネットワーク化され、人間の住環境を快適にするために協調してはたらくであろうということが前提になっている。
TRONプロジェクトには、基礎プロジェクトと応用プロジェクトがある。
応用プロジェクトは、インテリジェントオブジェクト化が進んだ未来の電脳社会を先取りしてシミュレーションすることを目的としたプロジェクト
であり、電脳住宅プロジェクト、電脳ビルプロジェクト、電脳都市プロジ
ェクト、電脳自動車網プロジェクトから成っている。一方、基礎プロジェ
クトは、応用プロジェクトからくる要求を満たすようなコンピュータを設計するためのプロジェクトであり、ITRON、BTRON、CTRON、MTRON、TRON仕様CHIPのサブプロジェクトに分かれている。
これらの基礎プロジェクトのうち、ITRONサブプロジェクトは最も長い歴史を持っている。ITRON仕様の設計は、1984年のTRONプロジェクト開始
とともに着手され、着実な成果を上げてきた。その理由としては、インテ
リジェントオブジェクトを作る際の実行時オペレーティングシステムとしてITRON仕様のOSが必要であることに加えて、BTRON仕様OSなど他のオ
ペレーティングシステムのカーネルとしてもITRON仕様OSを利用できるためである。すなわち、ITRONサブプロジェクトはTRONプロジェクト全体の中で極めて重要な位置を占めている。
現在では、ITRON仕様自体のシリーズ化や機能拡張も進んでいる。ITRON
仕様のシリーズ化は、16ビット汎用マイクロプロセッサ向けのITRON1に始まり、現在では32ビットマイクロプロセッサ（特にTRONCHIP）向けのITRON2、

およびシングルチップマイクロプロセッサ向けのμITRONへと発展してきた。もともとITRON仕様OSはいろいろな種類のプロセッサに実装することを前提として設計されたオペレーティングシステムであるが、こういったシリーズ化の手法により、さらにその適用範囲を広げることが可能となった。ITRON仕様OSは、これまでに数十のマイクロプロセッサの上に実際にインプリメントされ、その性能が確認されている。一方、ITRON仕様の機能拡張としては、標準入出力機能、BTRON仕様と互換性を持つファイル管
理機能、ITRON仕様OS同士を接続するためのネットワーク機能などの仕様が追加されている。
本書では、このうち、32ビットマイクロプロセッサおよびネットワーク
への対応を前提としたITRON2の仕様と、基本機能を重視し、8ビットマイ
クロプロセッサやシングルチップマイクロプロセッサの上でもインプリメントを可能としたμITRONの仕様を解説している。読者は本書を読むこと
により、TRONプロジェクトの中におけるITRON2およびμITRON仕様の位
置付け、これらのリアルタイムオペレーティングシステムの機能、詳細仕様などを知ることができよう。
ITRON2、μITRON仕様OSとも、現在では製品として入手可能になっており、多くのインプリメンタがTRON仕様CHIPを含めたいろいろなプロセッサの上で製品化を行っている。リアルタイムオペレーティングシステムの世界において、これだけ多くのインプリメンタが参加し、これだけ多くのプロセッサの上で動作するものは、ITRON仕様OS以外にはないと思われる。
本書がITRON仕様あるいはリアルタイムオペレーティングシステムに興味を持つ方々のお役に立てば幸いである。本書の利用によってITRON仕様
OSのユーザやインプリメンタが増え、それがTRONプロジェクトの最終目
標である電脳社会の構築に結び付くことを願ってやまない。
1990年12月
坂村 健
TRONプロジェクトリーダ

目次
第一部 ITRONの基礎

1

第一章 TRONプロジェクトとITRON

3

4
6

TRONプロジェクトの特徴
TRONのサブプロジェクト

第二章 ITRONの基本方針

910

マルチタスクOSとリアルタイムOS
ITRONの特長

14

ITRONのシリーズ化

18

第三章 ITRONの機能

19

20
タスク
20
資源
21

基本概念

タスクの状態と動作

21
24

タスクのスケジューリング

26

非タスク部実行中のシステム状態

27

タスク独立部と準タスク部
ID番号とアクセスキー

29
30

ITRONでの標準化の方針と互換性

33

システムコールインタフェース

アセンブリ言語とのインタフェース
言語Cとのインタフェース

第四章 μITRONとITRON2μITRONの概要

3636μITRON設計の具体化
38μITRONの条件
39
ITRON2の概要
40
ITRON2の基本方針
40
ITRON2設計の具体化
41μITRONの基本方針

33

33
35

第二部 μITRON

43

第一章 μITRON概説

45
46

μITRONの設計の考え方

50

μITRON設計の実際
タスク状態

50

51
システムコールインタフェース
55
μITRONにおける標準化の意味
60
μITRONの範囲
64
μITRONの追加機能
66
サブセット化が行われた機能

第二章 μITRONシステムコール

69

70

タスク管理機能83

タスク付属同期機能

93
125
138

同期・通信機能
割込み管理機能
例外管理機能139

メモリプール管理機能

146

時間管理・タイマハンドラ機能

159

システム管理機能第三章 μITRON標準インタフェース
アセンブラインタフェース

168

システムコール実行後のフラグ変化
機能コード

167
168

168

言語Cインタフェースとニモニック
エラーコードのフォーマット

170

172

第三部 ITRON2

175

第一章 ITRON2概説

177

ITRON2設計の実際
ITRON2の追加機能

178
183

第二章 ITRON2基本機能
タスク管理機能

190

189

222

タスク付属同期機能

231
264

同期・通信機能
割込み管理機能264

タスク独立部から発行可能なシステムコール

265

割込み処理とシステムコールの不可分性

273

例外管理機能273

例外の種類と例外クラス

例外ハンドラの独立性と例外ハンドラ定義環境

278

例外マスク環境286

例外ペンディング環境

例外関係の各機能の処理概要

288
290

例外ハンドラが未定義の場合の動作

293

複数の例外が同時に発生した場合の動作296

タスク独立部に対する例外処理

316

メモリプール管理機能

330

時間管理機能337

システム管理機能

第三章 ITRON2拡張機能
拡張同期・通信機能
強制例外機能

353

354

388
394

ローカルメモリプール管理機能
資源管理サポート機能
タイマハンドラ機能

405
416

第四章 ITRON2システム操作機能
拡張SVCサポート機能

429

430

第五章 ITRON2標準インタフェース
タスク管理情報とID番号
アセンブラインタフェース

435

436
438

アセンブラインタフェース共通原則
システムコール実行後のフラグ変化
機能コード

276

438
438

439

言語Cインタフェースとニモニック
エラーコードとシステムコール例外

440
443

第四部 レファレンス

447

第一章 μITRON・ITRON2共通レファレンス

449

機能コード
例外クラス
エラーコード

450
452
454

第二章 μITRONレファレンス
システムコール一覧(μITRON)
データタイプ(μITRON)

465
466

471

言語Cインタフェース(μITRON)473

共通定数と構造体のパケット形式(μITRON)

477

第三章 ITRON2レファレンス
システムコール一覧 (ITRON2)
データタイプ (ITRON2)

479
480

487

言語Cインタフェース (ITRON2)490

共通定数のニモニックと標準値 (ITRON2)
共通定数の適用システムコール (ITRON2)構造体のパケット形式 (ITRON2)

495
497

500

索引
μITRONシステムコール索引

509

ITRON2システムコール索引513

目次 4/28/98 12:48 PM ページ 9

図版目次［図1 . 1］I T R O Nのシステムコール命名法

17［表1 . 1］I T R O Nにおける省略名称の生成規則

17［図1 . 2］

I T R O Nのタスク状態遷移図

23［表1 . 2］

自タスク、他タスクの区別と状態遷移図24［図1.3 (a)］ 始めのレディキューの状態

25［図1.3 (b)］ タスクAが待ち状態になった後のレディキューの状態

26［図1 . 4］

I T R O Nのシステム状態の分類

27［図1 . 5］

割込みのネストと遅延ディスパッチ

29［図2 . 1］I T R O Nにおける適応化の考え方

47［図2 . 2］

セマフォ待ちシステムコールw a i ̲ s e mのインタフェース例 4 8［図2 . 3］

μI T R O Nにおける適応化の考え方

49［図2 . 4］

μI T R O Nのタスク状態遷移図52［図2 . 5］

イベントフラグ待ちシステムコールのパラメータ54［図2.6 (a)］ rot̲rdq 実行前のレディキューの状態

77［図2.6 (b)］ rot̲rdq (tskpri = 2) 実行後のレディキューの状態

77［図2 . 7］

1ワードイベントフラグに対する複数タスク待ちの機能 9 8［図2 . 8］

1ビットイベントフラグに対する複数タスク待ちの機能 1 0 4［表2 . 1］s i g ̲ s e m , i s i g ̲ s e mの返すエラー

107［図2 . 9］μI T R O Nにおけるメッセージの形式

113［図2.10 (a)］ g e t ̲ v e rで得られるm a k e rのフォーマット

161［図2.10 (b)］ g e t ̲ v e rで得られるi dのフォーマット

162［図2.10 (c)］ g e t ̲ v e rで得られるs p v e rのフォーマット

162［図2.10 (d)］ g e t ̲ v e rで得られるp r v e rのフォーマット

163［図2.10 (e)］ g e t ̲ v e rで得られるp r n oのフォーマット

163［図2.10 (f)］ g e t ̲ v e rで得られるc p uのフォーマット（前半）164［図2.10 (f)］ g e t ̲ v e rで得られるc p uのフォーマット（後半）165［図2.10 (g)］ g e t ̲ v e rで得られるv a rのフォーマット

166［図2 . 1 1］

μI T R O Nにおけるエラーコードのフォーマット

172［図3 . 1］I D番号に関する互換性

179［図3 . 2］

I T R O N 1とI T R O N 2との関係

182

［図3.3］

ランデブの動作184［図3.4］

セマフォによるクリティカルセクションの確保

185［図3.5］

tskatrのフォーマット

192［図3.6］

終了ハンドラとタスク優先度の変化

206［図3.7 (a)］rot̲rdq実行前のレディキューの状態

209［図3.7 (b)］rot̲rdq (tskpri = 2) 実行後のレディキューの状態

209［表3.1］

tskwaitとwidの値

215［表3.2］

例外の種類とexccd,eclsptnとの関係

217［図3.8］

hdr̲stsの実行環境の例

219［図3.9］

ECM̲SUSをクリアできないケース

224［図3.10］flgatrのフォーマット

232［図3.11］

イベントフラグに対する複数タスク待ちの機能

239［図3.12］

sematrのフォーマット

243［図3.13］

セマフォの待ち行列の作り方による動作の違い

245［図3.14］mbxatrのフォーマット

255［図3.15］ITRON2におけるメッセージの形式

258［図3.16］

セマフォの動作例とシステムコールの不可分性

266［図3.17］

inhatrのフォーマット

268［図3.18］拡張SVCハンドラに対する終了ハンドラ

280［図3.19］

例外マスクをクリアできないケース

284［図3.20］

拡張SVCハンドラと例外マスク285［表3.3］

例外ハンドラ未定義の場合の動作

291［表3.4］

例外発生時の動作と例外マスクや例外ハンドラ定義状態
との関係

291

［図3.21］

システムデフォルトのCPU例外ハンドラ292［図3.22］終了要求と強制例外とシステムコール例外が重なった場
合の動作

295

［図3.23］exhatrのフォーマット

299［図3.24］

サブルーチン中で実行したret̲exc

303［図3.25］end̲excの利用イメージ

305［図3.26］exhatrのフォーマット

314

［図3.27］

mplatrのフォーマット

319［図3.28］svhatrのフォーマット

339［図3.29］サブルーチンの中で実行したret̲svc

342［図3.30］

拡張SVCハンドラに対する例外ハンドラ中で実行した
ret̲svc［図3.31］343

拡張SVCハンドラに対する終了ハンドラ中で実行した
ret̲svc

343［図3.32 (a)］ get̲verで得られるmakerのフォーマット

346［図3.32 (b)］ get̲verで得られるidのフォーマット

347［図3.32 (c)］ get̲verで得られるspverのフォーマット

347［図3.32 (d)］ get̲verで得られるprverのフォーマット

348［図3.32 (e)］ get̲verで得られるprnoのフォーマット

348［図3.32 (f)］ get̲verで得られるcpuのフォーマット（前半）349［図3.32 (f)］ get̲verで得られるcpuのフォーマット（後半）350［図3.32 (g)］ get̲verで得られるvarのフォーマット

351［図3.33］mbfatrのフォーマット

356［図3.34］

poratrのフォーマット

365［図3.35］

ランデブで送られるメッセージの形式

369［図3.36］fwd̲porを使ったサーバタスクの動作イメージ

379［図3.37］

exhatrのフォーマット

389［図3.38］lmpatrのフォーマット

396［図3.39］cyhatrのフォーマット

418［図3.40］alhatrのフォーマット

423［図3.41］exhatrのフォーマット

432［図3.42］ITRON2におけるエラーコードのフォーマット

443［表3.5］

拡張SVCから返されるエラーとシステムコール例外

445

μITRONシステムコールの記述形式
本書のμITRONのシステムコール説明の部分では、システムコールごとに、以下のような形式で仕様の説明を行なっている。

和文説明［レベル］システムコール名
システムコール名称:

英文説明（名称の由来）※ このうち、［レベル］で示されている数字は、インプリメントの必要性の度合いを示すものである。数字の小さい方が必要性の高いことを表わす。
※［レベル］の項の数字にA,Bの記号が付いているシステムコールは、
インプリメンタの側で、A,Bのどちらかの仕様を選択してインプリメントすることを示す。
※［レベル］の項の数字に#の記号が付いているシステムコールは、他の方法で代替できる可能性のあるシステムコールを示す。例えば、def̲intには#が付いているが、これは、割込みハンドラ定義の機能が他の方法（例えばOS初期化時の静的な定義）で代替できれば、そのシステムコールが不要であることを示す。
【パラメータ】
システムコールのパラメータ、すなわち、システムコールを発行するときにμITRONに渡す情報に関する説明を行なう【リターンパラメータ】
システムコールのリターンパラメータ、すなわち、システムコールの実行が終ったときにμITRONから返される情報（エラーコンディションを除く）に関する説明を行なう【解説】
システムコールの機能の解説を行なう※ いくつかの値を選択して設定するようなパラメータの場合には、以下のような記述方法によって仕様説明を行っている。

( x‖y‖z )x, y, z のいずれか一つを選択して指定する。

x｜y

x と y を同時に指定可能である。
（同時に指定する場合は x と y の論理和をとる）[x]

x は指定しても指定しなくても良い。

例:
wfmode : = (TWF̲ANDW‖TWF̲ORW)｜[TWF̲CLR] の場合、
wfmode の指定は次の4種のいずれかになる。
TWF̲ANDWTWF̲ORW(TWF̲ANDW ¦ TWF̲CLR)(TWF̲ORW ¦ TWF̲CLR)※ μITRON では、【解説】に述べられている機能（システムコールの機能）のうち、一部の機能のみをインプリメントすることも許している。ただし、システムコールの一部の機能のみを提供しているという点については、マニュアルに明記して頂く必要がある。
この時、そのシステムコールに対してサポートされていない機能を指定した場合には、E̲NOSPT のエラーが返る。
※【解説】では、「 そのシステムコールの実行中に割込みが発生し、同じオブジェクトが操作されることは無い」といった前提のもとで説明を行っている。これは、システムコール実行中またはその直前直後に割り込みが入ったケースまで考えると、システムコー
ルの機能説明ができなくなってしまうためである。例えば、「資源数 = 3 のセマフォに対して sig̲sem (rcnt = 1) のシステムコールを実行すると、資源数は 4 になる」といった説明も、システムコー
ル実行中に割込みが入り、その中で sig̲sem が実行されるケースを考えると正確ではない。
【解説】は、途中の割込みがないという条件の下での動作を説明したものである。
【エラーコード】
システムコールで発生する可能性のあるエラーに関して説明を行なう※ 以下のエラーコードについては、各システムコールに対するエラー

コードの説明の項には含めていない場合があるが、各システムコールにおいて共通して発生する可能性がある。
E̲SYS, E̲RSFN, E̲NOSPT, E̲XNOSPT, E̲CTX※ μITRONの場合、インプリメント方法の制約やそれによる性能の低下を避けるために、エラーチェックに関する細かい規定は設けず、エラーコードを大まかに標準化するだけにとどめている。したがって、この項で提示されるエラーコードの仕様も、厳密に守らなければならないものではない。インプリメントによっては、一部のエラーコードを検出しない場合、より多くのエラーコードを検出する場合、エラー検出の条件が多少異なっている場合などがある。
※ この項で説明されているエラーコードは、原則として、起こりうる可能性をもつエラーコードの最大限のものである。ここに出ているエラーを、実際にすべて発生しなければならないという意味ではない。インプリメントの違いやエラー検出方法の違いにより、実際には発生しないエラーがあっても構わない。例えば、
wai̲tsk の E̲TNOSPT は、常にタイマが利用できれば発生する可能性の無いエラーである。

ITRON2システムコールの記述形式
本 書のITRON2のシステムコール説明の部分では、システムコールごとに、以下のような形式で仕様の説明を行なっている。

和文説明
システムコール名称

システムコール名称:

英文説明（名称の由来）【パラメータ】
システムコールのパラメータ、すなわち、システムコールを発行するときにITRON2に渡す情報に関する説明を行なう【リターンパラメータ】
システムコールのリターンパラメータ、すなわち、システムコールの実行が終ったときにITRON2から返される情報（エラーコンディションを除く）
に関する説明を行なう【解説】
システムコールの機能の解説を行なう※ いくつかの値を選択して設定するようなパラメータの場合には、
以下のような記述方法によって仕様説明を行っている。
( x‖y‖z )x, y, z のいずれか一つを選択して指定する。

x｜y

x と y を同時に指定可能である。
(同時に指定する場合は x と y の論理和をとる)[x]x は指定しても指定しなくても良い。

例:
wfmode : = (TWF̲ANDW‖TWF̲ORW)｜[TWF̲CLR] の場合、
wfmode の指定は次の4種のいずれかになる。
TWF̲ANDWTWF̲ORW(TWF̲ANDW ¦ TWF̲CLR)

(TWF̲ORW ¦ TWF̲CLR)※【解説】では、「そのシステムコールの実行中に割込みが発生し、同じオブジェクトが操作されることは無い」といった前提のもとで説明を行っている。これは、システムコール実行中またはその直前直後に割り込みが入ったケースまで考えると、システムコー
ルの機能説明ができなくなってしまうためである。例えば、「資
源数 = 3 のセマフォに対して sig̲sem (rcnt = 1 ) のシステムコールを実行すると、資源数は4になる」といった説明も、システムコール実行中に割込みが入り、その中で sig̲sem が実行されるケースを考えると正確ではない。
【解説】は、途中の割込みがないという条件の下での動作を説明したものである。
【補足事項】
仕様決定の理由や注意すべき点など、解説に対する補足事項を述べる【エラーコード】
システムコールで発生する可能性のあるエラーに関して説明を行なう※ 以下のエラーコードについては、各システムコールに対するエラーコードの説明の項には含めていない場合があるが、各システム
コールにおいて共通して発生する可能性がある。
E̲SYS, E̲RSFN, E̲NOSPT, E̲XNOSPT, E̲CTX※ この項で説明されているエラーコードは、原則として、起こりうる可能性をもつエラーコードの最大限のものである。ここに出ているエラーを、実際にすべて発生しなければならないという意味ではない。インプリメントの違いやエラー検出方法の違いにより、実際には発生しないエラーがあっても構わない。例えば、
wai̲tsk の E̲TNOSPT は、常にタイマが利用できれば発生する可能性の無いエラーである。

m

IT

RO

N

第 一 部

ITRONの基礎

I T

R

O

N

第一部 第一章

TRONプロジェクトとITRON4

TRONプロジェクトの特徴

マイクロプロセッサが誕生したのは1970年代初めであるが、その進歩は著しく、応用分野は今後もますます広がるであろう。数多くのマイクロプ
ロセッサが人間の生活空間の細部に入り込み、それらが相互に通信し、分散処理を行ないながら、より快適な生活を人間に提供するようになると思われる。1990年代には50〜100万トランジスタ以上の集積度を持つVLSIチップ出現すると予測されているが、進んだ半導体技術を利用すれば、必要とされるマイクロプロセッサの処理能力に対応することは可能である。
しかしながら、現在のマイクロプロセッサは、まだ応用からの要求にとって十分な能力を提供しているとは言い難い。つまり、現在のマイクロプ
ロセッサは、ハードウエア資源の乏しかった頃に作られたアーキテクチャ
をそのまま引きずっており、多くの部分で歪みを生じているということである。このまま半導体技術が進展すると、ハードウエア資源とアーキテク
チャとのギャップがますます大きくなり、ハードウエアの能力を生かし切ることができなくなる恐れがある。応用分野からのトップダウンの要求が高まり、半導体技術の進歩によるボトムアップの性能向上がなされても、その中間に位置するアーキテクチャが古いままであると、システム全体としてのバランスが非常に悪くなってしまう。よりVLSIを意識し、応用からの要求に応え、90年代にターゲットを合わせた、新しいマイクロプロセッ
サのアーキテクチャ体系が欲しい。
TRONプロジェクトは、このような問題点を解決すべく、マイクロプロ
セッサから応用分野にわたる一貫したコンピュータ体系を、全く新しく作
り直そうというものであり、1984年6月から始まった。TRONプロジェクト
では、将来のマイクロプロセッサの応用分野やユーザからくる要求と、
1990年代のVLSIの技術予測とを調べ、従来のアーキテクチャからの互換性にとらわれない新しいアーキテクチャを提唱する。このアーキテクチャ体
系は、リアルタイム特性に優れ、VLSIベース、分散処理指向といった特長をもち、1990年代における一つの標準となることを目指す。
TRONプロジェクトの基本的な考え方をまとめると、次のようになる。
第一部 ITRONの基礎

5・1990年代の技術水準をターゲットとした設計を進める。
現在のマイクロプロセッサのアーキテクチャは8ビット時代との互換性をいまだに引きずっているものが多く、VLSI化を始めから考慮したものではない。VLSI化で得られる豊富なハードウエア資源を、古いアーキテク
チャに無理に付け加えたような形になっており、無駄が多い。TRONプ
ロジェクトでは、始めからVLSIの存在を前提とした設計を行なう。
・リアルタイム処理を前提とする。
従来の計算機の使い方は、バッチ処理やTSS処理に見られるように、「人間の方が計算機を待つ」ものであった。しかし、今後は自然界を含めた外部環境を制御し、人間の生活をより快適にするために多くの計算機が使用される。この場合は、「計算機の方が人間（または外部環境からの刺激）を待つ」といった形態になる。これがリアルタイム性の本質である。リアルタ
イム性は、分散処理、通信などの応用においても必須のものである。しかし、リアルタイム処理では計算機の稼働率がさがるため、同じ処理能力を得るにはより高性能の計算機が必要になる。TRONプロジェクトではリアル
タイム処理を必須のものと考え、始めからそれを考慮して設計を行なった。
・究極のノイマン型計算機を目指す。
TRONプロジェクトでの研究の対象は、あくまでも汎用的なノイマン型計算機である。非ノイマン型アーキテクチャの研究はさかんに行なわれており、中にはノイマン型計算機の可能性をいたずらに否定する意見もある。しかし、ノイマン型計算機の汎用性や技術の完成度などを見た場合、1990年代になっても社会の中心になって使われるのがノイマン型計算機であることは間違いない。TRONプロジェクトの目標は、VLSIの特徴を生かせるような究極のノイマン型計算機のモデルを提供することである。
・計算機の各階層の設計を同時に行ない、トータルアーキテクチャを目指す。
TRONプロジェクトでは、マイクロプロセッサからネットワークまでの設計を、同時に行なっている。したがって、OSでネックになる部分はプ
ロセッサの命令で強化したり、ネットワークの構築のために必要なシス
テムコールをOSに導入したりといった、広い範囲にわたる設計のフィードバックが可能である。このように、設計段階において階層間にまたがるチューニングまで行なえるため、実質的な計算機の速度であるアプリ
ケーションの実行速度を大幅に向上させることが可能である。
第一章 TRONプロジェクトとITRON

6

TRONのサブプロジェクト

TRONプロジェクトでは、5つのサブプロジェクトを同時に進行させている。プロジェクト全体の核となるのが、1990年代の半導体技術を生かせるようなアーキテクチャを持つマイクロプロセッサ、TRONCHIPである。
TRONCHIPは、1990年代のアプリケーションやOSの実行に最も適したマ
イクロプロセッサとなる。次にOSの階層として、組み込み型制御用のリア
ルタイムOSであるITRON(Industorial-TRON)、ワークステーション向きのOSであるBTRON(Business-TRON)、大規模なデータ処理を行なうセンター
マシンのためのOSであるCTRON(Central-TRON)がある。このうち、
CTRONはマイクロコンピュータ用というよりはメインフレーム用のOSである。OSの階層を応用ニーズに応じて3つに分けたのは、組み込み用コン
ピュータ、ワークステーションコンピュータ、センターマシン用メインフ
レームのすべてを一つのOSでカバーするのは、無理があると判断したからである。さらに、複数のITRON、BTRON、CTRONをネートワークで有機的に結合し、人間の生活する環境全体を総合的に操作するのがMTRON(Macro-TRON)である。
TRONプロジェクトの特徴の一つとして、設計基準、すなわちアーキテ
クチャと実現手段、すなわちインプリメントを分離したことがある。ここで、アーキテクチャという言葉を定義しておこう。TRONプロジェクトの中では、G.M.Amdahlが定義した「アーキテクチャ」の意味を拡張し、「プログラマから見た命令セットのみならず、オペレーティングシステム、マンマシンインターフェースまで含めた、システムの各層の属性を規定するもの」といった意味で「アーキテクチャ」という言葉を用いている。具体的には、TRONCHIPの命令セットから、ITRONやBTRONのシステムコー
ル、BTRONのマンマシンインターフェースまでのすべてのインタフェー
ス仕様がTRONのアーキテクチャに含まれる。アーキテクチャとインプリメント手法の分離により、ある階層より下のインプリメンテーションが全く変わっても、それより上位の階層はそのまま使用できるという利点がある。すなわち、階層ごとに互換性が保たれている。また、TRONプロジェ
第一部 ITRONの基礎

7
クトで重要なことは、アーキテクチャは規定するが性能に関する規定は行
なわないことである。したがって、その部分がインプリメンタ間の自由競争の部分となる。ユーザから見ると、使い勝手は同じだが性能は異なるという製品が、メーカーの違いや時期の違いによって何種類も提供されるわけである。つまり、TRONプロジェクトは、統一化と同時に公平な技術競争を行なうための土俵を提供するものであると言える。

第一章 TRONプロジェクトとITRON

第一部 第二章

ITRONの基本方針

10

マルチタスクOSとリアルタイムOS

マイクロプロセッサを核として構成したコンピュータ、すなわちマイク
ロコンピュータは、小さい、安い、といった特徴を生かして、各種制御装置の置き替えというコンピュータの新しい応用分野を開拓した。すなわち、
これまでリレーや機械仕掛け、アナログ回路などによって実現されていた制御装置を、小型のコンピュータによって置き替えることが可能になったのである。具体的には、電話交換機、工業用のロボット、NC機械などを始め、家電製品のエアコン、洗濯機、テレビ、など多くのものがマイコン制御となった。
こういった各種の制御装置に使用されるマイクロコンピュータの場合、
メインフレームやパソコン、ワークステーションのようにそのコンピュータ自体に存在目的があるのではない。これらの制御用コンピュータは、より大きなシステムの一つの部品として使われている点に特色があり、そういった意味で、「組み込みコンピュータシステム（略して組み込みシス
テム）」と呼ばれる。
一般に、組み込みシステムでは外部で発生したいろいろな刺激や環境の変化をセンサーで感知して、それに対して応答の動作を起こしたり、周期的に外部に対して動作を起こしたりする能力が必要とされる。例えば、エアコンであれば外部の温度や湿度をセンサーで感知し、それに応じてエアコンの出力や風向きを制御するのである。組み込みシステムのプログラム
は、刻々変化する外部環境との関係に遅れることなく追従し、それを制御しなければならないという点で、一般的なデータ処理のプログラムとはかなり異なった性質を持っている。
組み込みシステムのプログラムの生産性を上げ、工期を短縮するためには、プロセッサの命令をそのまま使うのではなく、共通の管理プログラム、
すなわちオペレーティングシステム (OS) を利用し、その上にシステムに応じたアプリケーションプログラムを載せるのが有効である。この場合、OSといっても、汎用コンピュータのOSのようにユーザ間の保護やファイルの管理を主な目的とするものとは異なり、並行した処理や割込みによる外部
第一部 ITRONの基礎

11
事象との同期などのプログラミングを容易にするのが目的のものである。
一般に、コンピュータ、あるいはその上のプログラムはシーケンシャルに走るものであり、同時に二つのことを行なう能力はない。ところが、組
み込みシステムの場合には、センサーが複数存在し、それらを並行して監視しなければならないことが多い。監視するものが二つあれば、プログラ
ムも二つに分け、それらが同時に並行して走ると考える方が自然であり、プログラミングも容易になる。このような要求から生まれたのがマルチタ
スクの考え方である。すなわち、全体の処理のうちで、並行した流れを持
つ部分をタスクとして分割し、プログラムをタスクに分けることによって、わかりやすさやプログラムの生産性を上げようというものである。もちろん、裸のプロセッサではシーケンシャルに命令を実行する能力しかないので、マルチタスク機能はOSによって時分割で実現することになる。マルチタスク機能を持つOSをマルチタスクOSと呼び、これは組み込みシステム用のOSとして非常に有効なものである。
汎用コンピュータのOSも、複数のジョブ（プロセス、タスク）などを時分割で並行して実行するという意味ではマルチタスクOSである。しかし、汎用コンピュータの場合には、ジョブ（プロセス、タスク）どうしの独立性が強いのが普通である。例えば、同じ計算機である人が文書処理を行ない、ある人がコンパイルを行ない、ある人がエディタを使う、という意味では
マルチタスクで処理が行なわれているが、それぞれの人は自分の実行しているジョブ（プログラム）にのみ興味があるわけであり、並行してどのような処理が行なわれているかについては、特に関知しない。この場合、マル
チタスク処理を行なう目的は、主にコスト・パフォーマンスの向上である。
つまり、それぞれの人が専用のコンピュータを使用するのが理想であるにもかかわらず、コンピュータの台数が足りないために一つの計算機を共用する必要があり、その結果、マルチタスク処理になるのである。
一方、組み込みシステムの場合は、もともと一つの目的をもった作業を、プログラムの書きやすさという面から複数のタスクに分割したものである。
したがって、それぞれのタスクが勝手に動いているわけではなく、タスク間の関係は極めて複雑である。組み込みシステムの場合は、その中あるタ
スクの動きや相互関係を常に見渡しているシステム全体の設計者がおり、複数のタスクが協力して一つの目的を達成するのである。こういった意味
で、汎用コンピュータと組み込みシステムではマルチタスクの性格がかな

第二章 ITRONの基本方針

12
り異なっている。
組み込みシステム用のOSでもうひとつ重要な点は、リアルタイム性と呼ばれるものである。リアルタイム性（即時性）とは、抽象的に説明すると、コンピュータの処理が外部の状況の変化に追従できることであるが、具体的には、処理結果を出すまでの時間が制限されていることを指す。より簡
単に言えば、応答速度が十分速いこと、あるいは応答速度の最悪の値が予測できることである。
従来の計算機の使い方は、バッチ処理やTSS処理に見られるように、「人間の方が計算機を待つ」ものであった。こういったケースでは、コンピュー
タで計算をすること自体が一つの目的となっており、ほかのシステムとの関連があるわけではない。したがって、処理時間が長くなっても、単に人間が待っていれば済むことが多い。処理が速いに越したことはないが、処理が遅くなっても致命的な影響を与えるわけではない。
一方、組み込みシステムの場合には、計算すること自体が目的なのではなく、計算結果を使って他の機器を制御することが目的である。したがって、処理時間に対する要求が厳しく、処理が遅れると、結果を出しても無意味になってしまうことが多い。例えば、新幹線の保安機器の制御であれ
ば、異常を検出した場合に一定時間以内にブレーキをかけなければ、大事
故につながる。また、自動車のエンジンのプラグ点火のタイミングを組み込みコンピュータシステムによって制御する場合、ちょうどエンジンの回転がその位置に達するまでに結果を出しておかないと、タイミングを計算した意味がなくなってしまう。つまり、処理結果がどうなったか、ということと同じように、いつ結果を得られるか、ということも重要なのであり、遅れて処理結果がでるのは処理結果を出さないのと同じなのである。
ところが、処理時間に対する厳しい要求を満たすためには、「計算機の方が外部環境からの刺激を待つ」といった形態にならざるを得ず、計算機の稼働率は低下する。つまり、計算機の使い方が贅沢になるのである。これは、今日のようにコンピュータが普及して安価になったからこそはじめて実現できたことである。リアルタイム、組み込みといった用途がコンピュータの応用分野として比較的新しいものであるのは、こういった理由による。
普通のプログラミングであれば、そのアルゴリズム、データ構造やおお
まかな実行効率、計算量のオーダーを議論することはあっても、絶対的なプログラムの実行時間まで議論することは少ない。しかし、組み込みシス

第一部 ITRONの基礎

13
テムへの応用では、上で述べたように、実行時間があらかじめ予測できな
いと困ることが多い。それも、個々のプログラム（ジョブ、プロセス、タスク）のCPUタイムではなく、他のタスクの実行状況などを含めて、システム全体の負荷まで計算に入れた絶対時間の見積りが必要なのである。これは、極めて難しい問題であり、大型機のような複雑なOSではまず不可能である。
OS自体を軽く単純なものにしておかないと、OSのオーバーヘッドまで含めた時間の見積りはできない。
組み込みシステムに使用するOSは、以上のような意味で、一般的なデー
タ処理を行なうOSや開発用のOSとはかなり異なったものである。組み込みシステムのためのOSは、マルチタスク処理が可能で、リアルタイム性を持ったリアルタイム・マルチタスクOSでなければならない。

第二章 ITRONの基本方針

14

ITRONの特長

ITRON (Industrial - The Realtime Operating system Nucleus) は、産業用の組
み込みシステムに使用することを目的として作られたリアルタイム・マル
チタスクOSである。ITRONの大きな特長は、複数のプロセッサに実装するOSであるにもかかわらず、その処理性能を高くするために、必要以上の標準化、仮想化を行なっていないことである。また、もう一つの大きな特長
は、豊富な機能を持つOSであるにもかかわらず、適応化を考慮し、実際のオブジェクトをコンパクトなものにすることができる点である。
標準化や仮想化を進めることは、ソフトウエアの互換性や教育の面からは望ましいことであるが、そのために基本性能が低下するという点ではマ
イナスである。また、豊富な機能を持つということは、プログラムの書きやすさや特定のケースにおける性能向上という点からは望ましいことであるが、そのためにオブジェクトコードのサイズが大きくなるという点ではマイナスである。OSを設計する場合には、この両者のバランスをとることが重要であり、その一つの答えとして出てきたのがITRONなのである。また、これは、TRONプロジェクト全体に共通する「弱い標準化」の考え方を、
リアルタイムOSという分野で具体化したものであるとも言える。
こういったITRONの特長をまとめると、次のようになる。
・プロセッサの仮想化をしない。
ITRONは、複数のプロセッサ上に実装することを目的としたOSであるが、具体的な実装設計は、プロセッサ毎に独立して行なうことを基本方針としている。
標準OSといった場合に最初に考えられるのは、まずプロセッサ間で共通の仮想アーキテクチャを想定し、その上にITRONを実装することである。
しかし、当然のことながら、この方法では、プロセッサのネイティブなアーキテクチャと想定された仮想アーキテクチャとの間のギャップが、そのまま性能の低下につながる。リアルタイムOSとしての最高の性能を得るためには、どうしてもプロセッサの能力を最大に生かすようなアー

第一部 ITRONの基礎

15
キテクチャが必要であり、マシンやOSの極端な仮想化は避けなければならない。さらに、組み込み用という用途を考えると、オブジェクトの互換性に対する要求はあまり強くはない。むしろ、システムコールの名前
や機能の統一といった、教育の面からの互換性が重要なことが多い。
そこで、ITRONでは、OSの仕様のうちで何が標準化できるかを検討し、プロセッサ間で共通の仕様とプロセッサに依存した仕様とを明確に分離することを行なった。そして、標準化の難しい部分を無理に標準化する
ことは行なわず、標準化、仮想化による性能の低下を避けるようにした。
・豊富な機能を持つ。
ITRONでは、いろいろな機能を持つシステムコールが豊富に用意されている。例えば、ITRONでは同期手段としてイベントフラグ、セマフォ、および各タスクに付随した同期機構（slp̲tsk, wup̲tsk

システムコールで使用）など、考えられるほとんどのメカニズムを提供している。このため、応用に最適なメカニズムを選択することによる性能向上やプログラ
ムの書きやすさが期待できる。
・高速な応答が可能である。
リアルタイム応用において応答速度に特に影響する部分は、タスクの切り替え（ディスパッチング）を行なう部分と割込みハンドラを起動する部分である。後で述べる適応化と関連するが、ITRONでは、ディスパッチ
時に入れ換えを行なう汎用レジスタを指定することにより、高速のディスパッチングができるように考慮されている。
また、外部割込み発生時にはOSを介することなくユーザの定義した割込みハンドラを起動できるようになっており、この部分のオーバーヘッド
は基本的にゼロである。ただし、割込みハンドラで使用するレジスタは、ユーザ側で退避する必要がある。
・適応化を考慮している。
ITRONは一つのOSアーキテクチャであるが、組み込み用ということを考慮し、柔軟で適応性の強いアーキテクチャになっている。システムコー
ルの取捨選択、ディスパッチ時に入れ換えを行なうレジスタの指定、実行（可能）状態のタスクがない時の低消費電力モードの使用、システム
コール実行におけるエラーチェックの有無、などの選択の自由度がユー
ザに開放されており、これを用いて適応化を行なうことができる。
第二章 ITRONの基本方針16
例えば、メモリアドレスを指定するパラメータがあった場合、その値がセグメンテーションエラー、バスエラーなどのメモリ関係のエラーを起こす可能性があるかどうかをソフトウエアでチェックすると、システム
コールの実行にとってかなりのオーバーヘッドになる。一方、メモリア
ドレスを指定するパラメータが静的なものであり、かつユーザの書いたプログラムが正しければ、パラメータがエラーを起こすことはないはずである。以上のような状況では、デバッグ時に多少のオーバーヘッドがあっても完全なエラーチェックを行なっておき、デバッグが終了してからエラーチェックをはずすようにするのが一番望ましい。ITRONアーキ
テクチャでは、エラーチェックの有無にも自由度を持たせているため、このようなことが可能になっている。
・教育を重視している。
ITRONの設計方針の一つとして、教育を重視し、教育も機能の一つと考えるということがあげられる。
ITRONのシステムコールの名前や機能はいくつかの基準に基づいて系統的に決められており、理解が容易になっている。例えば、ITRONのシス
テムコール名は 'xxx̲yyy' 型の7文字、または 'zxxx̲yyy' 型の8文字であり、'xxx' が操作の方法、'yyy' が操作の対象（オブジェクト）を表わすのが基本である［図1.1］。xxx,yyyの意味は［表1.1］のようになっている。'z' の付
く8文字のシステムコールは、複数の機能を組み合せて実行する複合シス
テムコール、あるいは'z' の付かない7文字のシステムコールから派生した
システムコールであることを表わす。
また、ITRONは複数のプロセッサ上で動作するので、ITRONを使用すれば、複数のプロセッサを使用する場合でも、OSに関する教育は一本化することができる。これも、実際のプログラム開発を考えると大きな利点である。

第一部 ITRONの基礎

17cre̲tskdel̲tskcre̲tsk

タスク

cre̲flg
cre̲semdel̲flg

set̲flg

イベントフラグdel̲semsig̲sem

セマフォ

生成

削除

各種操作

＊ITRON のシステムコールの名前は、'xxx̲yyy' 型の７文字を使うのが原則である。このうち、'xxx' が操作の方法の省略
名称を表わし、'yyy' が操作の対象（オブジェクト）の省略
目名称を表わす。

［図1.1］ ITRONのシステムコール命名法

省略名
tsk
flg
sem
mbx
mpl
msg
int
exc
blk
tim
cre
del
def
can
wup
wai
ret

意味
Task
Eventflag
Semaphore
Mailbox
MemoryPool
Message
Interrupt
Exception
Block
Time
CreateDeleteDefineCancel
Wakeup
Wait
Return［表1.1］ ITRONにおける省略名称の生成規則

第二章 ITRONの基本方針

18

ITRONのシリーズ化

ITRONは標準OSであるが、その具体的な実装設計はプロセッサ毎に独立して行われる。そのため、対象となるプロセッサが増えるにしたがい、
ITRON標準仕様の中でもいくつかのシリーズ化が行われている。具体的には、現在ITRON1(ITRON Ver 1.11)、ITRON2、μITRONの3つのシリーズが用意されている。
このうち、ITRON1は、インテルiAPX86、モトローラM68000、ナショセ
ミNS32000、日本電気Vシリーズなどのプロセッサに実装されたITRONである。ITRON2は、TRONCHIPなどの新しい高性能プロセッサに載せることを意図したITRONであり、ITRON1と比較すると、機能の追加やITRON2相互間の互換性強化などが行われている。一方、μITRONは、ITRON2とは逆に、シングルチップコンピュータや8ビットプロセッサなどの低コストのプロセッサに実装することを意図したITRONである。
一般に、標準OSとしての互換性の追求と適応化による性能の向上とはト
レードオフの関係になるため、両者のバランスをとる必要が生じる。ここで、既存の16ビットプロセッサ向けに両者のバランスをとったのがITRON1であり、新しい32ビットプロセッサ向けに両者のバランスをとったのがITRON2であり、シングルチップコンピュータや8ビットプロセッサ向けに両者のバランスをとったのがμITRONであるということになる。言い換え
ると、ITRON1の標準化の程度を上げて仕様拡張を行ったのがITRON2であり、ITRON1の適応化の程度を上げて仕様を簡略化したのがμITRONとなる。

第一部 ITRONの基礎

第一部 第三章

ITRONの機能

20

基本概念

タスク
ITRONで言うタスクとは、プログラムの並行処理の単位である。すなわ
ち、一つのタスクの中のプログラムは逐次的に実行が行なわれるのに対して、異なるタスクのプログラムは並行して実行が行なわれる。ただし、並行して実行が行なわれるというのは、アプリケーションプログラマ（OSのユーザ）から見た概念的な動作として、並行した実行が行なわれるということである。物理的には、OSの制御のもとで、それぞれのタスクが時分割で実行されることになる。
プロセッサの実行するタスクが切り替わるのは、タスクの状態を遷移させるシステムコールが発行された時や割込みが発生した時である。プロセッサの実行するタスクが切り替わることをディスパッチングと呼び、これを実現するOS内のメカニズムをディスパッチャと呼ぶ。
実行可能なタスクが複数存在した場合、何らかのアルゴリズムに従って
タスクの実行順序を決定する必要がある。OSによるタスクの実行順序の制
御メカニズムをタスクのスケジューリングと呼ぶ。ITRONでは、タスクに与えられる優先度を基にした優先度ベースのスケジューリング方式を採用しており、数の小さい方が高い優先度を表わす。ITRONでは必ず優先度の高いタスクから実行され、自タスクよりも高優先度で実行可能状態のタス
クが無ければ、自タスクは必ず実行状態になる（絶対優先度）。また、マルチプロセッサ構成でない場合は、優先度の高いタスクが実行中である限り、それより優先度の低いタスクは全く実行されない。
個々のタスクを区別するために、ITRONでは番号を用いる。これをタスク
IDと呼ぶ。生成できるタスクの最大数は、ITRONのインプリメントに依存して、またターゲットシステムのハードウエア構成やコンフィグレーションテ
ーブルの内容に依存して変化する。μITRONのタスクはシステム起動時に静的に生成されるのに対して、ITRON1およびITRON2のタスクは、タスクIDを用いて動的に生成することができる。生成後は、タスクIDまたは生成時に得第一部 ITRONの基礎

21
られるタスクアクセスキー（ITRON1の場合のみ）を用いてタスクを識別する。
ITRONが多くのタスクの実行を制御し、マルチタスキングを実現するた
めには、タスクを管理するための情報を集めたものが必要である。これをタスク制御ブロック(TCB)と呼ぶ。TCBの内容は原則としてユーザには見えないものであり、TCB内部の値の設定、変更はシステムコールを通じて
ITRONが行なう。ITRONの場合、TCBには普通次のような情報が含まれる。
ただし、その詳細はインプリメントに依存して変化する。
タスクID番号
タスクの優先度
エントリポインタ（タスクスタートアドレス）
初期ユーザスタックポインタ
例外ハンドラのアドレス
タスクの使用するレジスタのセーブエリア
タスクの状態を示すフラグ群
資源
タスクの実行のために必要な各種の要素を資源と呼ぶ。資源には、プロセッサ、メモリ、入出力装置などのハードウエアやファイル、プログラムなどのソフトウエアが含まれる。大部分の資源は、複数のタスクから同時に使用することができないため、並行に動作する複数のタスクに対して、限られた資源を排他的に割り当てるようにOSが調整しなければならない。
資源を排他的に割り当てる手段として、ITRONには各種の同期・通信機能が用意されている。
タスクの状態と動作
ITRONのタスク状態と、状態間の遷移を引き起こすシステムコールを［図1.2］に示す。ITRONのタスク状態は以下の5つに分けられている。
［1］実行 (RUN) 状態
現在そのタスクを実行中であるという状態。
［2］実行可能 (READY) 状態
タスク側の実行の準備は整っているが、そのタスクよりも優先度が高い（同じ場合もあるが）タスクが実行中であるため、そのタスクの実行はできない

第三章 ITRONの機能

22という状態。つまり、プロセッサが使用可能になればいつでも実行できる状
態。実行可能状態のタスクが複数個あった場合、これらのタスクはプロセッ
サが空くのを待って待ち行列を作る。これをレディキューと呼ぶ。
［3］待ち (WAIT) 状態
そのタスクを実行できる条件が整わないために、実行ができない状態。
すなわち、何らかの条件が満足されるのを待っている状態。
待ち状態をさらに分類すると、そのタスクがシステムコールを発行して自らイベント待ち状態に入った「待ち (WAIT) 状態」と、他タスクによって強制的にイベント待ち状態に入った「強制待ち (SUSPEND) 状態」と、待ち状態のタスクがさらに強制的にイベント待ち状態にされた場合の「二重待ち (WAIT-SUSPEND) 状態」とに分かれる。ITRONでは、「待ち(WAIT) 状態」と「強制待ち (SUSPEND) 状態」を明確に区別しており、自ら「強制待ち (SUSPEND)状態」になることはできない。
待ち状態からの実行再開は中断した場所から行なわれ、プログラムカウ
ンタやレジスタなどのプログラム実行状態を表現する情報（これをコンテキストと呼ぶ）はそのまま復元される。待ち状態では、セマフォなどの資源は占有したままである（プロセッサを除く）。
［4］休止 (DORMANT) 状態
タスクがまだ起動されていない状態、または終了後の状態。タスクを新しく生成するとまずこの状態になる。
待ち状態との相違点は、資源をすべて解放している点、レジスタやプロ
グラムカウンタなどのコンテキストが実行再開時に初期化される点、そのタスクに対する各種のタスク操作命令（wup̲tsk,ter̲tsk,sus̲tsk,chg̲pri
システムコールなど）がエラーになる点である。
［5］未登録 (NON-EXITENT) 状態
タスクがまだ生成される前、または削除された後の、システムに登録されていない仮想的な状態である。
なお、μITRONの場合は、このうち、［5］の未登録 (NON-EXITENT) 状態を持たない。また、［ 3］の一部である強制待ち (SUSPEND) 状態、二重待ち(WAIT-SUSPEND)状態と、［4］の休止(DORMANT)状態を持つかどうかはイン
プリメント依存となっている。ITRON1とITRON2では、［1］〜［5］の全部の状

第一部 ITRONの基礎

23
DISPATCH
PREEMPT

READY
実効可能状態

RUN
待ち
条件

待ち
解除

実効状態

WAIT
強制終了
待ち状態
中断
(sus̲tsk)(ter̲tsk)
再開(rsm̲tsk, frsm̲tsk)

WAIT-SUSPEND
二重待ち状態

強制終了(ter̲tsk)

待ち解除

中断(sus̲tsk)

SUSPEND

強制終了

強制待ち状態(ter̲tsk)

再開 (rsm̲tsk,
frsm̲tsk)

起動 (sta̲tsk)

強制終了
DORMANT
休止状態

強制終了 (ter̲tsk)
生成(cre̲tsk)

終了 (ext̲tsk,
abo̲tsk)

削除(del̲tsk)

NON-EXISTENT

終了削除 (ext̲tsk)

未登録状態

初期状態
＊μITRONの場合、強制待ち状態(SUSPEND)、
二重待ち状態(WAIT-SUSPEND)、
休止状態 (DORMANT)はインプリメント依存である。
また、未登録状態(NON-EXISTENT)は持たない。

［図1.2］ITRONのタスク状態遷移図
第三章 ITRONの機能

24
自タスクに対する操作
他タスクに対する操作(実行状態からの遷移） (実行状態以外からの遷移）タスクの待ち状態（強制待ち状態を含む）
への移行

タスクの終了タスクの消除slp̲tsksus̲tsk

実行状態

実行可能、待ち状態

待ち状態

強制待ち、二重待ち状態

ext̲tsk, abo̲tsk

ter̲tsk

実行状態

実行可能、待ち状態

休止状態

休止状態

exd̲tskdel̲tsk

実行状態

休止状態

存在しない状態

存在しない状態＊ ITRONでは、タスクの状態遷移を明確にすることと、システムコールの理解を容易にすることを考え、自タスクの操作をするシステムコールと他タスクの操作をするシステムコールを明確に分離している。これは、言い換えると、実行状態
からの状態遷移とそれ以外の状態とそれ以外の状態からの状態遷移を明確に分離しているという意味にもなる。

［表1.2］自タスク、他タスクの区別と状態遷移図
態を持つことが必須となっている。
ITRONの特色として、自タスクの操作をするシステムコールと他タスクの操作をするシステムコールを明確に分離しているということがある［表1.2］。これは、タスクの状態遷移を明確にし、システムコールの理解を容易にするためである。自タスク操作と他タスク操作のシステムコールを分離しているということは、言い換えると、実行状態からの状態遷移とそ
れ以外の状態からの状態遷移を明確に分離しているという意味にもなる。
タスクのスケジューリングITRONでのタスクスケジューリングは、タスクの優先度を基準にして行なう。また、同じ優先度のタスク間では、FCFS (First Come First Service)方式と呼ばれるスケジューリングを行なう。この様子を、［図1.3］の例で説明する。
［図1.3(a)］は、優先度1のタスクA、優先度3のタスクE、優先度2のタス

第一部 ITRONの基礎

25
クB、C、Dをこの順に起動した後の、レディキューの状態である。現在実行可能状態にある最も優先度の高いタスクはタスクAであるから、タスクA
のみが実際に実行される。ITRONでは、タスクの優先度は絶対的な意味を持っており、タスクAが実行中であれば、優先度の低い他のタスクは全く実行されない（マルチプロセッサ構成の場合を除く）。
さらに、この状態で外部割込みが発生した場合、割込みハンドラから戻る時点で再度スケジューリングが行なわれる。しかし、割込みハンドラ内
でタスクBよりも優先度の高いタスクが実行可能状態に移っていない限り、
割込みハンドラから戻った後もやはりタスクBが実行される。つまり、外部
割込みの発生によって、タスクBが実行権を奪われるということはない。このような仕様になっているのは、外部割込みの発生と、その時に実行中であったタスクとの間には、直接の関係がないためである。
しかし、一旦待ち状態または休止状態に移行したタスクが、再度実行可能状態に移行した場合には、そのタスクは、その優先度のレディキューの最後尾に付く。また、ITRONでは同一優先度のレディキューを回転させる
システムコールrot̲rdqが用意されているので、それを発行することにより、タスクBをレディキューの最後尾にもっていくことも可能である。
同一優先度のタスクに対するスケジューリング方式を、FCFS方式ではな
く、一定時間の経過により別のタスクを実行するラウンドロビン方式にしたい場合は、これをユーザ側で実現することもできる。そのためには、タイマ割込みを使って割込みハンドラを一定時間毎に起動し、その中で
rot̲rdqシステムコールを発行すればよい。

レディキューの先頭・優先度
高＜優先度1＞

低＜優先度2＞［タスクB］＜優先度3＞［タスクE］［タスクC］［タスクD］［図1.3(a)］ 始めのレディキューの状態

第三章 ITRONの機能

26
レディキューの先頭・優先度
高＜優先度1＞

低＜優先度2＞［タスクB］＜優先度3＞［タスクE］［タスクC］［タスクD］［図1.3(b)］タスクAが待ち状態になった後のレディキューの状態
なお、タスクの優先度は、システムコールchg̲priを用いて動的に変化させることができる。
非タスク部実行中のシステム状態
ITRONの上で動くタスクのプログラミングを行なう場合には、タスク状
態遷移図を見て、各タスクの状態の変化を追っていけばよい。しかし、
ITRONでは、割込みハンドラや拡張SVCハンドラなど、タスクより核に近いレベルのプログラミングまでユーザが行なう場合がある。この場合は非タスク部、すなわちタスク以外の部分を実行している間のシステム状態についても考慮しておかないと、正しいプログラミングができない。ここではITRONのシステム状態について説明を行なう。
ITRONのシステム状態は、［図1.4］のように分類される。
［図1.4］で示されている状態のうち、「過渡的な状態」には、OS実行中（システムコール実行中）の状態が含まれる。ユーザから見ると、ユーザの発行したそれぞれのシステムコールが不可分に実行されるということが重要なのであり、システムコール実行中の内部状態はユーザからは見えない。
OS実行中の状態を「過渡的な状態」と考え、その内部をブラックボックス的に扱うのは、こういった理由による。
「タスク独立部」と「準タスク部」は、各種のハンドラなど（タスク部として実行される例外ハンドラを除く）を含むものである。このうち、タスクのコンテキストを持つ部分が「準タスク部」であり、タスクとは独立したコンテ
キストを持つ部分が「タスク独立部」である。具体的には、ユーザの定義した第一部 ITRONの基礎

27
拡張システムコールの処理を行う拡張SVCハンドラが「準タスク部」となり、
外部割込みによって起動される割込みハンドラが「タスク独立部」となる。
「準タスク部」では、一般のタスクと同じようにタスクの状態遷移を考えることができ、待ち状態に入るシステムコールも発行可能である。
ITRONでは、「過渡的な状態」、「タスク独立部」、「準タスク部」を合わせて「非タスク部」と呼んでいる。これ以外で、普通にタスクのプログラムを実行している状態が「タスク部実行中」の状態である。
タスク独立部と準タスク部
ITRONの中で「タスク独立部」となるのは、割込みハンドラやタイマハ
ンドラの部分である。タスク独立部の特徴は、タスク独立部に入る直前に実行中だったタスクを特定することが無意味であり、「自タスク」の概念が存在しないことである。したがって、タスク独立部からは、待ち状態に入るシステムコールや、暗黙で自タスクを指定するシステムコールを発行することはできない。また、タスク独立部では現在実行中のタスクが特定できないので、タスクの切り換え（ディスパッチング）は起らない。ディスパッチングは必要になっても、それはタスク独立部を抜けるまで遅らされる。これを遅延ディスパッチ(delayed dispatching)の原則と呼ぶ。
もし、タスク独立部である割込みハンドラの中でディスパッチを行なうと、割込みハンドラの残りの部分の実行が、そこで起動されるタスクよりも後回しになるため、割込みがネストしたような場合に問題が起こる。この様子を［図1.5］に示す。
［図1.5］は、タスクAの実行中に割込みXが発生し、その割込みハンドラ

過渡的な状態
OS実行中など
タスク独立部実行中
割込みハンドラなど
システム状態

非タスク部実行中
準タスク部実行中
拡張 SVCハンドラ(OS拡張部)など
タスク部実行中［図1.4］ITRONのシステム状態の分類
第三章 ITRONの機能

28
中でさらに高優先度の割込みYが発生した状態を示している。この場合、＜1＞の割込みYからのリターン時に即座にディスパッチを起こしてタスクBを起動すると、割込みXの＜2＞〜＜3＞の部分の実行がタスクBよりも後回しになり、タスクAが実行状態になった時にはじめて＜2＞〜＜3＞が実行されることになる。これでは、低優先度の割込みXのハンドラが、高優先度の割込みばかりではなく、それによって起動されたタスクBにもプリエンプトされる危険を持つことになる。したがって、割込みハンドラがタスクに優先して実行されるという保証がなくなり、実質的に割込みハンドラが書けなくなってしまう。ITRONで遅延ディスパッチの原則を設けているのは、
こういった理由による。
これに対して、ITRONの中で「準タスク部」となるのは、主にユーザがOSを拡張した部分である。具体的には、拡張SVCハンドラがこれに含まれる。ただし、プロセッサによっては、現在「準タスク部」を持たないものがあり、その場合は拡張SVCハンドラは「タスク独立部」になる。
準タスク部の特徴は、準タスク部に入る直前に実行中だったタスク（要求タスク）を特定することが可能であること、タスク部と同じようにタスクの状態が定義されており、準タスク部の中で待ち状態に入ることも可能なことである。
したがって、準タスク部の中では、通常のタスク実行中の状態と同じようにディスパッチングが起きる。その結果、割込みハンドラはすべてのタスクに優先して実行されるのに対して、OS拡張部などの準タスク部は、非タスクであるにもかかわらずタスク部の実行に優先して行なわれるとは限らない。
次の二つの例は、タスク独立部と準タスク部の違いを示すものである。
・タスクA（優先度8＝低）の実行中に割込みがかかり、その割込みハンドラ（タスク独立部である）の中でタスクB（優先度2＝高）に対するwup̲tskが実行された。しかし、遅延ディスパッチの原則により、ここではまだディスパッチが起きず、wup̲tsk実行後はまず割込みハンドラの残りの部分が実行される。割込みハンドラの最後のret̲intによって、はじめてディスパッチングが起り、タスクBが実行される。
・タスクA（優先度8＝低）の中で拡張システムコールが実行され、その拡張
SVCハンドラ（準タスク部とする）の中でタスクB（優先度2＝高）に対す
るwup̲tskが実行された。この場合は遅延ディスパッチの原則が適用されないので、wup̲tskの中でディスパッチングが行なわれ、タスクAが準タ

第一部 ITRONの基礎

29

タスクA
(優先度低):

タスク独立部

:

タスク部
タスクB
(優先度高)

割込み X(優先度低)

割込み Y(優先度高)

割込
割込
ネスト
wup̲tsk B＜1＞＜2＞

ret̲int

wup̲tsk C＜4＞

ret̲int ＜3＞＊＜2＞でディスパッチを行うと、割込みX の処理ハンドラの残りの部分の実行が後回しになってしまう。

［図1.5］割込みのネストと遅延ディスパッチ

スク内での実行可能状態に、タスクBが実行状態になる。したがって、拡張SVCハンドラの残りの部分よりもタスクBの方が先に実行される。拡張
SVCハンドラの残りの部分は、再びディスパッチングが起ってタスクAが実行状態となった後で実行される。
ID番号とアクセスキー
ITRONでは、タスクなどシステムコールの操作対象となるものを総称してオブジェクトと呼ぶ。オブジェクトには、タスクのほかにメモリプール
やイベントフラグ、セマフォ、メイルボックスなどの同期、通信機構が含まれる。各オブジェクトに対して、そのオブジェクトの管理テーブル（タスクの場合はTCB）がOSによって用意される。オブジェクトの識別はID番号を用いて行なわれるので、オブジェクトを最初に生成する時は、ID番号をパラメータとしてオブジェクトを指定する。しかし、その後何度もそのオ

第三章 ITRONの機能

30
ブジェクトをアクセスする場合にID番号をパラメータとして参照すると、
ID番号から管理テーブルアドレスへの変換が毎回生じるため、性能が落ちる場合がある。そこで、オブジェクトを生成した時に、そのオブジェクト
をアクセスするためのキー値をOSのリターンパラメータとして返すようにし、以後、そのオブジェクトのアクセスをする場合には、生成時に返されたキー値をパラメータとして用いる方法がある。このような目的で用いられるキー値をITRONでは「アクセスキー」と呼ぶ。
通常、アクセスキーとしては、オブジェクト管理テーブルのベースアド
レスが用いられることが多いため、アクセスキーは「アクセスアドレス」とも呼ばれる。ITRONでは、「アクセスキー」と「アクセスアドレス」を全く同義のことばとして用いている。ただし、アクセスキーとしてID番号をそのまま用いる場合や、オブジェクト管理ブロックのセグメント値を用いる場合、OSのデータ構造に依存したハッシュ値を用いる場合などもあるた
め、必ずしもアクセスキーがオブジェクト管理テーブルのアドレスを示すとは限らない。
なお、μITRONの場合は動的なオブジェクトの生成を行わず、必要となるオブジェクトは、すべてシステム起動時に静的に生成される。したがって、オブジェクトの識別にアクセスキーを用いる必要はなく、ID番号によってオブジェクトを指定する仕様になっている。また、ITRON2では、OSのインプリメントが違ってもアプリケーションの互換性を向上させるという意図から、やはり、ID番号によってオブジェクトの指定を行う仕様になっている。したがって、アクセスキーを用いているのはITRON1のみである。
ITRONでの標準化の方針と互換性
ITRONは、複数のプロセッサに実装される標準OSである。しかし、標準化や仮想化に伴う性能の低下を防ぐため、それぞれのプロセッサのアーキ
テクチャを生かす方向で、仕様にバリエーションを持たせている部分がある。また、ITRONの場合は、ターゲットシステムのハードウエアによって実行環境が大きく異なるので、OSのみに強い規定を設けても、オブジェク
トレベルの互換性をとることは難しい。したがって、むしろOSでの規定は緩いものにし、インプリメント毎の効率向上を目指すという考え方をとっている。そのため、対象プロセッサやITRONのインプリメントが異なれば、
ITRON1同士やμITRON同士であっても、完全な互換性は保証されない。仕第一部 ITRONの基礎31
様の細かい点ではインプリメント依存の項目があり、ITRON2、ITRON1、
μITRONの順でインプリメント依存項目が多くなっている。また、同様の理由により、ITRON1とITRON2や、ITRON1とμITRONも完全互換ではない。
ITRON1およびITRON2の仕様は、プロセッサ間で共通の部分、プロセッ
サに依存する部分、インプリメントに依存する部分の三段階に分けられている。ここでは、こういったITRONでの標準化のレベルについて説明する。
ITRONの仕様のうち、プロセッサ間共通の仕様となっているものには、
次のようなものがある。
システムコールの機能と名称
パラメータの種類と名称
エラーコードの種類と名前、エラーコードの値
機能コード番号（システムコールを区別する番号）
ただし、これらの点についても、すべての仕様を厳密に実現する必要があるわけではなく、インプリメントの都合で、多少の仕様変更が行われる
場合がある。また、ITRON1とITRON2の間では、上記のプロセッサ間共通の仕様に関しても、仕様の追加が行われていたり、仕様が多少違っていた
りする場合がある。
これに対して、パラメータの渡し方やビット数、システムコール起動の方法などの仕様は、プロセッサのアーキテクチャの影響を強く受ける部分である。これらの仕様をITRON1あるいはITRON2して統一することも不可能ではないが、それに伴う性能の低下を考えると好ましいことではない。
また、プロセッサが異なれば、もともとオブジェクトレベルの互換性が無いので、パラメータの渡し方などを統一してもあまり意味がない。
しかし、これらの仕様は、プロセッサが特定できれば標準化できる仕様である。そこで、ITRONでは、現在多く使用されているインテルiAPX86系、
モトローラM68000系、ナショナルセミコンダクタNS32000系のプロセッサについて、具体的にITRONを実装した場合にどのようにするのが望ましいかを考え、その標準的な仕様を提示した。これらの仕様は、プロセッサに依存した点があるため、それを実装するプロセッサの名前をつけて
ITRON/86（ITRON1をインテルiAPX86にインプリメントしたもの）、
ITRON/MMU286（ITRON1をインテルiAPX286にインプリメントしたもの）、
ITRON/68K（ITRON1をモトローラM68000にインプリメントしたもの）、

第三章 ITRONの機能

32
ITRON/32（ITRON1をナショセミNS32000にインプリメントしたもの）、
ITRON/CHIP（ITRON2をTRONCHIPにインプリメントしたもの）、といった形で呼ばれる。
また、ITRONでは、基本的に外部仕様のみを規定し、インプリメント方法は全くの自由となっている。しかし、システムコール実行の細かな点まで考えると、どうしてもインプリメント方法が外部仕様にまで影響する点が出てくる。そこで、ITRONでは、こういった部分を「インプリメントに依存した仕様」とし、外部仕様ではあるが、ITRONの性能が最も引き出せるようにインプリメンタが自由に決めてよい部分を設けている。インプリ
メントに依存した仕様には、エラー検出のレベルなどが含まれる。
μITRONの場合には、プロセッサの違いに依存して、OSの仕様の違いもずっと大きくなる。そこで、μITRON仕様全体をガイドライン的なものとし、「プロセッサ間共通の仕様」「プロセッサ依存の仕様」「インプリメント
依存の仕様」の三者を厳密に区別することは行っていない。「プロセッサ間共通の仕様」にあたるものが一応提示されているが、その仕様が強い拘束力を持つわけではなく、すべての点が「プロセッサ依存」でもあり「インプリメント依存」でもある。
なお、繰り返しになるが、ITRON仕様が完全互換性を保証するものではないにもかかわらず、ITRONとしてリアルタイムOSの標準仕様を提示している意義としては、次のような点がある。
・システムコール名や用語を統一することによって教育の一本化を図る。
・ITRONのインプリメンタが標準仕様との差を示すことにより、移植の際に変更の必要な部分が明確になる。

第一部 ITRONの基礎33

システムコールインタフェース

アセンブリ言語とのインタフェース
ITRONの仕様では、アセンブリ言語を使用している場合のシステムコー
ル呼び出し方法、つまりアセンブリ言語とのインタフェース方法は、プロセッサ依存となっている。ただし、ITRON1およびITRON2では、以下のよ
うな点について、どのプロセッサにも当てはまる共通の原則を設けている。
・システムコールのパラメータやリターンパラメータは、原則としてレジスタに置く。このために4〜8個程度のレジスタを使用する。
・システムコールの種類を示す機能コードは、通常アキュムレータとして使われているレジスタに置く。
・パラメータの数が多い場合や、データの長さが長い場合は、メモリ上にパケットを作る。その先頭アドレスは、通常アドレスレジスタまたはインデクスレジスタとして使われているレジスタに置く。
・リターンパラメータとして使用しないレジスタはすべて保存されるのが望ましい。
ITRON/86(ITRON/MMU286)、ITRON/68K、ITRON/32、ITRON/CHIPは、
これらの原則を踏まえた上で、iAPX86(iAPX286)、M68000、NS32000、
TRONCHIPに具体的にITRONを載せたものである。
なお、μITRONの場合にも同じ原則を当てはめることは可能であるが、原則に合わせるかどうかよりも性能を優先する必要があるため、上記の原則はあまり意味を持たない。
言語Cとのインタフェース
ITRONでは、マシンの仮想化を行なっていないため、当然のことながら、
プロセッサが異なればオブジェクトコードの互換性はない。異なるプロセッサ間で、ITRONのアプリケーションプログラムの移植性を確保するためには、高級言語を使用してプログラムを記述する必要がある。ITRONでは、
現在、言語Cを標準的な高級言語として使用することにしており、言語Cか

第三章 ITRONの機能

34
らITRONのシステムコールを実行する場合のインタフェース方法を標準化している。ITRONと言語Cとのインタフェースについては、以下のような原則が設けられている。
・システムコールはすべてCの関数として定義され、システムコールのエラ
ーコンディションを関数の戻り値として返す。エラーコード以外のリタ
ーンパラメータは、原則としてポインタを用いて返される。
・パラメータの順序は、リターンパラメータへのポインタ、その他のパラメータの順となる。このほか、ITRON1では、命令オプションが最初のパラメータとして置かれる場合がある。
言語CでのITRONシステムコールインターフェースは、基本的にはプロセッサに依存しないものになっている。しかし、割込み処理や例外処理などシステムコールの機能自体がプロセッサによって違っている部分、およびITRON/86(ITRON/MMU286)において、iAPX86系のプロセッサのセグメントを使ったアドレッシングに関係している部分については、プロセッサに
よって多少仕様の異なる部分がある。もっとも、これはITRONの問題というよりも、プロセッサのアーキテクチャの問題である。また、ITRON1とITRON2の間でも、言語Cのシステムコールインターフェースに多少の相違がある。

第一部 ITRONの基礎

第一部 第四章

μITRONとITRON2

36

μITRONの概要

家電製品や自動車などへの組み込みを目的とした制御用のシングルチッ
プコンピュータでは、ROM容量やRAM容量の制限、量産時のコストダウン
に対する要求などから、これまで標準OSを用いることは少なく、アプリケ
ーション側でOSの機能まで包含してプログラミングを行うのが一般的であった。μITRONは、こういったケースで利用することを目的としたOSの体系であり、教育の一本化といった標準OSのメリットを生かしつつ、メモリ
容量や性能の面では、標準化によるオーバーヘッドを回避することを可能としたものである。
μITRONの基本方針
最近では、いくつかの半導体メーカーが、制御用のシングルチップコン
ピュータに入れるプロセッサや、ASIC核となるプロセッサとして、オリジ
ナルアーキテクチャの8〜16ビットプロセッサを作るケースが増えてきた。
これらのプロセッサは、リアルタイム、組み込みの用途で使用されることが多いため、OSとしてITRONを載せたいという要求が強い。
しかし、ITRONは汎用の16ビットプロセッサを対象として設計されているため、シングルチップコンピュータや8ビットプロセッサに実装するには機能が多過ぎ、ROM容量やRAM容量に不足をきたす場合がある。ITRONでは、適応化によって不要な機能を削除できるようになっているが、これは、個々のアプリケーションに対する適応化や機能のサブセット化を意味する
ものであり、OS全体として勝手に機能を減らしても良いわけではない。OSでサポートされない機能があると互換性が失われてしまうため、ITRONでは、最低限インプリメントの必要な機能を定めているが、それだけでも多くの機能が含まれている。
また、適応化のために機能のサブセット化を行う場合には、システムコール全体を削除するだけではなく、システムコールの一部の機能のみを削除したいことがある。例えば、ITRONのセマフォは計数型のセマフォであるため、セマフォ待ちシステムコール wai̲sem (Wait Semaphore) では、パラ

第一部 ITRONの基礎

37
メータ rcnt により、資源獲得値を自由に指定できるようになっている。ここで、セマフォの機能全体を削除するのではなく、資源獲得値の指定機能のみを削除して機能のサブセット化を行い、資源獲得値を1に固定した場
合、wai̲sem システムコールの rcnt パラメータは不要になる。同様に、
セマフォ待ちにおけるタイムアウトの機能を削除した場合には、タイムア
ウトの時間指定を行うパラメータ tmout も不要になる。パラメータを減らすことは、ROM容量やRAM容量の節約に効果があるので、ROM容量やRAM容量の制限の厳しいシングルチップコンピュータの場合に大きな意味がある。
ところが、パラメータの有無はシステムコールインタフェースに影響するので、高級言語による互換性を必要とする場合には、勝手にパラメータを削除するわけにはいかない。ITRONは、適応化を一つの特長としたOSであるが、一方では高級言語による互換性も考慮しているため、無制限の適応化を行うことができるわけではない。
μITRONは、こういったITRONの適応性の限界を越えることを狙ったアーキテクチャである。すなわち、ITRONでは、適応化よりも標準化に重点を置いた設計になっていたが、μITRONでは、標準化よりも適応化に重点を置くことにより、RAM容量やROM容量の極端に少ないシングルチップマ
イクロコンピュータやプロセッサの絶対能力が低い8ビットプロセッサでも、十分な性能を発揮できるようにした。
具体的には、ITRONで標準化を行っていた仕様のうち、システムコール
インタフェースやパラメータの有無などいくつかの点について、推奨仕様
あるいはインプリメント依存仕様に格下げを行い、インプリメントの際の自由度をずっと大きくした。また、OSレベルでの機能のサブセット化を許し、OSのインプリメンタが、プロセッサアーキテクチャに合った機能や必要性の高い機能を自由に選択できるようにした。
一般に、標準化と適応化はトレードオフの関係になる。μITRONでは、OSレベルでの強力な適応化ができる分だけ、標準化の程度は弱くなっている。OSによってインプリメントが行われていない機能があったり、システ
ムコールインタフェースの詳細仕様に差異があったりするため、高級言語レベルでも完全な互換性は保障されない。
しかし、μITRONを実装するプロセッサは千差万別なので、互換性に関して言えば、μITRONの仕様の違いによる問題よりも、プロセッサのアー

第四章 μITRONとITRON2

38
キテクチャの違いの方がずっと大きな問題となる。プロセッサが異なると、ワード長やアドレス空間の大きさ、アドレッシング方式等の違いも生じる
ため、OSのシステムコールを全く利用しないユーザプログラムであっても、高級言語レベルの互換性が保障されているわけではない。また、組み込みのコントローラ等に使用するというμITRONの用途を考えると、接続されているハードウエアや入出力機器の差による影響も大きいため、プログラ
ム移植の際には、プログラムの見直しや修正がどうしても必要になる。したがって、μITRONで高級言語レベルの互換性を保障しなくても、それほど大きな問題とはならない。
この場合、μITRONによる標準化のメリットは、システムコール名称と機能との対応といった教育面でのメリットに絞られることになる。しかし、プログラマの教育コストやプログラムの生産性向上を考えた場合、教育面
での標準化の効果は大きなものがある。上で述べたように、μITRONの適用される用途では、必要に応じてプログラムの書き直しを行うことが多い
ため、プログラム自体の互換性よりも、教育面での互換性の方が重要になる。μITRONに準拠したOSであれば、どの名称のシステムコールでどういう機能を実現するかという点がITRONも含めて標準化されているので、プロセッサが変わっても、システムコールと機能との対応付けが容易である。
また、ITRONを理解していればμITRONの理解が容易であり、逆にμ
ITRONを理解していればITRONの理解も容易になる。
結局、μITRONは、一つのOSの仕様を指すものではなく、OSの仕様設計を行ない、システムコールの命名を行うためのガイドラインであると言える。μITRONでは、プロセッサ毎あるいはアプリケーション毎に、一つのガイドラインに沿った別々のOS仕様が存在しており、それらのOSがμITRONというOSのファミリを形成していると考えられる。μITRONは、複数のOSの仕様を包含したOS群とも呼ぶべきものであり、「μITRON準拠」
であるとは、μITRONで決めたシステムコール名称を使っているという意
味になる。
μITRON設計の具体化
μITRONは、基本的にはITRONで定めている機能をサブセット化し、仕様のインプリメント依存部分を多くしたものである。しかし、単にITRONの仕様の一部を抜き出すことによってサブセット化を行うと、機能がアン

第一部 ITRONの基礎

39
バランスになったり、サポートしない機能に対するパラメータが存在して無駄が生じたりする。したがって、μITRONのシステムコールの名称やインタフェースは、必ずしもITRONと同一になっているわけではなく、必要な部分については仕様の見直しを行なっている。全体的な方向としては、仕様の簡素化を行い、汎用性よりも高速性を目指すようにしている。
μITRONの条件
μITRONの用途を考えると、μITRONとして必須の機能やシステムコー
ルを決めても、結局中途半端なものになってしまう。そこで、μITRONは、「機能とシステムコール名称との対応付けのガイドライン」といった位置付
けのものに撤することにし、μITRON必須の機能は次の2つだけとしている。
＜1＞RUN, READY, WAIT の3つのタスク状態を持つ。（マルチタスクOSである）
インプリメントによっては、このほかに DORMANT, SUSPEND の状態を持っても良い。
＜2＞割込みハンドラの定義が可能であり、割込みハンドラからシステムコールを発行することによって、タスクを起床する手段が存在する。
（リア
ルタイムOSである）
割込みハンドラの定義は、静的に（システムジェネレーション時や初期化時に）、または def̲int システムコールにより行う。
簡単に言えば、「システムコール名称をITRONに合わせたリアルタイム
OS」はすべてμITRONということになる。極端な話、タスクを待ち状態にするシステムコール(slp̲tsk)と、割込みハンドラから待ち状態のタスクを起床するシステムコール（wup̲tskまたはret̲wup）の2つのシステムコールしか持たないOSであっても、μITRONに含まれるわけである。
この場合、μITRONを利用する方から見ると、μITRON準拠のOSだからといって、どの機能が利用できるかが保障されているわけではない。しかし、前にも述べたように、μITRONであれば、システムコール名と機能との対応付けが保障されている。すなわち、ある機能が欲しい時にどういうシステム
コールを使ったら良いかということや、プログラム中のシステムコールを見て何を行っているかということを容易に知ることができる。こういった「教育の互換性」は、実際にプログラミングを行う上で非常に重要なことである。

第四章 μITRONとITRON2

40

ITRON2の概要

ITRON2の仕様は、ITRONを高性能な32ビットプロセッサに実装することを前提として、従来のITRON(ITRON1)の仕様をバージョンアップしたものである。
ITRON2の基本方針
ITRON2では、ITRON間の互換性やアプリケーションプログラムの移植性を高めることを大きな目的としており、従来のITRONの基本方針に加えて、次のような点を考慮して設計されている。
・標準化のレベルアップ
プロセッサの性能が上がっているため、標準化、仮想化のレベルを上げ、互換性を高める。例えば、従来プロセッサ依存となっていた例外管理機
能についても、標準仕様を設ける。
ただし、ITRON2になっても、バーチャルマシンアプローチはとらず、最高性能のものを求めるという方針はITRON1と同じである。
・TRONファミリのOSとしての統合性
名称や用語などについて、BTRON、CTRONとITRONとの整合性を強化する。
・システムコールのレベル分け
ITRON2では、ITRON1と比べてかなりの機能が追加されている。そこで、ユーザにとっての理解しやすさやITRON1からの移行のしやすさを考えて、システムコールのレベル分けを行なう。具体的には、基本機能≪I1≫、拡張機能≪I2≫、システム操作用機能の3段階に分けられている。このうち、基本機能≪I1≫だけを見ると、ほぼITRON1に相当する機能となる。

第一部 ITRONの基礎

41
ITRON2設計の具体化
ここでは、ITRON2設計の際の考え方や、ITRON1とITRON2の具体的な相違点について、項目別に説明する。
・システムコールの分割と名称
ITRON2では、μITRONとの整合性強化、命令オプションの整理、機能追加、システムコールの取捨選択による適応化への対応などといった理由
により、これまで一つのシステムコールで総称的(generic) に実現されていた機能が、複数のシステムコールに分割されている場合がある。
分割により生まれた派生的な意味を持つシステムコールの名称は、もとのシステムコール名称と関連を持たせるのが望ましい。しかし、従来のxxx̲yyy の形のシステムコール名称では、わかりやすい名前を付けるのが難しい。
そこで、従来の形(xxx̲yyy) の名称に加えて、zxxx̲yyy の形の8文字のシ
ステムコール名称も使うことにする。'xxx', 'yyy' の部分は、従来通り操作
方法と対象（オブジェクト）を表わすが、'z' は、そこから派生したシス
テムコールであることを表わす。
・オブジェクトのアクセス方法
ITRON2では、ITRON1のように、オブジェクト生成時に動的に得られたアクセスキーによってオブジェクトのアクセスを行なうのではなく、実行開始前に確定している値（ID番号など）によってオブジェクトのアクセスを行なう。これは、プログラムの書きやすさと互換性に対する配慮
である。
・例外管理
例外のクラス分け、例外ハンドラの多重起動、拡張SVCハンドラに対する例外管理などの仕様を明確化し、例外処理のプログラムについても標準化を促進する。
また、ITRON2の拡張機能(≪I2≫)として、ソフトウエアにより他タスクの例外ハンドラを起動する機能（強制例外）を設ける。ITRON1の終了時
処理ルーチンは、例外ハンドラの一つ（終了ハンドラ）として扱う。

第四章 μITRONとITRON2

m

I

O
TR

N

第二部

μITRON

I T

R

O

N

第二部 第一章

μITRON概説

この章では、μITRONの仕様設計の考え方、ITRON1とμITRONとの関係などに関して説明を行う。

46

μITRONの設計の考え方

最近では、いくつかの半導体メーカーが、制御用のシングルチップコン
ピュータに入れるプロセッサや、ASIC核となるプロセッサとして、オリジ
ナルアーキテクチャの8〜16ビットプロセッサを作るケースが増えてきた。
これらのプロセッサは、リアルタイム、組み込みの用途で使用されることが多いため、OSとしてITRONを載せたいという要求が強い。
しかし、ITRONは汎用の16ビットプロセッサを対象として設計されているため、シングルチップコンピュータや8ビットプロセッサに実装するには機能が多過ぎ、ROM容量やRAM容量に不足をきたす場合がある。ITRONでは、適応化によって不要な機能を削除できるようになっているが、これは、個々のアプリケーションに対する適応化や機能のサブセット化を意味する
ものであり、OS全体として勝手に機能を減らしても良いわけではない。OSでサポートされない機能があると互換性が失われてしまうため、ITRONでは、最低限インプリメントの必要な機能を定めているが、それだけでも多くの機能が含まれている。ITRONでの適応化の考え方を［図2.1］に示す。
また、適応化のために機能のサブセット化を行う場合には、システムコール全体を削除するだけではなく、システムコールの一部の機能のみを削除したいことがある。例えば、ITRONのセマフォは計数型のセマフォであるため、セマフォ待ちシステムコール wai̲sem (Wait Semaphore) では、パラメータ rcnt により、資源獲得値を自由に指定できるようになっている。ここで、セマフォの機能全体を削除するのではなく、資源獲得値の指定機能のみを削除して機能のサブセット化を行い、資源獲得値を1に固定した場合、
wai̲sem システムコールの rcnt パラメータは不要になる。同様に、セマフォ待ちにおけるタイムアウトの機能を削除した場合には、タイムアウトの時間指定を行うパラメータ tmoutも不要になる。パラメータを減らすことは、ROM容量やRAM容量の節約に効果があるので、ROM容量やRAM容量の制限の厳しいシングルチップコンピュータの場合に大きな意味がある。
ところが、パラメータの有無はシステムコールインタフェースに影響するので、高級言語による互換性を必要とする場合には、勝手にパラメータ
第二部 μITRON

47
ITRON仕様で定める機能
タスク管理 イベントフラグ セマフォ メイルボックス メモリプール その他

プロセッサアーキテクチャによる影響（ITRON/86でインプリメントされる機能）
タスク管理 イベントフラグ セマフォ メイルボックス メモリプール その他 プロセッサ依存機能（ITRON/68Kでインプリメントされる機能）
タスク管理 イベントフラグ セマフォ メイルボックス メモリプール その他

プロセッサ依存機能（ITRON/32でインプリメントされる機能）
プロセッサ依存機能

タスク管理 イベントフラグ セマフォ メイルボックス メモリプール その他

アプリケーション毎の適応化（アプリケーションAに適応化したITRON）
セマフォ

タスク管理

メモリプールプロセッサ依存機能（アプリケーションBに適応化したITRON）
タスク管理 イベントフラグ

メモリプールプロセッサ依存機能（アプリケーションCに適応化したITRON）
タスク管理

セマフォ メイルボックス

プロセッサ依存機能［図2.1］ITRONにおける適応化の考え方を削除するわけにはいかない。この様子を［図2.2］に示す。ITRONは、適応化を一つの特長としたOSであるが、一方では高級言語による互換性も考慮しているため、無制限の適応化を行うことができるわけではない。
μITRONは、こういったITRONの適応性の限界を越えることを狙ったアーキテクチャである。すなわち、ITRONでは、適応化よりも標準化に重点を置いた設計になっていたが、μITRONでは、標準化よりも適応化に重点を置くことにより、RAM容量やROM容量の極端に少ないシングルチップマ
イクロコンピュータやプロセッサの絶対能力が低い8ビットプロセッサでも、十分な性能を発揮できるようにした。

第一章 μITRON概説

48
ITRON1 仕様におけるwai̲semのインタフェース
ercd = wai̲sem (option, a̲sem, cnt, tmout) ;option : タイムアウト検出の有無の指定
a̲sem : セマフォアクセスキー（セマフォID）
cnt :
資源獲得値
tmout : タイムアウト時間
ercd : エラーコード
資源獲得値とタイムアウト指定が不要な場合のwai̲semのインタフェース（ITRON1仕様からは逸脱する）
ercd = wai̲sem (a̲sem) ;a̲sem : セマフォアクセスキー（セマフォID）
ercd : エラーコード［図2.2］セマフォ待ちシステムコールwai̲semのインタフェース例
具体的には、ITRONで標準化を行っていた仕様のうち、システムコールイ
ンタフェースやパラメータの有無などいくつかの点について、推奨仕様あるいはインプリメント依存仕様に格下げを行い、インプリメントの際の自由度をず
っと大きくした。また、OSレベルでの機能のサブセット化を許し、OSのインプリメンタが、プロセッサアーキテクチャに合った機能や必要性の高い機能を自由に選択できるようにした。μITRONでの適応化の考え方を［図2.3］に示す。
一般に、標準化と適応化はトレードオフの関係になる。μITRONでは、OSレベルでの強力な適応化ができる分だけ、標準化の程度は弱くなっている。OSによってインプリメントが行われていない機能があったり、システ
ムコールインタフェースの詳細仕様に差異があったりするため、高級言語レベルでも完全な互換性は保障されない。
しかし、μITRON を実装するプロセッサは千差万別なので、互換性に関して言えば、μITRONの仕様の違いによる問題よりも、プロセッサのアー
キテクチャの違いの方がずっと大きな問題となる。プロセッサが異なると、ワード長やアドレス空間の大きさ、アドレッシング方式等の違いも生じる
ため、OSのシステムコールを全く利用しないユーザプログラムであっても、高級言語レベルの互換性が保障されているわけではない。また、組み込みのコントローラ等に使用するというμITRONの用途を考えると、接続されているハードウエアや入出力機器の差による影響も大きいため、プログラ
ム移植の際には、プログラムの見直しや修正がどうしても必要になる。したがって、μITRONで高級言語レベルの互換性を保障しなくても、それほ
第二部 μITRON

49
μITRON仕様で定める機能
タスク管理 イベントフラグ セマフォ メイルボックス メモリプール その他 追加機能、プロセッサ依存機能

プロセッサアーキテクチャによる影響
適用アプリケーションによる影響
インプリメンタの選択（プロセッサAのμITRONでインプリメントされる機能）
タスク管理

セマフォ

メモリプールプロセッサ依存機能（プロセッサBのμITRONでインプリメントされる機能）
タスク管理 イベントフラグ

メモリプールプロセッサ依存機能（プロセッサCのμITRONでインプリメントされる機能）［図2.3］μITRONにおける適応化の考え方
ど大きな問題とはならない。
この場合、μITRONによる標準化のメリットは、システムコール名称と機能との対応といった教育面でのメリットに絞られることになる。しかし、プログラマの教育コストやプログラムの生産性向上を考えた場合、教育面
での標準化の効果は大きなものがある。上で述べたように、μITRONの適用される用途では、必要に応じてプログラムの書き直しを行うことが多い
ため、プログラム自体の互換性よりも、教育面での互換性の方が重要になる。μITRONに準拠したOSであれば、どの名称のシステムコールでどういう機能を実現するかという点がITRONも含めて標準化されているので、プロセッサが変わっても、システムコールと機能との対応付けが容易である。
また、ITRONを理解していればμITRONの理解が容易であり、逆にμ
ITRONを理解していればITRONの理解も容易になる。
結局、μITRONは、一つのOSの仕様を指すものではなく、OSの仕様設計を行ない、システムコールの命名を行うためのガイドラインであると言える。
μITRONでは、プロセッサ毎あるいはアプリケーション毎に、一つのガイドラインに沿った別々のOS仕様が存在しており、それらのOSがμITRONというOSのファミリを形成していると考えられる。μITRONは、複数のOSの仕様を包含したOS群とも呼ぶべきものであり、「μITRON準拠」であるとは、
μITRONで決めたシステムコール名称を使っているという意味になる。
本章の以下の部分では、μITRON設計の実際について具体的に述べ、またμITRONにおける標準化の意味について説明を行っている。
第一章 μITRON概説

50

μITRON設計の実際

μITRONは、基本的にはITRONで定めている機能をサブセット化し、仕様のインプリメント依存部分を多くしたものである。しかし、単にITRONの仕様の一部を抜き出すことによってサブセット化を行うと、機能がアンバランスになったり、サポートしない機能に対するパラメータが存在して無駄が生じたりする。したがって、μITRONのシステムコールの名称やインタフェースは、必ずしもITRONと同一になっているわけではなく、必要な部分については仕様の見直しを行なっている。全体的な方向としては、仕様の簡素化を行い、汎用性よりも高速性を目指すようにしている。
以下では、μITRON設計の際の考え方や、ITRONとμITRONの具体的な相違点について、項目別に説明する。
タスク状態
μITRONは、ITRONと同様にプリエンプティブスケジューリングを行う
リアルタイムOSである。タスクに優先度を付ける場合にも、ITRONと同様に、数字の小さい方を高い優先度とする。
μITRONでは、ITRONのようなオブジェクト（タスク、セマフォ等）の動的生成機能は持たないので、ITRONの未登録(NON-EXITENT)状態に相当
するタスク状態は無い。それ以外の次の5つのタスク状態を持つ。
［1］実行(RUN)状態
現在そのタスクを実行中であるという状態。
［2］実行可能(READY)状態
タスク側の実行の準備は整っているが、そのタスクよりも優先度が高い（同じ場合もあるが）タスクが実行中であるため、そのタスクの実行はできないという状態。
［3］待ち(WAIT)状態
タスクの実行を継続できる条件が整わないため、実行が止まっている状態。
［4］の強制待ち(SUSPEND)状態との違いは、自タスクの発行したシステ
第二部 μITRON

51
ムコールにより実行が止まっているという点である。
［4］強制待ち(SUSPEND)状態
他タスクによって、強制的に実行を中断させられた状態。
なお、この状態は、［ 3 ］の 待 ち ( W A I T ) 状 態 と 重 な る 場 合 が あ る 。
［3］と［4］が重なった状態を「二重待ち(WAIT-SUSPEND)状態」と呼ぶ。
［5］休止(DORMANT)状態
タスクがまだ起動されていない状態、または終了後の状態。
待ち状態との相違点は、資源をすべて解放している点、レジスタやプロ
グラムカウンタなどのコンテキストが実行再開時に初期化される点など
である。
このうち、
［4］の強制待ち(SUSPEND)状態と［5］の休止(DORMANT)状態
は、μITRONでは必ずしもインプリメントしなくても良いタスク状態である。μITRONのタスク状態遷移図を［図2.4］に示す。μITRONのタスク状
態は、ITRONのサブセットとなっている。
サブセット化が行われた機能
ITRONの持つ機能のうちの一部については、μITRONの用途に適合する
ように、サブセット化や仕様の簡素化が行われた。その内容を以下に示す。
・オブジェクトを動的に生成する機能
ITRONでは、オブジェクト（タスク、イベントフラグ、セマフォ、メイ
ルボックス、メモリプール）を動的に生成、削除することが可能であったが、μITRONの場合、オブジェクトは初期起動時に静的に生成されるのが基本である。実行の途中でオブジェクトを生成、削除することは行
わない。したがって、オブジェクトの生成や削除を行うシステムコール
である cre̲XXX(Create OBJECT) と del̲XXX(Delete OBJECT) は、μ
ITRONの仕様には含まれていない。これは、オブジェクトの動的な生成や削除によってメモリ管理等が複雑化し、インプリメントの負担がかな
り増えるためである。なお、XXX は tsk, flg, sem, mbx, mpl のいずれかを表わす。
μITRONでは、オブジェクトの動的な生成を行わないので、ITRONのよ
うに、cre̲XXXシステムコールによってID番号からアクセスキーを得、第一章 μITRON概説

52

DISPATCH
PREEMPT

READY
実効可能状態

RUN
待ち
条件

待ち
解除

実効状態
μITRONで必須の
タスク状態

WAIT
強制終了
待ち状態
中断
(sus̲tsk)(ter̲tsk)
再開(rsm̲tsk, frsm̲tsk)

WAIT-SUSPEND
二重待ち状態中断(sus̲tsk)

強制終了(ter̲tsk)

待ち解除

SUSPEND

強制終了

強制待ち状態(ter̲tsk)

再開 (rsm̲tsk,
frsm̲tsk)

起動 (sta̲tsk)

強制終了
DORMANT

強制終了 (ter̲tsk)

休止状態

終了 (ext̲tsk,abo̲tsk)＊点線の部分はインプリメント依存である。
＊タスクの初期状態は、システムジェネレーション時や初期化時に指定する。
＊待ち条件になるシステムコール :slp̲tsk, wai̲tsk, wai̲flg, cwai̲flg, wai̲sem, rcv̲tmb, get̲blk＊待ち解除になるシステムコール :wup̲tsk, rel̲wai, set̲flg, sig̲sem, snd̲tmb, rel̲blk, ret̲wup,
iwup̲tsk, irel̲wai, iset̲flg, isig̲sem, isnd̲msg, osnd̲tmd［図2.4］μITRONのタスク状態遷移図
第二部 μITRON

53
それを使ってオブジェクトのアクセスを行うことはできなくなる。アクセスキーとしては静的な値を持たなければならないので、原則として、
ID番号をアクセスキーとしてそのまま使用する。
μITRONのID番号は1〜2バイトで表現するが、最大数についてはインプ
リメント依存とする。また、使用できるID番号に制約を設けたり、リンカによってアクセスキーの割り当てを行なう（アセンブラやリンカがID
番号からアクセスキーへの変換を行なう）といった方法をとっても構わない。いずれにしても、オブジェクト生成時に動的に得られたアクセス
キーによってオブジェクトのアクセスを行なうのではなく、実行開始前に確定している値（ID番号など）によってオブジェクトのアクセスを行うことになる。
・キューイング機能
ITRONの場合、タスクを起床するシステムコール wup̲tsk(Wakeup Task)
が既に発行されているタスクに対して、もう一度 wup̲tsk を発行しても、エラーにはならず、その要求が保持される。これを要求のキューイング
機能と呼んでいる。この時、wup̲tsk の対象タスクは、待ち状態移行のシ
ステムコール slp̲tsk(Sleep Task) を2回実行してもまだ待ち状態にはならず、3回目の slp̲tsk の実行でやっと待ち状態になる。ITRONでは、
wup̲tsk〜slp̲tskシステムコールによるタスク付属の同期機構や、
sus̲tsk(Suspend Task)〜rsm̲tsk(ResumeTask)システムコールによるタスクの実行中断・再開の際に、複数回のキューイングが可能になっている。
しかし、キューイングの機能を実現するためには、要求のカウント数を保持する必要が生じる。これは、ITRONの場合には大きな問題ではないが、少しでもRAM容量を減らしたいμITRONの場合には、実現が難しくなる場合がある。そこで、μITRONでは、wup̲tsk シ ス テ ム コ ー ル やsus̲tsk システムコールにおける複数回のキューイング機能をインプリメ
ント依存とし、1回のキューイングしかできなくても構わないことにした。
・タイムアウト指定機能
ITRONでは待ち状態に入るシステムコールにおいてタイムアウトの指定が可能であった。しかし、タイムアウトの処理はインプリメントの負担が大きいのでμITRONの仕様には含めない。

第一章 μITRON概説

54
・イベントフラグ
ITRONのイベントフラグでは、1ワード（16〜32ビット）分のイベントフ
ラグをグループ化して扱っており、指定ビットのセットをOR条件やAND条件で待つことができるようになっていた。しかし、この機能のために、イベントフラグ操作用システムコールのパラメータが増え、性能向上やメモリ容量での負担になる場合があった。そこで、μITRONでは、1ワー
ド（8〜16ビット）のイベントフラグをグループ化する仕様のほかに、1ビットのイベントフラグの仕様を用意し、インプリメント側で選択できるようにした。1ビットのイベントフラグは、機能的には、1ワードのイ
ベントフラグのサブセットになる。1ワードを扱うイベントフラグ操作と、1ビットを扱うイベントフラグ操作のパラメータやリターンパラメータの違いを［図2.5］に示す。

イベントフラグが1ビットの場合
システムコール
wai̲flg
cwai̲flg

パラメータ
flgid
flgid

-

-

-

wfmodeflgptnクリア指定なし
クリア指定ありイベントフラグが1ワードの場合
システムコール
wai̲flg

パラメータ
flgid

waiptnflgid :
イベントフラグID
waiptn : 待ち条件を示すビットパターン
wfmode : AND待ち/OR待ちの選択と待ち状態解除時のクリア指定
flgptn : 待ち状態解除時のイベントフラグのビットパターン＊イベントフラグが1ワードになると、その機能を生かすために、多くのパラメータが必要になる。

［図2.5］イベントフラグ待ちシステムコールのパラメータ

第二部 μITRON

55
・セマフォの資源獲得値指定機能
ITRONのセマフォは計数型のセマフォであり、P命令を表わすシステムコール wai̲sem (Wait Semaphore)やV命令を表わすシステムコール sig̲sem(Signal Semaphore) では、資源獲得値や資源返却値を自由に指定できるよ
うになっていた。しかし、μITRONでは、資源獲得値や資源返却値を1に固定することにより、システムコールのパラメータを減らした。
・可変長のメモリブロック管理機能
ITRONの仕様では、可変長（任意長）のメモリブロック管理機能と固定長のメモリブロック管理機能の両方をサポートしている。しかし、一般に可変長のメモリブロックの管理はインプリメントの負担が大きく、リアルタイム性も損なわれやすい。そこで、μITRONでは可変長のメモリ
ブロック管理機能を含めず、固定長のみをサポートしている。
・例外管理機能ITRONでは、システムコール実行のエラーにより例外ハンドラを起動するシステムコール例外の機能と、プロセッサの例外処理（ゼロ除算等）
によってタスクの例外ハンドラを起動するCPU例外の機能があった。しかし、システムコール例外の機能はシステムコール実行のオーバーヘッ
ドになりやすいので、μITRONの仕様には含めない。また、CPU例外の管理機能も、プロセッサのアーキテクチャに対する依存性が高いため、
μITRONの標準仕様には含めない。
ただし、インプリメントによっては、デバッグサポート等の目的で、例
外管理機能を独自に追加することも可能である。
システムコールインタフェース
ITRONのシステムコールには、かなり高機能なものや汎用的なものが含まれている。例えば、自ら待ち状態に入るシステムコールでは、必ずタイ
ムアウトの指定ができるようになっている。タイムアウトの検出を行うかどうかは、パラメータの一つである命令オプションで指定する。このような仕様にすると、タイムアウトの有無にかかわらず同じシステムコールが使えるため、ユーザから見てシステムコールの選択が容易になり、OS全体
がわかりやすいものになるというメリットがある。
しかし、複数の機能を一つのシステムコールで実現しているため、OSを

第一章 μITRON概説

56
インプリメントする方から見ると、システムコール実行時におけるOS内部の判断や分岐が多くなり、性能面でデメリットを生じる場合がある。
また、システムコールの一つ一つが高機能であったり、いろいろな機能を包含していたりすると、システムコール単位で不要な機能を削除する場
合でも、その効果が現われにくい。例えば、タイムアウトの検出を行うシ
ステムコールと行わないシステムコールが別々になっていれば、タイムア
ウトの機能が不要な場合にタイムアウトの検出を行うシステムコールを削除し、プログラム容量を減らすことができる。しかし、タイムアウトの検出を行うシステムコールと行わないシステムコールが一つにまとまっていると、タイムアウトの機能が不要な場合にも、システムコールを削除することができない。この場合、タイムアウトの有無の指定が動的に（パラメータによって）決まるため、不要な機能であっても、その処理プログラムを削除することは難しくなる。
μITRONの場合、ITRON以上に性能面での要求やメモリ容量の制限が厳
しく、より高度な適応化を行う必要がある。そこで、ITRONのシステムコールのうち、高度な機能を持つもの、複合した機能を持つもの、パラメー
タの多いものなどについて見直しを行い、システムコールの機能を分割して機能がプリミティブなものになるように変更を行った。システムコールの機能をプリミティブにすることにより、よりアプリケーションに適応した高性能なプログラムを書くことが可能になり、また、不要な機能を削除することによるメモリ容量の節約を、キメ細かく行うことが可能になった。
実際に分割の行われたシステムコールはあまり多くないが、分割の行われたシステムコールについても、μITRONとITRONとの間で整合性や連続性を確保できるようにする必要がある。すなわち、分割により生まれた派生的なシステムコールの名称は、分割を行う前のシステムコールの名称と関連を持たせるのが望ましい。しかし、ITRONと同じ XXX̲YYY（XXXは操作方法、
YYYは対象オブジェクト）の形のシステムコール名称だけでは、わかりやす
い名前を付けるのが難しい。そこで、従来の形(XXX̲YYY)の名称に加えて、
μITRONでは、ZXXX̲YYY の形の8文字のシステムコール名称も使うことにした。'XXX'、'YYY' の部分は、従来通り操作方法と対象オブジェクトを表わ
すが、'Z' は、そこから派生したシステムコールであることを表わす。なお、TRON体系全体としては、ITRONの複合システムコールやBTRONの外核でも
ZXXX̲YYY の形のシステムコール名称が使用されている。

第二部 μITRON

57
μITRONにおいて、具体的に分割やプリミティブ化が行われた機能としては、次のようなものがある。
・ポーリング機能
ITRON1では、資源獲得を行うシステムコールにおいて、資源が確保できなくても待ち状態に入りたくない場合、すなわち資源獲得のポーリングを行いたい場合は、タイムアウト時間を0にしてそのシステムコールを実行すれば良かった。この場合、正常終了により資源が獲得できたことを示し、タイムアウトエラーにより資源が獲得できなかったことを示す。
ITRONでは、資源獲得待ち機能、ポーリング機能、タイムアウト機能を
一つのシステムコールで実現していたことになる。
このうち、μITRONではタイムアウト機能が外されたが、残りの機能についてもプリミティブ化を行い、システムコールを分離した。分離した
システムコールのうち、資源獲得待ちを行うものはITRONと同じ名称を使用し、ポーリングを行うものは、poll を表わす 'p' の一文字を先頭に付けた名称を使用することにした。
例えば、ITRONやμITRONでは、メッセージの受信を待つシステムコー
ルとして rcv̲msg(Receive Message) が用意されているが、このシステムコールでは、メッセージが未着の場合に待ち状態に入ってしまう。それを避けたい場合、ITRONであればタイムアウトを0にして同じ rcv̲msg シス
テムコールを実行すれば良いのに対して、μITRONであれば、
prcv̲msg(Poll and Receive Message) システムコールを実行すれば良い。
ポーリング機能を実現するシステムコールとしては、次のようなものがある。
preq̲sem（wai̲sem の tmout=0 に相当）
prcv̲msg（rcv̲msg の tmout=0 に相当）
pget̲blk（get̲blk の tmout=0 に相当）
なお、ポーリング機能に類似の機能として、オブジェクトや資源の状態を見るシステムコール XXX̲sts(Get OBJECT Status) が用意されている。
しかし、XXX̲sts では、資源が獲得できるかどうかを見るだけで、資源が獲得できる場合でも獲得を行わない。これに対して、ポーリング機能の場合は、資源を獲得できる場合は資源を獲得してしまう。この点で、単にオブジェクトの状態を見る機能と、資源のポーリングを行う機能とは異なっている。

第一章 μITRON概説

58
・タスク独立部から発行するシステムコール
ITRONの仕様では、タスク部から発行するシステムコールとタスク独立部（割込みハンドラ）から発行するシステムコールを、特に区別しない
ようになっていた。ITRONでは、割込みハンドラ中で起ったディスパッ
チの要求が、割込みハンドラから抜ける時まで遅延させられる（遅延ディスパッチの原則）ため、システムコールがタスクから発行されたか割込みハンドラから発行されたかによって、OS内部の処理が変わってくる。
しかし、システムコールはどちらの場合も共通であり、OS内部で、シス
テムコールの発行されたコンテキストがタスクかタスク独立部かを判断するようになっていた。
これに対して、μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避けて性能を上げるため、タスク独立部（割込みハンドラ）から発行するシステムコールとタスクから発行するシステムコールを分離し、別システムコールとする仕様を用意した。μITRONでタスク独立部から発行するシステムコールを別名称とする場合には、interruptを表わす 'i' の一文字を先頭に付けた名称を使用する。
例えば、ITRONでは、タスクを起床するシステムコール wup̲tskは、タスクからでもタスク独立部からでも発行可能である。しかし、μITRON
では、インプリメントによって、タスク独立部からも wup̲tsk が発行できる場合と、wup̲tsk の代わりに iwup̲tsk を発行する場合とがある。OS
の負担を減らし、タスク独立部から発行するシステムコールの処理を高速化するためには、タスク独立部から発行するシステムコール iwup̲tskとタスク部から発行するシステムコール wup̲tsk は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール wup̲tsk を発行できる方が便利である。μITRONでは、この両者の仕様の選択もインプリメント側で対応できるようにし、プロセッサやアプリケーションに対する適応性を強めた。
・周期起動ハンドラとアラームハンドラの機能
ITRONでは、指定時刻から一定周期でタスクの起床要求を出す機能、すなわち cyc̲wup (Cyclic Wakeup)システムコールによるタスクの周期起床の機能が用意されていた。μITRONでは、この機能の代わりに、より仕様を簡素化、プリミティブ化したメカニズムとして、周期起動ハンドラ

第二部 μITRON

59とアラームハンドラ（指定時刻起動ハンドラ）の機能を設けた。前者は周期的に起動されるタスク独立のハンドラであり、後者は指定時刻に一回だけ起動されるタスク独立のハンドラである。μITRONにおいて、
ITRONのタスク周期起床の機能を実現するためには、ユーザの側で周期
起動ハンドラやアラームハンドラのプログラムを書き、その中でタスク
起床のシステムコール wup̲tsk(Wakeup Task) を発行すれば良い。
なお、実際に周期起動ハンドラやアラームハンドラの機能をサポートするかどうかは、μITRONではインプリメント依存になっている。

第一章 μITRON概説

60

μITRONにおける標準化の意味

前に述べたように、μITRONの適用される用途では、OSの仕様に互換性を持たせたとしても、それ以外の部分（プロセッサアーキテクチャやハードウエア等）で互換性を阻害する要因が多い。したがって、μITRONでは、プログラムの完全互換性を確保することはあまり大きな意味を持たず、性能を上げたり、必要メモリ容量を小さくすることの方がずっと重要である。
そのため、μITRONをインプリメントする際には、性能に影響しないとこ
ろや無理のないところのみを標準仕様に合わせて頂くというのが基本的な考え方である。互換性を確保するために、性能を低下させるような無理な標準化を行う必要はない。互換性についての要求が高ければ、μITRONではなくITRONを使って頂けば良い。
以下では、μITRONで標準仕様を提示している項目と、標準仕様の位置
付けについて述べる。
・機能セットとシステムコール
システムコールの機能とそれに対応する名称は、μITRONとして標準化されている。ただし、機能のサブセット化は自由である。μITRONの一番大きな目的が、システムコール名称の統一によって教育の互換性を確保することであるため、機能とシステムコール名の対応のみは強く標準化される。システムコール自体を取捨選択してサブセット化することは可能であるが、同じ機能に対しては同じシステムコール名を割り当てなければならない。
μITRONの一部のシステムコールでは、仕様が二本立てになっている部分がある。例えば、μITRONのイベントフラグの仕様では、1ビットのみを扱うイベントフラグの仕様と、1ワード（8〜16ビット）をグループ化
して扱うイベントフラグの仕様とが両方用意されており、インプリメン
ト側でどちらかを選択するようになっている。これは、次のような理由による。

第二部 μITRON

61
現在のシングルチップマイクロコンピュータの規模では、イベントフラ
グを1ビットとするのが最適な仕様だと考えられる。しかし、デバイス技術の進歩により、今後はμITRONでも1ワード（8〜16ビット）のイベン
トフラグを実現できる可能性があるし、アプリケーションからの強い要求があれば、多少の無理があっても1ワードのイベントフラグを実現した
方が良い場合がある。また、ITRONとの整合性という意味では、最終的には、イベントフラグを1ワード（8〜16〜32ビット）にできる方が望ましい。こういった点やμITRONの設計方針を考えると、μITRONのイベ
ントフラグを1ビットに固定してしまうのはあまり意味がなく、むしろ、
イベントフラグを1ビットにした時の仕様と1ワードにした時の仕様をそれぞれ標準化する方が望ましいと考えられる。イベントフラグの仕様が二本立てになっているのは、こういった理由による。
もちろん、ユーザにとっては、仕様が何通りもあるのは好ましいことではない。μITRONでも、仕様を二本立てにしてインプリメンタの選択項
目としているのは、最小限の機能に限られている。
・パラメータの種類
原則として標準化し、同じシステムコールは同じパラメータを持つものとする。ただし、アプリケーションに応じて特定の機能を強化したいよ
うな場合は、一部のシステムコールについて、パラメータの追加が必要になることがある。例えば、セマフォにおける資源獲得値指定機能は、
μITRONでサブセット化されている機能であり、サポートしない方が原則である。しかし、特定のアプリケーションでどうしてもこの機能が必
要な場合は、この機能を追加しても構わない。その場合、セマフォ管理
システムコールのパラメータにも追加を生じ、μITRON標準のシステム
コールパラメータとは変わってくる可能性があるが、そうなってもμITRONの範囲から逸脱するわけではない。このような場合は、標準仕様との相違点について、インプリメント毎に明らかにして頂ければ良い。
・アセンブラインタフェース（パラメータの渡し方）
プロセッサのアーキテクチャやコンパイラの影響を強く受ける部分なので、μITRONでも標準化は行わない。プロセッサ毎に仕様を定めるものとする。

第一章 μITRON概説

62
・高級言語（言語C）インタフェース
システムコール名とパラメータが標準化されているので、言語Cインタフ
ェースも原則として標準化する。ただし、パラメータの項で述べたように、特殊な用途ではパラメータの有無が変わる場合があり、そうなると言語Cのインタフェースも変わることになる。標準仕様は提示されるが厳密なものではなく、「弱い標準化」になる。
・機能コードITRONでは、システムコール発行時にシステムコールの種類を区別する
番号を、機能コードと呼んでいる。μITRONで使用する機能コードについても、ITRONと同様に標準を設けるが、やはり「弱い標準」であり、厳密なものではない。
また、μITRONの場合、プロセッサアーキテクチャや開発環境との関係
によっては、トラップ命令（ソフトウエア割込み命令）ではなく、サブ
ルーチンジャンプ命令によって、OS内のシステムコール処理ルーチンに直接ジャンプするケースがある。そのような場合には、機能コードを使用しなくても構わない。
・エラーコード
エラーのニモニックやエラーコードの値についても、μITRONでは「弱い標準化」を行ない、一応の標準仕様を提示している。
一般には、エラーコードを標準化しても、性能向上やオブジェクトサイ
ズ縮小の障害になることは少ないと考えられる。しかし、エラーチェッ
クの厳密さや、複数のエラーが発生した場合の検出順序について細かい規定を行うと、インプリメント方法を制約し、性能にも影響が出る可能性がある。したがって、μITRONでは、エラーチェックに関する細かい規定は設けず、エラーコードを大まかに標準化するだけにとどめている。
なお、BTRONおよびITRON2との整合性を強化するため、μITRONのエラーコードの標準値としては、負の値を使用している。ITRON2のエラー
コードの値とμITRONのエラーコードの標準値は共通になっている。
・負の数の扱い
TRONファミリ全体での方針（一種の「TRON作法」）として、負の数はシス
テム用の数、正の数はユーザ用の数と考えるという原則がある。また、0は特殊な意味を表わすものとしている。例として次のようなものがある。
第二部 μITRON

63― ITRONでは、tskid = 0 で自タスクの指定になる。
― ITRON/MMUでは、srcid = (-1) により共通空間を示す。
― BTRONでは、システムコールの関数値が負になったことによりエラーを示す。
― BTRONでは、process̲id = 0 により自プロセスを、process̲id = (-1) により親プロセスを示す。
― TRONCHIPでは、負のアドレスが SS（共通半空間）、正のアドレスがUS（個別半空間）となっている。
― CTRONでは、tmout = (-1) でタイムアウト無しを示す。
μITRONの場合は、個々のプロセッサアーキテクチャの制約が強いため、
必ずしもこの原則を適用できるとは限らない。しかし、オブジェクトのID番号や優先度を割り当てる際には、性能を落とさない範囲で、できるだけこの原則に合わせるのが望ましい。例えば、μITRONのカーネルと共に入出力用のタスクを提供する場合は、タスクIDを符号付きの数として扱い、負のID番号（例えば -8〜-5）を入出力用のタスクに割り当てるのが望ましい。
なお、上記のうち、必ずしも標準仕様に合わせなくて良い項目であっても、μITRONのインプリメンタは、どの部分が標準仕様と違っているかということを明確に示す必要がある。これは、プログラムの移植に対して、どこを修正すべきかをはっきりさせるためである。
また、プロセッサによっては、レジスタバンクの切り換え機能や、アイドル状態での低消費電力モードなどの特殊機能が用意されている場合がある。そのような機能は、μITRONでも積極的に利用するのが望ましい。そういった追加機能をサポートするためには、プロセッサやインプリメントに依存した特殊なシステムコールが必要となることがあるので、μITRON
では、そのための機能コードの範囲を決めている。

第一章 μITRON概説

64

μITRONの範囲

これまで述べてきたように、μITRONは、非常にインプリメント依存部
分の多いOSである。以下の章におけるμITRONのシステムコール説明では、
システムコールの必要性に関するレベルが示されているが、これは絶対的なものではない。したがって、インプリメンタ側としては、どういう条件を満たせばμITRONと呼べるのか、といった問題を生じる。すなわち、μ
ITRONと呼べるOSの範囲について明確にする必要がある。
一つの方法として考えられるのは、μITRONでサポートを必須とするシ
ステムコールを決めることである。しかし、μITRONはいろいろな応用分野を持つOSであり、μITRONで提供すべき機能も、アプリケーション毎にかなり異なっている。実際、どのようなアプリケーションでも絶対に使用するシステムコールというのは、一つも存在しない。
例えば、割込み処理の機能はリアルタイムOSとして必須の機能であるが、割込みハンドラの定義のために、必ずしも割込みハンドラ定義のシステム
コール(def̲int)を使う必要はない。OSのジェネレーション時や初期化時に、静的な方法で割込みハンドラを定義することも可能である。したがって、
システムコールとしては必須のものが無い。タスク管理機能についても同様である。休止(DORMANT)状態が無いケースを考えると、タスクの起動(sta̲tsk)や終了(ext̲tsk)のシステムコールも不可欠ではない。
また、同期・通信の機能はリアルタイムOSとして不可欠の機能であるが、μITRONではタスク付属同期機能(wup̲tsk)、イベントフラグ、セマフォ、
メイルボックスなどいくつかの同期・通信機能が用意されているため、最低限どれか一つの機能があれば十分である。プロセッサのアーキテクチャ
やアプリケーションが決まっていれば、どの同期・通信機能が最適かということが決まるので、最適なものを必須の機能としておけば良いが、μITRONの用途を考えると無理である。例えば、セマフォの機能をμITRONの必須機能としても、セマフォよりメイルボックスの方が適したアプリケーションは常に存在し、メイルボックスを使えばセマフォは不要になるかもしれない。したがって、セマフォをμITRONの必須機能とするのは、あ第二部 μITRON

65
まり意味がない。
こういった点を考えると、μITRONとして必須の機能やシステムコール
を決めても、結局中途半端なものになってしまう。そこで、μITRONは、「機能とシステムコール名称との対応付けのガイドライン」といった位置付
けのものに撤することにし、μITRON必須の機能は次の2つだけとした。
＜1＞RUN, READY, WAIT の3つのタスク状態を持つ。
（マルチタスクOSである）
インプリメントによっては、このほかに DORMANT, SUSPEND の状態を持っても良い。
＜2＞割込みハンドラの定義が可能であり、割込みハンドラからシステムコールを発行することによって、タスクを起床する手段が存在する。
（リア
ルタイムOSである）
割込みハンドラの定義は、静的に（システムジェネレーション時や初期化時に）、または def̲int システムコールにより行う。
簡単に言えば、「システムコール名称をITRONに合わせたリアルタイム
OS」はすべてμITRONということになる。極端な話、タスクを待ち状態にするシステムコール(slp̲tsk)と、割込みハンドラから待ち状態のタスクを起床するシステムコール（wup̲tskまたはret̲wup）の2つのシステムコールしか持たないOSあっても、μITRONに含まれるわけである。
この場合、μITRONを利用する方から見ると、μITRON準拠のOSだからといって、どの機能が利用できるかが保障されているわけではない。しかし、前にも述べたように、μITRONであれば、システムコール名と機能との対応付けが保障されている。すなわち、ある機能が欲しい時にどういう
システムコールを使ったら良いかということや、プログラム中のシステムコールを見て何を行っているかということを容易に知ることができる。こういった「教育の互換性」は、実際にプログラミングを行う上で非常に重要なことである。特に、リアルタイムOSの分野では、UNIXやMS-DOSのように実質標準として広く使われているOSが無いため、システムコール名を揃えたというだけでも大きな効果がある。
TRON体系全体から見ると、教育の互換性のみを達成するのがμITRONであり、実際に動作させた時のプログラム互換性まで考慮しているのがITRONということになる。
第一章 μITRON概説

66

μITRONの追加機能

μITRONでは、ITRONよりもさらに適応性を高めるため、考えられる機能はできるだけ広く用意するという方針をとっている。そのため、μITRONの仕様では、ITRON1の仕様に比べて次のような機能が追加された。
なお、これらの追加機能の一部はITRON2と共通になっている。また、これらの機能を実際に導入するかどうかは、インプリメント依存である。
・周期起動ハンドラ、指定時刻起動ハンドラの機能「システムコールインタフェース」の項でも述べたが、μITRONでは、
ITRON1の周期起床(cyc̲wup)の代替機能として、周期起動ハンドラおよび指定時刻起動ハンドラ（アラームハンドラ）の機能を設けた。前者は周期的に起動されるタスク独立のハンドラであり、後者は指定時刻に起動されるタスク独立のハンドラである。
・オブジェクトの状態を見る機能
タスク、イベントフラグ、セマフォ、メイルボックス、メモリプールなどのオブジェクトについて、状態参照システムコール(XXX̲sts) を設けた。
オブジェクトの状態参照は、ITRON1では、XXX̲adr （アクセスアドレスを得るシステムコール）を利用して管理ブロックの内部を直接見るという方針であった。しかし、互換性を高めるためには、XXX̲adr を使用す
るよりも、オブジェクトの状態を直接参照できるシステムコールを用意する方が望ましい。そこで、ITRON1のXXX̲adr のシステムコールは廃止し、代わりに XXX̲sts のシステムコールを導入した。
・タスク付属メイルボックスの機能
ITRONでは、一つ一つのタスクの仕様を軽くするため、タスク従属の機能（タスク付属の機能）はできるだけ入れない方針である。そのため、
ITRONのメイルボックスの機能は、タスクとは独立したものになっている。すなわち、メッセージの送信先はタスクではなくメイルボックスであり、その時にそのメイルボックスに対してメッセージを待っていたタ

第二部 μITRON

67
スクが、送信されたメッセージを受け取るという仕様である。
しかし、メッセージを受信するタスクがあらかじめ分かっている場合には、メッセージ通信を高速化するために、メイルボックスをタスク付属のものにした方が良い場合がある。μITRONのタスク付属メイルボック
スは、このために導入された機能である。ここに送られたメッセージを受信できるのは、そのメイルボックスの属しているタスクに限られるため、メッセージを待つタスクの待ち行列が無くなり、メッセージ通信を高速化できる。
μITRONにおいて、タスク従属の機能は、t〜 という名称で区別する方針とする。したがって、タスク付属メイルボックスのオブジェクトの名称
は、
tmb

Task Mailboxとなる。
・タスクリスタート機能
タスクリスタート機能は、割込み処理からの戻り時に、指定タスクを指定
アドレスから実行再開する機能である。この機能は、実行再開を指定されたタスクから見ると、一種の例外処理（ソフトウエアによる強制例外）に相当するが、簡単な仕様にして高速化することを狙うため、μITRONでは例外処理と別扱いにしている。
この機能は、例えば、フォールトトレラントの目的で、実行プログラムをチェックポイントまで戻したいような場合に利用する。
・その他
μITRONの仕様を今後の半導体技術の進歩に対応させていくためには、機能の絞り込みを行うだけではなく、一旦絞った機能を再度拡大できる
ように、仕様に柔軟性を持たせることが必要である。特に、μITRONの場合には、その上位のOSとしてITRON1やITRON2があり、μITRONを機能拡大する際は、できるだけこれらのOSと同じ仕様にすることが目標になる。そういった意味で、μITRONの仕様書は、一つのOSの仕様を表わすものではなく、μITRONの仕様がITRON1やITRON2の仕様からどの程度異なっても良いかということを示すガイドラインだと考えられる。
本書の以下の部分では、μITRONの標準システムコールの説明が行われているが、これは、μITRONで提供することができる機能の上限を定め

第一章 μITRON概説

68
たものではない。必要があれば、この仕様書に無いシステムコールを追加して設けることも可能である。ただし、追加した機能がITRON2でサポートする機能に含まれるものであれば、ITRON2のシステムコール名やシ
ステムコールインタフェースと矛盾の無い仕様にしなければならない。

第二部 μITRON第二部 第二章

μITRONシステムコール

この章では、μITRONで提供している各システムコールに関して説明を行う。

2-2 4/28/98 12:28 PM ページ 70

70

タスク管理機能第二部

μITRON2-2 4/28/98 12:28 PM ページ 71［2］sta̲tsk

71

タスクを起動する［2］sta̲tsk
sta̲tsk:Start Task

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】
t s k i d で 示 さ れ た タ ス ク を 起 動 す る 。 つ ま り 、 D O R M A N T 状態から
READY 状態へと移す。
このシステムコールによる起動要求のキューイングは行なわない。したがって、対象タスクが DORMANT 状態にない場合に発せられた起動要求に対しては、発行タスクにエラー E̲NODMT が戻る。
μITRONの場合、タスクの生成はシステム起動時に静的に行う。タスク
生成時に必要なタスクスタートアドレス (stadr)、初期優先度 (itskpri) などのパラメータも、システム起動時に静的に指定する。
μITRONのタスク状態は、ITRONのサブセットとなる。 ITRONのタスク
状態のうち、NON-EXISTENT を除く●RUN ●READY ●WAIT ●DORMANT ●SUSPEND ●WAIT-SUSPENDの状態がμITRONに含まれる。ただし、インプリメントによっては、このうちDORMANT, SUSPEND(WAIT-SUSPEND) 状態を持たない場合がある。
【エラーコード(ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲NODMT

タスクがDORMANTでない（tskidのタスクがDORMANTでな

い）

第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 72

72［2］ext̲tsk

自タスクを正常終了する［2］ext̲tsk
ext̲tsk:

Exit Task【パラメータ】
なし【リターンパラメータ】※ システムコールを発行したコンテキストには戻らない【解説】
自タスクを正常終了させ、DORMANT 状態へと移行させる。
なお、ext̲tsk では、タスクがそれ以前に獲得した資源（メモリブロッ
ク、セマフォなど）を自動的に解放するということはない。タスク終了前に資源を解放しておくのは、ユーザの責任である。
ret̲XXX および ext̲tsk システムコールでは、エラーを検出した場合にエラーコードを返しても、これらのシステムコールを呼んだ側でそのチェックを行なっていなければ、プログラムが暴走する。そこで、これらのシス
テムコールでは、エラーを検出した場合にも、システムコール発行元へは戻らないのが望ましい。
【エラーコード】※次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、
システムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合の動作は、インプリメント依
存となる。
E̲CTX

コンテキストエラー（タスク独立部から実行）

第二部

μITRON2-2 4/28/98 12:28 PM ページ 73［3］ter̲tsk

73

他タスクを強制的に異常終了させる［3］ter̲tsk
ter̲tsk:

Terminate Task

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】tskid で示されたタスクを強制的に異常終了させる。
ter̲tsk によりタスクを終了する場合でも、ext̲tsk の場合と同様に、対象タスクがそれ以前に獲得した資源（メモリブロック、セマフォなど）を自動的に解放するわけではない。
対象タスクが待ち状態に入り、何らかの待ち行列につながれていた場合には、ter̲tskの実行によってその待ち行列から削除される。すなわち、対象
タスクは待ち解除となってから終了する。
本システムコールでは、自タスクの指定はできない。
【エラーコード(ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲SELF

自タスク、自プロセスの指定（t s k i dが自タスク、タスク
部の発行でtskid=0）

第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 74

74［3］chg̲pri ［#3］ichg̲pri

タスク優先度を変更する［3］chg̲pri

タスク優先度を変更する（タスク独立部専用）［#3］ichg̲pri

chg̲pri:Change Task Priority

ichg̲pri:

Change Task Priority (for Interrupt Handler)【パラメータ】
tskid

TaskIdentifier

タスクID

tskpri

TaskPriority

優先度【リターンパラメータ】
なし【解説】chg̲pri, ichg̲pri では、tskidで示されたタスクの現在の優先度を、tskpriで示される値に変更する。tskid = TSK̲SELF によって自タスクの指定になる。
タスクの優先度は、数の小さい方が高い優先度となる。対象タスクが何らかの待ち行列につながれていた場合には、このシステムコールにより待ち行列の順番が変わることがある。
インプリメントによっては、tskpri = TPRI̲INI (0) の指定により、システ
ム起動時に指定された初期優先度（タスクの固有優先度）に戻ることのできる場合がある。この機能は、不可分の処理を行なうために一時的にタスクの優先度を高くし、その後タスク優先度を元に戻す場合などに使用する。
このシステムコールで変更した優先度は、タスクが終了するまで有効である。タスクが DORMANT 状態になると、終了前のタスク優先度は捨てられ、次にタスクが起動された時のタスク優先度は、システム起動時に指定された初期優先度 itskpri になる。
μITRONのタスク優先度は、1バイト程度で表現する（例えば 0〜255）のが原則であるが、インプリメントやアプリケーションによっては、優先度を数個（例えば1〜4）に絞ることによって高速化するという選択ができてもよい。

第二部

μITRON2-2 4/28/98 12:28 PM ページ 75［3］chg̲pri ［#3］ichg̲pri

75

μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避けて性能を上げるため、タスク独立部（割込みハンドラ）から発行するシステ
ムコールを、一般のタスクから発行するシステムコール chg̲pri から分離して別システムコール ichg̲pri とすることができる。OSの負担を減らし、タスク独立部から発行するシステムコールの処理を高速化するためには、タスク独立部から発行するシステムコール ichg̲pri とタスク部から発行する
システムコール chg̲pri は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール chg̲pri を発行できる方が便利である。どちらの仕様を用いるかはインプリメント側の選択項目となっている。ichg̲pri をサポートする方がOSの機能が高いというわけではない。
【エラーコード(ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（タスク部からichg̲priを実行）

E̲TPRI

不正タスク優先度（tskpriが不正）

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 76

76［3］rot̲rdq ［#3］irot̲rdq

タスクのレディキューを回転する［3］rot̲rdq

タスクのレディキューを回転する（タスク独立部専用）［#3］irot̲rdq
rot̲rdq:

Rotate Ready Queueirot̲rdq:

Rotate Ready Queue (for Interrupt Handler)【パラメータ】
tskpri

TaskPriority

優先度【リターンパラメータ】
なし【解説】tskpri で示される優先度のレディキューを回転する。すなわち、その優先
度のレディキューの先頭につながれているタスクをレディキューの最後尾につなぎかえ、同一優先度のタスクの実行を切り換える。このシステムコールを一定時間間隔で発行することにより、ラウンドロビン・スケジュー
リングを行なうことが可能となる。
tskpri = TPRI̲RUN (0) により、その時実行状態にあるタスクを含むレディキュー（最高優先度のレディキュー）を回転させるものとする。一般のタスクから発行される rot̲rdq では、これは自タスクの持つ優先度のレディ
キューを回転するのと同じ意味になるが、このような仕様にしておけば、
周期起動ハンドラなどのタスク独立部から rot̲rdq (tskpri=TPRI̲RUN) を発行することも可能である。
rot̲rdq の tskpri として TPRI̲RUN または自タスクの優先度を指定した場
合には、自タスクがそのレディキューの後ろにまわることになる。つまり、自ら実行権を放棄するために、rot̲rdq を発行することができる。（ここで言う「レディキュー」は、実行状態のタスクも含んだものと考えている。）
指定した優先度のレディキューにタスクがない場合は何もしないが、エラーとはならない。

第二部

μITRON2-2 4/28/98 12:28 PM ページ 77［3］rot̲rdq ［#3］irot̲rdq

77

rot̲rdq の実行例を［図2.6(a)］、［図2.6(b)］に示す。［図2.6(a)］の状態で、
tskpri=2をパラメータとしてこのシステムコールが呼ばれると、新しいレデ
ィキューの状態は［図2.6(b)］のようになり、次に実行されるのはタスクCとなる。
μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避けて性能を上げるため、タスク独立部（割込みハンドラ）から発行するシス
テムコールを、一般のタスクから発行するシステムコール rot̲rdq から分離
して別システムコール irot̲rdq とすることができる。OSの負担を減らし、タスク独立部から発行するシステムコールの処理を高速化するためには、
タスク独立部から発行するシステムコール irot̲rdq とタスク部から発行する
システムコール rot̲rdq は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール rot̲rdq を発行できる方が便利である。どちらの仕様を用いるかはインプリメント側の選択項目となっている。irot̲rdq をサポートする方がOSの機能が高いというわけではない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（タスク部からirot̲rdqを実行）

E̲TPRI

不正タスク優先度（tskpriが不正）

優先度
高

低

1
2

［タスク B］

3［タスク E］［タスク C］［タスク D］［図2.6(a)］rot̲rdq実行前のレディキューの状態
優先度
高

低

1
2

［タスク C］

3［タスク E］［タスク D］［タスク B］［図2.6(b)］rot̲rdq(tskpri=2)実行後のレディキューの状態
第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 78

78［#5］irel̲wai ［5］rel̲wai

タスクの待ち状態を強制解除する［5］rel̲wai

タスクの待ち状態を強制解除する（タスク独立部専用）rel̲wai:［#5］irel̲wai

Release Wait

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】
rel̲wai, irel̲wai では、 t s k idで示されるタスクが何らかの待ち状態（SUSPEND状態を除く）にある場合に、それを強制的に解除する。
本システムコールにより待ち状態が解除されたタスクに対しては、エラー E̲RLWAI が返る。アラームハンドラ等を用いて、あるタスクが待ち状態に入ってから一定時間後にこのシステムコールを発行することにより、タイムアウトに類似した機能を実現することができる。
本システムコールでは、待ち状態解除要求のキューイングは行わない。
tskid で示される対象タスクが既に待ち状態であればその待ち状態を解除す
るが、対象タスクが待ち状態でなければ、発行元にエラー E̲NOWAI が返る。本システムコールで自タスクを指定した場合にも、同様に E̲NOWAIのエラーとなる。
本システムコールでは、SUSPEND状態の解除は行わない。二重待ち状態(WAIT-SUSPEND) のタスクを対象としてこのシステムコールを発行すると、対象タスクはSUSPEND状態となる。 SUSPEND状態も解除する必要がある場合には、別に frsm̲tsk を発行する必要がある。
rel̲wai (irel̲wai) と wup̲tsk (iwup̲tsk) との違いをまとめると、次のよう
になる。

第二部

μITRON2-2 4/28/98 12:28 PM ページ 79［#5］irel̲wai ［5］rel̲wai

79― wup̲tsk は slp̲tsk, wai̲tsk による待ち状態のみを解除するが、rel̲wai ではそれ以外の要因（wai̲flg, wai̲sem, rcv̲msg, get̲blk 等）による待ち状
態も解除する。
― 待ち状態に入っていたタスクから見ると、wup̲tsk による待ち状態の解除は正常終了(E̲OK) であるのに対して、rel̲wai による待ち状態の解除
はエラー(E̲RLWAI) である。
― wup̲tsk の場合は、対象タスクがまだ slp̲tsk, wai̲tsk を実行していなくても、要求がキューイングされる。一方、rel̲wai の場合は、対象タスクが既に待ち状態に無い場合にはエラーとなる。
μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避けて性能を上げるため、タスク独立部（割込みハンドラ）から発行するシス
テムコールを、一般のタスクから発行するシステムコール rel̲wai から分離
して別システムコール irel̲wai とすることができる。OSの負担を減らし、タスク独立部から発行するシステムコールの処理を高速化するためには、
タスク独立部から発行するシステムコール irel̲wai とタスク部から発行する
システムコール rel̲wai は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール rel̲wai を発行できる方が便利である。どちらの仕様を用いるかはインプリメント側の選択項目となっている。irel̲wai をサポートする方がOSの機能が高いというわけではない。
【エラーコード(ercd)】
E̲OK正常終了
E̲CTX

コンテキストエラー（タスク部からirel̲waiを実行）

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲NOWAI

タスクが待ち状態でない（tskidが自タスクの場合を含む）

第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 80

80［3］get̲tid

自タスクのIDを得る［3］get̲tid
get̲tid:

Get Task Identifier【パラメータ】
なし【リターンパラメータ】
tskid

TaskIdentifier

タスクID

【解説】
自タスクのID番号を得る。タスク独立部から発行された場合は、tskid として FALSE (0) が返る。
【エラーコード(ercd)】
E̲OK

正常終了

第二部

μITRON2-2 4/28/98 12:28 PM ページ 81［3］tsk̲sts

81

タスクの状態を見る［3］tsk̲sts
tsk̲sts :Get Task Status【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
tskpri

TaskPriority

現在の優先度tskstat

TaskState

タスク状態

【解説】
tsk̲sts では、tskid で示された対象タスクの各種の状態を参照し、対象タ
スクの現在の優先度 tskpri、タスク状態 tskstat 等をリターンパラメータとして返す。
このシステムコールのインタフェース形式としては、パケットを利用して tskpri, tskstat 等の情報をまとめて読み出す場合と、個々の情報を別々に読み出す場合とがある。
このうち、tskstat は次のような値をとるのが標準である。
tskstat :TTS̲RUN

RUN状態

TTS̲RDY

READY状態

TTS̲WAIWAIT状態TTS̲SUSSUSPEND状態

TTS̲WAS

WAIT-SUSPEND状態

TTS̲DMT

DORMANT状態

なお、tskstat として TTS̲RUN, TTS̲WAIT 等の値が定義されているが、これは、同じ値を TCB に入れなければならないという意味ではない。TCB
内でのタスク状態の表現方法はインプリメント依存であり、tsk̲sts 実行時に、内部表現のタスク状態を TTS̲RUN, TTS̲WAIT 等の標準値に変換すれば良いわけである。

第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 82

82［3］tsk̲sts

インプリメントによっては、tskpri, tskstat 以外に次のような追加情報を参照できる場合がある。
tskatr/* タスク属性 */itskpri/* 初期優先度 */suscnt/* SUSPEND要求カウント */wupcnt/* 起床要求カウン ト */tskid = TSK̲SELF によって自タスクの指定になるが、このシステムコー
ルでは自タスクの I D はわからない。自タスクの I Dを知りたい場合は、
get̲tid を利用する。
tsk̲sts で、対象タスクが存在しない場合には、エラー E̲NOEXS となる。
【エラーコード(ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲ILADR

不正アドレス（リターンパラメータ用のパケットアドレ

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

スが使用できない値）

第二部

μITRON2-2 4/28/98 12:28 PM ページ 83

83

タスク付属同期機能

第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 84

84［3］sus̲tsk ［#3］isus̲tsk

タスクを強制待ち状態へ移行する［3］sus̲tsk

タスクを強制待ち状態へ移行する（タスク独立部専用）［#3］isus̲tsk

sus̲tsk :Suspend Task

isus̲tsk :Suspend Task (for Interrupt Handler)【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】tskid で示されたタスクの実行を中断させ、強制待ち状態に移す。強制待ち状態は、rsm̲tsk, frsm̲tsk システムコールの発行によって解除される。強
制待ち状態は、他タスクのシステムコールによる中断状態を意味するものなので、本システムコールで自タスクを指定することはできない。
sus̲tsk の要求のキューイングの有無、およびその回数の制限はインプリ
メント依存である。すなわち、既に強制待ち状態のタスクに対して sus̲tskを発行した場合に、エラー E̲QOVR となるか、多重の強制待ち状態になる
かはインプリメント依存である。後者の場合、sus̲tsk が発行された回数(suscnt) だけ rsm̲tsk を発行すると、必ずもとの状態に戻るため、sus̲tsk〜
rsm̲tsk の対をネストすることが可能である。
WAIT-SUSPEND 状態のタスクに対しても、WAIT状態のタスクと同じよ
うに資源の割り当てが行なわれる。資源が割当てられることにより、そのタスクは SUSPEND 状態に移行する。WAIT-SUSPEND 状態のタスクに対する特別措置（資源割り当て遅延など）は取らない。これは、以下のような理由による。
・システムコールの意味的な問題
S U S P E N D 状態は、他の処理とは直交した関係のものであり、第二部

μITRON2-2 4/28/98 12:28 PM ページ 85［3］sus̲tsk ［#3］isus̲tsk

85

SUSPEND の時だけ勝手に別の仕様に変えるのは良くないという考えによる。
・必要な場合は使い方の問題で対処可能であること
SUSPEND 状態のタスクの優先度を一時的に下げたいのであれば、ユーザタスクのレベルで、sus̲tsk,rsm̲tsk に chg̲pri を組み合せて発行すれば済む。
μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避けて性能を上げるため、タスク独立部（割込みハンドラ）から発行するシス
テムコールを、一般のタスクから発行するシステムコール sus̲tsk から分離
して別システムコール isus̲tsk とすることができる。OSの負担を減らし、タスク独立部から発行するシステムコールの処理を高速化するためには、
タスク独立部から発行するシステムコール isus̲tsk とタスク部から発行する
システムコール sus̲tsk は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール sus̲tsk を発行できる方が便利である。どちらの仕様を用いるかはインプリメント側の選択項目となっている。isus̲tsk をサポートする方がOSの機能が高いというわけではない。
【エラーコード(ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（タスク部からisus̲tskを実行）

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲SELF

自タスク、自プロセスの指定（tskidが自タスク、タスク部の発行でtskid=0）

E̲QOVR

キューイングのオーバーフロー（キューイング不可能、
suscntのオーバーフロー）

第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 86

86［3］rsm̲tsk ［#3］irsm̲tsk ［4］frsm̲tsk

強制待ち状態のタスクを再開する［3］rsm̲tsk

強制待ち状態のタスクを再開する（タスク独立部専用）［#3］irsm̲tsk

強制待ち状態のタスクを強制再開する［4］frsm̲tsk
rsm̲tsk :Resume Task

irsm̲tsk :Resume Task (for Interrupt Handler)frsm̲tsk :Force Resume Task

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】rsm̲tsk, irsm̲tsk, frsm̲tsk システムコールでは、tskid で示された対象タスクが sus̲tsk によって強制待ち状態に入っている場合に、その強制待ち状態を解除する。本システムコールでは、自タスクを指定することはできない。
rsm̲tsk (irsm̲tsk) システムコールでは、1回分の sus̲tsk 要求 (suscnt) を解除する。したがって、対象タスクに対して2回以上の sus̲tskが発行されていた場合 (suscnt≧2) には、rsm̲tsk の実行が終わった後も、対象タスクはまだ強制待ち状態のままである。一方、frsm̲tsk システムコールの場合は、対象
タスクに対して2回以上の sus̲tsk が発行されていた場合 (suscnt≧2) でも、
それらの要求をすべて解除して suscnt = 0 となる。すなわち、強制待ち状態は必ず解除され、対象タスクは待ち状態（二重待ち状態）でない限り実行を再開できる。
μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避け

第二部

μITRON2-2 4/28/98 12:28 PM ページ 87［3］rsm̲tsk ［#3］irsm̲tsk ［4］frsm̲tsk

87て性能を上げるため、タスク独立部（割込みハンドラ）から発行するシス
テムコールを、一般のタスクから発行するシステムコール rsm̲tsk から分離
して別システムコール irsm̲tsk とすることができる。OSの負担を減らし、タスク独立部から発行するシステムコールの処理を高速化するためには、
タスク独立部から発行するシステムコール irsm̲tsk とタスク部から発行するシステムコール rsm̲tsk は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール rsm̲tsk を発行できる方が便利である。どちらの仕様を用いるかはインプリメント側の選択項目となっている。irsm̲tsk をサポートする方がOSの機能が高いというわけではない。
【エラーコード(ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（タスク部からirsm̲tskを実行）

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲SELF

自タスク、自プロセスの指定（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲NOSUS

タスクがSUSPENDでない（インプリメント依存）第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 88

88［1］slp̲tsk ［3］wai̲tsk

タスクを待ち状態へ移行する［1］slp̲tsk

タスクを一定時間待ち状態に移行する［3］wai̲tsk
slp̲tsk:

Sleep Task

wai̲tsk:

Wait for Wakeup Task

【パラメータ】＜1＞tmout

Timeout

タイムアウト指定［＜1＞wai̲tsk のみ］【リターンパラメータ】
なし【解説】
slp̲tsk システムコールでは、自タスクを実行状態から待ち状態に移す。
この待ち状態は、本タスクを対象として発行された wup̲tsk (iwup̲tsk) シス
テムコールまたは rel̲wai (irel̲wai) システムコールにより解除される。
wai̲tsk システムコールでは、自タスクを一定時間だけ実行状態から待ち状態に移す。この待ち状態は、本タスクを対象とした wup̲tsk (iwup̲tsk) シ
ステムコールの発行、本タスクを対象とした rel̲wai (irel̲wai) システムコー
ルの発行、あるいは tmout で指定した時間の経過により解除される。wup̲tsk
が発行された場合は正常終了、時間経過の場合はタイムアウトエラー
E̲TMOUT としてリターンする。このシステムコールは、slp̲tsk システム
コールにタイムアウト機能を付けたものであり、タスクの単純な遅延に用いることができる。
wai̲tsk の tmout のビット数やデータタイプ（符号付き、符号無し）はインプ
リメント依存である。また、インプリメントによっては、tmout = TMO̲FEVR
によりタイムアウト指定が行なわれないことを示す。この場合は、wup̲tsk が発行されるまで永久に待ち状態になるため、slp̲tsk と同じ動作をする。
自タスクの指定のみであるため、slp̲tsk, wai̲tsk のネスティングは有り

第二部

μITRON2-2 4/28/98 12:28 PM ページ 89［1］slp̲tsk ［3］wai̲tsk

89

得ないが、slp̲tsk, wai̲tsk により待ち状態となっている時に、他のタスクから sus̲tsk が実行されることはある。この場合はwup̲tsk により待ち状態が解除されてもまだ強制待ち状態であり、rsm̲tsk (irsm̲tsk, frsm̲tsk) の発行までタスクの実行は再開されない。
【エラーコード(ercd)】
E̲OK

正常終了

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲ILTIME

不正時間指定（インプリメント依存）

E̲CTX

コンテキストエラー（タスク独立部から実行）

E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にrel̲waiを受け付け）

第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 90

90［1］wup̲tsk ［#1］iwup̲tsk

待ち状態のタスクを起床する［1］wup̲tsk

待ち状態のタスクを起床する（タスク独立部専用）［#1］iwup̲tsk

wup̲tsk :Wakeup Task

iwup̲tsk :Wakeup Task (for Interrupt Handler)【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】
wup̲tsk, iwup̲tsk システムコールでは、slp̲tsk または wai̲tsk システムコールの実行により待ち状態になっていたタスクを、待ち状態から実行可能状態に移す。対象タスクは、tskid で示され、自タスクを指定することはできない。
対象タスクが slp̲tsk または wai̲tsk を実行しておらず、待ち状態でない場合には、このwai̲tsk要求はキューイングされる。その場合、この wup̲tsk
要求は、後に対象タスクが slp̲tsk または wai̲tsk システムコールを実行した時に有効となる。具体的には、wup̲tsk を実行すると対象タスクの起床要
求カウントがプラス1され、対象タスクが slp̲tsk または wai̲tsk を実行すると、対象タスクの起床要求カウントがマイナス1される。起床要求カウント
が負になろうとした時に、はじめて待ち状態になる。
起床要求 (wupcnt) のキューイング数の最大値はインプリメント依存であるが、最小限1回のキューイングはできるものとする。2回以上のキューイ
ングができるかどうかは、インプリメントによって異なる。
μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避けて性能を上げるため、タスク独立部（割込みハンドラ）から発行するシス
テムコールを、一般のタスクから発行するシステムコール wup̲tsk から分

第二部

μITRON2-2 4/28/98 12:28 PM ページ 91［1］wup̲tsk ［#1］iwup̲tsk

91

離して別システムコール iwup̲tsk とすることができる。OSの負担を減らし、タスク独立部から発行するシステムコールの処理を高速化するためには、
タスク独立部から発行するシステムコール iwup̲tsk とタスク部から発行するシステムコール wup̲tsk は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール wup̲tsk
を発行できる方が便利である。どちらの仕様を用いるかはインプリメント
側の選択項目となっている。iwup̲tsk をサポートする方がOSの機能が高いというわけではない。
【エラーコード(ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（タスク部からiwup̲tskを実行）

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲SELF

自タスク、自プロセスの指定（tskidが自タスク、タスク部の発行でtskid=0）

E̲QOVR

キューイングのオーバーフロー（wupcntのオーバーフロー）

第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 92

92［3］can̲wup

タスクの起床要求を無効にする［3］can̲wup
can̲wup:

Cancel Wakeup Task

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
wupcntWakeup Count

キューイングされていた起床要求回数【解説】
can̲wup システムコールでは、tskid で示された対象タスクにキューイン
グされていた起床要求回数(wupcnt)をリターンパラメータとして返し、同時にその起床要求をすべて解除する。tskid = TSK̲SELF によって自タスクの指定になる。
このシステムコールは、周期的にタスクを起床するような処理を行う場
合に、時間内に処理が終わっているかどうか（前の起床要求に対する
slp̲tsk が実行される前に、次の起床要求が発生していないか）を判定するために利用できる。can̲wup のリターンパラメータである wupcnt が 0 でな
ければ、前の起床要求に対する処理が時間内に終了しなかったということがわかるので、それに対して何らかの処置をすることができる。
【エラーコード(ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

第二部

μITRON2-2 4/28/98 12:28 PM ページ 93

93

同期・通信機能第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 94

94［3A］set̲flg ［#3A］iset̲flg ［3A］clr̲flg

1ワードイベントフラグをセットする［3A］set̲flg

1ワードイベントフラグをセットする（タスク独立部専用）［#3A］iset̲flg

1ワードイベントフラグをクリアする

set̲flg:

Set EventFlag

iset̲flg:

Set EventFlag (for Interrupt Handler)clr̲flg:

Clear EventFlag【パラメータ】
flgid

EventFlagIdentifier

イベントフラグID＜1＞setptn

SetBitPattern

セットするビットパターン＜2＞clrptn

ClearBitPattern

クリアするビットパターン［＜1＞set̲flg のみ］［＜2＞clr̲flg のみ］【リターンパラメータ】
なし【解説】
set̲flg では、flgid で示される1ワードイベントフラグのうち、setptn で示されているビットがセットされる。すなわち、flgid で示される1ワードイベ
ントフラグの値に対して、setptn の値で論理和がとられる。また、clr̲flg では、flgid で示される1ワードイベントフラグのうち、対応する clrptn が0になっているビットがクリアされる。すなわち、flgid で示されるイベントフ
ラグの値に対して、clrptn の値で論理積がとられる。
set̲flg において、イベントフラグ値の変更の結果、そのイベントフラグ
を待っていたタスクの待ち解除条件を満たすようになれば、そのタスクが実行可能状態へと移行する。イベントフラグでは、ビット対応のイベントの OR や AND を条件として待つことができるが、そのほか、イベントフラ

第二部

μITRON2-2 4/28/98 12:28 PM ページ 95［3A］set̲flg ［#3A］iset̲flg ［3A］clr̲flg

95

グの全ビットを使用すれば、1ワードの簡単なメッセージ転送（キューイン
グ無し）を行なうこともできる。
clr̲flg では、そのイベントフラグを待っているタスクが待ち解除となることはない。すなわち、ディスパッチは起らない。
set̲flg で setptn の全ビットを0とした場合や、clr̲flg で clrptn の全ビットを1とした場合には、対象イベントフラグに対して何の操作も行わないことになる。ただし、その場合でもエラーとはならない。
同一イベントフラグに対する複数タスクの待ちも可能である。したがって、イベントフラグでもタスクが待ち行列を作ることになる。この場合、一回の set̲flg で複数のタスクが待ち解除となることがある。
μITRONの場合、イベントフラグの生成はシステム起動時に静的に行う。
また、μITRONの仕様では、1ワードイベントフラグの仕様と1ビットイベ
ントフラグの仕様の両方が用意されており、インプリメンタの側で必要な方を選択してサポートすることができる。高機能でITRON1やITRON2の仕様に近いものをインプリメントするという意味では1ワードイベントフラグ
が良く、高速で必要メモリ量の少ないものをインプリメントするという意
味では1ビットイベントフラグが良い。
μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避けて性能を上げるため、タスク独立部（割込みハンドラ）から発行するシステ
ムコールを、一般のタスクから発行するシステムコール set̲flg から分離して別システムコール iset̲flg とすることができる。OSの負担を減らし、タスク
独立部から発行するシステムコールの処理を高速化するためには、タスク独立部から発行するシステムコール iset̲flg とタスク部から発行するシステム
コール set̲flg は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール set̲flg を発行できる方が便利である。どちらの仕様を用いるかはインプリメント側の選択項目となっている。iset̲flg をサポートする方がOSの機能が高いというわけではない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（タスク部からiset̲flgを実行）

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（f l g i dのイベントフラグ
が存在しない）第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 96

96［3A］wai̲flg ［3A］pol̲flg

1ワードイベントフラグを待つ［3A］wai̲flg

1ワードイベントフラグを得る［3A］pol̲flg
wai̲flg:

Wait EventFlag

pol̲flg:

Poll EventFlag【パラメータ】
flgid

EventFlagIdentifier

イベントフラグID

waiptn

WaitBitPattern

待ちビットパターンwfmode

WaitEventFlagMode

待ちモード【リターンパラメータ】
flgptnEventFlagBitPattern

待ち解除時のビットパターン【解説】wai̲flg では、wfmode で示される待ち条件にしたがって、flgid で示されるイベントフラグがセットされるのを待つ。
wfmode では、次のような指定を行う。
wfmode : = (TWF̲ANDW‖TWF̲ORW) ｜［TWF̲CLR］
TWF̲ANDWAND待ちTWF̲ORW

OR待ち

TWF̲CLR

クリア指定

TWF̲ORW を指定した場合には、flgid で示されるイベントフラグのうち、
w a i p t nで 指 定 し た ビ ッ ト の い ず れ か が セ ッ ト さ れ る の を 待 つ 。 ま た 、TWF̲ANDW を指定した場合には、flgid で示されるイベントフラグのうち、
waiptn で指定したビットがすべてセットされるのを待つ。
TWF̲CLR の指定が無い場合には、条件が満足されてこのタスクが待ち解除となった場合にも、イベントフラグの値はそのままである。一方、TWF̲CLR の指定がある場合には、条件が満足されてこのタスクが待ち解

第二部

μITRON2-2 4/28/98 12:28 PM ページ 97［3A］wai̲flg ［3A］pol̲flg

97除となった場合、イベントフラグの値（全部のビット）を0にクリアする。
μITRONの wai̲flg ではタイムアウトの指定はできず、条件が満足されるまで永久に待つことになる。一方、待ち条件が満たされない場合でも即時にリターンするシステムコールとして、pol̲flg が用意されている。
pol̲flg システムコールのパラメータ等の意味は wai̲flg と同じである 。
pol̲flg では、待ち条件が満たされていれば正常終了となるが、待ち条件が満たされていない場合には、待ち状態に入らずにエラー E̲PLFAIL を返す。
TWF̲CLR の指定によってフラグのクリアが行われるのは、pol̲flg が正常終了した場合のみである。
flgptn は、本システムコールによる待ち状態が解除される時のイベント
フラグの値 （TWF̲CLR 指定の場合は、イベントフラグがクリアされる前の値） を示すリターンパラメータである。flgptn で返る値は、このシステ
ムコールの待ち解除の条件を満たすものになっている。
同一イベントフラグに対する複数タスクの待ちも可能である。この場合、一回の set̲flg で複数のタスクが待ち解除となることがある。イベントフラ
グでもタスクの待ち行列が定義され、次のような動作をする。
― 待ち行列の順番は FIFO である。ただし、waiptn や wfmode との関係により、必ずしも行列先頭のタスクから待ち解除になるとは限らない。
― 待ち行列中にクリア指定のタスクがあれば、そのタスクが待ち解除になる時に、フラグをクリアする。
― クリア指定を行っていたタスクよりも後ろの待ち行列にあったタスクは、
既にクリアされた後のイベントフラグを見ることになるため、待ち解除とはならない。
イベントフラグに対する複数タスク待ちの機能は、次のような場合に有効である。例えば、タスクAが＜1＞set̲flg を実行するまで、タスクB、タスクCを＜2＞＜3＞wai̲flg で待たせておく場合に、イベントフラグの複数待ちが可能であれば、＜1＞＜2＞＜3＞のどのシステムコールが先に実行されても結果は同じになる［図2.7］。一方、イベントフラグの複数待ちができなければ、＜2＞→＜3＞→＜1＞の順でシステムコールが実行された場合に、＜3＞のwai̲flgがエラーになる。

第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 98

98［3A］wai̲flg ［3A］pol̲flg［タスクA］＜1＞ set̲flg［タスクB］［タスクC］＜2＞ wai̲flg＜3＞ wai̲flg（クリア無）（クリア無）［図2.7］1ワードイベントフラグに対する複数タスク待ちの機能

waiptn を0とした場合は、set̲flg により待ち状態から抜けることができなくなるため、パラメータエラー E̲PAR とする。したがって、set̲flg で全ビットをセットした場合、待ち行列の先頭にあるタスクであれば、どのような条件でイベントフラグを待つタスクであっても待ち解除となることが保証される。
【エラーコード(ercd)】
E̲OK

正常終了

E̲RSMD

予約モード、予約オプション（wfmodeが不正）

E̲RSID

予約ID番号（インプリメント依存）E̲PAR

一般的なパラメータエラー（waiptn = 0）E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（f l g i dのイベントフラグ

E̲CTX

コンテキストエラー（タスク独立部から実行）

E̲RLWAI

待ち状態強制解除（待ちの間にrel̲waiを受け付け）

E̲PLFAIL

ポーリング失敗が存在しない）第二部

μITRON2-2 4/28/98 12:28 PM ページ 99［4A］flg̲sts

99

1ワードイベントフラグ状態を参照する［4A］flg̲sts
flg̲sts:

Get EventFlag Status【パラメータ】
flgid

EventFlagIdentifier

イベントフラグID【リターンパラメータ】
wtskidWaitTaskID

待ちタスクID

flgptnEventFlagBitPattern

イベントフラグのビットパターン【解説】flg̲sts では、flgid で示された対象イベントフラグの各種の状態を参照し、
対象イベントフラグの現在のフラグ値 flgptn、待ちタスクID番号 wtskid 等
をリターンパラメータとして返す。
このシステムコールのインタフェース形式としては、パケットを利用して flgptn, wtskid 等の情報をまとめて読み出す場合と、個々の情報を別々に読み出す場合とがある。
wtskid には、待ち行列の先頭のタスクのIDが返る。すなわち、現在このイベントフラグを待っているタスクのうち、最も早く待ち状態になったタ
スクのIDが返る。待ちタスクが無い場合は FALSE(0) が返る。
インプリメントによっては、flgptn, wtskid 以外の追加情報も参照できる
場合がある。
flg̲sts で、対象イベントフラグが存在しない場合には、エラー E̲NOEXSとなる。
【エラーコード(ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲ILADR

不正アドレス（リターンパラメータ用のパケットアドレスが使用できない値）E̲IDOVR
E̲NOEXS

ID範囲外（インプリメント依存）
オブジェクトが存在していない（f l g i dのイベントフラグ
が存在しない）第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 100

100［3B］set̲flg ［#3B］iset̲flg ［3B］clr̲flg

1ビットイベントフラグをセットする［3B］set̲flg

1ビットイベントフラグをセットする（タスク独立部専用）［#3B］iset̲flg

1ビットイベントフラグをクリアする［3B］clr̲flg
set̲flg:

Set EventFlag

iset̲flg:

Set EventFlag (for Interrupt Handler)clr̲flg:

Clear EventFlag【パラメータ】
flgid

EventFlagIdentifier

イベントフラグID【リターンパラメータ】
なし【解説】
set̲flg では、flgid で示される1ビットイベントフラグが1にセットされる。
また、clr̲flg では、flgid で示される1ビットイベントフラグが0にクリアされる。
set̲flg の場合、wai̲flg, cwai̲flg によってそのイベントフラグを待っているタスクがあれば、そのタスクの待ちを解除して実行可能状態へと移す。
一方、clr̲flg の場合は、そのイベントフラグを待っているタスクが待ち解除となることはない。すなわち、ディスパッチは起らない。
1ビットイベントフラグの場合には、ビット対応に事象を表現し、それらのOR待ちやAND待ちを行うことはできない。しかし、単純な事象のOR待ち
やAND待ちを行うのであれば、set̲flgを複数回組み合わせたり、wai̲flg や
cwai̲flg を複数回組み合わせたりすることによって実現できる場合がある。
同一イベントフラグに対する複数タスクの待ちも可能である。したがって、イベントフラグでもタスクが待ち行列を作ることになる。この場合、第二部

μITRON2-2 4/28/98 12:28 PM ページ 101［3B］set̲flg ［#3B］iset̲flg ［3B］clr̲flg

101

一回の set̲flg で複数のタスクが待ち解除となることがある。
μITRONの場合、イベントフラグの生成はシステム起動時に静的に行う。
また、μITRONの仕様では、1ワードイベントフラグの仕様と1ビットイベ
ントフラグの仕様の両方が用意されており、インプリメンタの側で必要な方を選択してサポートすることができる。高機能でITRON1やITRON2の仕様に近いものをインプリメントするという意味では1ワードイベントフラグ
が良く、高速で必要メモリ量の少ないものをインプリメントするという意
味では1ビットイベントフラグが良い。
μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避けて性能を上げるため、タスク独立部（割込みハンドラ）から発行するシス
テムコールを、一般のタスクから発行するシステムコール set̲flg から分離
して別システムコール iset̲flg とすることができる。OSの負担を減らし、タスク独立部から発行するシステムコールの処理を高速化するためには、タスク独立部から発行するシステムコール iset̲flg とタスク部から発行するシステムコール set̲flg は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール set̲flg を発行できる方が便利である。どちらの仕様を用いるかはインプリメント側の選択項目となっている。iset̲flg をサポートする方がOSの機能が高いというわけではない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（タスク部からiset̲flgを実行）

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（f l g i dのイベントフラグ
が存在しない）第二章

μITRONシステムコール

2-2 4/28/98 12:28 PM ページ 102

102［3B］wai̲flg ［3B］cwai̲flg ［3B］pol̲flg ［3B］cpol＿flg

1ビットイベントフラグを待つ（クリア無）［3B］wai̲flg

1ビットイベントフラグを待つ（クリア有）［3B］cwai̲flg

1ビットイベントフラグを得る（クリア無）［3B］pol̲flg

1ビットイベントフラグを得る（クリア有）［3B］cpol＿flg

wai̲flg:

Wait EventFlag

cwai̲flg:

Wait and Clear EventFlag

pol̲flg:

Poll EventFlag

cpol̲flg:

Poll and Clear EventFlag【パラメータ】
flgid

EventFlagIdentifier

イベントフラグID【リターンパラメータ】
なし【解説】wai̲flg, cwai̲flg では、flgidで示されるイベントフラグが1にセットされるのを待つ。
wai̲flg の場合には、イベントフラグがセットされてこのタスクが待ち解除となった場合にも、イベントフラグの値はセットされたままである。一方、cwai̲flg の場合には、イベントフラグがセットされてこのタスクが待ち解除となった場合、イベントフラグの値が0にクリアされる。
μITRONの wai̲flg, cwai̲flg ではタイムアウトの指定はできず、イベン
トフラグがセットされるまで永久に待つことになる。一方、イベントフラ
グがセットされていなくても即時にリターンするシステムコールとして、

第二部

μITRON2-2 4/28/98 12:28 PM ページ 103［3B］wai̲flg ［3B］cwai̲flg ［3B］pol̲flg ［3B］cpol＿flg

103pol̲flg, cpol̲flg が用意されている。pol̲flg, cpol̲flg システムコールのパラメータ等の意味は wai̲flg, cwai̲flg と同じである。pol̲flg, cpol̲flg では、
イベントフラグがセットされていれば正常終了となるが、イベントフラグ
がセットされていない場合には、待ち状態に入らずにエラー E̲PLFAIL を返す。cpol̲flg の場合にフラグのクリアが行われるのは、正常終了した場
合のみである。なお、cpol̲flg ではイベントフラグがセットされていた場合にそれをクリアするのに対して、pol̲flg では単にイベントフラグの値の参照のみを行う。したがって、pol̲flg の機能は次の flg̲sts で代用可能であるが、パラメータの整理と対称性のために別システムコールとなっている。
同一イベントフラグに対する複数タスクの待ちも可能である。この場合、一回の set̲flg で複数のタスクが待ち解除となることがある。イベントフラ
グでもタスクの待ち行列が定義され、次のような動作をする。
― 待ち行列の順番は FIFO である。1ビットイベントフラグの場合には、必ず行列先頭のタスクから待ち解除になる。
― 待ち行列中にクリア指定のタスク（cwai̲flgで待っているタスク）があれば、そのタスクが待ち解除になる時に、フラグをクリアする。
― クリア指定を行っていたタスクよりも後ろの待ち行列にあったタスクは、
既にクリアされた後のイベントフラグを見ることになるため、待ち解除とはならない。
1ビットイベントフラグでは、set̲flg が実行された場合に、待ち行列の先頭にあるタスクは必ず待ち解除となる。
イベントフラグに対する複数タスク待ちの機能は、次のような場合に有効である。例えば、タスクAが＜1＞set̲flg を実行するまで、タスクB、タスクCを＜2＞＜3＞wai̲flg で待たせておく場合に、イベントフラグの複数待ちが可能であれば、＜1＞＜2＞＜3＞のどのシステムコールが先に実行されても結果は同じになる［図2.8］。一方、イベントフラグの複数待ちができなければ、＜2＞→＜3＞→＜1＞の順でシステムコールが実行された場合に、＜3＞のwai̲flgがエラーになる。

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 104

104［3B］wai̲flg ［3B］cwai̲flg ［3B］pol̲flg ［3B］cpol＿flg［タスクA］＜1＞ set̲flg［タスクB］［タスクC］＜2＞ wai̲flg＜3＞ wai̲flg（クリア無）（クリア無）［図2.8］1ビットイベントフラグに対する複数タスク待ちの機能【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（f l g i dのイベントフラグ
が存在しない）E̲CTX

コンテキストエラー（タスク独立部から実行）

E̲RLWAI

待ち状態強制解除（待ちの間にrel̲waiを受け付け）

E̲PLFAIL

ポーリング失敗第二部

μITRON2-2 4/28/98 12:29 PM ページ 105［4B］flg̲sts

105

1ビットイベントフラグ状態を参照する［4B］flg̲sts
flg̲sts:

Get EventFlag Status【パラメータ】
flgid

EventFlagIdentifier

イベントフラグID【リターンパラメータ】
wtskidWaitTaskID

待ちタスクID

flgptnEventFlagBitPattern

イベントフラグのビットパターン【解説】flg̲sts では、flgid で示された対象イベントフラグの各種の状態を参照し、
対象イベントフラグの現在のフラグ値 flgptn（1ビット）、待ちタスクID番号
wtskid 等をリターンパラメータとして返す。
このシステムコールのインタフェース形式としては、パケットを利用して flgptn, wtskid 等の情報をまとめて読み出す場合と、個々の情報を別々に読み出す場合とがある。
wtskid には、待ち行列の先頭のタスクのIDが返る。すなわち、現在このイベントフラグを待っているタスクのうち、最も早く待ち状態になったタ
スクのIDが返る。待ちタスクが無い場合は FALSE (0) が返る。
インプリメントによっては、flgptn, wtskid 以外の追加情報も参照できる
場合がある。
flg̲sts で、対象イベントフラグが存在しない場合には、エラー E̲NOEXSとなる。
【エラーコード(ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲ILADR

不正アドレス（リターンパラメータ用のパケットアドレス

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（f l g i dのイベントフラグが使用できない値）

が存在しない）第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 106

106［1］sig̲sem ［#1］isig̲sem

セマフォに対する信号操作（V命令）［1］sig̲sem

セマフォに対する信号操作（タスク独立部専用）［#1］isig̲sem

sig̲sem:Signal Semaphoreisig̲sem:

Signal Semaphore (for Interrupt Handler)【パラメータ】
semid

SemaphoreIdentifier

セマフォID【リターンパラメータ】
なし【解説】
semidで示されたセマフォに対して待っているタスクがあれば、待ち行列の先頭のタスクを実行可能状態にする。セマフォに対して待っているタス
クが無ければ、そのセマフォのカウント値 (semcnt) を1だけ増やす。
セマフォのカウント値の増加により、カウント値がシステム起動時のカ
ウント値 (isemcnt) を越えた場合にも、エラーとはしない。これは、資源管理ではなく、同期の目的（wup̲tsk〜slp̲tsk と同様）でセマフォを使用することを想定しているためである。また、セマフォを一旦生成した後で、資源数を動的に再設定したい場合にも、カウント値が初期値を越える場合がある。なお、セマフォのカウント値 (semcnt) がインプリメントの都合による上限値を越えた場合には、エラー E̲QOVR を返す。
μITRONの場合、セマフォの生成はシステム起動時に静的に行う。セマ
フォ生成時に必要なセマフォ初期値 (isemcnt) などのパラメータも、システ
ム起動時に静的に指定する。
μITRONのセマフォの場合、待ちタスクのキューイング方法はFIFO(TA̲TFIFO)とするのが標準である。ただし、インプリメントによっては、タスク優先度順 (TA̲TPRI) のキューイング方法を選択できるようになっていても良い。また、μITRONの wai̲sem では資源要求数 (rcnt) が1に固第二部

μITRON2-2 4/28/98 12:29 PM ページ 107［1］sig̲sem ［#1］isig̲sem

107

定されているので、ITRON2における TA̲FIRST（行列先頭のタスクを優先扱い）と TA̲CNT（要求数の少ないタスクを優先扱い）の区別は意味を持たない。
μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避けて性能を上げるため、タスク独立部（割込みハンドラ）から発行するシス
テムコールを、一般のタスクから発行するシステムコール sig̲sem から分離
して別システムコール isig̲sem とすることができる。OSの負担を減らし、タスク独立部から発行するシステムコールの処理を高速化するためには、
タスク独立部から発行するシステムコール isig̲sem とタスク部から発行するシステムコール sig̲sem は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール sig̲semを発行できる方が便利である。どちらの仕様を用いるかはインプリメント
側の選択項目となっている。isig̲sem をサポートする方がOSの機能が高いというわけではない。
isig̲sem のシステムコールをタスク部から発行した場合には、システムコールの意味的な間違いであるという意味で E̲CTX のエラーを返すのが望ましい。また、isig̲sem のシステムコール全体が実装されていない場合には、E̲RSFN のエラーを返すのが望ましい。具体的には、インプリメントに依存して［表2.1］の＜1＞〜＜4＞のいずれかの動作をすることになる。
iset̲flg, isnd̲msg なども同様である。

タスク部から発行

タスク独立部から発行

sig̲sem ＜1＞E̲RSFN＜2＞実行可能＜1＞E̲RSFN＜2＞実行可能＜3＞E̲XNOSPT＜4＞E̲CTX

isig̲sem ＜1＞E̲RSFN＜2＞E̲CTX＜1＞E̲RSFN＜2＞実行可能［表2.1］sig̲sem,isig̲semの返すエラー

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 108

108［1］sig̲sem ［#1］isig̲sem【エラーコード (ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（タスク部からisig̲semを実行）

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（ semidのセマフォが存在しない）

E̲QOVR

キューイングのオーバーフロー（semcntのオーバーフロー）

第二部

μITRON2-2 4/28/98 12:29 PM ページ 109［1］wai̲sem ［1］preq̲sem

109

セマフォに対する待ち操作（P命令）［1］wai̲sem

セマフォ資源を得る［1］preq̲sem
wai̲sem:

Wait on Semaphorepreq̲sem:

Poll and Request Semaphore【パラメータ】
semid

SemaphoreIdentifier

セマフォID【リターンパラメータ】
なし【解説】
wai̲sem では、semid で示されたセマフォのカウント値 (semcnt) が1以上の場合、セマフォのカウント値を1だけ減じて、本システムコールの発行タ
スクは実行を継続する。セマフォのカウント値が0の場合は、セマフォのカ
ウント値は変更せず、本システムコールを発行したタスクはそのセマフォに対する待ち行列につながれる。待ち行列へのつながれ方はFIFOが標準である。
μITRONの wai̲sem ではタイムアウトの指定はできず、条件が満足されるまで永久に待つことになる。一方、待ち条件が満たされない場合でも即時にリターンするシステムコールとして、preq̲sem が用意されている。
preq̲sem システムコールでは、semid で示されたセマフォのカウント値が1以上の場合、セマフォのカウント値を1だけ減じて、本システムコールの発行タスクは正常終了する。セマフォのカウント値が0の場合は、待ち状態に入らずにエラー E̲PLFAIL を返す。この場合、セマフォのカウント値は0のままである。
preq̲sem の機能は、ITRON2では wai̲sem (tmout=TMO̲POL) の指定により実現される機能であるが、μITRONの場合は wai̲sem でタイムアウトの指定ができないため、別システムコール preq̲sem に分離している。なお、

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 110

110［1］wai̲sem ［1］preq̲sem

sem̲sts が単にセマフォ値を参照するシステムコールであるのに対して、
preq̲sem の場合は、資源を獲得できる時は獲得してしまう（セマフォのカ
ウント値が正であれば1だけ減じる）という点が異なっている。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（semidのセマフォが存在
しない）

E̲CTX

コンテキストエラー（タスク独立部から実行）

E̲RLWAI

待ち状態強制解除（待ちの間にrel̲waiを受け付け）

E̲PLFAIL

ポーリング失敗第二部

μITRON2-2 4/28/98 12:29 PM ページ 111［4］sem̲sts

111

セマフォ状態を参照する［4］sem̲sts
sem̲sts:

Get Semaphore Status【パラメータ】
semid

SemaphoreIdentifier

セマフォID【リターンパラメータ】
wtskidWaitTaskID

待ちタスクID

semcntSemaphoreCount

現在のセマフォカウント値【解説】
sem̲sts では、semid で示された対象セマフォの各種の状態を参照し、対象セマフォの現在のカウント値semcnt、待ちタスク ID番号 wtskid等をリタ
ーンパラメータとして返す。
このシステムコールのインタフェース形式としては、パケットを利用して semcnt, wtskid 等の情報をまとめて読み出す場合と、個々の情報を別々に読み出す場合とがある。
wtskid には、待ち行列の先頭のタスクのIDが返る。すなわち、待ち行列へのつながれ方がFIFOの場合には、現在このセマフォを待っているタスクのうち、最も早く待ち状態になったタスクのIDが返る。待ちタスクの無い
時は FALSE (0) が返る。semcnt と wtskid の少なくとも一方は0となる。
インプリメントによっては、semcnt, wtskid 以外の追加情報も参照できる
場合がある。
sem̲sts で、対象セマフォが存在しない場合には、エラーE̲NOEXS となる。
【エラーコード(ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲ILADR

不正アドレス（リターンパラメータ用のパケットアドレス

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（ semidのセマフォが存在が使用できない値）

しない）

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 112

112［2］snd̲msg ［#2］isnd̲msg

メイルボックスへ送信する［2］snd̲msg

メイルボックスへ送信する（タスク独立部専用）［#2］isnd̲msg

snd̲msg:

Send Message to Mailbox

isnd̲msg:

Send Message to Mailbox (for Interrupt Handler)【パラメータ】
mbxid

MailboxIdentifier メイルボックスID

pk̲msgMessagePacket

送信メッセージの先頭アドレス【リターンパラメータ】
なし【解説】
mbxidで示された対象メイルボックスに、pk̲msg のアドレスに入っているメッセージを送信する。メッセージの内容はコピーされず、受信時にはアドレス（pk̲msgの値）のみが渡される。
対象メイルボックスでメッセージを待つタスクがない時に snd̲msg が発行されても、snd̲msg 発行タスクは待ち状態とはならない。このシステム
コールでは、メッセージをメイルボックスに入れ、メッセージキューと呼ぶ待ち行列につなぐだけで、タスクはその先の実行を続ける。つまり、非同期のメッセージ送信を行なう。また、待ち行列につながれるのは、そのタスクの発行したメッセージであって、タスクそのものではない。すなわ
ち、メッセージの待ち行列（キュー）、受信タスクの待ち行列は存在するが、送信タスクの待ち行列は存在しない。
メッセージキューをリングバッファによって実現するか、線形リストによって実現するかはインプリメント依存である。メッセージキューをリン
グバッファによって実現した場合に、リングバッファが一杯になってメッ
セージのキューイングができなくなっても、snd̲msg 発行タスクは待ち状
態とはならない。この場合、snd̲msg 発行タスクは E̲QOVR のエラーを返第二部

μITRON2-2 4/28/98 12:29 PM ページ 113［2］snd̲msg ［#2］isnd̲msg

113

pk̲msgメッセージヘッダ（有無や内容はインプリメント依存）
メッセージの内容［図2.9］μITRONにおけるメッセージの形式

して即座にリターンする。
一方、メッセージキューを線形リストによって実現した場合、メッセー
ジブロックの中に、 OSで用いるキューのリンク用エリアが必要となる。したがって、OSの管理用として、ユーザの用意したメッセージブロックの一部を使用することがある。この部分を、メッセージヘッダと呼ぶ。この場
合、pk̲msg は、メッセージヘッダをも含めたメッセージブロックの先頭ア
ドレスを表わす［図2.9］。ユーザが実際にメッセージを入れることができるのは、pk̲msg の直後からではなく、メッセージヘッダの後の部分からとなる。メッセージヘッダの有無や大きさはインプリメント依存である。
μITRONの場合、メイルボックスの生成はシステム起動時に静的に行う。
メイルボックス生成時に必要なパラメータ（メイルボックス属性など）がある場合にも、システム起動時に静的に指定する。
μITRONのメイルボックスの場合、待ちタスクとメッセージのキューイ
ング方法はFIFO (TA̲TFIFO, TA̲MFIFO) とするのが標準である。ただし、インプリメントによっては、タスク優先度順 (TA̲TPRI) やメッセージ優先度順(TA̲MPRI)のキューイング方法を選択できるようになっていても良い。
これらの選択を行う場合には、システム起動時のメイルボックス生成の際に指定するメイルボックス属性 (mbxatr) を利用する。メッセージ優先度順の属性とした場合には、メッセージヘッダの中で各メッセージの優先度(msgpri) の指定を行う。
μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避けて性能を上げるため、タスク独立部（割込みハンドラ）から発行するシステ

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 114

114［2］snd̲msg ［#2］isnd̲msg

ムコールを、一般のタスクから発行するシステムコール snd̲msg から分離
して別システムコール isnd̲msg とすることができる。OSの負担を減らし、タスク独立部から発行するシステムコールの処理を高速化するためには、
タスク独立部から発行するシステムコール isnd̲msg とタスク部から発行するシステムコール snd̲msg は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール
snd̲msg を発行できる方が便利である。どちらの仕様を用いるかはインプリメント側の選択項目となっている。isnd̲msg をサポートする方がOSの機能が高いというわけではない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（タスク部からisnd̲msgを実行）

E̲RSID

予約ID番号（インプリメント依存）

E̲ILADR

不正アドレス（pk̲msgが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILMSG

不正メッセージ形式（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（ mbxidのメイルボックスが存在しない）E̲QOVR

キューイングのオーバーフロー（メッセージキューのオーバーフロー）第二部

μITRON2-2 4/28/98 12:29 PM ページ 115［2］rcv̲msg ［2］prcv̲msg

115

メイルボックスからの受信を待つ［2］rcv̲msg

メイルボックスから受信する［2］prcv̲msg
rcv̲msg:

Receive Message from Mailbox

prcv̲msg:

Poll and Receive Message from Mailbox【パラメータ】
mbxid

MailboxIdentifier メイルボックスID【リターンパラメータ】
pk̲msgMessagePacket

受信メッセージの先頭アドレス【解説】rcv̲msg では、mbxid で示されたメイルボックスからメッセージを受信し、受信したメッセージの先頭アドレスをリターンパラメータとして返す。まだそのメイルボックスにメッセージが到着していない場合には、本システ
ムコール発行タスクはメッセージ到着を待つ待ち行列につながれる。待ち行列へのつながれ方はFIFOが標準である。
pk̲msg は、メッセージヘッダ（OSで使用する予約領域など）をも含めたメッセージブロックの先頭アドレスである。ユーザが実際にメッセージを入れることができるのは、メッセージヘッダの後の部分であるが、メッセージヘッダの有無や大きさはインプリメント依存である。
μITRONの rcv̲msg ではタイムアウトの指定はできず、メッセージが受信できるまで永久に待つことになる。一方、まだメッセージが到着していない場合にも即時にリターンするシステムコールとして、prcv̲msg が用意されている。prcv̲msg システムコールでは、対象メイルボックスに既にメッセージが有る場合には、そのメッセージを受信して正常終了する。メッセージが無い場合には、待ち状態に入らずにエラー E̲PLFAIL を返す。
prcv̲msg の機能は、ITRON2では rcv̲msg (tmout=TMO̲POL) の指定により実現される機能であるが、μITRONの場合は rcv̲msg でタイムアウトの第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 116

116［2］rcv̲msg ［2］prcv̲msg

指定ができないため、別システムコール prcv̲msg に分離している。なお、
mbx̲sts を利用しても次に受信されるべきメッセージを知ることは可能であるが、prcv̲msg の場合は、メッセージが受信できる時には受信してしまう（先頭のメッセージをメッセージキューから削除する）という点が異なっている。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（ mbxidのメイルボックス

E̲CTX

コンテキストエラー（タスク独立部から実行）が存在しない）E̲RLWAI

待ち状態強制解除（待ちの間にrel＿waiを受け付け）

E̲PLFAIL

ポーリング失敗第二部

μITRON2-2 4/28/98 12:29 PM ページ 117［4］mbx̲sts

117

メイルボックス状態を参照する［4］mbx̲sts
mbx̲sts:

Get Mailbox Status【パラメータ】
mbxid

MailboxIdentifier メイルボックスID【リターンパラメータ】
wtskidWaitTaskID

待ちタスクIDpk̲msgMessagePacket

次のメッセージの先頭アドレス【解説】mbx̲sts では、mbxid で示された対象メイルボックスの各種の状態を参照
し、次に受信されるメッセージの先頭アドレス pk̲msg、待ちタスクID番号
wtskid 等をリターンパラメータとして返す。
このシステムコールのインタフェース形式としては、パケットを利用して pk̲msg, wtskid 等の情報をまとめて読み出す場合と、個々の情報を別々に読み出す場合とがある。
wtskid には、待ち行列の先頭のタスクのIDが返る。すなわち、待ち行列へのつながれ方がFIFOの場合には、現在このメイルボックスでメッセージ
を待っているタスクのうち、最も早く待ち状態になったタスクのIDが返る。
待ちタスクの無い時は FALSE (0) が返る。
pk̲msg には、次に受信されるメッセージの先頭アドレスが返る。直後に
rcv̲msg を実行した場合には、同じ値が pk̲msgとして戻される。メッセー
ジが無い時は、pk̲msg は NADR (-1) となる。また、どんな場合でも、
pk̲msg=NADR と wtskid=FALSE の少なくても一方は必ず成り立つ。
インプリメントによっては、pk̲msg, wtskid 以外の追加情報も参照でき
る場合がある。また、pk̲msg の代りに、まだ受信されていないメッセージの個数を参照できる場合もある。
mbx̲sts で、対象メイルボックスが存在しない場合には、エラー E̲NOEXS
となる。

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 118

118［4］mbx̲sts【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲ILADR

不正アドレス（リターンパラメータ用のパケットアドレスが使用できない値）E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（mbxidのメイルボックスが存在しない）第二部

μITRON2-2 4/28/98 12:29 PM ページ 119［5］snd̲tmb ［#5］isnd̲tmb

119

タスク付属メイルボックスへ送信する［5］snd̲tmb

タスク付属メイルボックスへ送信する（タスク独立部専用）［#5］isnd̲tmb

snd̲tmb:

Send Message to Task Mailbox

isnd̲tmb:

Send Message to Task Mailbox (for Interrupt Handler)【パラメータ】
tskid

TaskIdentifier

送信先タスクID

pk̲msgMessagePacket

送信メッセージの先頭アドレス【リターンパラメータ】
なし【解説】tskidで指定したタスクに付属するメイルボックスに、pk̲msg のアドレスに入っているメッセージを送信する。メッセージの内容はコピーされず、受信時にはアドレス（pk̲msgの値）のみが渡される。送信されたメッセージ
は、FIFO でキューイングされる。
メッセージのキューをリングバッファによって実現するか、線形リスト
によって実現するかはインプリメント依存である。メッセージキューをリ
ングバッファによって実現した場合に、リングバッファが一杯になってメッセージのキューイングができなくなっても、snd̲tmb 発行タスクは待ち状
態とはならない。この場合、snd̲tmb発行タスクは E̲QOVR のエラーを返して即座にリターンする。
タスク付属メイルボックスの機能は、ITRON1やITRON2ではサポートしていない。μITRONの独自機能である。
μITRONでは、OS内部でコンテキストを判断するオーバーヘッドを避けて性能を上げるため、タスク独立部（割込みハンドラ）から発行するシステ
ムコールを、一般のタスクから発行するシステムコール snd̲tmb から分離
して別システムコール isnd̲tmb とすることができる。OSの負担を減らし、

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 120

120［5］snd̲tmb ［#5］isnd̲tmb

タスク独立部から発行するシステムコールの処理を高速化するためには、
タスク独立部から発行するシステムコール isnd̲tmb とタスク部から発行するシステムコール snd̲tmb は分離されている方が良い。一方、ユーザから見ると、タスク部からもタスク独立部からも共通のシステムコール snd̲tmbを発行できる方が便利である。どちらの仕様を用いるかはインプリメント
側の選択項目となっている。isnd̲tmb をサポートする方がOSの機能が高いというわけではない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（タスク部からisnd̲tmbを実行）

E̲RSID

予約ID番号（インプリメント依存）

E̲ILADR

不正アドレス（pk̲msgが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILMSG

不正メッセージ形式（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（ t s k i dのタスクが存在

E̲QOVR

キューイングのオーバーフロー（メッセージキューのしない）
オーバーフロー）第二部

μITRON2-2 4/28/98 12:29 PM ページ 121［5］rcv̲tmb ［5］prcv̲tmb

121

タスク付属メイルボックスからの受信を待つ［5］rcv̲tmb

タスク付属メイルボックスから受信する［5］prcv̲tmb
rcv̲tmb:

Receive Message from Task Mailbox

prcv̲tmb:

Poll and Receive Message from Task Mailbox【パラメータ】
なし【リターンパラメータ】
pk̲msgMessagePacket

受信メッセージの先頭アドレス【解説】
rcv̲tmb では、タスク付属メイルボックスからメッセージを受信し、受信したメッセージの先頭アドレスをリターンパラメータとして返す。タスク付属メイルボックスにまだメッセージが到着していない場合には、本シ
ステムコール発行タスクはメッセージ待ち状態となる。なお、本システム
コールでメッセージを待つメイルボックスはタスク付属のものなので、それに対して待ち状態となるタスクは、高々一つだけである。したがって、
rcv̲tmb では、メッセージ待ちのタスクが待ち行列を作ることはない。
rcv̲tmb ではタイムアウトの指定はできず、メッセージが受信できるまで永久に待つことになる。その代り、まだメッセージが到着していない場
合にも即時にリターンするシステムコールとして、prcv̲tmb が用意されている。prcv̲tmb システムコールでは、既にメッセージが到着している場合には、そのメッセージを受信して正常終了する。メッセージが無い場合には、待ち状態に入らずにエラー E̲PLFAIL を返す。
なお、tmb̲sts を利用しても次に受信されるべきメッセージを知ることは可能であるが、prcv̲tmb の場合は、メッセージが受信できる時には受信してしまう（先頭のメッセージをメッセージキューから削除する）という点が本質的に異なっている。

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 122

122［5］rcv̲tmb ［5］prcv̲tmb【エラーコード (ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（タスク独立部から実行）

E̲RLWAI

待ち状態強制解除（待ちの間にrel̲waiを受け付け）

E̲PLFAIL

ポーリング失敗第二部

μITRON2-2 4/28/98 12:29 PM ページ 123［5］tmb̲sts

123

タスク付属メイルボックスの状態を参照する［5］tmb̲sts
tmb̲sts:

Get Task Mailbox Status【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
tmbwait

Task Mailbox Wait

タスク付属メイルボックス待ち状態

pk̲msgMessagePacket

次のメッセージの先頭アドレス【解説】tmb̲sts では、tskid で示されたタスクに付属するメイルボックスの各種の状態を参照し、待ちタスクの有無 tmbwait、次に受信されるメッセージの先頭アドレス pk̲msg 等をリターンパラメータとして返す。
tmbwait は、ブール値を返すリターンパラメータである。tskid で示されるタスクがタスク付属メイルボックスを待っている状態の時には、
t m b w a i t に T R U E（0でない値、標準は1）が 返 り 、 そ う で な い 時 に はFALSE(0) が返る。タスク付属メイルボックスの場合、待ちタスクの I Dを知ることには意味が無いので、他のシステムコール（ s e m ̲ s t s , m b x ̲ s t sなど）の wtskid に相当するリターンパラメータがブール値の tmbwait となっている。
pk̲msg には、次に受信されるメッセージの先頭アドレスが返る。tskidで示されるタスクが直後に rcv̲tmbを実行した場合には、同じ値が pk̲msg
として戻される。メッセージが無い時は、pk̲msg は NADR (-1) となる。また、どんな場合でも、pk̲msg = NADR と tmbwait = FALSE の少なくても一方は必ず成り立つ。
このシステムコールのインタフェース形式としては、パケットを利用して tmbwait, pk̲msg 等の情報をまとめて読み出す場合、個々の情報を別々に読み出す場合のほか、tmbwait の情報をpk̲msg やリターン値（エラーコード）にエンコードして読み出す場合がある。
インプリメントによっては、tmbwait, pk̲msg 以外の追加情報も参照でき

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 124

124［5］tmb̲sts

る場合がある。また、pk̲msg の代りに、まだ受信されていないメッセージの個数を参照できる場合もある。
【エラーコード(ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲ILADR

不正アドレス（リターンパラメータ用のパケットアドレスが使用できない値）E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（ t s k i dのタスクが存在
しない）

第二部

μITRON2-2 4/28/98 12:29 PM ページ 125

125

割込み管理機能第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 126

126［#1］def̲int

割込みハンドラを定義する［#1］def̲int
def̲int:

Define Interrupt Handler【パラメータ】
intno

InterruptNumber

割込み番号

inthdrInterruptHandlerAddress

割込みハンドラアドレス【リターンパラメータ】
なし【解説】
割込みハンドラを定義し、使用可能にする。すなわち、inthdr で示される割込みハンドラのアドレスと、intno で示される割込み番号との対応付けを行なう。
intnoの具体的な意味はプロセッサ依存であり、割込みベクトル番号、割込みデバイス番号などを表わす。また、プロセッサによっては、これ以外のパラメータ（割込みハンドラの属性やハンドラ起動時の割込みマスクの値など）の指定も行う場合がある。
ITRONやμITRONでは、原則として、割込みハンドラの起動時にはOSが介入しない。割込み発生時には、ハードウエアの割込み処理メカニズムにより、このシステムコールで定義した割込みハンドラが直接起動される。
したがって、割込みハンドラで使用するレジスタの退避と復帰は、ユーザが責任をもって行なう必要がある。
割込みハンドラは、ret̲int 等のシステムコール、またはアセンブラの割込みリターン命令により終了する。
割込みハンドラ内のシステムコール発行によりタスクのディスパッチ
を生じた場合は、割込みハンドラが終了して ret̲int 等のシステムコール
により O Sにコントロールが戻ってくるまで、ディスパッチを遅らせるのが原則である。したがって、割込みハンドラ内でディスパッチを生ずる可能性がある場合、一般には、アセンブラの割込みリターン命令ではなく、必ず ret̲int システムコールを使って割込みハンドラから復帰する必第二部

μITRON2-2 4/28/98 12:29 PM ページ 127［#1］def̲int

127

要がある。
inthdr = NADR (-1) とした場合には、前に定義した割込みハンドラの定義解除になる。ただし、def̲intのシステムコールインタフェースがパケットを使っており、しかも、定義解除の対象を指定するパラメータ (intno) がパケットに含まれていない場合には、パケットアドレス= NADR (-1) によって定義解除を行うこともある。
def̲int によって割込みハンドラを再定義する場合でも、あらかじめ前のハンドラの定義解除を行なっておく必要はない。既に割込みハンドラが定義された intno に対して直接新しいハンドラを定義しても、エラーにはならない。
割込みハンドラはタスク独立部として実行される。したがって、割込
みハンドラの中では、待ちとなるシステムコールや、tskid = TSK̲SELF
によって自タスクの指定を意味するシステムコールは実行することはできない。
割込みハンドラ内において使用可能なシステムコールは、インプリメン
ト依存である。また、μITRONの場合は、インプリメント依存の仕様として、次のような制限を設けることも許している。
― あるシステムコールをタスク独立部（割込みハンドラ）のみから発行できるように制限する。
― タスク部から発行するシステムコールとタスク独立部（割込みハンドラ）から発行するシステムコールを分離することによって、性能を上げる。
すなわち、ITRONではタスク部発行とタスク独立部発行のシステムコー
ルで同一の名称を使用しているのに対して、μITRONでは別名称を使っても良い。この場合、タスク部から発行するシステムコールの名称がXXX̲YYY であれば、タスク独立部から発行するシステムコールの名称
は iXXX̲YYY となる。
μITRONでは、割込みハンドラを定義する機能が必須である。しかし、
割込みハンドラの定義は、このシステムコールを使って動的に行う必要はなく、オブジェクトの生成と同様に、システム起動時に静的に行うこともできる。つまり、他の方法で割込みハンドラを定義することが可能であれ
ば、必ずしもこのシステムコールをサポートする必要は無い。

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 128

128［#1］def̲int【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足（インプリメント依存）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSATR

予約属性（インプリメント依存）E̲PAR

一般的なパラメータエラー（インプリメント依存）

E̲ILADR

不正アドレス（inthdrが使用できない値）

E̲VECN

不正ベクトル番号（インプリメント依存）第二部

μITRON2-2 4/28/98 12:29 PM ページ 129［#1］ret̲int

129

割込みハンドラから復帰する［#1］ret̲int
ret̲int:

Return from Interrupt Handler【パラメータ】
なし【リターンパラメータ】※ システムコールを発行したコンテキストには戻らない【解説】
割込みハンドラからのリターンの際に発行するシステムコールである。
ITRONやμITRONでは、原則として、割込みハンドラの中でシステムコールを実行してもディスパッチは起らず、このシステムコールが発行されて割込みハンドラを抜けるまで、ディスパッチが遅延させられる。ただし、
μITRONの場合、プロセッサのアーキテクチャや多重割込みの扱い方によっては、必ずしも遅延ディスパッチの原則が適用されるとは限らない。
このシステムコールを呼び出した時の状態（スタック、レジスタ等）は、割込みハンドラへ入った時の状態と同じでなければいけない。すなわち、割込み
ハンドラで使用するレジスタの退避や復帰は、ユーザが行わなければならない。
また、レジスタの復帰をユーザが行なう関係で、このシステムコールでは機能コードを使用できないことがある。したがって、このシステムコー
ルの呼び出しの際、一般には、他のシステムコールとは別ベクトルのトラップ命令を用いる。
割込みハンドラから戻っても、必ず同じタスクが実行を継続することがわかっている場合には、ret̲intではなくアセンブラのリターン命令によって割込みハンドラから戻っても構わない。
【エラーコード】※次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、シス
テムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合の動作は、インプリメント依存となる。
E̲CTX

コンテキストエラー（タスク部から実行）

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 130

130［3］ret̲wup

割込処理復帰とタスク起床を行う［3］ret̲wup
ret̲wup:

Return and Wakeup Task

【パラメータ】
tskid

TaskIdentifier

起床タスクID【リターンパラメータ】※ システムコールを発行したコンテキストには戻らない【解説】
割込みハンドラからリターンし、同時に tskid で示される割込み処理タス
ク（slp̲tsk, wai̲tsk で待っているタスク）を起床する。
ret̲wup において、対象タスクがまだ slp̲tsk, wai̲tsk を実行していない場
合には、要求がキューイングされる。
なお、ITRONやμITRONにおいて、ハンドラの終わりを示すシステムコ
ールは、すべて 'ret' を付けるということで統一している。また、元のコンテキストに戻らないシステムコールは、すべて ret̲XXX または ext̲XXX(exd̲XXX) の名称となっている。
【エラーコード】※ 次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、
システムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合の動作は、インプリメント依
存となる。
E̲CTX

コンテキストエラー（タスク部から実行）

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲QOVR

キューイングのオーバーフロー（wupcntのオーバーフロー）

第二部

μITRON2-2 4/28/98 12:29 PM ページ 131［#5］def̲rst

131

タスクリスタートアドレスを定義する［#5］def̲rst
def̲rst:Define TaskRestartAddress【パラメータ】
tskid

TaskIdentifier

タスクID

rstadrRestartAddress

タスクリスタートアドレス【リターンパラメータ】
なし【解説】tskidで指定したタスクのリスタートアドレスを定義する。ここで定義したアドレスは、ret̲rst システムコール実行時に使用される。
タスクリスタート機能は、割込み処理からの戻り時に ret̲rst を実行する
ことにより、指定タスクを指定アドレスから実行再開する機能である。この機能は、実行再開を指定されたタスクから見ると、一種の例外処理（ソフトウエアによる強制例外）に相当するが、簡単な仕様にして高速化することを狙うため、μITRONでは例外処理と別扱いにしている。
この機能は、例えば、フォールトトレラントの目的で、実行プログラムをチェックポイントまで戻したいような場合に利用する。
対象タスクがDORMANT状態であっても、タスクリスタートアドレスを定義することが可能である。
タスクリスタートの機能は、ITRON1やITRON2ではサポートしていない。
μITRONの独自機能である。
タスクリスタートの機能を提供する場合でも、タスクリスタートアドレ
スの定義は、このシステムコールを使って動的に行う必要はなく、オブジ
ェクトの生成と同様に、システム起動時に静的に行う（タスクの属性の一つとして指定する）ことができる。つまり、他の方法でタスクリスタートア
ドレスを定義することが可能であれば、このシステムコールをサポートする必要は無い。この点は、def̲int 等と同様である。

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 132

132［#5］def̲rst【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足（インプリメント依存）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（ t s k i dのタスクが存在

E̲ILADR

不正アドレス（rstadrが使用できない値）

しない）

第二部

μITRON2-2 4/28/98 12:29 PM ページ 133［5］ret̲rst

133

割込処理復帰とタスクリスタートを行う［5］ret̲rst
ret̲rst:Return and Restart Task

【パラメータ】
tskid

TaskIdentifier

リスタートタスクID【リターンパラメータ】※ システムコールを発行したコンテキストには戻らない【解説】
割込みハンドラからリターンし、同時に tskid で指定されたタスクをリスタートさせる。
tskidで指定された対象タスクは、これ以前に、システム起動時の静的な指定あるいは def̲rst システムコールによって、リスタートアドレス rstadrを定義している。このシステムコールでは、対象タスクのプログラムカウ
ンタを rstadr に変更する。
tskidで指定されたタスクが待ち状態であった場合には、待ち状態が強制解除される。これは、割込みハンドラが、slp̲tsk 等による割込み待ちタス
クに対して、ret̲wup による実行再開と、ret̲rst による実行再開の二つの処理を指示する可能性があるためである。
【エラーコード】※ 次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、
システムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合の動作は、インプリメント依
存となる。
E̲CTX

コンテキストエラー（タスク部から実行）

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 134

134［2A］dis̲int

割込みを禁止する［2A］dis̲int
dis̲int:

Disable Interrupt【パラメータ】
intno

InterruptNumber

割込み番号【リターンパラメータ】
なし【解説】
割込み番号 intno で指定される割込みを禁止する。
intnoの具体的な意味はプロセッサ依存であり、割込みベクトル番号、割込みデバイス番号などを表わす。
【エラーコード (ercd)】
E̲OK

正常終了

E̲PAR

一般的なパラメータエラー（インプリメント依存）

E̲VECN

不正ベクトル番号（インプリメント依存）第二部

μITRON2-2 4/28/98 12:29 PM ページ 135［2A］ena̲int

135

割込みを許可する［2A］ena̲int
ena̲int:

Enable Interrupt【パラメータ】
intno

InterruptNumber

割込み番号【リターンパラメータ】
なし【解説】
割込み番号 intno で指定される割込みを許可する。
intnoの具体的な意味はプロセッサ依存であり、割込みベクトル番号、割込みデバイス番号などを表わす。
【エラーコード (ercd)】
E̲OK

正常終了

E̲PAR

一般的なパラメータエラー（インプリメント依存）

E̲VECN

不正ベクトル番号（インプリメント依存）第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 136

136［2B］chg̲iXX

割込みマスク（レベル, 優先度）を変更する［2B］chg̲iXX
chg̲iXX:

Change Interrupt XXXX

【パラメータ】
iXXXX

Interrupt XXXX

割込みマスク（レベル、優先度）【リターンパラメータ】
なし【解説】
プロセッサの割込みマスク（レベル、優先度）を、iXXXX で指定した値に変更する。
システムコール名称およびパラメータ名称の一部の XXXX には、対象プ
ロセッサのアーキテクチャに応じて適当な名前を入れる。具体的なシステ
ムコール名は、例えば chg̲ims, chg̲ipl, chg̲ilv 等となる。また、プロセッ
サによっては、このシステムコールが、iXXXX に加えて intno 等のパラメータを持つ場合がある。
通常、このシステムコールは、ユーザタスクの一部を割込み禁止にするために用いられる。
なお、このシステムコールにより割込みの禁止を行なっている間は、割込みハンドラ実行中と同じように、割込みマスクが解除されるまでディスパッチを遅延するのが原則である。これは、割込みを禁止したままでディスパッチが行なわれると、割込み禁止の状態が中断したり、命令の実行に矛盾が起こったりするためである。
【エラーコード (ercd)】
E̲OK

正常終了

E̲PAR

一般的なパラメータエラー（インプリメント依存）

E̲VECN

不正ベクトル番号（インプリメント依存）

E̲IMS

不正IMASK（インプリメント依存）第二部

μITRON2-2 4/28/98 12:29 PM ページ 137［3B］iXX̲sts

137

割込みマスク（レベル, 優先度）を参照する［3B］iXX̲sts
iXX̲sts:

Get Interrupt XXXX Status【パラメータ】
なし【リターンパラメータ】
iXXXX

Interrupt XXXX

割込みマスク（レベル、優先度）【解説】
プロセッサの割込みマスク（レベル、優先度）を参照し、リターンパラ
メータ iXXXX として返す。
システムコール名称およびパラメータ名称の一部の XXXX には、対象プ
ロセッサのアーキテクチャに応じて適当な名前を入れる。具体的なシステ
ムコール名は、例えば ims̲sts, ipl̲sts, ilv̲sts 等となる。また、プロセッサによっては、このシステムコールが intno 等のパラメータを持つ場合がある。
【エラーコード (ercd)】
E̲OK

正常終了

E̲PAR

一般的なパラメータエラー（インプリメント依存）

E̲VECN

不正ベクトル番号（インプリメント依存）第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 138

138

例外管理機能ITRONでは、システムコール実行のエラーにより例外ハンドラを起動するシステムコール例外の機能と、プロセッサの例外処理（ゼロ除算等）によってタスクの例外ハンドラを起動するCPU例外の機能があった。しかし、システムコール例外の機能はシステムコール実行のオーバーヘッドになりやすいので、μITRON標準仕様には含めない。また、CPU例外の管理機能
も、プロセッサのアーキテクチャに対する依存性が高いため、μITRONの標準仕様には含めない。μITRONの例外管理機能は、すべてプロセッサ依存あるいはインプリメント依存となっている。
μITRONの用途では、必ずしも例外管理の機能は必要ではないが、デバ
ッグサポートなどのために、インプリメントに依存した独自の例外管理機
能を設けることは可能である。

第二部

μITRON2-2 4/28/98 12:29 PM ページ 139

139

メモリプール管理機能

この章の「メモリプール管理機能」で対象としているのは、ソフトウエ
アによるメモリプールやメモリブロックの管理機能である。MMU に関する操作（MMUサポート機能）は、ここには含まれない。
μITRONでは、タスク間で共有される固定長メモリブロックのみを扱うのが普通である。

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 140

140［4］get̲blk ［3］pget̲blk

固定長メモリブロックの獲得待ちを行う［4］get̲blk
固定長メモリブロックを獲得する［3］pget̲blk
get̲blk:

Get Memory Block

pget̲blk:

Poll and Get Memory Block【パラメータ】
mplid

MemoryPoolIdentifier

メモリプールID【リターンパラメータ】
blk

BlockStartAddress

メモリブロックの先頭アドレス【解説】
mplidで示されるメモリプールから、共有メモリブロック（固定長）を獲得する。獲得したメモリブロックの先頭アドレスが blk に返される。獲得されるメモリブロックのサイズは、システム起動時にメモリブロック毎に指定した値 (blksz) となる。
get̲blk で獲得したメモリのゼロクリアは特に行われない。獲得されたメ
モリブロックの内容は不定である。
get̲blk の場合、指定したメモリプールからメモリブロックが獲得できなければ、get̲blk 発行タスクがそのメモリプールのメモリ獲得待ち行列につながれ、獲得できるようになるまで待つ。一方、メモリブロックが獲得できない場合でも即座にリターンするシステムコールとして、p g e t ̲ b l kが用意されている。pget̲blk システムコールでは、mplid で示されたメモ
リプールから即座にメモリブロックが獲得できる場合には、メモリブロックの獲得を行って、システムコールは正常終了する。即座にメモリブロックが獲得できない場合には、待ち状態に入らずにエラー E̲PLFAIL を返す。
pget̲blk の機能は、ITRON2では get̲blk (tmout=TMO̲POL) の指定により実現される機能であるが、μITRONの場合は get̲blk でタイムアウトの指定ができないため、別システムコール pget̲blk に分離している。なお、

第二部

μITRON2-2 4/28/98 12:29 PM ページ 141［4］get̲blk ［3］pget̲blk

141

リアルタイムOSの場合は、メモリ獲得待ちでタスクの実行を止めるということはあまり無い。したがって、get̲blk よりも pget̲blk の方が必要性が高い。
μITRONの場合、メモリプールの生成はシステム起動時に静的に行う。
メモリプール生成時に必要なメモリブロックサイズ (blksz) やメモリプール全
体のサイズ(mplsz) などのパラメータも、システム起動時に静的に指定する。
μI T R O Nのメモリプールの場合、get̲blk における待ちタスクのキュー
イング方法はFIFO (TA̲TFIFO) とするのが標準である。ただし、インプリ
メントによっては、タスク優先度順 (TA̲TPRI) のキューイング方法を選択できるようになっていても良い。また、μITRONの get̲blkでは固定長のメ
モリブロックのみを扱うのが標準なので、ITRON2における TA̲FIRST（行
列先頭のタスクを優先扱い）と TA̲CNT（要求数の少ないタスクを優先扱い）の区別は意味を持たない。
μITRONでは固定長のメモリブロックしかサポートしないので、メモリプールが1つしかないとすると、1種類のサイズのメモリブロックしか確保できないことになる。そこで、μITRONでも get̲blk, pget̲blk システムコー
ルのパラメータとして mplid を含めることにより、複数のメモリプールを持つことが可能となるようにしている。
資源獲得を行うシステムコールのうち、pget̲blk に限っては、次のような理由により、例外的にタスク独立部からも実行できる場合がある。
（実際に実行可能かどうかはインプリメント依存である。
）― 一般的には、セマフォカウント値やメモリブロックなどの「資源」は、タスクに与えられるものであるということになっている。したがって、
割込みハンドラ等のタスク独立部では、資源を確保することができず、タスク独立部から wai̲sem 等を発行することはできない。
― しかし、タスク独立部が資源を確保したとしても、リターンの前に資源を返してしまう（あるいは他のタスクやメイルボックスに渡してしまう）
ことにすれば、特に矛盾は生じない。実際、割込みハンドラの中からメッセージを送る場合には、その前に get̲blk を実行する必要が生じる。もちろん、割込みハンドラでは待ち状態になることはできないので、
get̲blkではなく、pget̲blk を発行しなければならない。
― pget̲blk 以外の pol̲flg, preq̲sem, prsv̲msg などをタスク独立部から実行

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 142

142［4］get̲blk ［3］pget̲blk

する必要性はない。pget̲blk 以外のシステムコールに関しては、やはりE̲CTX のエラーとする。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（ mplidのメモリプールが存在しない）E̲CTX

コンテキストエラー（タスク独立部から実行、インプリ

E̲RLWAI

待ち状態強制解除（待ちの間にrel̲waiを受け付け）

E̲PLFAIL

ポーリング失敗

メント依存）

第二部

μITRON2-2 4/28/98 12:29 PM ページ 143［3］rel̲blk

143

固定長メモリブロックを返却する［3］rel̲blk
rel̲blk:

Release Memory Block【パラメータ】
mplid

MemoryPoolIdentifier

メモリプールID

blk

BlockStartAddress

メモリブロックの先頭アドレス【リターンパラメータ】
なし【解説】
blk で示されるメモリブロックを、mplidで示されるメモリプールへ返却する。
メモリブロックの返却を行うメモリプールは、メモリブロックの獲得を行ったメモリプールと同じものでなければならない。メモリブロックの返却を行うメモリプールが、メモリブロックの獲得を行ったメモリプールと異なっていることが検出された場合には、E̲ILBLK のエラーとなる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（mplidのメモリプールが

E̲ILBLK

不正メモリブロックの返却、操作存在しない）

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 144

144［4］mpl̲sts

メモリプールの状態を参照する［4］mpl̲sts
mpl̲sts:

Get MemoryPool Status【パラメータ】
mplid

MemoryPoolIdentifier

メモリプールID【リターンパラメータ】
wtskidWaitTaskID

待ちタスクID

frbcntFreeBlockCount

空き領域のブロック数【解説】
mpl̲sts では、mplid で示された対象メモリプールの各種の状態を参照し、対象メモリプールの現在の空きブロック数 frbcnt、待ちタスクID番号 wtskid
等をリターンパラメータとして返す。
このシステムコールのインタフェース形式としては、パケットを利用して frbcnt, wtskid 等の情報をまとめて読み出す場合と、個々の情報を別々に読み出す場合とがある。
wtskid には、待ち行列の先頭のタスクのIDが返る。すなわち、待ち行列へのつながれ方が FIFOの場合には、現在このメモリプールからメモリブロックの獲得を待っているタスクのうち、最も早く待ち状態になったタスクのIDが返る。待ちタスクの無い時は FALSE (0) が返る。frbcntと wtskid の少なくとも一方は0となる。
インプリメントによっては、frbcnt, wtskid 以外の追加情報（メモリプー
ル全体のサイズmplszやブロックサイズblkszなど）も参照できる場合がある。
mpl̲sts で、対象メモリプールが存在しない場合には、エラー E̲NOEXS
となる。

第二部

μITRON2-2 4/28/98 12:29 PM ページ 145［4］mpl̲sts

145【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（インプリメント依存）

E̲ILADR

不正アドレス（リターンパラメータ用のパケットアドレスが使用できない値）E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（mplidのメモリプールが存在しない）

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 146

146

時間管理・タイマハンドラ機能

第二部

μITRON2-2 4/28/98 12:29 PM ページ 147［2］set̲tim

147

システムクロックを設定する［2］set̲tim
set̲tim:

Set Time【パラメータ】
time

CurrentDateTime

現在の年月日時刻データ【リターンパラメータ】
なし【解説】
システムが保持しているシステムクロックの現在の値を、time で示される値に設定する。
システムクロックのビット数（timeのビット数）はインプリメント依存であるが、48ビットを推奨する。timeとして必要なビット数のデータを一度に扱えないプロセッサの場合には、パラメータの time を上位 (utime) と下位(ltime) あるいは上位 (utime) と中位 (mtime) と下位 (ltime) に分けて扱うのが普通である。
システムクロックの意味や単位もインプリメント依存であるが、他の制約が無い場合には、1985年1月1日0時 (GMT) からの通算のミリ秒数とする
ことを推奨する。
システムの動作中に set̲tim を使ってシステムクロックを変更した場合には、それまで時間待ちをしていたタスクや、起動を待っていたハンドラ（周期起動ハンドラやアラームハンドラ）の動作のタイミングが狂う可能性がある。このような場合の動作はインプリメント依存である。
【エラーコード (ercd)】
E̲OK

正常終了

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲ILTIME

不正時間指定（インプリメント依存）第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 148

148［2］get̲tim

システムクロックの値を読み出す［2］get̲tim
get̲tim:Get Time【パラメータ】
なし【リターンパラメータ】
time

CurrentDateTime

現在の年月日時刻データ【解説】
システムが保持しているシステムクロックの現在の値を読み出し、リタ
ーンパラメータ time に返す。
システムクロックのビット数（timeのビット数）はインプリメント依存であるが、48ビットを推奨する。time として必要なビット数のデータを一度に扱えないプロセッサの場合には、リターンパラメータの time を上位(utime) と下位 (ltime) あるいは上位 (utime) と中位 (mtime) と下位 (ltime) に分けて扱うのが普通である。
システムクロックの意味や単位もインプリメント依存であるが、他の制約が無い場合には、1985年1月1日0時 (GMT) からの通算のミリ秒数とする
ことを推奨する。
【エラーコード (ercd)】
E̲OK正常終了
E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存
である。

第二部

μITRON2-2 4/28/98 12:29 PM ページ 149［#4］def̲cyc

149

周期起動ハンドラを定義する［#4］def̲cyc
def̲cyc:

Define Cyclic Handler【パラメータ】
cyhno

CyclicHandlerNumber

周期起動ハンドラ指定番号

cychdrCyclicHandlerAddress

周期起動ハンドラアドレス

cyhactCyclicHandlerActivation

周期起動ハンドラ活性状態

cytimeCycleTime

周期起動時間間隔【リターンパラメータ】
なし【解説】
周期起動ハンドラは、指定した時間間隔で動くタスク独立部のハンドラである。このシステムコールでは、周期起動ハンドラを定義する。
cyhno は複数の周期起動ハンドラを区別するための番号であり、act̲cyc,cyh̲sts 等で使用される。また、cycadr は周期起動ハンドラの先頭アドレス、
cytime は周期起動の時間間隔、cyhact は周期起動ハンドラの一時的なON/OFFの選択（活性状態）を表わす。cyhact では、次のような値を指定する。
cyhact : = (TCY̲OFF‖TCY̲ON)TCY̲OFF

周期起動ハンドラは起動されない

TCY̲ON

周期起動ハンドラは起動される

cyhact = TCY̲OFF は周期起動ハンドラの一時的な中断を意味し、この間はハンドラが起動されない。
def̲cyc の実行により周期カウントがクリアされるため、def̲cyc を実行
してからちょうど指定周期経った後に、最初のハンドラ起動が起こることになる。
cychdr = NADR(-1) とした場合には、前に定義した周期起動ハンドラの定義解除になる。ただし、def̲cyc のシステムコールインタフェースがパケッ
トを使っており、しかも、定義解除の対象を指定するパラメータ (cyhno) が第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 150

150［#4］def̲cyc

パケットに含まれていない場合には、パケットアドレス= NADR (-1) によって定義解除を行うこともある。
def̲cyc では回数の指定が無いので、act̲cyc によって cyhact を TCY̲OFFにするか、ハンドラを定義解除するまで周期起動が繰り返される。また、
既に定義されている周期起動ハンドラの cyhno に対して、再度def̲cyc が実行された場合には、前の定義がすべて取り消され、新しい定義が有効になる。def̲cyc によって周期起動ハンドラを再定義する場合でも、あらかじめ前のハンドラの定義解除を行なっておく必要はない。これは、def̲int などと同様である。
周期起動ハンドラでのレジスタの退避と復帰はユーザの責任である。
周期起動ハンドラはタスク独立部として実行されるため、周期起動ハンドラの中では、待ちとなるシステムコールや、tskid = TSK̲SELF によって自タスクの指定を意味するシステムコールは実行することはできない。また、周期起動ハンドラの中でシステムコールを実行してもディスパッチは起らず、ret̲tmr システムコールの発行により周期起動ハンドラを抜けるまで、ディスパッチを遅延するのが原則である。
周期起動ハンドラやアラームハンドラをタスク独立部と考えているのは、
周期起動ハンドラやアラームハンドラの定義が有効な間に、 d e f ̲ c y c ,def̲alm を発行したタスクが終了、削除される可能性があるためである。
周期起動ハンドラはオブジェクトではないため、ID番号ではなく、cyhno
により複数ハンドラの区別を行なっている。
周期起動ハンドラの機能を提供する場合でも、周期起動ハンドラの定義
は、このシステムコールを使って動的に行う必要はなく、オブジェクトの生成と同様に、システム起動時に静的に行うことができる。つまり、他の方法で周期起動ハンドラを定義することが可能であれば、このシステムコ
ールをサポートする必要は無い。この点は、def̲int 等と同様である。

第二部

μITRON2-2 4/28/98 12:29 PM ページ 151［#4］def̲cyc

151【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足（インプリメント依存）※ このエラーが発生するかどうかはインプリメント依存である。

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSMD

予約モード、予約オプション（cyhactが不正）

E̲RSATR

予約属性（インプリメント依存）E̲PAR

一般的なパラメータエラー（cyhnoが不正）

E̲ILADR

不正アドレス（cychdrが使用できない値）

E̲ILTIME

不正時間指定（インプリメント依存）第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 152

152［4］act̲cyc

周期起動ハンドラの活性制御を行なう［4］act̲cyc
act̲cyc:

Activate Cyclic Handler【パラメータ】
cyhno

CyclicHandlerNumber

周期起動ハンドラ指定番号

cyhactCyclicHandlerActivation

周期起動ハンドラ活性状態【リターンパラメータ】
なし【解説】
周期起動ハンドラの活性状態 (cyhact) を変更する。
cyhact の具体的な指定方法は次のようになる。
cyhact : = (TCY̲OFF‖TCY̲ON)｜[TCY̲INI]TCY̲OFF

周期起動ハンドラは起動されない

TCY̲ON

周期起動ハンドラは起動される

TCY̲INI

周期起動ハンドラのカウントが初期化される

cyhact = TCY̲ON の指定を行うと、周期の経過とは独立に活性状態を
ON にする。OS内部の動作としては、活性状態が OFF の間も指定周期のカ
ウントを行っているため、act̲cyc を実行してから最初に周期起動ハンドラが実行されるまでの時間は一定しない。
一方、cyhact = (TCY̲ON ¦ TCY̲INI) の指定を行うと、活性状態を ON にするのと同時に周期カウントをクリアする。したがって、act̲cyc を実行してからちょうど指定周期経った後に、最初のハンドラ起動が起こることになる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSMD

予約モード、予約オプション（cyhactが不正）

E̲NOEXS

オブジェクトが存在していない（cyhnoの周期起動ハンドラが存在しない）第二部

μITRON2-2 4/28/98 12:29 PM ページ 153［4］cyh̲sts

153

周期起動ハンドラの状態を参照する［4］cyh̲sts
cyh̲sts:

Get Cyclic Handler Status【パラメータ】
cyhno

CyclicHandlerNumber

周期起動ハンドラ指定番号【リターンパラメータ】
cyhactCyclicHandlerActivation 周期起動ハンドラ活性状態

lftimeLeftTime

次のハンドラ起動までの残り時間【解説】cyh̲sts では、cyhno で示された周期起動ハンドラの状態を参照し、周期起動ハンドラ活性状態 cyhact、次のハンドラ起動までの残り時間 lftime 等をリ
ターンパラメータとして返す。このうち、cyhact では、TCY̲ONと TCY̲OFFの区別のみが返され、TCY̲INI の情報が返ることはない。
このシステムコールのインタフェース形式としては、パケットを利用して cyhact, lftime 等の情報をまとめて読み出す場合と、個々の情報を別々に読み出す場合とがある。
インプリメントによっては、cyhact, lftime 以外の追加情報（周期cytimeなど）も参照できる場合がある。
cyh̲sts で、cyhno の周期起動ハンドラが存在しない場合には、エラー
E̲NOEXS となる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲PAR

一般的なパラメータエラー（インプリメント依存）

E̲ILADR

不正アドレス（リターンパラメータ用のパケットアドレスが使用できない値）

E̲NOEXS

オブジェクトが存在していない（cyhnoの周期起動ハンドラが存在しない）第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 154

154［#4］def̲alm

アラームハンドラを定義する［#4］def̲alm
def̲alm:

Define Alarm Handler【パラメータ】
alhno

AlarmHandlerNumber

アラームハンドラ指定番号

almhdrAlarmHandlerAddress

アラームハンドラアドレス

time

AlarmTime

ハンドラ起動時刻

tmmodeTimeMode

初期時刻指定モード【リターンパラメータ】
なし【解説】
アラームハンドラ（指定時刻起動ハンドラ）は、指定した時刻に起動されるタスク独立部のハンドラである。このシステムコールでは、指定時刻起動ハンドラを定義する。
alhnoは複数のアラームハンドラを区別するための番号である。almadr は起動されるアラームハンドラの先頭アドレスを表わす。また、time により、
アラームハンドラの起動時刻を指定する。tmmode により、次のようにして絶対時刻と相対時刻の指定が可能である。
tmmode : = (TTM̲ABS‖TTM̲REL)
TTM̲ABS

絶対時刻での指定

TTM̲REL

相対時刻での指定

指定した時刻が過去の時刻であった場合には、エラー E̲ILTIME となる。
time のビット数はインプリメント依存であるが、システムクロックのビット数と同じく 48ビットを使用するのが望ましい。time として必要なビット数のデータを一度に扱えないプロセッサの場合には、パラメータの time
を上位 (utime) と下位 (ltime) あるいは上位 (utime) と中位 (mtime) と下位(ltime) に分けて扱うのが普通である。
almhdr = NADR (-1) とした場合には、前に定義したアラームハンドラの第二部

μITRON2-2 4/28/98 12:29 PM ページ 155［#4］def̲alm

155

定義解除になる。ただし、def̲alm のシステムコールインタフェースがパケットを使っており、しかも、定義解除の対象を指定するパラメータ (alhno)
がパケットに含まれていない場合には、パケットアドレス= NADR (-1) によって定義解除を行うこともある。
def̲alm によってアラームハンドラを再定義する場合でも、あらかじめ前のハンドラの定義解除を行なっておく必要はない。既にアラームハンドラが定義された alhno に対して直接新しいハンドラを定義しても、エラーにはならず、前の定義が取り消されて新しい定義が有効になる。これは、
def̲int などと同様である。
アラームハンドラでのレジスタの退避と復帰はユーザの責任である。
アラームハンドラはタスク独立部として実行されるため、アラームハン
ドラの中では、待ちとなるシステムコールや、tskid = TSK̲SELF によって自タスクの指定を意味するシステムコールは実行することはできない。また、アラームハンドラの中でシステムコールを実行してもディスパッチは起らず、ret̲tmr システムコールの発行によりアラームハンドラを抜けるまで、ディスパッチを遅延するのが原則である。
アラームハンドラはオブジェクトではないため、ID番号ではなく、alhnoにより複数ハンドラの区別を行なっている。
アラームハンドラの機能を提供する場合でも、アラームハンドラの定義
は、このシステムコールを使って動的に行う必要はなく、オブジェクトの生成と同様に、システム起動時に静的に行うことができる。つまり、他の方法でアラームハンドラを定義することが可能であれば、このシステムコ
ールをサポートする必要は無い。この点は、def̲int 等と同様である。
アラームハンドラの中で rel̲wai, irel̲wai を発行し、待ち状態のタスクを待ち解除とすることにより、タイムアウトに似た機能を実現することが
できる。

第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 156

156［#4］def̲alm【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足（インプリメント依存）※ このエラーが発生するかどうかはインプリメント依存である。

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSMD

予約モード、予約オプション（tmmode が不正）

E̲RSATR

予約属性（インプリメント依存）E̲PAR

一般的なパラメータエラー（alhno が不正）

E̲ILADR

不正アドレス（almhdr が使用できない値）

E̲ILTIME

不正時間指定（インプリメント依存）第二部

μITRON2-2 4/28/98 12:29 PM ページ 157［4］alh̲sts

157

アラームハンドラの状態を参照する［4］alh̲sts
alh̲sts:

Get Alarm Handler Status【パラメータ】
alhno

AlarmHandlerNumber

アラームハンドラ指定番号【リターンパラメータ】
lftimeLeftTime

次のハンドラ起動までの残り時間【解説】alh̲sts では、alhno で示されたアラームハンドラの状態を参照し、次のハンドラ起動までの残り時間lftime 等をリターンパラメータとして返す。
インプリメントによっては、lftime 以外の追加情報も参照できる場合がある。
このシステムコールのインタフェース形式としては、パケットを利用して lftime やそれ以外の追加情報をまとめて読み出す場合と、個々の情報を別々に読み出す場合とがある。また、lftime に必要なビット数のデータを一度に扱えないプロセッサの場合には、リターンパラメータの lftime を上位(lfutime) と下位 (lfltime) あるいは上位 (lfutime) と中位 (lfmtime) と下位(lfltime) に分けて扱うのが普通である。
alh̲sts で、alhno のアラームハンドラが存在しない場合には、エラー
E̲NOEXS となる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲PAR

一般的なパラメータエラー（インプリメント依存）

E̲ILADR

不正アドレス（リターンパラメータ用のパケットアドレスが使用できない値）

E̲NOEXS

オブジェクトが存在していない（alhnoのアラームハンドラが存在しない）第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 158

158［#4］ret̲tmr

タイマハンドラから復帰する［#4］ret̲tmr
ret̲tmr:

Return from Timer Handler【パラメータ】
なし【リターンパラメータ】※ システムコールを発行したコンテキストには戻らない【解説】
タイマハンドラ（周期起動ハンドラ、アラームハンドラ）から戻る際に発行するシステムコールである。
このシステムコールでは、ret̲int と同様に、タイマハンドラの中で遅延させられていたディスパッチの起こる可能性がある。
プロセッサのアーキテクチャや OSのインプリメントによっては、サブルーチンリターン命令や割込みリターン命令によって、このシステムコールを実現する場合がある。
なお、ret̲tmr を、同じタスク独立部からの戻りシステムコールである
ret̲int と統合しないのは、ハンドラ起動時にOSが介入するかどうかという
点で違いがあるためである。すなわち、ret̲int がハードウエアで直接起動されたタスク独立のハンドラからのリターンを表わすのに対して、ret̲tmr
はOSから起動されたタスク独立のハンドラからのリターンを表わす。
【エラーコード】※ 次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、
システムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合の動作は、インプリメント依
存となる。
E̲CTX

コンテキストエラー（タスク部から実行）

第二部

μITRON2-2 4/28/98 12:29 PM ページ 159

159

システム管理機能第二章

μITRONシステムコール

2-2 4/28/98 12:29 PM ページ 160

160［1］get̲ver

ITRON, μITRONのバージョン番号を得る［1］get̲verget̲ver:

Get Version NO【パラメータ】
pk̲verPacket of Version Numbers バ ー ジ ョ ン 管 理 情 報 を 返 す
パケットの先頭アドレス【リターンパラメータ】
なし【解説】
現在実行中の ITRON仕様OSやμITRON仕様OSのスペックの概要、OSの形式番号、バージョン番号などを得る。
このシステムコールは、OSのメーカーおよびバージョン番号を、プログ
ラムから読み出すことを目的としたものである。
バージョンの読み出しは、次のようなパケットを用いて行なわれる。なお、以下で、UH は 16ビット符号無し整数のデータタイプを表わす。
typedef struct t̲ver {UHmaker;/* メーカー */

UH

id;

/* 形式番号 */UH

spver;/* 仕様書バージョン */UH

prver;/* 製品バージョン */UH

prno[4];/* 製品管理情報 */

UH

cpu;

/* CPU情報 */

UH

var;

/* バリエーション記述子 */} T̲VER;
T̲VER*pk̲ver;/* バージョン管理ブロックへのポインタ */パケットの形式や構造体の各メンバのフォーマットは、プロセッサ間で、あるいはITRON1、ITRON2、μITRON、BTRONの間でほぼ共通になっている。以下では、各メンバのフォーマットや意味について説明を行う。

第二部

μITRON2-2 4/28/98 12:29 PM ページ 161［1］get̲ver

161

makerでは、この製品 (ITRON、BTRON、TRONCHIP) を作ったメーカーを表わす。maker のフォーマットを［図2.10(a)］に示す。
ITRON、BTRON、TRONCHIPのうちの複数のプロジェクトに参加しているメーカーに対しては、協議の上［図2.10 (a)］＜1＞のフォーマットを割り当てる。この場合、MAKER1 のコードは、ITRON、BTRON、TRONCHIP
で共通になる。それ以外のメーカーの場合は、［図2.10 (a)］＜2＞のフォー
マットを使用し、B'0000000100000001〜 のコードを割り当てる。 MAKER2のコードは登録制となる。 M A K E R 2のコードは、 I T R O N 、 B T R O N 、
TRONCHIP の間で異なったものになる。
なお、MAKER1 のコードを持つメーカーの子会社や関連会社の場合は、そのメーカーの判断によって、MAKER1のコード番号を使うか、新しく登録する MAKER2のコードを使うかということを決める。

[maker]
＜1＞ 0

0

0

0

0

0

0

0

MAKER1＜2＞

MAKER2

MAKER1 : メーカー番号
B' 00000000
B' 00000001...

バージョンなし〔実験システムなど〕
University of TOKYOB' 00001001
B' 00001010
B' 00001011
B' 00001100
B' 00001101
B' 00001110
B' 00001111＊以下はABC順
FUJITSUHITACHIMATSUSHITAMITSUBISHINECOKITOSHIBAB' 00010000〜B' 11111111
reserved［図2.10 (a)］get̲verで得られるmakerのフォーマット

第二章

μITRONシステムコール

2-2 4/28/98 3:09 PM ページ 162

162［1］get̲ver[id]
id［図2.10 (b)］get̲verで得られるidのフォーマット

[spver]MAGIC

SpecVer

MAGIC: TRONのシリーズを区別する番号
H' 0
TRON共通(TAD等)
H' 1
ITRON
H' 2
BTRON
H' 3
CTRON
H' 4
reserved
H' 5μITRONH' 6
μBTRONSpecVer:この製品のものになった東京大学のTRON仕様書のバージョン番号。3桁のバックト型式BCDコードで入れる。

［図2.10 (c)］get̲verで得られるspverのフォーマット

id は、 O SやV L S Iの種類を区別する番号である。id のフォーマットを［図2.10(b)］に示す。1つのメーカーの中で、MMU対応版とMMU非対応版のような複数の種類の製品を作った場合、それらを区別するためにidを用いることができる。
idの番号の付け方はメーカーの自由とする。ただし、製品の区別はあくまでもこの番号のみで行なうので、各メーカーにおいて番号の付け方を十分に検討した上、体系づけて使用するようにしなければならない。
spver では、ITRON, μITRON, BTRON, CTRON, TRONCHIPの区別と、この製品のもとになった仕様書のバージョン番号を表わす。spver のフォーマットを［図2.10(c)］に示す。
μITRONは、ITRON2との整合性が高いという意味で、最初のバージョンが 1.00 ではなく 2.00 となる。たとえば、μITRONの最初のバージョンに対応する spver は次のようになる。

第二部

μITRON2-2 4/28/98 3:09 PM ページ 163［1］get̲ver
MAGIC = H'5(μITRON)

SpecVer = H'200(Ver 2.00)

163

spver = H'5200
また、μITRON Ver 2.56.xx.xx の仕様書をインプリメントした製品の場合、spver = H'5256となる。
prver では、内部インプリメント上のバージョン番号を表わす。prver の
フォーマットを［図2.10 (d)］に示す。MAJOR はバージョン番号の大きな区
別、MINOR はバージョン番号の小さな区別を表わす。番号の付け方はメーカーの自由である。
prno は、製品管理情報や製品番号などを入れるために、各メーカーが自由に使用してもよい部分である。prno のフォーマットを[prver]
MINOR

MAJOR

［図2.10 (d)］get̲verで得られるprverのフォーマット

[prno]
prno[0]prno[1]
prno[2]prno[3]［図2.10 (e)］get̲verで得られるprnoのフォーマット

第二章

μITRONシステムコール

2-2 4/28/98 12:30 PM ページ 164

164［1］get̲ver

[cpu]
<1>

0 0 0 0 0 0 0 0

CPU1

<2>

MAKER1

CPU2

CPU1:

B'00000000 (H'00) CPUを特定しない、CPU情報を持たない
B'00000001 (H'01) TRONCHIP32共通、メーカーを特定しない
B'00000010 (H'02) reserved
B'00000011 (H'03) reserved
B'00000100 (H'04) reserved
B'00000101 (H'05) reserved（≪L1R≫仕様のTRONCHIIP）
B'00000110 (H'06) reserved（≪L1≫仕様の仕様のTRONCHIIP）
B'00000111 (H'07) reserved（LSIDの機能を持つTRONCHIIP）＊ B' 00000000〜B' 00000111 の場合、CPUのメーカーを特定しない。
B'00001000 (H'08) reserved
B'00001001 (H'09) GMICRO/100
B'00001010 (H'0a) GMICRO/200
B'00001011 (H'0b) GMICRO/300
B'00001100 (H'0c) reserved
B'00001101 (H'0d) TX1
B'00001110 (H'0e) reserved
B'00001111 (H'0f) TX3
B'00010000 (H'10) reserved
B'00010001 (H'11) reserved
B'00010010 (H'12) reserved
B'00010011 (H'13) 032
B'00010100 (H'14) reserved
B'00010101 (H'15) MN10400
B'00010110 (H'16) reserved
B'00010111 (H'17) reserved
B' 00011000〜B' 00111111 (H'18〜H'3f) - reserved＊GMICRO拡張用、TXシリーズ拡張用、TRONCHIP64用［図2.10 (f)］get̲verで得られるcpuのフォーマット（前半）

第二部

μITRON2-2 4/28/98 12:30 PM ページ 165［1］get̲ver165

B'01000000 (H'40) 68000
B'01000001 (H'41) 68010
B'01000010 (H'42) 68020
B'01000011 (H'43) 68030
B'01000000〜B'01001111 (H'40〜H'4f) - 68000 系
B'01010000 (H'50) 32032
B'01010000〜B'01011111(H'50〜H'5f) - NS32000 系
B'01100000 (H'60) 8086, 8088
B'01100001 (H'61) 80186
B'01100010 (H'62) 80286
B'01100011 (H'63) 80386
B'01100000〜B'01101111(H'60〜H'6f) - 86 系
B'01110000〜B'01111111(H'70〜H'7f) - NEC V シリーズ
割り当てはＶシリーズ関連メーカーが決める。
B' 10000000〜B' 11111111 (H' 80〜H' ff) - reserved［図2.10 (f)］get̲verで得られるcpuのフォーマット（後半）［図2.10 (e)］に示す。
cpu は、このITRONを実行するプロセッサを表わす。cpu のフォーマット
を［図2.10 (f)］に示す。 T R O N C H I P、モトローラ M 6 8 0 0 0系、インテル
iAPX86系、ナショセミ NS32000系、NEC-Vシリーズのプロセッサの場合は［図2.10 (f)］＜1＞のフォーマットを使用し、それ以外の各社独自アーキテク
チャのプロセッサの場合には、［図2.10 (f)］＜2＞のフォーマットを使用する。
［図2.10 (f)］＜1＞のフォーマットにおける CPU1 のコード割当ては、
ITRONとBTRONで共通である。また、BTRON / CHIP 標準オブジェクトフォーマットのCPUタイプの部分にも、これと同じ番号が入る。
一方、［図2.10 (f)］＜2＞のフォーマットは、主としてμITRON で用いられるものである。この場合、MAKER1 のコードの割当ては、maker の項で説明したものと同じになる。また、CPU2 のコードの割当ては MAKER1のメーカーが決める。

第二章

μITRONシステムコール

2-2 4/28/98 12:30 PM ページ 166

166［1］get̲vervar では、このITRON2、μITRONで利用できる機能の概要を表わす。varのフォーマットを［図2.10 (g)］に示す。
なお、製品の種類の区別はあくまでも idの部分で行なう。var, cpu による表示は便宜的なものに過ぎない。すなわち、var, cpu が異なり、かつ id の等
しい製品が存在してはいけない。
μITRONの場合、M, V, P のフィールドは 0 となる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲ILADR

不正アドレス（pk̲verが使用できない値）

[var]
LEV
:
LEV:

M=1:
M=0:
V=1:
P=1:
FIL:

IO:

M V P

FIL

IO

reserved（0 が返る）
カーネル仕様のレベル分け
B' 000 μITRON
B' 001 reserved
B' 010 reserved
B' 011 ITRON2基本仕様（≪I1≫仕様）
B' 100 ITRON2一部拡張仕様（一部≪I2≫仕様）
B' 101 ITRON2拡張仕様（≪I2≫仕様）
B' 110 reserved
B' 111 reserved
マルチプロセッササポート
シングルプロセッサ用
仮想記憶サポート
MMU対応版
ファイル仕様のレベル分け
B' 000 サポートなし
B' 001 ≪FI0≫仕様
B' 010 ≪FI1≫仕様
B' 011〜B' 111
入出力仕様
B' 00 サポートなし
B' 01
標準仕様
B' 10 reserved
B' 11 reserved［図2.10 (g)］get̲verで得られるvarのフォーマット

第二部

μITRON

第二部 第三章

μITRON標準インタフェース

この章では、μITRON仕様で推奨しているシステムコールイン
タフェースに関して説明を行う。具体的には、機能コード、エラーコード、言語Cインタフェースなどの説明がここに含まれる。

168

アセンブラインタフェース

μITRONの各システムコールのアセンブラインタフェースは、プロセッ
サ毎に定める。ただし、機能コードやフラグ変化など一部の点については、
μITRON全体として、この節で述べるような原則を設けている。他の制約が無い場合には、できるだけこれらの原則に合わせて頂けるのが望ましい。
システムコール実行後のフラグ変化
システムコール実行後のフラグの値については、特に規定せず、不定値になるものとする。
ITRON1では、エラーの有無に応じてゼロフラグのセットを行うことを推奨していた。しかし、OSがせっかくフラグをセットしても、必ずしも参照されるとは限らないし、言語Cを使えば全く不要な機能である。また、フラグセットのためのオーバーヘッドも無視できない。
プロセッサによっては、OSで特にフラグの操作をしない場合に、トラッ
プ命令のハードウエア処理によって自然にフラグを保存できることがある。
しかし、将来システムコールをハードウエア化することがあれば、フラグのセットを行う方が望ましいということになる可能性もあり、必ずしもフラグを保存するように規定するのが良いとは言えない。そこで、現段階では、システムコール実行後のフラグ値に関して規定を設けないことにする。
機能コード
ITRONでは、システムコールの種類を区別する番号として、「機能コード」を用いている。機能コードをあるレジスタに置き、それからトラップ命令を発行することによって、対応するシステムコールが実行される。
μITRONの場合、プロセッサアーキテクチャや開発環境との関係によっては、トラップ命令（ソフトウエア割込み命令）ではなく、サブルーチンジ
ャンプ命令によって、OS内のシステムコール処理ルーチンに直接ジャンプするケースがある。そのような場合には、機能コードを使用しないことがある。しかし、μITRONでも、機能コードを使ったシステムコールインタ

第二部 μITRON

169
フェースを行うのであれば、特に他の制約が無い限り、機能コードの値を標準化しておくのが望ましい。
ITRON2およびμITRONにおける標準機能コードの割当方針を以下に示す。
【機能コードの割当て方針】― TRONの全体方針に合わせて、機能コードの標準値には負の値を使用している。
― 8の 倍 数 に 対 す る ア ラ イ メ ン ト や 、 共 通 機 能（ cre̲XXX, XXX̲sts,
uXXX̲YYY, sXXX̲YYY など）に対する共通ビットパターンを考慮した。
― 必ずしも、仕様書の出現順に機能コードを割り当てるわけではない。ただし、仕様書の機能グループ毎には、まとまった範囲の機能コードを割当てるようにする。
（強制例外などシステムコール数が少ないものについては、他のグループにまとめられる場合もある。）
また、仕様書での説明の順序は、機能コードとは直接関係しない。
― μITRONで使用する iXXX̲YYY, pXXX̲YYY は、それぞれ一つのグループを作るので、一般のシステムコールと混在させるのではなく、番号を飛ばした別グループとしている。
μITRONの標準機能コードはITRON2とも共通になっている。実際の機能コードの値（ITRON2とμITRONで共通）を、巻末のレファレンスに示す。

第三章 μITRON標準インタフェース

170

言語Cインタフェースとニモニック

μITRONやITRON2では、ニモニックの付与に関して、以下のような共通原則を設けている。
・データタイプの名称
データタイプの名称としては、構造体も含めてすべて大文字を使用する。
ポインタのデータタイプは 〜P の名称とする。
構造体については、T̲〜 の名称とする。
・定数のニモニック
エラーコードは E̲〜 の名称とする。
特定のシステムコールやパラメータでのみ使用するモードなどの名称は、Txy̲〜 とする。xy の部分は、システムコールやパラメータに応じて変化する。
・パラメータ、リターンパラメータの名称
パラメータ、リターンパラメータの名称に関しては、次のような原則を設ける。
p̲

リターンパラメータを入れる領域へのポインタ

pk̲

パケットアドレス

〜cd

〜コード

ar̲

配列へのポインタ

i〜

初期値

〜sz

サイズ

・パラメータ名が同じであれば、原則として同じデータタイプを持つようにする。
また、μITRONの言語Cインタフェースでは、次のような共通原則を設けている。
・関数としての戻り値は、原則としてシステムコールのエラーコード (ercd)

第二部 μITRON

171になる。正常終了の場合には ercd は 0 となり、エラーが発生した場合には、ercd は0以外の値（標準は負の値）になる。
・エラーコード以外のリターンパラメータ(XXX)を返す場合には、リター
ンパラメータを入れる領域へのポインタ(p̲XXX)をパラメータとして指定する。
・リターンパラメータへのポインタは、パラメータよりも先に置くものとする。
アセンブラインタフェースでの指定がポインタ（パケットアドレス）になっているものについても、意味的にリターンパラメータに相当するものであれば、この原則が適用される（XXX̲sts など）。
μITRONで使用する標準データタイプ、および言語Cインタフェースの標準仕様を巻末のレファレンスに示す。また、システムで共通に使用する定数のニモニックや標準値、および構造体のパケット形式を巻末のレファ
レンスに示す。

第三章 μITRON標準インタフェース

172

エラーコードのフォーマット

μITRONでは、各システムコールで発生するエラーに対して、それを表わすニモニックとエラーコード値の標準を設けている。また、これらの標準は、μITRONとITRON2で共通化されている。
エラーコードの標準値は負の数になっており、その中に ercls（例外クラス）と errno の情報を含んでいる。例外クラスは、例外の重要度や分類を示すものである。μITRONの場合、例外クラスの違いが直接OSの動作に影響するわけではないが、ITRON2においては、システムコール例外の起動の有無を決めるために例外クラスが利用されている。
μITRONで使用するエラーコードのフォーマットを［図2.11］に示す。
― excls (4≦excls≦31) により、発生するシステムコール例外の例外クラスを表わす。
― errno (1≦errno≦255) により、同じ例外クラスに属する複数のエラーを区別する。

ercd ＜1＞ 0

RETURN̲CODE

正常終了（＞0）ercd ＜2＞ 0 . . . 0 0 0 0 0 0 0 0 0 0 0 0 0 0

正常終了（＝0）

ercd ＜3＞ 1 . . . 1 1 1 1 1 1

ERRNO

エラー発生（＜0）

ercd ＜4＞ 1 . . . 1

ERRNO

エラー発生（＜0）

EXCLS＊EXCLSはexclsの1の補数、ERRNOはerrnoの2の補数である。

［図2.11］μITRONにおけるエラーコードのフォーマット

第二部 μITRON

173― エラー発生の場合の ercd の値は (- (excls ≪ 8) - errno) によって表わされ、原則として ercd＜4＞のフォーマットを使用する。ただし、'≪' は左シフトである。
― excls が異なるのに errno が等しくなる組み合せが生じないようにする。
つまり、excls の部分が無くても、errno のみで ercd の識別を可能とする。
（errno には、excls と独立にシーケンシャルな番号を与える。
）― ercd＜1＞のフォーマットは、μITRONでは使用していない。ITRON2では、ファイル管理で ercd＜1＞のフォーマットを使用している。
― デバッガ等で ercd の値を直接見る場合に、errno の部分のみの値を知りたければ、ercd を1バイトの符号付きの数として扱えば良い。
― μITRONで8ビットの制約がある場合には、excls の情報を省略し、errnoの部分のみを用いても良い（ercd＜3＞のフォーマット）。
ITRON2およびμITRONで使用する例外クラス(excls)を、巻末のレファレンスに示す。
μITRONやITRON2では、エラーコードのニモニックの付与に関して、
以下のような共通原則を設けている。
― 汎用的に使用されるエラーは汎用的な名称とする。特殊な意味を持つエ
ラーは、誤解が起きないように、特殊な意味を持つことが想像できるようにする。
― 他のオブジェクトでも発生することが予想されるが、実際は一種類のオブジェクトにのみ関連して発生するエラーがある。このような場合は、誤解を防ぐために、エラー名称にそのオブジェクトの名称を含めるようにする。
例えば、ファイルのアクセス権違反を示すエラーは、メモリのアクセス権違反と区別するために 'F'の名称を含める。
― ITRON1で使っていたエラーコードとの連続性、整合性を考慮する。
―「不正エラー（意味的に間違った操作）」と「予約機能エラー（将来の機能追加によりエラーとならなくなるもの）」の区別がはっきりしている部分
は、その区別を行う。
ITRON2およびμITRONで使用するエラーコードのニモニックとその標第三章 μITRON標準インタフェース

174
準値を、巻末のレファレンスに示す。
μITRONにおいて、インプリメント依存のエラーコード、およびユーザ
用（拡張SVCなど）のエラーコードとしては、次の値を使用する。
インプリメント依存:

errno = 225〜255, ERRNO = B'000XXXXX
ercd = B'11...111YYYYY000XXXXX

ユーザ用:

errno = 193〜223, ERRNO = B'001XXXXX
ercd = B'11...111YYYYY001XXXXX

個々のエラーに対応するエラークラス (ercls) については、エラーの種類や意味に応じて、0または適当な値を入れる。

第二部 μITRON

m

I

O
TR

N

第三部

ITRON2

I T

R

O

N

第三部 第一章

ITRON2概説

この章では、ITRON1とITRON2との関係、ITRON2の追加機能などに関して説明を行う。

178

ITRON2設計の実際

ここでは、ITRON2設計の際の考え方や、ITRON1とITRON2との関係、両者の具体的な相違点などについて、項目別に説明する。
・豊富な機能
豊富な機能の取捨選択による適応化、といった観点から、考えられる機能はできるだけ用意するという方針にする。これは、ITRON1と同様である。
・同期・通信機能
ITRONでは TCB を軽くするという意味で、slp̲tsk〜wup̲tsk 以外の同期・通信機能は、原則としてタスク独立となっている。ITRON2では、メッセージバッファ（内容をコピーするメッセージ）やランデブの機能が拡張機能として追加されているが、タスク独立の原則は、ITRON2で新規に追加された機能に対しても適用される。
・例外管理
例外のクラス分け、例外ハンドラの多重起動、拡張SVCハンドラに対する例外管理などの仕様を明確化し、例外処理のプログラムについても標準化を促進する。
また、ソフトウエアによって他タスクの例外ハンドラを起動する機能（強制例外）を設ける。ITRON1の終了時処理ルーチンは、例外ハンドラの一つ（終了ハンドラ）という扱いにする。
・メモリプール管理
タスクがローカルに使用するメモリブロックと、タスク間で共用されるメ
モリブロックについては、non-MMU 版でもシステムコールレベルで区別す
るものとする。これは、MMU 対応版への移行をスムーズにするためである。
・オブジェクトのアクセス方法
ITRON2では、ITRON1のように、オブジェクト生成時に動的に得られたアクセスキーによってオブジェクトのアクセスを行なうのではなく、実第三部 ITRON 2

179
行開始前に確定している値（ID番号など）によってオブジェクトのアクセスを行なう。これは、プログラムの書きやすさと互換性に対する配慮である。
ID番号を使った仕様で十分な性能を出すためには、ID番号を内部のアク
セスアドレスに変換する際に、ID番号をインデクスとする配列を用いるのが一般的である。この場合、システム構築時に、ユーザに最大、最小のID番号を指定させ、ID番号をできるだけ詰めて使ってもらうようにしても構わない。
なお、ITRON1で無制限の大きさのID番号値を使用していた場合との互換性については、以下のように考えることができる［図3.1］。μITRONで
ITRON1をエミュレーションする際にも、同じ考え方が適用できる。
―オブジェクト生成システムコール (cre̲XXX) では、パラメータで指定された無制限の大きさのID番号を、ITRON2で使用する詰めたID番号に変換する。
―変換後の詰めたID番号は、ITRON1をエミュレーションするためのアクセスキーとして使用する。また、同じ値を、ITRON2のオブジェクト
操作システムコールに対するパラメータとして使用する。

ITRON1用のユーザタスクITRON1〜ITRON2
エミュレータITRON2cre̲tsk（無制限のID）

無制限のIDを詰めたID番号に変換

cre̲tsk（詰めたID）

詰めたID番号をアクセスキーとして使用詰めたID番号をそのままパラメータとして使用［図3.1］ID番号に関する互換性

第一章 ITRON 2概説

180
・エラーコード
BTRONのシステムコールでは、システムコールの戻り値が負の場合にエラーを表わし、0または正の場合に正常終了を表わす。したがって、エラーコードは負の値になっている。戻り値が正の場合は、何らかの意味のある情報（ファイルオープン時のファイルディスクリプタ等）を表わす。
BTRONとの整合性強化のため、ITRON2では、エラーコードとして負の値を使用する。また、μITRONでも、ITRON2に合わせてエラーコードの値を負にするのが望ましい。この場合、正の値を使えば、システムコー
ルの関数値としてエラー以外の情報を返すことができる。ただし、現在
ITRONで正の値を返すシステムコールは、ファイル関連のシステムコー
ルのみとなっている。
これに伴って、エラーコードのニモニックもBTRONと合わせて整理が行なわれる。
・負の数の扱い
TRONファミリ全体での方針（一種の「TRON作法」）として、負の数はシ
ステム用の数、正の数はユーザ用の数と考えるという原則がある。また、0は特殊な意味を表わすものとしている。例えば、TRON全体として次のような例がある。
― ITRONでは、tskid = 0 で自タスクの指定になる。
― ITRON / MMUでは、srcid = (-1) により共通空間を示す。
― BTRONでは、システムコールの関数値が負になったことによりエラーを示す。
― BTRONでは、process̲id = 0 により自プロセスを、process̲id = (-1)
により親プロセスを示す。
― TRONCHIPでは、負のアドレスがSS（共通半空間）、正のアドレスがUS（個別半空間）となっている。
― CTRONでは、tmout = (-1) でタイムアウト無しを示す。
これに合わせて、ITRON2でも負のID番号を利用できるようにし、負のID番号を持つタスクはシステムタスクとして扱う。例えば、ITRON2のカーネルと共に入出力用のタスクを提供する場合には、負のID番号（例えば-8 〜 -5）を入出力用のタスクに割り当てるのが望ましいということになる。

第三部 ITRON 2

181
また、ITRON2の標準システムコール用の機能コードとしては、負の値を使用する。
左記のうち、自タスクや共通空間など特殊な意味を持つ値については、
次のようなニモニックを使用する。
タスクIDに対する指定 (tskid)
TSK̲SELF

0/* 自タスク指定 */TSK̲CMN(-1)/* タスク間共通の例外ハンドラの定義 */TSK̲INDP(-2)/* タスク独立部の指定 */タイムアウト指定 (tmout)
TMO̲POL

0

TMO̲FEVR (-1)/* ポーリング *//* 永久待ち */拡張SVCでの機能コード指定 (s̲fncd)
TFN̲CMN(-1)/* 拡張SVC共通の例外ハンドラの定義 */スペースIDの指定(spcid)
TSP̲SELF

0/* 自タスクの属する空間 */TSP̲CMN(-1)/* 共通空間 */・ITRON1との互換性
ITRON2は、機能の増強や整理、BTRONやCTRONとの整合性強化のため、
ITRON1とは完全互換にならない部分がある。それでも、ITRON1との連続性を確保するため、互換性を保証するためのツールやライブラリを提供できるようにする。
ITRON1(ITRON Ver 1.11) とITRON2との関係を［図3.2］に示す。

第一章 ITRON 2概説

182（ITRON1 の仕様）

（ITRON2 検討項目）

＜1＞

＜2＞

一部のシステムコール
オプション
エラーコードなど

仕様明確化
ハンドラの
位置付けなど機能追加
ランデブなど＜3＞

TRON仕様チップ
依存機能など＜4＞仕様のバージョンアップ（ITRON2）

仕様明確化

機能追加

一部仕様変更

そのまま

ITRON
基本機能

＊ ITRON1 の内容だけでは、<1><2><3>の部分が含まれない。

［図3.2］ITRON1とITRON2との関係

第三部 ITRON 2

183

ITRON2の追加機能

ITRON2では、ITRON1と比べてかなりの機能が追加されている。そこで、ユーザにとっての理解しやすさやITRON1からの移行のしやすさを考えて、システムコールのレベル分けを行なっている。具体的には、基本機
能≪I1≫、拡張機能≪I2≫、システム操作用機能の3段階に分けられている。
ここでは、ITRON2で追加された機能に関して説明を行う。
・ランデブ機能
ランデブ機能は、ADA の言語仕様に導入されている同期/通信機能であり、その元になっているのは、Hoare の提唱した CSP (Communicating
Sequential Processes) である。ランデブ機能は、メッセージ機能を組み合せて実現することもできる。しかし、アクノレッジを伴う通信を行なうのであれば、ランデブを利用する方が無駄が少ないため、ITRON2で機能を追加する。
ランデブでは、call, accept, reply の3つのプリミティブを利用し、次のよ
うな動作を行なう。
［図3.3］で、タスクA と タスクB は非同期に動いている。もし、タスク
A が先に＜1＞に到達し、call port を実行した場合には、タスクB が＜2＞に到達するまで タスクA は待ち状態になる。逆に、タスクB が先に＜2＞に到達し、accept port を実行した場合には、タスクA が＜1＞に到達するまで タスクB は待ち状態になる。
タスクAが call port を実行し、タスクB が accept port を実行した時点でランデブが成立し、タスクAが待ち状態のままタスクBの＜3＞〜＜4＞が実行される。＜4＞の reply が実行された時点で、タスクAが待ち状態から解放され、タスクAは＜5＞より、タスクB は＜6＞より、再び実行を始める。
＜3＞〜＜4＞の間ではタスクAとタスクB が同時に動かないということが保証されるので、タスク間で共有するデータを操作することができる。
また、インプリメントの観点から見ると、データの授受が済むまで双方

第一章 ITRON 2概説

184[タスクA]＜1＞call port＜5＞[タスクB]＜2＞
accept port
＜3＞
＜4＞
reply
＜6＞

［図3.3］ランデブの動作のタスクを待たせておくことになるため、データ（メッセージ）のキュー
イングやバッファリングが不要になるという利点がある。
・資源管理サポート機能
資源管理サポート機能とは、資源の獲得や返却と同時（不可分）に、指定されたメモリの内容を変更する機能である。この機能により、タスクが自分で資源管理することを容易にし、強制終了や強制待ちに対するクリティカルセクションを無くする。
資源管理サポート機能は、具体的には、次のような場合に使用する。一般に、複数の操作を不可分に行なう場合は、［図3.4］のように、セマフォ
等によるクリティカルセクション (C.S.) を設ける。これ以外に、割込み禁止にする方法もあるが、割込みに対する応答性が悪くなるため、あまり望ましく無い。
ところが、このタスクが強制終了されたような場合、このタスクが C.S.
内にいたかどうかによって、終了ハンドラの処理内容が変わってくる。つまり、図の＜1＞以前や＜4＞以後にいたのであれば、この C.S. やセマフ
ォに関して終了処理の必要はないが、＜2＞〜＜3＞にいたのであれば、
wai̲sem で獲得したセマフォ資源を返却しておく必要が生じる。したがって、終了ハンドラでは、タスクが持っていた資源を知ることが重要になる。
「資源管理サポート機能」は、このような場合に利用する機能である。
マルチユーザのOSであれば、タスク強制終了時の資源返却はOSが行なうのが普通である。しかし、ITRONの場合は、OSを軽くするためタスク終了時の自動的な資源返却を行なわない。その代わり、それをサポートする機能を提供することにより、終了ハンドラの中でユーザが容易に資源
第三部 ITRON 2

185
返却のプログラムを書けるようにする、という方針である。それを実現するのが資源管理サポート機能である。
レジスタではなくメモリに情報を入れるのは、例外ハンドラ（終了ハンドラ）からも容易にその情報にアクセスするためである。
資源管理サポート機能のシステムコールの名称は、〜 with memory updateの意味で u〜 とする。
（例） uwai̲sem
usig̲sem
ITRON1のシステムコールのみを使って、ユーザ側で資源の割り当て状況を厳密に管理しようとした場合には、資源獲得を示すテーブルの更新命
令と wai̲sem や sig̲sem の操作を不可分にしなければならず、この間を割込み禁止にする必要が生じていた。
・メッセージバッファ（コピー）機能
メッセージブロックをリンクでつなぐ従来のITRONの方式は、効率優先で決められた仕様であるが、以下の点で問題がある。
― ITRON/MMU（特にページングマシン）では非常に使いにくい。
ページ単位でないとメモリの共有ができない。
― 異常終了に対する対応が難しい。
タスクが異常終了したり、メイルボックスが削除されたりしたよwai̲sem( . . )

＜1＞
＜2＞

C. S. 不可分のデータ操作

sig̲sem( . . )

＜3＞
＜4＞

［図3.4］セマフォによるクリティカルセクションの確保

第一章 ITRON 2概説186
うな場合に、それに合わせてメッセージブロックを解放するのが難しい。（資源管理サポート機能を使えば、不可能ではない。）
これを解決するため、現在の仕様に加えて、内容のコピーによりメッセージのやりとりをする機能（メッセージバッファ機能）を追加する。
・オブジェクトの状態を見る機能
タスク、イベントフラグ、セマフォ、メイルボックス、メモリプールなどのオブジェクトについて、状態参照システムコール (XXX̲sts) を設ける。
オブジェクトの状態参照は、ITRON1では、アクセスアドレスを得るシス
テムコール (XXX̲adr) を使って管理ブロックの内部を直接見るという方針であった。しかし、互換性を高めるためには、XXX̲adr よりも、オブジェクトの状態を見るシステムコールを用意する方が望ましい。そこで、
XXX̲adr のシステムコールは廃止し、代わりに XXX̲sts のシステムコー
ルを導入する。
・オブジェクトの属性設定機能
各オブジェクトの属性として、コプロセッサの有無や待ち行列の作り方などシステム (OS) でサポートしている属性以外に、ユーザが自由に定義できる属性を設ける。具体的には、全オブジェクトに対して属性を示す
ワード (XXXatr) を設け、その最上位バイトをユーザ用、第二上位バイトをインプリメンタ用、下位2バイトをシステム用（ITRON1の命令オプシ
ョン機能を含む）とする。XXXatr は、XXX̲sts システムコールで読み出すことができる。
例えば、タスクのユーザ定義属性であれば、大規模なOSには入っているがITRONには入っていない機能を、ユーザがシミュレートするような場合に利用できる。具体的には、タスクに親子関係を導入したり、タスク
をグループ化したりするために利用することが考えられる。
・周期起動ハンドラ、アラームハンドラ（指定時刻起動ハンドラ）の機能
ITRON1では、周期起床 (cyc̲wup) の機能により、時間に関係する処理を行なうようになっていた。ITRON2では、それに加えて、周期起動ハンドラ、
指定時刻起動ハンドラ（アラームハンドラ）の機能を設ける。前者は周期的に起動されるタスク独立のハンドラであり、後者は指定時刻に起動されるタスク独立のハンドラである。これらの機能は、ITRON1の周期起床の機能と比較すると、よりプリミティブで自由度の高いメカニズムとなる。
第三部 ITRON 2

187
以上のような機能追加により、ITRON2のOS全体の仕様は、かなり大きなものになる。しかし、追加した仕様の多くは≪I2≫仕様（拡張仕様）になるので、≪I1≫仕様（基本仕様）の部分だけを見れば、ITRON1と同程度の規模である。
ITRONの場合は、適応化によってターゲットシステム上の最終的なオブジェクトを小さくすることが可能なので、適応化前の仕様としては、できるだけ多くのものを包含するという考え方になっている。従来のITRONもそのような方針に基づいて設計されたものであるが、ITRON2では、その考え方をさらに推し進めたものになっている。

第一章 ITRON 2概説

第三部 第二章

ITRON2基本機能

この章では、ITRON2でサポートを必須としている機能（≪I1≫レ
ベルのシステムコール）に関する説明を行う。このレベルの機能は、ほぼITRON1でサポートしていた機能に相当するものである。

190

タスク管理機能第三部 ITRON 2

cre̲tsk

191

タスクを生成する
cre̲tskcre̲tsk:Create Task

【パラメータ】
tskid

TaskIdentifier

タスクID

tskatrTaskAttribute

タスク属性

stadr

TaskStartAddress

タスクスタートアドレス

itskpri

InitialTaskPriority

初期優先度

stksz

UserStackSize

ユーザスタックのサイズ【リターンパラメータ】
なし【解説】
cre̲tsk では、tskid で指定された ID 番号を持つタスクを生成する。次に、生成されたタスクに対してTCBを割り付け、パラメータで与えた情報(itskpri, stadr, stksz) をもとにその初期設定を行う。
itskpriは2バイトで表現されるが、その取りうる値は (-16)〜255 に制限されている。一般に、負の優先度はシステム用として使用される。対象タス
クは生成後、DORMANT 状態となる。
ID 番号が (-4)〜0 のタスクは生成できない。また、負のID番号のタスク
は、システムタスクである。
tskatr のサイズは標準で4バイトである。tskatr のフォーマットを［図3.5］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）はユーザ属性を表わし、第二上位バイト（bit8〜bit15 あるいは2^23〜2^16 のビット）はインプリメント依存の属性を表わし、下位ハーフワード（bit16〜
bit31 あるいは 2^15〜2^0 のビット）はシステム属性を表わす。ユーザは、タスクに関する情報を入れておくために、tskatr の最上位バイトを自由に使用することができる。

第二章 ITRON 2基本機能

192

cre̲tsk

第二上位バイトのインプリメント依存属性の機能は、例えば、被デバッ
グ対象のタスクであることを指定したり、TRONCHIPのデバッグモード DBの値を設定したりするために利用できる。
tskatr のシステム属性の部分では、次のような指定を行う。
tskatr : = (TA̲ASM‖TA̲HLNG)¦ [TA̲COP0] ¦ [TA̲COP1] ¦ [TA̲COP2] ¦ [TA̲COP3]¦ [TA̲COP4] ¦ [TA̲COP5] ¦ [TA̲COP6] ¦ [TA̲COP7]
TA̲ASM

対象タスクがアセンブラで書かれている

TA̲HLNG

対象タスクが高級言語で書かれている

TA̲COPn

対象タスクが第n番目のコプロセッサを使用する（浮動小数点演算用のコプロセッサを含む）

TA̲HLNG の指定を行った場合には、タスク起動時に直接 stadr のアドレ
スにジャンプするのではなく、高級言語の環境設定プログラム（高級言語対
応ルーチン）を通してから stadr のアドレスにジャンプする。
tskatr のシステム属性の部分のうち、この他の reserved の部分は、将来マルチプロセッサ属性の指定などを行なうために利用できる。
cre̲tsk で指定した tskatr は、tsk̲sts により読み出すことができる。
タスクが DORMANT 状態の時は、すべての状態（wupcnt, suscnt を含む）
がリセットされるというのが原則である。ただし、DORMANT 状態でも例
外的にリセットされないものとしては、例外マスク状態、例外ハンドラの定義状態などがある。これらの状態は、タスクの環境設定といった意味合いのものなので、DORMANT 状態の他タスクに対しても指定可能としている。
cre̲tsk で生成されたタスクの例外マスク (emsptn) のデフォルト値は、

bit0
tskatr

bit8
ユーザ属性

bit16

インプリメント依存属性

bit31
システム属性［図3.5］tskatrのフォーマット

第三部 ITRON 2

cre̲tsk

193

˜( ECM̲CEX ¦ ECM̲TER ) となっている。すなわち、ter̲tek, ras̲ter による終了要求とCPU例外のみが受け付けられ、その他の例外はマスクされた状態となっている。タスク起動時に終了要求をマスクしておきたい場合は、
cre̲tsk の直後に set̲ems(setptn=ECM̲TER) を実行しておけば良い。
【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足（管理ブロック用の領域が確保できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲NOMEM

メモリ不足（ユーザスタック用の領域が確保できない）※ E̲NOSMEMとE̲NOMEMとの厳密な区別はインプリメ
ント依存である。

E̲RSID

予約ID番号（-4≦tskid≦0）

E̲RSATR

予約属性（tskatrの下位3バイトが不正）E̲PAR一般的なパラメータエラー（stkszが不正）

E̲ILADR

不正アドレス（stadrが奇数、あるいは使用できない値）

E̲IDOVR

ID範囲外（tskidがシステムで利用できる範囲を越えた）

E̲TPRI

不正タスク優先度（itskpriが不正）

E̲EXS

オブジェクトが既に存在している（同一ID番号のタスクが存在）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

第二章 ITRON 2基本機能

194

sta̲tsk

タスクを起動する
sta̲tsksta̲tsk:Start Task

【パラメータ】
tskid

TaskIdentifier

タスクID

stacd

TaskStartCode

タスク起動コード【リターンパラメータ】
なし【解説】tskid で示されたタスクを起動する。つまり、DORMANT 状態からREADY状態へと移す。
stacd により、タスクのスタート時にタスクに渡すパラメータを設定することができる。このパラメータは、対象タスクから参照することができ、簡単なメッセージ通信の目的で利用できる。
スタート時のタスク優先度は、対象タスクが生成された時に指定された
初期優先度となる。
このシステムコールによる起動要求のキューイングは行なわない。したがって、対象タスクが DORMANT 状態にない場合に発せられた起動要求に対しては、発行タスクにエラー E̲NODMT が戻る。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）
E̲NODMT

タスクがDORMANTでない（tskidのタスクがDORMANT
でない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行で tskid＜(-4)）

第三部 ITRON 2

del̲tsk

195

タスクを削除する
del̲tskdel̲tsk:

Delete Task

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】tskid で示されたタスクを削除する。つまり、DORMANT 状態からシステ
ムに存在しない状態へと移行させ、それに伴って TCB、スタック領域を解放する。 DORMANT 状態にでないタスクの削除はエラー E̲NODMT となる。
その後はこのタスクのID番号と同じID番号で、新しいタスクを生成することが許可される。
このシステムコールでは、自タスクの指定はできない。自タスクを指定した場合には、自タスクが DORMANT状態ではないため、E̲NODMT のエラーとなる。自タスクを削除するには、本システムコールではなく、
exd̲tskシステムコールを発行する。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）
E̲NODMT

タスクがDORMANTでない（tskidのタスクがDORMANT
でない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行で tskid＜(-4)）

第二章 ITRON 2基本機能

196

ext̲tsk

自タスクを正常終了する
ext̲tskext̲tsk:

Exit Task【パラメータ】
なし【リターンパラメータ】※ システムコールを発行したコンテキストには戻らない【解説】
自タスクを正常終了させ、DORMANT 状態へと移行させる。正常終了であるので、終了ハンドラは実行されない。本システムコールは、終了ハンドラの最後でも発行されることがある。
ext̲tsk では、タスクがそれ以前に獲得した資源（メモリブロック、セマ
フォなど）を自動的に解放するということはない。タスク終了前に資源を解放しておくのは、ユーザの責任である。
ret̲XXX および ext̲tsk, exd̲tsk, abo̲tsk システムコールでは、エラーを検出した場合にエラーコードを返しても、これらのシステムコールを呼んだ側でそのチェックを行なっていなければ、プログラムが暴走する。そこ
で、これらのシステムコールでは、エラーを検出した場合でも、決してシ
ステムコール発行元へは戻らないものとする。万一エラーを検出した場合には、メッセージバッファへのロギングやコンソールへのエラーメッセー
ジの表示を行うのが望ましいが、詳細な動作はインプリメント依存となる。
このシステムコールを準タスク部（拡張SVCハンドラ）から発行した場合
は、拡張SVCを呼んだタスクに対する終了ハンドラが起動されないまま、タスクが終了してしまう。したがって、拡張SVCハンドラからこのシステ
ムコールを発行するのは望ましくなく、E̲CTX のエラーとするべきである。
しかし、このシステムコールは元のコンテキストに戻らないシステムコー
ルなので、エラーチェックを行ったとしても、エラーコードを返すことができない。そこで、拡張SVCハンドラの中からこのシステムコールを発行した場合の動作は、インプリメント依存となっている。なお、拡張SVCハ第三部 ITRON 2

ext̲tsk

197

ンドラの中でタスクを終了する必要が生じた場合、通常は abo̲tsk を使用する。abo̲tsk を発行すれば、タスクを終了する前に、拡張SVCハンドラに対する終了ハンドラやタスクに対する終了ハンドラを起動することができる。
タスクが終了して DORMANT 状態になるときには、emsptn がタスク生
成直後と同じ値、すなわち
emsptn = ˜( ECM̲CEX ¦ ECM̲TER ¦ ECM̲ABO ¦ ECM̲SUS )にリセットされる。これは、タスク終了直前の emsptn の値とは無関係である。同様に、タスクに対する例外ハンドラも、タスクが終了してDORMANT 状態になるときにはリセットされる（未定義の状態になる）。ただし、これはタスクが他の状態から DORMANT 状態に変わる時（すなわちタスクの生成時またはタスクの終了時）にemsptn と例外ハンドラが一旦リセットされるという意味であり、既に DORMANT 状態になっている他タスクに対して、emsptn の変更や例外ハンドラの定義を行うことは可能である。タ
スクの起動前に emsptn の設定や例外ハンドラの定義を行っておく必要があ
れば、必要に応じて、sta̲tsk の前に clr̲ems や def̲Xex を実行すればよい。
これに対して、tskpri（タスク優先度）、wupcnt, suscnt などのタスク属性は、他の状態から DORMANT 状態に変わる時にリセットされるだけではなく、タスクが DORMANT 状態の間は一切変更できない。これらの属性を変更しようとするシステムコールは、E̲DMT のエラーになる。
【エラーコード】※ 次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、
システムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合には、メッセージバッファへのロギングや、コンソールへのエラーメッセージの表示などを行うのが望ましいが、詳細な動作はインプリメント依存となる。
E̲CTX

コンテキストエラー（拡張SVCハンドラ、タスク独立部
あるいはディスパッチ遅延中のタスクから発行）

第二章 ITRON 2基本機能

198

exd̲tsk

自タスクを正常終了後、削除する
exd̲tsk
exd̲tsk:

Exit and Delete Task

【パラメータ】
なし【リターンパラメータ】※ システムコールを発行したコンテキストには戻らない【解説】
自タスクを正常終了させ、さらに自タスクを削除する。すなわち、シス
テムに存在しない状態へと移行させる。正常終了であるので、終了ハンド
ラは実行されない。本システムコールは、終了ハンドラの最後でも発行されることがある。
なお、exd̲tsk で、タスクがそれ以前に獲得した資源（メモリブロック、
セマフォなど）を自動的に解放するということはない。タスク終了前に資源を解放しておくのは、ユーザの責任である。
このシステムコールを準タスク部（拡張SVCハンドラ）から発行した場合
は、拡張SVCを呼んだタスクに対する終了ハンドラが起動されないまま、タスクが終了してしまう。したがって、拡張SVCハンドラからこのシステ
ムコールを発行するのは望ましくなく、E̲CTX のエラーとするべきである。
しかし、このシステムコールは元のコンテキストに戻らないシステムコー
ルなので、エラーチェックを行ったとしても、エラーコードを返すことができない。そこで、拡張SVCハンドラの中からこのシステムコールを発行した場合の動作は、インプリメント依存となっている。なお、拡張SVCハ
ンドラの中でタスクを終了する必要が生じた場合、通常は abo̲tsk を使用する。abo̲tsk を発行すれば、タスクを終了する前に、拡張SVCハンドラに対する終了ハンドラやタスクに対する終了ハンドラを起動することができる。

第三部 ITRON 2

exd̲tsk

199【エラーコード】※ 次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、
システムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合には、メッセージバッファへのロギングや、コンソールへのエラーメッセージの表示などを行うのが望ましいが、詳細な動作はインプリメント依存となる。
E̲CTX

コンテキストエラー（拡張SVCハンドラ、タスク独立部
あるいはディスパッチ遅延中のタスクから発行）

第二章 ITRON 2基本機能

200

abo̲tsk

自タスクを異常終了させる
abo̲tskabo̲tsk:

Abort Task

【パラメータ】
exccd

ExceptionCode

例外コード【リターンパラメータ】
なし【解説】
自タスクに対して終了要求を出し、自タスクを異常終了させる。
本システムコールの発行タスクや拡張SVCハンドラに終了ハンドラが定義されていた場合には、タスクを直ちに DORMANT 状態に移行させるのではなく、制御を終了ハンドラに移すだけである。この時、終了ハンドラへのパラメータを exccd として与えることができる。
一般に、拡張SVCハンドラの中から拡張SVCハンドラを呼んだタスクを異常終了したい場合には、このシステムコールを使用する。拡張SVCハン
ドラの中から abo̲tsk を発行した場合には、まず拡張SVCハンドラに対する終了ハンドラが起動され、タスクに戻ってからタスクに対する終了ハンドラが起動される。この時の動作は、例外マスク関連の条件を除き、拡張
SVCハンドラ実行中のタスクを対象として ter̲tsk が発行された場合と同じである。これに対して、拡張SVCハンドラの中から ext̲tsk, exd̲tsk を発行
すると、タスクに対する終了ハンドラが実行されないままタスクを終了してしまう。タスクの終了処理を含むような拡張SVCハンドラを書いた場合
は、タスクに対する終了ハンドラを実行してからタスクを終了するために、
ext̲tsk や exd̲tsk ではなく、abo̲tsk を発行しなければならない。
終了ハンドラが定義されていない場合には、本システムコールにより直ちにタスクや拡張SVCハンドラを終了する。その動作は ext̲tsk, ret̲svc と同じである。拡張SVCハンドラの実行中に abo̲tsk が発行されたが拡張SVCに対する終了ハンドラが未定義だった場合、拡張SVCを呼んだ側に返すエラーコードは、abo̲tsk で指定した exccd ではなく、E̲TER になる。すなわち、第三部 ITRON 2

abo̲tsk

201

このケースでは、abo̲tsk によって ret̲svc (s̲ercd=E̲TER) 相当の処理を行うことになる。
abo̲tsk では、終了ハンドラのマスクの状態（ECM̲TER がクリアされているか、あるいはクリア可能かどうかといった状態）に関係なく、即座に終了ハンドラが起動されるものとする。すなわち、abo̲tsk を使えば、ECM̲TER がセットされていても、終了ハンドラが起動される場合がある。
ECM̲TER は、他のタスクからの終了要求 (ter̲tsk, ras̲ter) に対するマスクであり、自タスクからの終了要求（abo̲tsk, ハンドラ未定義の例外）に対するマスクを意味するものではない。また、例外ハンドラ（CPU例外ハンドラ、システムコール例外ハンドラ、強制例外ハンドラ）が未定義でマスクされておらず、これらの例外が終了要求に置き換わった場合にも、abo̲tskと同様の動作をする。すなわち、終了ハンドラのマスク状態に関係なく、即座に終了ハンドラが起動される。
終了ハンドラの起動をマスクした状態で abo̲tsk を実行し、終了ハンドラが起動された場合（ハンドラ未定義の例外が終了要求に置き換わった場合を含む）、終了ハンドラ起動前の環境の emsptn の ECM̲TER はセットされたままであると考える。すなわち、abo̲tsk によって終了ハンドラを起動する
際には ECM̲TER の状態を無視するが、この時 ECM̲TER がクリアされる
わけではない。したがって、起動された終了ハンドラで hdr̲sts を実行し、終了ハンドラを呼び出した環境の emsptn（すなわち ar̲hdrs [1].emsptn &ECM̲TER）をチェックすることにより、終了マスク中に起動された終了ハ
ンドラかどうかを調べることができる。終了マスク中に起動された終了ハ
ンドラでは、クリティカルセクションに対する処置が変ってくる可能性があるが、このような形で必要な情報を得ることができる。
終了マスク中に abo̲tsk で即座に起動されるのは、現在の環境（タスク、
拡張SVCハンドラ）に対する終了ハンドラのみである。たとえば、タスク[A] が終了マスク中に呼んだ拡張SVCハンドラ [B] の中で abo̲tsk が発行された場合、拡張SVCハンドラ [B] の終了マスクの状態にかかわらず、[B] に対する終了ハンドラは即座に起動される。しかし、[A] に対する終了ハンド
ラは、[B] に対する終了ハンドラから戻った後で即座に起動されるわけではない。[A] に対する終了ハンドラは、拡張SVCハンドラ [B] からタスク [A]の実行に戻り、終了マスクがクリアされた後で起動される。
abo̲tsk, ter̲tsk, ras̲ter による複数の終了要求のキューイングは行わない。

第二章 ITRON 2基本機能

202

abo̲tsk

すなわち、これらのシステムコールが複数回発行されても、終了ハンドラは1回しか起動されない。ただし、同一タスクに対して abo̲tsk,ter̲tsk,
ras̲ter の発行が複数回行なわれた場合は、各システムコールで指定された
exccd の論理和がとられていき、pk̲exc の exccd ではこの論理和の値が返る。
したがって、exccd をビット対応で使うことにより、疑似的に複数の要求を区別することができる。たとえば、例外コードとしての情報が1ビットで良ければ、32種類の独立した要求を区別することができる。起動された終了
ハンドラでは、exccd を見て複数の起動要求があるかどうかを判断し、内部の処理を振り分ければ良い。
なお、デフォルト例外ハンドラからの終了要求による例外コードや、将来システムで定義される予定の例外コードでは、例外コードの上位ビット（上位1〜2バイト）を使用する予定である。したがって、ユーザが abo̲tskで利用する例外コードとしては、下位ビット（下位2バイト）を使用するのが望ましい。
終了ハンドラ実行中（終了ハンドラ実行中に起動された例外ハンドラを含む）に abo̲tsk を実行した場合（終了ハンドラ実行中に例外が発生し、そのハンドラが未定義だった場合を含む）には、終了ハンドラを起動するのではなく、即座にタスクや拡張SVCハンドラを終了するものとする。すなわ
ち、ext̲tsk あるいは ret̲svc (s̲ercd=E̲TER) 相当の動作をする。これは、終了ハンドラが再帰的に起動されるのを防ぐためである。
上記の仕様を明確に表現するため、emsptn の中に ECM̲ABO というビットを設け、このビットによってabo̲tsk の動作を選択するように考える。
ECM̲ABO は終了ハンドラ実行中の間セットされており、この場合に
abo̲tsk が実行されると、拡張SVCハンドラあるいはタスクの終了を行う。
一方、終了ハンドラ実行中でない場合は ECM̲ABO がクリアされており、
この時 abo̲tsk が実行されると、終了マスクの状態にかかわらず終了ハンドラの起動を行う。ECM̲ABO は、abo̲tsk の動作に影響するビットであると同時に、終了ハンドラ実行中かどうかを示すビットでもある。ECM̲ABOのビット配置は次のようになる。
ECM̲ABO

H'00000002

ECM̲ABO は、タスク起動時や拡張SVCハンドラ起動時にはクリアされている。終了ハンドラ起動時には、ECM̲ABO が自動的にセットされる。
一方、例外ハンドラ起動時には ECM̲ABO の値は変わらない。たとえば、第三部 ITRON 2

abo̲tsk

203

終了ハンドラから呼ばれた例外ハンドラでは、ECM̲ABO はセットされたままである。すなわち、終了ハンドラから呼ばれた例外ハンドラの中で
abo̲tsk が実行されても、再度終了ハンドラが起動されるわけではなく、そのタスクあるいは拡張SVCハンドラを終了する。なお、clr̲ems, set̲ems では、ECM̲ABO のビットを操作（変更）できないものとする。clr̲ems,
set̲ems により ECM̲ABO のビットを操作しようとした場合には、E̲PARのエラーになる。
終了要求が出された場合、その対象タスク（abo̲tskの場合は自タスク）
は、ECM̲TER のマスク状態や拡張SVCハンドラ実行中かどうかにかかわらず、直ちに最高のタスク優先度になる。すなわち、abo̲tsk の処理の中にchg̲pri の処理を含むと考えることができる。また、終了マスクのため、拡張SVCに対する終了ハンドラとタスクに対する終了ハンドラが連続して実行されない場合でも、その間で実行されるタスク部（ECM̲TER をマスクした状態）の優先度は、最高の状態のままになっている。これは、終了要求の緊急性を考慮したためである。
【エラーコード】※ 次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、
システムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合には、メッセージバッファへのロギングや、コンソールへのエラーメッセージの表示などを行うのが望ましいが、詳細な動作はインプリメント依存となる。
E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

第二章 ITRON 2基本機能

204

ter̲tskras̲ter

他タスクを強制的に異常終了させる
ter̲tsk

他タスクに対して終了要求を出す
ras̲terter̲tsk:

Terminate Task

ras̲ter:Raise Terminate【パラメータ】
tskid

TaskIdentifier

タスクID

exccd

ExceptionCode

例外コード【リターンパラメータ】
なし【解説】tskid で示されたタスクに対して終了処理要求を出し、対象タスクを強制的に異常終了させる。
ter̲tsk, ras̲ter の対象タスクが終了ハンドラを定義していた場合には、対象タスクにそれを実行させる。すなわち、対象タスクが直ちに DORMANT 状態に移行するのではなく、対象タスクの制御を終了ハンドラに移す。この時、終了ハンドラへのパラメータを exccd として与えることができる。 exccd は、対象タスクのスタックを通じて、対象タスクから参照することができる。
ter̲tsk, ras̲ter の対象タスクが終了処理要求をマスクしていた場合は、マスクが解除されるまで終了ハンドラの起動が遅延させられる。この機能は、対象タスクがクリティカルセクション中で強制終了させられるのを防ぐためのものである。
ter̲tsk の場合は、対象タスクが待ち状態に入り、何らかの待ち行列につながれていても、その待ち状態を強制解除する。これは、終了ハンドラのマスク状態には関係しない。終了ハンドラの起動をマスクしたまま待ち状態に入っていたタスクに対して ter̲tsk が発行されると、待ち状態は解除されて E̲RLWAI のエラーが返るが、終了ハンドラは起動されない。

第三部 ITRON 2

ter̲tsk

ras̲ter

205

また、ter̲tsk では、対象タスクが強制待ち状態（SUSPEND状態）であっても、強制的に実行を再開させる。すなわち、ter̲tsk の処理は、rel̲wai の処理と frsm̲tsk の処理を含んでいる。ter̲tsk では SUSPEND状態が解除されるため、当然 suscnt もクリアされて0になる。
一方、ras̲ter では、対象タスクの待ち状態や強制待ち状態を解除することはない。待ち状態のタスクに対して ras̲ter が発行された場合、終了ハンドラが起動されるのは他の要因によって待ち状態が解除された後になる。
ter̲tsk で対象タスクの終了ハンドラが定義されておらず、かつ終了ハンド
ラの起動がマスクされていない場合には、本システムコールにより対象タス
クが直ちに終了する。この場合、ext̲tsk 等と同様に、対象タスクがそれ以前に獲得した資源（メモリブロック、セマフォなど）は自動的に解放されないので、注意が必要である。終了ハンドラの起動がマスクされ、かつ終了ハンドラが定義されていない場合には、マスクが解除されるまでタスクの終了が遅らされる。対象タスクが待ち状態や強制待ち状態であった場合でも、
ter̲tsk によりそれらの待ち状態が解除されるため、上記と同じ動作をする。
ras̲ter の動作も ter̲tsk とほぼ同様であるが、対象タスクが待ち状態だった場
合には、他の要因により待ち状態が解除された後でタスクが終了する。
対象タスクが拡張SVC実行中であった場合には、タスクに対する終了ハ
ンドラを起動する代りに拡張SVCに対する終了ハンドラが起動される。拡
張SVCに対する終了ハンドラが定義されていない場合は、タスクを終了する代りに、即座に拡張SVCハンドラからリターンする。拡張SVCハンドラ
実行中も、終了ハンドラの起動や拡張SVCハンドラの終了（拡張SVCハンドラからのリターン）をマスクすることが可能であるが、例外マスクの値はタ
スク実行中とは異なったものが使用される。
（例外管理の説明を参照）。
ter̲tsk, ras̲ter では、自タスクの指定はできない。自タスクを指定した場
合は E̲SELF のエラーとなる。
終了要求が出された場合、その対象タスクは、ECM̲TER のマスク状態や拡張SVCハンドラ実行中かどうかにかかわらず、直ちに最高のタスク優先度になる。すなわち、ter̲tsk, ras̲ter の処理の中に chg̲pri の処理を含むと考えることができる。また、終了マスクのため、拡張SVCに対する終了ハンドラとタスクに対する終了ハンドラが連続して実行されない場合でも、その間で実行されるタスク部（ECM̲TER をマスクした状態）の優先度は、最高の状態のままになっている。これは、終了要求の緊急性を考慮したためである。

第二章 ITRON 2基本機能

206

ter̲tskras̲ter

タスク{A}

拡張SVC{B}(def̲svcで定義)

set̲ems (終了要求)

拡張SVC{B}に対する終了ハンドラ {BE}(sdef̲ext で定義)

set̲ems (終了要求)
終了要求

cal̲svc(B)clr̲ems (終了要求)✩

拡張SVC{B}に対する資源回収ret̲svc
タスク{A}に対する終了ハンドラ {AE}clr̲ems (終了要求)

タスク{A}に対する資源回収ext-tsk＊ ' ' は最高の優先度で実行される区間を示す。

［図3.6］終了ハンドラとタスク優先度の変化

拡張SVCハンドラ実行中に終了要求を受け付け、拡張SVCハンドラに対する終了ハンドラが起動された場合のタスク優先度の変化を［図3.6］に示す。
なお、終了要求の受け付けにより最高の優先度になった後も、優先度の変更は可能である。終了要求によるタスク優先度の変更は終了要求のシステム
コール発行時に行われるだけであり、その後のタスク優先度の変更は自由である。例えば、［図3.6］の{BE}の中でタスク優先度が変更された場合、変更後の優先度は、タスク{A}のcal̲svc (B)の後の部分や、{AE}の中でも有効である。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦-1、タスク独立部の発行でtskid=0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲SELF

自タスク、自プロセスの指定（tskidが自タスク、タスク部
や準タスク部の発行でtskid=0）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

第三部 ITRON 2

chg̲pri

207

タスク優先度を変更する
chg̲prichg̲pri:Change Task Priority【パラメータ】
tskid

TaskIdentifier

タスクID

tskpri

TaskPriority

優先度【リターンパラメータ】
なし【解説】chg̲pri では、tskid で示されたタスクの現在の優先度を、tskpri で示される値に変更する。tskid = TSK̲SELF によって自タスクの指定になる。
タスクの優先度は、数の小さい方が高い優先度となる。対象タスクが何らかの待ち行列につながれていた場合には、このシステムコールにより待ち行列の順番が変わることがある。
tskpri = TPRI̲INI (0) の指定により、タスク生成時に指定された優先度（タスクの固有優先度）に戻るものとする。
このシステムコールで変更した優先度は、タスクが終了するまで（あるいは終了ハンドラが起動されるまで）有効である。タスクが DORMANT 状
態になると、終了前のタスク優先度は捨てられ、次にタスクが起動された時のタスク優先度は、タスク生成時に指定された優先度 itskpri になる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲TPRI

不正タスク優先度（tskpriが不正）

E̲RSID

予約ID番号（-4≦tskid≦-1、タスク独立部の発行でtskid=0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しな

い）
E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

第二章

ITRON2基本機能

208

rot̲rdq

タスクのレディキューを回転する
rot̲rdqrot̲rdq:

Rotate Ready Queue【パラメータ】
tskpri

TaskPriority

優先度【リターンパラメータ】
なし【解説】tskpri で示される優先度のレディキューを回転する。すなわち、その優先
度のレディキューの先頭につながれているタスクをレディキューの最後尾につなぎかえ、同一優先度のタスクの実行を切り換える。このシステムコールを一定時間間隔で発行することにより、ラウンドロビン・スケジュー
リングを行なうことが可能となる。
tskpri = TPRI̲RUN(0) により、その時実行状態にあるタスクを含むレディキュー（最高優先度のレディキュー）を回転させるものとする。一般のタ
スクから発行される rot̲rdq では、これは自タスクの持つ優先度のレディキ
ューを回転するのと同じ意味になるが、このような仕様にしておけば、周期起動ハンドラなどのタスク独立部から rot̲rdq (tskpri=TPRI̲RUN) を発行することも可能である。
rot̲rdq の tskpri として TPRI̲RUN または自タスクの優先度を指定した場
合には、自タスクがそのレディキューの後ろにまわることになる。つまり、自ら実行権を放棄するために、rot̲rdq を発行することができる。
（ここで言う「レディキュー」は、実行状態のタスクも含んだものと考えている。）
指定した優先度のレディキューにタスクがない場合は何もしないが、エラーとはならない。
rot̲rdq の実行例を［図3.7 (a)］,［図3.7 (b)］に示す。
［図3.7 (a)］の状態で、
tskpri = 2をパラメータとしてこのシステムコールが呼ばれると、新しいレディキューの状態は［図3.7 (b) ］のようになり、次に実行されるのはタスクC
となる。

第三部

ITRON2rot̲rdq【エラーコード (ercd)】
E̲OK

正常終了

E̲TPRI

不正タスク優先度（tskpriが不正）

優先度
高

低

1
2

[タスクB]

3[タスクE][タスクC][タスクD]［図3.7 (a)］rot̲rdq 実行前のレディキューの状態

優先度
高

低

1
2

[タスクC]

3[タスクE][タスクD][タスクD]＊次に実行されるのはタスクCである。

［図3.7 (b)］rot̲rdq (tskpri = 2) 実行後のレディキューの状態

第二章 ITRON 2基本機能

209

210

rel̲wai

タスクの待ち状態を強制解除する
rel̲wairel̲wai:

Release Wait

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】
rel̲wai では、tskid で示されるタスクが何らかの待ち状態（SUSPEND状態を除く）にある場合に、それを強制的に解除する。
本システムコールにより待ち状態が解除されたタスクに対しては、エラー E̲RLWAI が返る。アラームハンドラ等を用いて、あるタスクが待ち状態に入ってから一定時間後にこのシステムコールを発行することにより、タイムアウトに類似した機能を実現することができる。
本システムコールでは、待ち状態解除要求のキューイングは行わない。
tskidで示される対象タスクが既に待ち状態であればその待ち状態を解除す
るが、対象タスクが待ち状態でなければ、発行元にエラー E̲NOWAI が返る。本システムコールで自タスクを指定した場合にも、同様に E̲NOWAIのエラーとなる。
本システムコールでは、SUSPEND状態の解除は行わない。二重待ち状態(WAIT-SUSPEND) のタスクを対象としてこのシステムコールを発行すると、対象タスクはSUSPEND状態となる。SUSPEND状態も解除する必要がある場合には、別に frsm̲tsk を発行する必要がある。
rel̲wai と wup̲tsk との違いをまとめると、次のようになる。
― wup̲tsk は slp̲tsk, wai̲tsk による待ち状態のみを解除するが、rel̲wai
ではそれ以外の要因（wai̲flg, wai̲sem, rcv̲msg, get̲blk 等）による待ち状態も解除する。
― 待ち状態に入っていたタスクから見ると、wup̲tsk による待ち状態の解除は正常終了(E̲OK) であるのに対して、rel̲wai による待ち状態の第三部 ITRON 2

rel̲wai211

解除はエラー(E̲RLWAI) である。
― wup̲tsk の場合は、対象タスクがまだ slp̲tsk, wai̲tsk を実行していな
くても、要求がキューイングされる。一方、rel̲wai の場合は、対象タ
スクが既に待ち状態に無い場合にはエラーとなる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しな

い）
E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲NOWAI

タスクが待ち状態でない（tskidが自タスクの場合を含む）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

第二章 ITRON 2基本機能

212

get̲tid

自タスクのIDを得る
get̲tidget̲tid:

Get Task Identifier【パラメータ】
なし【リターンパラメータ】
tskid

TaskIdentifier

タスクID

【解説】
自タスクのID番号を得る。タスク独立部から発行された場合は、タスク
独立部のため tskid が得られなかったという意味で FALSE = 0が返る。
【エラーコード (ercd)】
E̲OK

正常終了

第三部 ITRON 2

tsk̲sts213

タスクの状態を見る
tsk̲ststsk̲sts:

Get Task Status【パラメータ】
tskid

TaskIdentifier

pk̲tsks

Packet of TaskStatus タスク状態を返すパケットの先頭アドレス

タスクID【リターンパラメータ】
なし【解説】tsk̲sts では、tskid で示されたタスクの状態を読み出し、その結果をpk̲tsks 以下の領域に返す。
pk̲tsks に返される情報としては、次のようなものがある。
tskatr/* タスク属性 */spcid/*スペースID、MMU 未サポートや共有空間の場合は TSP̲CMN */tskstat/* タスク状態 */epndptn/* ペンディング中の終了要求と強制例外 */tskwait/* 待ち要因 */wid/* 待ちオブジェクトID */suscnt/* SUSPEND要求カウント、0≦suscnt＜2^31 */wupcnt/* 起床要求カウント、0≦wupcnt＜2^31 */stadr/* タスクスタートアドレス */isp/* 初期SP値 */itskpri/* 初期優先度 */tskpri/* 現在優先度 */このうち、tskstat は次のような値をとる。

第二章 ITRON 2基本機能

214

tsk̲sts

tskstat:
TTS̲RUN

RUN状態

TTS̲RDY

READY状態

TTS̲WAIWAIT状態TTS̲SUSSUSPEND状態

TTS̲WAS

WAIT-SUSPEND状態

TTS̲DMT

DORMANT状態

TTS̲DBG

デバッグ待ち状態

上記のうち、TTS̲DBG は他のすべての状態と複合することができる。
また、TTS̲SUS と TTS̲WAI を複合した状態が TTS̲WAS である。tskstat
が TTS̲SUS（TTS̲WAS を含む）の場合は、必ず suscnt＞0 となる。
tskstat が TTS̲WAI（TTS̲WAS を含む）の場合、tskwait, wid は［表3.1］のような値をとる。
tskstat が TTS̲WAI（TTS̲WAS を含む）でない場合は、tskwait, wid はともに0となる。
なお、tskstat, tskwait として上記のような値が定義されているが、これは、同じ値を TCB に入れなければならないという意味ではない。TCB 内での表
現方法はインプリメント依存であり、tsk̲sts 実行時に、TTS̲RUN, TTS̲WAI
等の標準値に変換すれば良いわけである。
tskid = TSK̲SELF によって自タスクの指定になるが、このシステムコー
ルで は 自 タ ス ク のID は わ か ら な い 。 自 タ ス ク のID を知りたい場合は、
get̲tid を利用する。
tsk̲sts で、対象タスクが存在しないタスクであれば、エラー E̲NOEXSとする。
タスクが DORMANT 状態の時は、すべての状態（wupcnt, suscnt を含む）
がリセットされるというのが原則である。すなわち、DORMANT 状態のタ
スクでは wupcnt=0, suscnt=0 であり、また、tskstat = ( TTS̲DMT ¦ TTS̲SUS )といった複合状態は無い。
割込みハンドラの中から、割り込まれたタスクを対象とした tsk̲sts を実行した場合、tskstat として RUN状態 (TTS̲RUN) を返すものとする。これは、割込みハンドラが、タスクとは別のレベルで動くものと考えられるためである。また、もしこの場合に実行可能状態を返すと、この時点で実行状態

第三部 ITRON 2

tsk̲sts

215のタスクが一つも無くなるため、変則的な状況になる。
（強いて言えば割込
みハンドラが「実行状態」ということであるが、タスク独立部はタスク状態を持たないので、これは不合理である。）【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦-1、タスク独立部の発行でtskid=0）

E̲ILADR

不正アドレス（pk̲tsksが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

tskwait

意味

wid

TTW̲SLP
TTW̲DLY
TTW̲FLG
TTW̲SEM
TTW̲MBX
TTW̲MPL
TTW̲MBF
TTW̲CAL
TTW̲ACPTTW̲RPL
TTW̲LMPslp̲tsk, wai̲tsk による待ちdly̲tsk による待ちwai̲flg による待ちwai̲sem, uwai̲sem による待ち
rcv̲msg, urcv̲msg による待ちget̲blk, uget̲blk による待ち
rcv̲mbf による待ちランデブ呼出待ち
ランデブ受付待ち
ランデブ終了待ちget̲lbl, uget̲lbl による待ち

00
待ち対象のflgid
待ち対象のsemid
待ち対象のmbxid
待ち対象のmplid
待ち対象のmblid
待ち対象のporid
待ち対象のporid
待ち対象のporid
待ち対象のlmpid［表3.1］tskwaitとwidの値

第二章 ITRON 2基本機能

216

hdr̲sts

ハンドラ実行環境を参照する
hdr̲sts
hdr̲sts:

Get Handler Status【パラメータ】
tskid

TaskIdentifier

タスクID

ar̲hdrs

Array of Handlers

ハンドラ実行環境の情報を返す配列へのポインタ

hdstartStartLevel of Handlers

実行環境の参照を開始する
ハンドラのネスト段数

hdcnt

Count of Hanldlers

実行環境の参照を行うハンドラの段数【リターンパラメータ】
なし【解説】tskidで示されたタスクがハンドラ（例外ハンドラ、拡張SVCハンドラ）を実行中かどうかを調べ、その情報（ハンドラ実行環境）を ar̲hdrs 以下の領域に返す。tskid = TSK̲SELF により自タスクの指定になる。ハンドラがネストしていた場合には、ネストしたハンドラの各段に関するハンドラ実行
環境の情報を、ar̲hdrs 以下の領域に配列として返す。
ar̲hdrs は、以下のような情報を含む構造体 (T̲HDRS) の配列である。
emsptn/* 例外マスク */pk̲exc/* 例外情報を示すパケットへのポインタ */pk̲regs/*ハンドラ起動時のレジスタを入れたパケット

pk̲eit/*ハンドラ起動時の PC, PSW を入れたパケット

へのポインタ */へのポインタ */ネストした各段のハンドラに対して、これらの情報を含んだ一つの構造体が対応する。現在実行中のハンドラから数えて hdstart 段目より hdcnt 段

第三部 ITRON 2

hdr̲sts
exccd
終了要求
強制例外
CPU例外
システムコール例外

ter̲tsk(ras̲ter)で指定したexccd
ras̲fexで指定したexccd
CPU例外に関する情報(EITINF等)
ercd(ret̲svcで指定したs̲ercd)

217

eclsptn
ECM̲TERECM̲FEXECM̲CEXercd(s̲ercd)に依存＊ システムコール例外の場合の eclsptn は、ercd(s̲ercd) 中のercls フィールドによって決まる。したがって、eclsptn の情報は、exccd の情報と重複している。

［表3.2］例外の種類とexccd, eclsptnとの関係

数のハンドラに関して、上記の情報を含む構造体を配列にしたもの（要素数はhdcnt個）が ar̲hdrs に返される。
ar̲hdrs に返される情報のうち、emsptn は、その例外ハンドラ、あるいは
拡張SVCハンドラの実行環境における例外マスクの値を示す。
pk̲exc は、例外ハンドラ（終了ハンドラ、強制例外ハンドラを含む）の場合にのみ有効な値を持ち、拡張SVCハンドラの場合には NADR となる。
例外ハンドラの場合、pk̲exc の指す領域には以下のような情報を含んでいる。
eclsptn/* 例外クラスビットパターン */exccd/* 例外コード（エラーコード） */fncd/* 例外発生システムコール機能コード */その他/* インプリメント依存追加情報 */この中の eclsptn の内容を調べることにより、このハンドラが終了ハンド
ラ、強制例外ハンドラ、CPU例外ハンドラ、システムコール例外ハンドラのいずれであるかを知ることができる。また、上記のうち、fncd はシステ
ムコール例外ハンドラの場合にのみ意味を持ち、他の場合には0となる。発生した例外の種類と、pk̲exc の中の exccd, eclsptn との関係は、［表3.2］のようになる。
pk̲regs は、ハンドラ起動時の汎用レジスタ（このハンドラが起動されたことにより退避された汎用レジスタ）を含むパケットへのポインタである。
また、pk̲eit は、ハンドラ起動時の PC, PSW（このハンドラが起動されたことにより退避された PC, PSW）を含むパケットへのポインタである。ここで、pk̲eit の指す T̲EIT 構造体には、pc, psw 以外に eitinf, expc などの情報

第二章 ITRON 2基本機能

218

hdr̲stsも含まれているが、このシステムコールで返される pk̲eit ではそれらの情報が入るべき領域は使用していない。eitinf, expc など未使用の領域を読み出した場合には、インプリメント依存の不定値が返る。また、拡張SVCハン
ドラ実行中の状態の場合は、pk̲regs に含まれているレジスタの値（機能コードを入れるレジスタの値、ITRON/CHIPの場合は r 0）を調べることにより、実行中の拡張SVCの機能コードを知ることができる。
ハンドラのネストの段数が (hdstart + hdcnt) よりも少なく、hdstart 以上であった場合には、ar̲hdrs の配列のその次の要素の pk̲eit の値が NADR となる。すなわち、ハンドラのネストの深さをNとすると、hdstart≦N＜(hdstart+ hdcnt) の場合に ar̲hdrs[N-hdstart].pk̲eit が NADR となる。特に、タスクが全くハンドラを呼んでいない状態(N=0) において、hdstart=0, hdcnt＞0 としてこのシステムコールを発行すると、ar̲hdrs [0].pk̲eit が NADR となる
この場合、ar̲hdrs の配列のそれ以下の要素に対する pk̲eit、すなわち
ar̲hdrs[N-hdstart+1].pk̲eit,ar̲hdrs[N-hdstart+2].pk̲eit, ... ar̲hdrs[hdcnt-1].pk̲eitの 値 は 不 定 で あ る 。 ま た 、 ar̲hdrs[N-hdstart].pk̲exc, ar̲hdrs[Nhdstart+1].pk̲exc, ... ar̲hdrs[hdcnt-1].pk̲exc の 値 や 、 ar̲hdrs[Nhdstart].pk̲regs, ar̲hdrs[N-hdstart+2].pk̲regs, ... ar̲hdrs[hdcnt-1].pk̲regs の値も不定である。
hdstart＞N の場合は、hdstart = N の場合と同じ動作をするものとする。すなわち、hdstart＞N, hdcnt＞0の場合は ar̲hdrs [0].pk̲eit が NADR になり、
hdstart＞N, hdcnt = 0 の場合は ar̲hdrs の領域は無変化で、単に E̲OK が返る。
ハンドラのネストの段数が (hdstart + hdcnt) で指定した数よりも多い場合には、用意した配列の長さが短すぎるということであるから、E̲AROVRのエラーとする。なお、エラー発生の場合にはできるだけ元の状態に戻すという一般原則とは異なり、このエラーの場合は、hdcnt 段までのハンドラの情報が ar̲hdrs に返される。また、hdcnt が 0 の場合にも同様の動作をするが、この場合は、エラーコードが E̲AROVR かどうかによって、ハンドラのネストの段数が hdstart より多いかどうかをチェックすることになる。
hdcnt が 0 であれば、ar̲hdrs の指す領域の内容は変化しない。
pk̲exc, pk̲regs, pk̲eit は、例外ハンドラの起動時にパラメータとして渡される情報と同じものである。

第三部 ITRON 2

hdr̲sts219【hdr̲sts の実行例】［図3.8］は、タスク{A}で XXX̲YYY のシステムコールを発行したが、XXX̲YYY でエラーが検出されたためシステムコール例外ハンドラ{B}が起動され、{B}の中でさらに拡張SVCハンドラ{C}を呼び、{C}の中で CPU例
外が発生したためCPU例外ハンドラ{D}が起動された様子を示したものである。このような状況で hdr̲sts (hdstart = 0, hdcnt = 5) が発行された場合に、
ar̲hdrs に戻される情報は次のようになる。

タスク {A}＜1＞
XXX̲YYY
システムコール例外

システムコール
例外ハンドラ {B}

拡張SVC
ハンドラ {C}

拡張SVCに対する
CPU例外ハンドラ {D}＜2＞cal̲svc

＜3＞
CPU例外

＜4＞
hdr̲sts

ret̲exc

ret̲svc

ret̲exc［図3.8］hdr̲stsの実行環境の例

第二章 ITRON 2基本機能

220

hdr̲stsar̲hdrs[0].emsptn= 例外ハンドラ{D}の環境の例外マスク

ar̲hdrs[0].pk̲exc->eclsptn = ECM̲CEX
ar̲hdrs[0].pk̲exc->exccd= {C}で発生したCPU例外のEITINF（CPU例外の例外コード）

ar̲hdrs[0].pk̲exc->fncd=0ar̲hdrs[0].pk̲regs= CPU例外発生直前(＜3＞)の{C}のレジスタ値

ar̲hdrs[0].pk̲eit= CPU例外発生直前(＜3＞)の{C}のPC,PSW

ar̲hdrs[1].emsptn= 拡張SVCハンドラ{C}の環境の例外マスク

ar̲hdrs[1].pk̲exc= NADRar̲hdrs[1].pk̲regs= 拡張SVC呼びだし直前(＜2＞)の{B}のレジスタ値

ar̲hdrs[1].pk̲regs->r0= {C}の拡張SVCの機能コード

ar̲hdrs[1].pk̲eit= 拡張SVC呼びだし直前(＜2＞)の{B}のPC,PSW

ar̲hdrs[2].emsptn= 例外ハンドラ{B}の環境の例外マスク

ar̲hdrs[2].pk̲exc->eclsptn = {A}で発生したシステムコール例外の例外クラス（XXX̲YYYで戻されたエラーコードの例外クラス）
ar̲hdrs[2].pk̲exc->exccd= XXX̲YYYで戻されたエラーコード（システムコール例外の例外コード）

ar̲hdrs[2].pk̲exc->fncd= XXX̲YYYの機能コード

ar̲hdrs[2].pk̲regs= XXX̲YYY実行直後の{A}のレジスタ値

ar̲hdrs[2].pk̲regs->r0= XXX̲YYYで戻されたエラーコード（ar̲hdrs[2].pk̲exc->exccdと同じ）

ar̲hdrs[2].pk̲eit= XXX̲YYY実行直後の{A}のPC,PSW

ar̲hdrs[3].emsptn= タスク{A}の環境の例外マスク

ar̲hdrs[3].pk̲exc= 不定

ar̲hdrs[3].pk̲regs= 不定

ar̲hdrs[3].pk̲eit= NADRar̲hdrs[4].emsptn= 不定ar̲hdrs[4].pk̲exc= 不定

ar̲hdrs[4].pk̲regs= 不定

ar̲hdrs[4].pk̲eit= 不定

第三部 ITRON 2

hdr̲sts

221{D}のCPU例外ハンドラの起動時に渡される pk̲exc, pk̲regs, pk̲eit の値
は、上記の ar̲hdrs[0].pk̲exc,ar̲hdrs [0].pk̲regs, ar̲hdrs[0].pk̲eit の値と同じものになる。また、{B}のシステムコール例外ハンドラの起動時に渡される
pk̲exc, pk̲regs, pk̲eit の 値 は 、 上 記 の ar̲hdrs [2].pk̲exc, ar̲hdrs[2].pk̲regs,ar̲hdrs[2].pk̲eit の値と同じものになる。
なお、hdr̲sts では、{D}の環境のレジスタ値や PSW 値を参照することはできない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦-1、タスク独立部の発行でtskid=0）

E̲PAR

一般的なパラメータエラー（hdstart＜0、hdcnt＜0）

E̲ILADR

不正アドレス（ar̲hdrsが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

E̲AROVR

用意した領域のサイズが小さすぎる

第二章 ITRON 2基本機能

222

タスク付属同期機能

第三部 ITRON 2

sus̲tsk

223

タスクを強制待ち状態へ移行する
sus̲tsksus̲tsk:

Suspend Task

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】tskid で示されたタスクの実行を中断させ、強制待ち状態に移す。強制待ち状態は、rsm̲tsk システムコールの発行によって解除される。強制待ち状
態は、他タスクのシステムコールによる中断状態を意味するものなので、本システムコールで自タスクを指定することはできない。
sus̲tsk の要求はキューイングされる。すなわち、対象タスクが既に待ち状態や強制待ち状態であっても、sus̲tsk の要求は無視されず、多重の待ち状態となる。sus̲tsk が発行された回数だけ rsm̲tsk を発行すると、必ずもとの状態に戻るため、sus̲tsk 〜 rsm̲tsk の対をネストすることが可能である。
WAIT-SUSPEND 状態のタスクに対しても、WAIT状態のタスクと同じように資源の割り当てが行なわれる。資源が割当てられることにより、そのタス
クは SUSPEND 状態に移行する。WAIT-SUSPEND 状態のタスクに対する特別措置（資源割り当て遅延など）は取らない。これは、以下のような理由による。
― システムコールの意味的な問題
SUSPEND 状態は、他の処理とは直交した関係のものであり、SUSPENDの時だけ勝手に別の仕様に変えるのは良くないという考えによる。
― 必要な場合は使い方の問題で対処可能であること
SUSPEND 状態のタスクの優先度を一時的に下げたいのであれば、ユーザ
タスクのレベルで、sus̲tsk,rsm̲tsk に chg̲pri を組み合せて発行すれば済む。
サスペンド要求 (suscnt) のキューイング数の最大値は、標準で (2^31-1)
である。ただし、'^' はべき乗を表わす。

第二章 ITRON 2基本機能

224

sus̲tsk

拡張SVCハンドラ実行中は SUSPEND 要求を遅延（拒否）させることができる。具体的には、SUSPEND 要求を遅延させるかどうかの選択を例外マス
ク環境（例外管理の章参照）に含め、emsptn の最下位ビット (ECM̲SUS) を
SUSPEND 要求拒否ビットとしている。ECM̲SUS がセットされている間は、
SUSPEND 要求が遅延させられる。
拡張SVCハンドラ起動時のデフォルト値は、ECM̲SUS がセットされた状態であり、そのままの状態では、拡張SVCハンドラが終了するまで
SUSPEND 要求の遅延が行われる。拡張SVCハンドラが動き出してから、
clr̲ems (clrptn=˜ECM̲SUS) を実行することにより、それ以後は SUSPEND
要求を受け付けることができるようになる。
一方、タスク実行中は、ECM̲SUS がクリアされた状態となっており、
SUSPEND 要求は常に受け付け可能である。タスク実行中に set̲ems (setptn= ECM̲SUS) を実行した場合は、E̲PAR のエラーとなる。
'
'
'

タスク

' ECM̲SUS クリア状態、SUSPEND 要求受付可' ECM̲SUS セット状態（クリア可）' ECM̲SUS セット状態（クリア不可）

拡張SVCハンドラA

拡張SVCハンドラB

clr̲ems ( 〜 ECM̲SUS)

cal̲svc̲B
set̲ems (ECM̲SUS)

ret̲svc
拡張SVCハンドラC

cal̲svc̲C
ret̲exc

cal̲svc̲A
ret̲svc［図3.9］ECM̲SUSをクリアできないケース
第三部 ITRON 2

sus̲tsk

225

タスク、あるいは拡張SVCハンドラに対する例外ハンドラが起動された
場合、例外マスク環境の中の ECM̲SUSの値は、例外ハンドラ起動前の値をそのまま引き継ぐ。
SUSPEND 要求を遅延させている間は、その中からネストして呼ばれた
拡張SVCハンドラや例外ハンドラの実行中も SUSPEND 要求を遅延させる必要がある。したがって、拡張SVCハンドラを呼んだ側の環境で SUSPEND
要求を遅延していた場合には、呼ばれた側の拡張SVCハンドラでは遅延状態を解除できないものとする。具体的には、clr̲ems (clrptn=˜ECM̲SUS) を実行した場合に E̲PAR のエラーになる。
拡張SVCハンドラの中で ECM̲SUS をクリアできないケースについて、具体的な動作例を［図3.9］に示す。
sus̲tsk の対象タスクが ECM̲SUS をセットした状態になっていた場合でも、SUSPEND 要求が受け付けられないのではなく、遅延させられるだけである。したがって、sus̲tsk を発行した側にはエラーが返らない。また、
SUSPEND 要求が遅延させられている間も、tsk̲sts で返る suscnt の情報はこのタスクに対する sus̲tsk の実行を反映したものになっている。SUSPEND
要求の遅延中は、suscnt＞0かつ tskstat≠TTS̲SUSとなることがある。
インプリメント上は、suscnt＞0 の場合に SUSPEND 状態とするのではな
く、suscnt＞0.and. (emsptn &ECM̲SUS) = 0 の場合に SUSPEND 状態とすれば良いことになる。また、例外マスク環境が変る時（clr̲ems,ret̲exc, ret̲svc等）には、遅延されている SUSPEND 要求が無いかどうかのチェックをする
必要が生じる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦-1、タスク独立部の発行でtskid = 0）E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲SELF

自タスク、自プロセスの指定（tskidが自タスク、タスク部
や準タスク部の発行でtskid = 0）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

E̲QOVR

キューイングのオーバーフロー（suscntのオーバーフロー）第二章 ITRON 2基本機能

226

rsm̲tsk

frsm̲tsk

強制待ち状態のタスクを再開する
rsm̲tsk

強制待ち状態のタスクを強制再開する
frsm̲tsk
rsm̲tsk:

Resume Task

frsm̲tsk:

Force Resume Task

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】tskid で示されたタスクが sus̲tsk システムコールによって中断されている場合、対象タスクの強制待ち状態を解除し、実行を再開させる。本シス
テムコールでは、自タスクを指定することはできない。
rsm̲tsk システムコールでは、一回分の sus̲tsk 要求を解除する。また、
frsm̲tsk システムコールでは、sus̲tsk 要求が複数回キューイングされていても、それらをすべて解除する。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦-1、タスク独立部の発行でtskid = 0）E̲IDOVR

ID範囲外（インプリメント依存）

E̲SELF

自タスク、自プロセスの指定（tskidが自タスク、タスク部
や準タスク部の発行でtskid=0）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲NOSUS

タスクがSUSPENDでないE̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

第三部 ITRON 2

slp̲tsk

wai̲tsk227

タスクを待ち状態へ移行する
slp̲tsk

タスクを一定時間待ち状態に移行する
wai̲tsk
slp̲tsk:

Sleep Task

wai̲tsk:

Wait for Wakeup Task

【パラメータ】＜1＞tmout

Timeout

タイムアウト指定［＜1＞wai̲tsk のみ］【リターンパラメータ】
なし【解説】
slp̲tsk システムコールでは、自タスクを実行状態から待ち状態に移す。
この待ち状態は、本タスクを対象として発行された wup̲tsk システムコー
ルにより解除される。
wai̲tsk システムコールでは、自タスクを一定時間だけ実行状態から待ち状態に移す。この待ち状態は、本タスクを対象とした wup̲tsk システムコールの発行、本タスクを対象とした ter̲tsk, ras̲fex システムコールの発行、あるいは tmout で指定した時間の経過により解除される。wup̲tsk が発行された場合は正常終了、時間経過の場合はタイムアウトエラー E̲TMOUT としてリターンする。このシステムコールは、slp̲tsk システムコールにタイ
ムアウト機能を付けたものである。
wai̲tsk の tmout は正の値のみが有効である。(-2^31)〜(-2) の値の指定はreserved であり、指定した場合には E̲ILTIME のエラーとなる。また、
tmout = TMO̲FEVR によりタイムアウト指定が行なわれないことを示す。
この場合は、wup̲tsk が発行されるまで永久に待ち状態になるため、slp̲tskと同じ動作をする。また、wai̲tsk で tmout = TMO̲POL を利用することも可能である。wai̲tsk (tmout = TMO̲POL) では、起床要求が出ているかどう

第二章 ITRON 2基本機能

228

slp̲tsk

wai̲tsk

かをチェックして、起床要求が出ている場合にはそれを1つ減らして正常終了し、起床要求が出ていない場合には E̲TMOUT のエラーになる。
自タスクの指定のみであるため、slp̲tsk, wai̲tsk のネスティングは有り得ないが、slp̲tsk, wai̲tsk により待ち状態となっている時に、他のタスクから sus̲tsk が実行されることはある。この場合はwup̲tsk により待ち状態が解除されてもまだ強制待ち状態であり、rsm̲tsk の発行までタスクの実行は再開されない。
なお、タスクの単純な遅延を行うのであれば、wai̲tsk 以外に、dly̲tsk
も利用できる。
【エラーコード (ercd)】
E̲OK
E̲TNOSPT

正常終了
タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲ILTIME

不正時間指定（tmout≦-2）

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第三部 ITRON 2

wup̲tsk

229

待ち状態のタスクを起床する
wup̲tskwup̲tsk:Wakeup Task

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】
wup̲tsk システムコールでは、slp̲tsk または wai̲tsk システムコールの実行により待ち状態になっていたタスクを、待ち状態から実行可能状態に移す。対象タスクは、tskid で示され、自タスクを指定することはできない。
対象タスクが slp̲tsk または wai̲tsk を実行しておらず、待ち状態でない場合には、この wup̲tsk 要求はキューイングされる。その場合、この
wup̲tsk 要求は、後に対象タスクが slp̲tsk または wai̲tsk システムコールを実行した時に有効となる。具体的には、wup̲tsk を実行すると対象タスクの起床要求カウントがプラス1され、対象タスクが slp̲tsk または wai̲tsk を実行すると、対象タスクの起床要求カウントがマイナス1される。起床要求カ
ウントが負になろうとした時に、はじめて待ち状態になる。
起床要求(wupcnt)のキューイング数の最大値は、標準で (2^31-1) である。
ただし、'^' はべき乗を表わす。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦-1、タスク独立部の発行でtskid = 0）E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲SELF

自タスク、自プロセスの指定（tskidが自タスク、タスク部
や準タスク部の発行でtskid=0）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

E̲QOVR

キューイングのオーバーフロー（wupcntのオーバーフロー）第二章 ITRON 2基本機能

230

can̲wup

タスクの起床要求を無効にする
can̲wupcan̲wup:

Cancel Wakeup Task

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
wupcntWakeup Count

キューイングされていた起床要求回数【解説】
can̲wup システムコールでは、tskid で示された対象タスクにキューイン
グされていた起床要求回数をリターンパラメータとして返し、同時にその起床要求をすべて解除する。tskid = TSK̲SELF によって自タスクの指定になる。
このシステムコールは、周期起床において、時間内に処理が終わっているかどうか（前の起床要求に対するslp̲tsk が実行される前に、次の起床要求が発生していないか）を判定する必要がある場合に利用できる。can̲wup のリターンパラメータである wupcnt が 0でなければ、前の起床要求に対する処理が時間内に終了しなかったということがわかるので、それに対して何らかの処置をすることができる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦-1、タスク独立部の発行でtskid=0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

第三部 ITRON 2

231

同期・通信機能第二章 ITRON 2基本機能

232

cre̲flg

イベントフラグを生成する
cre̲flg
cre̲flg:

Create EventFlag【パラメータ】
flgid

EventFlagIdentifier

イベントフラグID

flgatrEventFlagAttribute

イベントフラグ属性【リターンパラメータ】
なし【解説】
cre̲flg では、flgid で指定された ID 番号を持つイベントフラグを生成する。次に、生成されたイベントフラグに対して管理ブロックを割り付け、
その初期値 (flgptn) を0とする。一つのイベントフラグで、プロセッサの1ワード（32ビット）分のビットをグループ化して扱う。操作はすべて1ワード分を単位とする。
ID 番号が (-4)〜0 のイベントフラグは生成できない。また、負の ID 番号のイベントフラグは、システム用のものである。
flgatr のサイズは標準で4バイトである。flgatr のフォーマットを［図3.10］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）はユーザ属性を表わし、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16のビ ッ ト ）は イ ンプ リ メ ン ト 依 存 の 属 性 を 表 わし、下位ハーフワード（bit16〜bit31 あるいは 2^15〜2^0 のビット）はシステム属性を表わす。ユー
ザは、イベントフラグに関する情報を入れておくために、flgatr の最上位バ
イトを自由に使用することができる。

bit0
flgatr

bit8
ユーザ属性

bit16

インプリメント依存属性

bit31
システム属性(0)［図3.10］flgatrのフォーマット

第三部 ITRON 2

cre̲flg

233

cre̲flg で指定した flgatr は、flg̲sts により読み出すことができる。
flgatr のシステム属性の部分では、次のような指定を行うことができる。
flgatr: = (TA̲WMUL‖TA̲WSGL)TA̲WMUL

複数タスクの待ちを許す (Wait Multiple Task)

TA̲WSGL

複数タスクの待ちを許さない (Wait Single Task)【エラーコード (ercd)】
E̲OK
E̲NOSMEM

正常終了
システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦flgid≦0）

E̲RSATR

予約属性（flgatrの下位3バイトが不正）

E̲IDOVR

ID範囲外（flgidがシステムで利用できる範囲を越えた）

E̲EXS

オブジェクトが既に存在している（同一ID番号のイベント
フラグが存在）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でflgid＜(-4)）

第二章 ITRON 2基本機能

234

del̲flg

イベントフラグを削除する
del̲flgdel̲flg:

Delete EventFlag【パラメータ】
flgid

EventFlagIdentifier

イベントフラグID【リターンパラメータ】
なし【解説】
flgid で示されるイベントフラグを削除する。そのイベントフラグにおいてイベント発生を待っているタスクがある場合にも本システムコールは正常終了するが、イベント発生を待っていたタスクにはエラー E̲DLT が返される。
本システムコール発行後は、同じID番号のイベントフラグを再び新しく生成することができる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦flgid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（flgidのイベントフラグ
が存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でflgid＜(-4)）

第三部 ITRON 2

set̲flg

clr̲flg

235

イベントフラグをセットする
set̲flg

イベントフラグをクリアする
clr̲flg
set̲flg:

Set EventFlag

clr̲flg:

Clear EventFlag【パラメータ】
flgid

EventFlagIdentifier

イベントフラグID＜1＞setptn

SetBitPattern

セットするビットパターン＜2＞clrptn

ClearBitPattern

クリアするビットパターン［＜1＞set̲flg のみ］［＜2＞clr̲flg のみ］【リターンパラメータ】
なし【解説】
set̲flg では、flgid で示されるイベントフラグのうち、setptn で示されているビットがセットされる。すなわち、flgid で示されるイベントフラグの値に対して、setptn の値で論理和がとられる。また、clr̲flg では、flgid で示されるイベントフラグのうち、対応する clrptn が 0 になっているビットがクリアされる。すなわち、flgid で示されるイベントフラグの値に対して、
clrptn の値で論理積がとられる。
set̲flg において、イベントフラグ値の変更の結果、そのイベントフラグ
を待っていたタスクの待ち解除条件を満たすようになれば、そのタスクが実行可能状態へと移行する。イベントフラグでは、ビット対応のイベントの OR や AND を条件として待つことができるが、そのほか、イベントフラ
グの全ビットを使用すれば、1ワードの簡単なメッセージ転送（キューイン
グ無し）を行なうこともできる。
同一イベントフラグに対する複数タスクの待ちも可能である。したがっ第二章 ITRON 2基本機能

236

set̲flg

clr̲flgて、イベントフラグでもタスクが待ち行列を作ることになる。この場合、一回の set̲flg で複数のタスクが待ち解除となることがある。
clr̲flg では、そのイベントフラグを待っているタスクが待ち解除となることはない。すなわち、ディスパッチは起らない。
set̲flg で setptn の全ビットを 0 とした場合や、clr̲flg で clrptn の全ビットを 1 とした場合には、対象イベントフラグに対して何の操作も行わないことになる。ただし、その場合でもエラーとはならない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦flgid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（flgidのイベントフラグ
が存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でflgid＜(-4)）

第三部 ITRON 2

wai̲flg

237

イベントフラグを待つ
wai̲flg
wai̲flg:

Wait EventFlag【パラメータ】
flgid

EventFlagIdentifier

イベントフラグID

waiptn

WaitBitPattern

待ちビットパターンtmout

Timeout

タイムアウト指定

wfmode

WaitEventFlagMode

待ちモード【リターンパラメータ】
flgptnEventFlagBitPattern

待ち解除時のビットパターン【解説】
wfmode で示される待ち条件にしたがって、flgid で示されるイベントフ
ラグがセットされるのを待つ。
wfmode では、次のような指定を行う。
wfmode : = (TWF̲ANDW‖TWF̲ORW) ｜ [TWF̲CLR]
TWF̲ANDWAND待ちTWF̲ORW

OR待ち

TWF̲CLR

クリア指定

TWF̲ORW を指定した場合には、flgid で示されるイベントフラグのうち、
waiptn で指定したビットのいずれかがセットされるのを待つ。また、
TWF̲ANDW を指定した場合には、flgid で示されるイベントフラグのうち、
waiptn で指定したビットがすべてセットされるのを待つ。
TWF̲CLR の指定が無い場合には、条件が満足されてこのタスクが待ち解除となった場合にも、イベントフラグの値はそのままである。一方、TWF̲CLR の指定がある場合には、条件が満足されてこのタスクが待ち解除となった場合、イベントフラグの値（全部のビット）を 0 にクリアする。
tmout に よ り 待 ち 時 間 の タ イ ム ア ウ ト 指 定 を 行 な う こ と が で き る 。
tmout としては、正の値のみを指定することができる。タイムアウト指定

第二章 ITRON 2基本機能

238

wai̲flgが行なわれた場合、条件が満足されぬまま tmout 時間が経過すると、タイムアウトエラー E̲TMOUT としてエラーリターンする。また、tmout として TMO̲POL を指定した場合は、待ち条件が満たされない場合でも即時にリターンする。この場合、待ち条件が満たされていれば正常終了に、待ち条件が満たされていなければタイムアウトエラー E̲TMOUT になる。
TWF̲CLR の指定によってフラグのクリアが行われるのは、正常終了した
場合のみである。さらに、tmout = TMO̲FEVR によりタイムアウト指定が行なわれないことを示す。この場合は条件が満足されるまで永久に待つ。
flgptn は、本システムコールによる待ち状態が解除される時のイベント
フラグの値（TWF̲CLR 指定の場合は、イベントフラグがクリアされる前の値）を示すリターンパラメータである。flgptn で返る値は、このシステムコールの待ち解除の条件を満たすものになっている。
TA̲WMUL 属性のイベントフラグの場合は、同一イベントフラグに対する複数タスクの待ちも可能である。この場合、一回の set̲flg で複数のタス
クが待ち解除となることがある。TA̲WMUL 属性のイベントフラグでは、タスクの待ち行列が定義され、次のような動作をする。
― 待ち行列の順番は FIFO である。ただし、waiptn や wfmode との関係により、必ずしも行列先頭のタスクから待ち解除になるとは限らない。
― 待ち行列中にクリア指定のタスクがあれば、そのタスクが待ち解除になる時に、フラグをクリアする。
― クリア指定を行っていたタスクよりも後ろの待ち行列にあったタスクは、
既にクリアされた後のイベントフラグを見ることになるため、待ち解除とはならない。
イベントフラグに対する複数タスク待ちの機能は、次のような場合に有効である。例えば、タスクA が＜1＞set̲flg を実行するまで、タスクB、タスクC を＜2＞＜3＞wai̲flg で待たせておく場合に、イベントフラグの複数待ちが可能であれば、＜1＞＜2＞＜3＞のどのシステムコールが先に実行されても結果は同じになる［図3.11］。一方、イベントフラグの複数待ちができなければ、＜2＞→＜3＞→＜1＞の順でシステムコールが実行された場合に、＜3＞の wai̲flg がエラーになる。

第三部 ITRON 2

wai̲flg［タスクA］［タスクB］＜1＞set̲flg

239［タスクC］＜2＞wai̲flg＜3＞wai̲flg（クリア無）（クリア無）［図3.11］イベントフラグに対する複数タスク待ちの機能

waiptn を0とした場合は、set̲flg により待ち状態から抜けることができなくなるため、パラメータエラー E̲PAR とする。したがって、set̲flg で全ビットをセットした場合、待ち行列の先頭にあるタスクであれば、どのような条件でイベントフラグを待つタスクであっても待ち解除となることが保証される。
一方、既に待ちタスクの存在する TA̲WSGL 属性のイベントフラグに対して、別のタスクが wai̲flg を実行することはできない。ただし、これに違反した場合にエラーチェックを行って E̲OBJ のエラーを返すかどうかはインプリメント依存である。インプリメントによっては、TA̲WSGLに対する
エラーチェックが行われない場合がある。互換性の高いプログラミングを行うためには、TA̲WSGL 属性のイベントフラグに対する複数のタスク待ちが起こらないようにしなければならない。
【エラーコード (ercd)】
E̲OK
E̲TNOSPT

正常終了
タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSMD

予約モード、予約オプション（wfmodeが不正）

E̲RSID

予約ID番号（-4≦flgid≦0）

E̲PAR

一般的なパラメータエラー（waiptn = 0）E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILTIME

不正時間指定（tmout≦-2）

第二章 ITRON 2基本機能

240

wai̲flg

E̲NOEXS

オブジェクトが存在していない（flgidのイベントフラグが存在しない）E̲OBJ

オブジェクト状態に関するその他のエラー（TA̲WSGL
属性のイベントフラグに対する複数タスクの待ち,インプ
リメント依存）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でflgid＜(-4)）

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

E̲DLT

待ちオブジェクトが削除された（待ちの間に対象イベント
フラグが削除）E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第三部 ITRON 2

flg̲sts241

イベントフラグ状態を参照する
flg̲sts
flg̲sts:

Get EventFlag Status【パラメータ】
flgid

EventFlagIdentifier

イベントフラグID

pk̲flgs

Packet of EventFlagStatus

イベントフラグ状態を返す
パケットの先頭アドレス【リターンパラメータ】
なし【解説】
flgid で示されたイベントフラグの状態を読み出し、その結果を pk̲flgs
以下の領域に返す。
pk̲flgs に返される情報としては、次のようなものがある。
flgatr/* イベントフラグ属性 */wtskid/* 待ち行列先頭のタスクID */flgptn/* 現在のフラグ値 */wtskid には、待ち行列の先頭のタスクのIDが返る。すなわち、現在このイベントフラグを待っているタスクのうち、最も早く待ち状態になったタ
スクのIDが返る。待ちタスクが無い場合は FALSE = 0 が返る。
対象となるイベントフラグは、既に生成されたものでなければならない。
なお、ITRONでは、cre̲XXX で生成したオブジェクトや def̲XXX で定義したハンドラの状態を見るシステムコールの名称を XXX̲sts としている。

第二章 ITRON 2基本機能

242

flg̲sts【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦flgid≦0）

E̲ILADR

不正アドレス（pk̲flgsが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（flgidのイベントフラグ
が存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でflgid＜(-4)）

第三部 ITRON 2

cre̲sem243

セマフォを生成する
cre̲semcre̲sem:Create Semaphore【パラメータ】
semid

SemaphoreIdentifier

セマフォID

sematrSemaphoreAttribute

セマフォ属性

isemcnt

InitialSemaphoreCount

セマフォの初期値【リターンパラメータ】
なし【解説】
cre̲sem では、semid で指定されたID番号を持つセマフォを生成する。次に、生成されたセマフォに対して管理ブロックを割り付け、そのセマフォ
初期値を isemcnt とする。
ID 番号が (-4)〜0 のセマフォは生成できない。また、負の ID 番号のセマ
フォは、システム用のものである。
sematrのサイズは標準で4バイトである。sematrのフォーマットを［図3.12］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）はユーザ属性を表わし、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16の ビ ッ ト ）は イ ン プ リ メ ン ト 依 存 の 属 性 を 表 わ し 、 下 位 ハ ー フ ワ ー ド（bit16〜bit31 あるいは 2^15〜2^0 のビット）はシステム属性を表わす。ユー
ザは、セマフォに関する情報を入れておくために、sematrの最上位バイトを自由に使用することができる。

bit0
sematr

bit8
ユーザ属性

bit16

インプリメント依存属性

bit31
システム属性［図3.12］sematrのフォーマット

第二章 ITRON 2基本機能

244

cre̲semcre̲sem で指定した sematr は、sem̲sts により読み出すことができる。
sematr のシステム属性の部分では、次のような指定を行うことができる。
sematr: = (TA̲TFIFO‖TA̲TPRI) ｜ (TA̲FIRST‖TA̲CNT)｜ (TA̲VAR‖TA̲FIX)TA̲TFIFO

待ちタスクのキューイングは FIFOTA̲TPRI

待ちタスクのキューイングは優先度順

TA̲FIRST

行列先頭のタスクを優先扱い

TA̲CNT

要求数の少ないタスクを優先扱い

TA̲VAR

要求/返却資源数を指定可能

TA̲FIX

要求/返却資源数は1のみ

TA̲VAR の属性を指定したセマフォに対しては、sig̲sem, wai̲sem の要
求/返却資源数 (rcnt) として、任意の正の値を指定することができる。一方、TA̲VAR の属性を指定したセマフォに対しては、sig̲sem, wai̲sem の要求 /返却資源数 (rcnt) は 1 に固定される。
TA̲TFIFO, TA̲TPRI では、タスクがセマフォの待ち行列に並ぶ際の並び方を指定することができる。属性がTA̲TFIFO であればタスクの待ち行列
は FIFO となり、属性が TA̲TPRI であればタスクの待ち行列はタスクの優
先度順となる。
また、TA̲CNT と TA̲FIRST の属性指定により、要求カウント数の少ないタスクを優先扱いにするか、行列先頭のタスクを優先扱いにするかが指定できる。TA̲CNT の属性を指定した場合には、要求カウント数によって、行列途中のタスクから先に待ち解除になる場合がある。例えば、あるセマ
フォに対して 要求カウント=5 のタスク A と要求カウント = 1 のタスク B がこの順で待っており、sig̲sem によりカウントが 1 になった場合、行列先頭にあるタスク A は要求カウント数が多いので、行列の後にあるタスク B の方が先に待ち解除になる。
TA̲FIRST の属性を指定した場合には、カウント数にかかわらず、必ず行列先頭のタスクから資源が割り当てられる。これは、カウント要求数よりも行列の順序や優先度を重視した考え方である。上の例では、sig̲sem 実
行後も タスク B は待ち解除にならず、さらに sig̲sem が実行されてセマフ
ォのカウント数が 5 以上になった時にはじめてタスク A が待ち解除になり、その後タスク B が待ち解除になる。
第三部 ITRON 2

cre̲sem245

セマフォやメモリプールの待ち行列の属性としては、
TA̲TFIFO または TA̲TPRI と、
TA̲FIRST または TA̲CNT
を組み合わせて指定できるようになっている。このうち、TA̲TPRI とTA̲TFIFO の属性は、待ち行列の作り方を指定するものであり、wai̲sem のシステムコール発行時にのみ参照され、sig̲sem の処理では参照されない。
一方、TA̲CNT と TA̲FIRST の指定は、待ち行列の順序には影響しない。
TA̲CNT を指定した場合でも、資源要求数 (rcnt) の少ない順に待ち行列を構成するわけではない。待ち行列の構成順序は、常にタスク優先度順(TA̲TPRI) または先着順 (TA̲TFIFO) のいずれかであり、資源要求数は待ち行列の構成順序には関係しない。
もし、TA̲CNT 指定時に資源要求数順の待ち行列を作るものとすると、［図3.13］のような場合の動作が異なってくる。

task̲A [tskpri=1] が wai̲sem(rcnt=5) を実行
task̲B [tskpri=2] が wai̲sem(rcnt=1) を実行
task̲C [tskpri=3] が wai̲sem(rcnt=1) を実行(a) ITRON本来の仕様の場合(b) 要求数順の待ち行例を作る場合

task̲Atask̲Btask̲Ctask̲Btask̲Ctskpri1

2

3

tskpri2

3

task̲A
1

rcnt

5

1

1

rcnt

1

1

5

＊この状態で sig̲sem(rcnt=2) を実行した場合の動作は同じであり、(a)(b) とも task̲B, task̲C が待ち解除となる。
＊一方、sig̲sem(rcnt=5) を実行した場合、(a) では task̲A が待ち解除となるのに対して、(b) では task̲B, task̲C が待ち解除となる。このような場合は、task̲Aが待ち解除となるのが本来の仕様である。

［図3.13］セマフォの待ち行列の作り方による動作の違い

第二章 ITRON 2基本機能

246

cre̲sem

なお、TA̲FIX 属性の場合は TA̲CNT と TA̲FIRST の属性の違いが無くなってしまうが、これに関しては何もチェックしない。(TA̲FIX ¦ TA̲CNT)の指定と (TA̲FIX ¦ TA̲FIRST) の指定はどちらもエラーにはならず、同じ動作を行なう。
【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦semid≦0）

E̲RSATR

予約属性（sematrの下位3バイトが不正）E̲PAR一般的なパラメータエラー（isemcntが負）E̲IDOVR

ID範囲外（semidがシステムで利用できる範囲を越えた）

E̲EXS

オブジェクトが既に存在している（同一ID番号のセマフォ
が存在）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でsemid＜(-4)）

第三部 ITRON 2

del̲sem247

セマフォを削除する
del̲semdel̲sem:

Delete Semaphore【パラメータ】
semid

SemaphoreIdentifier

セマフォID【リターンパラメータ】
なし【解説】
semid で示されるセマフォを削除する。
そのセマフォにおいて sig̲sem を待っているタスクがある場合にも本シ
ステムコールは正常終了するが、イベント発生を待っていたタスクにはエラー E̲DLT が返される。
本システムコール発行後は、そのID番号のセマフォを再び新しく生成することができる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦semid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（semidのセマフォが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でsemid＜(-4)）

第二章 ITRON 2基本機能

248

sig̲sem

セマフォに対する信号操作（V命令）
sig̲sem:sig̲semSignal Semaphore【パラメータ】
semid

SemaphoreIdentifier

セマフォID

rcnt

ResourceCount

増カウント値【リターンパラメータ】
なし【解説】
semid で示されたセマフォのカウント値を rcnt だけ増やす。その後、そのセマフォの待ち行列の中から、減カウント値がセマフォのカウンタ値以下であるタスクを選んで実行可能状態に移行させ、セマフォのカウンタ値
を減カウント値だけ減らす。実行可能状態にするタスクの選び方は、
cre̲sem 時に指定する sematr (TA̲CNT,TA̲FIRST) で指定される。sig̲semで指定した増カウント値と、待ち行列中のタスクの減カウント値との関係
によって、実行可能状態に移行するタスクが無い場合や、複数のタスクが実行可能状態に移行する場合が生じる。
セマフォのカウント値の増加により、カウント値が cre̲sem で指定した
isemcnt の値を越えた場合にも、エラーとはしない。これは、資源管理ではなく、同期の目的（wup̲tsk〜slp̲tsk と同様）でセマフォを使用することを想定しているためである。また、セマフォを一旦生成した後で、資源数を動的に再設定したい場合にも、カウント値が isemcnt を越える場合がある。
TA̲FIX 属性のセマフォに対して、rcnt≠1 の sig̲sem, wai̲sem を発行することはできない。ただし、これに違反した場合に rcnt=1 と同じ動作をするか、指定した rcnt がそのまま有効になる（TA̲VAR属性のセマフォと同じ動作をする）かはインプリメント依存である。互換性の高いプログラミ
ングを行うためには、TA̲FIX属性のセマフォに対して rcnt≠1 の sig̲sem,wai̲sem を発行してはならない。

第三部 ITRON 2

sig̲sem249【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦semid≦0）

E̲PAR

一般的なパラメータエラー（rcnt≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（semidのセマフォが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でsemid＜(-4)）

E̲QOVR

キューイングのオーバーフロー（semcntのオーバーフロー）第二章 ITRON 2基本機能

250

wai̲sem

セマフォに対する待ち操作（P命令）
wai̲sem:wai̲sem
Wait on Semaphore【パラメータ】
semid

SemaphoreIdentifier

セマフォID

rcnt

ResourceCount

減カウント値

tmout

Timeout

タイムアウト指定【リターンパラメータ】
なし【解説】
semid で示されたセマフォのカウント値が rcnt 以上であれば、セマフォのカウント値を rcnt だけ減じて、本システムコールの発行タスクは実行を継続する。セマフォのカウント値が rcnt より小さければ、セマフォ値は変
更せず、このシステムコールを発行したタスクはそのセマフォの待ち行列につながれる。待ち行列へのつながれ方は、セマフォ生成時に sematr で指定されたセマフォ属性により、FIFO または タスク優先度順のいずれかが選択される。
tmout により待ち時間のタイムアウト指定を行なうことができる。tmout
としては、正の値のみを指定することができる。タイムアウト指定が行なわれた場合、条件が満足されぬまま tmout 時間が経過すると、タイムアウ
トエラー E̲TMOUT としてエラーリターンする。また、tmout として
TMO̲POL を指定した場合は、資源が獲得できない場合でも即時にリター
ンする。この場合、資源が獲得できれば正常終了に、資源が獲得できなけ
ればタイムアウトエラー E̲TMOUT になる。さらに、tmout = TMO̲FEVR
によりタイムアウト指定が行なわれないことを示す。この場合は条件が満足されるまで永久に待つ。
TA̲FIX 属性のセマフォに対して、rcnt≠1 の sig̲sem, wai̲sem を発行することはできない。ただし、これに違反した場合に rcnt=1 と同じ動作をするか、指定した rcnt がそのまま有効になる（TA̲VAR属性のセマフォと同じ

第三部 ITRON 2

wai̲sem

251

動作をする）かはインプリメント依存である。互換性の高いプログラミングを行うためには、TA̲FIX 属性のセマフォに対して rcnt≠1 の sig̲sem,wai̲sem を発行してはならない。
セマフォやメモリブロックなどの資源を要求するシステムコール(wai̲sem, get̲blk) では、(a) 資源要求時に資源要求タスクを一旦待ち行列につなぎ、(b) それから資源が割り当て可能かどうか（タスクが本当に待ち状態になるかどうか）をチェックする、と考えて処理を行う。この場合、(a)の処理の部分では、TA̲FIRST/TA̲CNTの属性は関係せず、TA̲TFIFO/TA̲TPRIの属性のみが関係する。
一方、(b)の処理の部分では、TA̲TFIFO/TA̲TPRIの属性は関係せず、TA̲FIRST/TA̲CNT の属性のみが関係する。
【エラーコード (ercd)】
E̲OK

正常終了

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦semid≦0）

E̲PAR

一般的なパラメータエラー（rcnt≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILTIME

不正時間指定（tmout≦-2）

E̲NOEXS

オブジェクトが存在していない（semidのセマフォが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でsemid＜(-4)）

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

E̲DLT

待ちオブジェクトが削除された（待ちの間に対象セマフォ
が削除）

E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第二章 ITRON 2基本機能

252

sem̲sts

セマフォ状態を参照する
sem̲stssem̲sts:

Get Semaphore Status【パラメータ】
semid

SemaphoreIdentifier

セマフォIDpk̲sems

Packet of SemaphoreStatus

セマフォ状態を返すパケットの先頭アドレス【リターンパラメータ】
なし【解説】
semid で示されたセマフォの状態を読み出し、その結果を pk̲sems 以下の領域に返す。
pk̲sems に返される情報としては、次のようなものがある。
sematr/* セマフォ属性 */wtskid/* 待ち行列先頭のタスクID */semcnt/* 現在のカウント値 */wtskid には、待ち行列の先頭のタスクのIDが返る。すなわち、セマフォ
属性が TA̲TFIFO であれば、現在このセマフォを待っているタスクのうち、最も早く待ち状態になったタスクのIDが返る。また、セマフォ属性がTA̲TPRI であれば、現在このセマフォを待っているタスクのうち、最も優先度の高いタスクのIDが返る。待ちタスクの無い時は FALSE = 0 が返る。
wai̲sem で待ちタスクの指定している減カウント値が、セマフォの現在のカウント値よりも大きければ、semcnt＞0かつ wtskid≠0となる場合がある。
対象となるセマフォは、既に生成されたものでなければならない。

第三部 ITRON 2

sem̲sts

253【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦semid≦0）

E̲ILADR

不正アドレス（pk̲semsが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（semidのセマフォが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でsemid＜(-4)）

第二章 ITRON 2基本機能

254

cre̲mbx

メイルボックスを生成する
cre̲mbxcre̲mbx:

Create Mailbox【パラメータ】
mbxid

MailboxIdentifier

メイルボックスID

mbxatrMailboxAttribute

メイルボックス属性【リターンパラメータ】
なし【解説】
cre̲mbx では、mbxid で指定された ID 番号を持つメイルボックスを生成する。次に、生成されたメイルボックスに対して管理ブロックを割り付ける。メイルボックスは、そのメイルボックスに入れられたメッセージのキ
ューと、それを待つタスクの待ち行列とから構成される。メッセージのキ
ューは、リングバッファではなく、メッセージを線形リストでつないだものである。
ID 番号が (-4)〜0 のメイルボックスは生成できない。また、負の ID 番号のメイルボックスは、システム用のものである。
mbxatrのサイズは標準で4バイトである。mbxatrのフォーマットを［図3.14］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）はユーザ属性を表わし、第二上位バイト（bit8〜bit15あるいは 2^23〜2^16の ビ ッ ト ）は イ ン プ リ メ ン ト 依 存 の 属 性 を 表 わ し 、 下 位 ハ ー フ ワ ー ド（bit16〜bit31 あるいは 2^15〜2^0 のビット）はシステム属性を表わす。ユー
ザは、メイルボックスに関する情報を入れておくために、mbxatr の最上位バイトを自由に使用することができる。
cre̲mbx で指定した mbxatr は、mbx̲sts により読み出すことができる。
mbxatr のシステム属性の部分では、次のような指定を行うことができる。
mbxatr: = (TA̲TFIFO‖TA̲TPRI) ｜ (TA̲MFIFO‖TA̲MPRI)TA̲TFIFO

待ちタスクのキューイングは FIFOTA̲TPRI

待ちタスクのキューイングは優先度順

第三部 ITRON 2

cre̲mbx
TA̲MFIFO

メッセージはFIFOTA̲MPRI

メッセージは優先度順

255

TA̲TFIFO の属性を指定した場合には、メッセージを待つタスクは FIFOの待ち行列を作り、TA̲TPRI の属性を指定した場合には、メッセージを待つタスクはタスクの優先度順の待ち行列を作る。また、TA̲MFIFO の属性を指定した場合には、メッセージは FIFO のキューを作り、TA̲MPRI の属性を指定した場合には、メッセージはメッセージに与えられた優先度
msgpri にしたがってキューを作る。
【エラーコード (ercd)】
E̲OK
E̲NOSMEM

正常終了
システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦mbxid≦0）

E̲RSATR

予約属性（mbxatrの下位3バイトが不正）

E̲IDOVR

ID範囲外（mbxidがシステムで利用できる範囲を越えた）

E̲EXS

オブジェクトが既に存在している（同一ID番号のメイル
ボックスが存在）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でmbxid＜(-4)）

bit0
mbxatr

bit8
ユーザ属性

bit16

インプリメント依存属性

bit31
システム属性［図3.14］mbxatrのフォーマット

第二章 ITRON 2基本機能

256

del̲mbx

メイルボックスを削除する
del̲mbx
del̲mbx:

Delete Mailbox【パラメータ】
mbxid

MailboxIdentifier

メイルボックスID【リターンパラメータ】
なし【解説】
mbxid で示されるメイルボックスを削除する。
そのメイルボックスに対してメッセージの到着を待っているタスクがある場合、本システムコールは正常終了するが、メッセージの到着を待っていたタスクにはエラー E̲DLT が返される。
本システムコールでは、対象メイルボックスの中にメッセージが残っている場合でも、エラーとはならず、メイルボックスの削除が行なわれる。
本システムコール発行後は、そのID番号のメイルボックスを再び新しく生成することができる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦mbxid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（mbxidのメイルボックスが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でmbxid＜(-4)）

第三部 ITRON 2

snd̲msg

257

メイルボックスへ送信する
snd̲msg
snd̲msg:

Send Message to Mailbox【パラメータ】
mbxid

MailboxIdentifier

メイルボックスIDpk̲msgMessagePacket

送信メッセージの先頭アドレス【リターンパラメータ】
なし【解説】
mbxid で示された対象メイルボックスに、pk̲msg のアドレスに入っているメッセージを送信する。メッセージの内容はコピーされず、受信時にはアドレス（pk̲msgの値）のみが渡される。
対象メイルボックスでメッセージを待つタスクがない時に snd̲msg が発行されても、snd̲msg 発行タスクは待ち状態とはならない。このシステム
コールでは、メッセージをメイルボックスに入れ、メッセージキューと呼ぶ待ち行列につなぐだけで、タスクはその先の実行を続ける。つまり、非同期のメッセージ送信を行なう。また、待ち行列につながれるのは、そのタスクの発行したメッセージであって、タスクそのものではない。すなわ
ち、メッセージの待ち行列（キュー）、受信タスクの待ち行列は存在するが、送信タスクの待ち行列は存在しない。
一般に、線形リストによりメッセージのキューを作る場合、メッセージブ
ロックの中に、OSで用いるキューのリンク用エリアが必要となる。また、対象メイルボックスのメッセージの並び方の属性がメッセージ優先度順となっている場合には、メッセージの内部にメッセージの優先度を入れておく必要がある。したがって、OSの管理用として、ユーザの用意したメッセージブロ
ックの一部を使用することになる。この部分を、メッセージヘッダと呼ぶ。
pk̲msg は、メッセージヘッダをも含めたメッセージブロックの先頭アドレスである。実際にユーザがメッセージを入れることができるのは、ヘッ
ダの後の部分である。

第二章 ITRON 2基本機能

258

snd̲msg(pk̲msg = blk)

bcnt (size)

reserved 4バイト

線形リスト用領域

reserved 4バイト

線形リスト用領域

msgtype 2バイト
msgpri 2バイト(0)0に予約、将来はメッセージタイプなどを入れる
メッセージの優先度

msgcont(size-12) バイト＊pk̲msgは、メッセージの先頭アドレスであり、snd̲msgのパラメータで指定される値である。メッセージとして、メモリプールから確保したメモリブロックをそのまま使用する場合にはget̲blkで得られるメモリブロックのアドレス (blk)をpk̲msg
として指定すれば良い。
＊可変長メモリブロックの場合には、一般に各メモリブロックに対応してmplid,bcnt（サイズ）等の情報をOSが管理するための領域が必要になる。しかし、その領域はメッセージヘッダとは別になっており、上記のメッセージブロック（＝メモリブロック）の図には含まれていない。

［図3.15］ITRON2におけるメッセージの形式

メッセージの具体的な形式は［図3.15］のようになる。このうち、ユーザが自由に使用できるのは、msgcont の部分である。
メッセージとしては、get̲blk でメモリプールから動的に確保されたメモ
リブロックを使用することも可能であるし、静的に確保された領域を使用することも可能である。しかし、一般には、メモリプールから動的に確保されたメモリブロックをメッセージとして使用することが多い。この場合、メモリブロックのサイズをそのままメッセージのサイズと考えることにより、ユーザが改めてメッセージサイズをセットする必要は無くなる。受信した側でサイズを参照したい場合には、blk̲sts システムコール（メモリブロ
ックアドレスblkからブロック数bcntを返す）を利用すれば良い。
第三部 ITRON 2

snd̲msg

259

TA̲MPRI 属性のメイルボックスにおけるメッセージ優先度 msgpri は、符号付きの数として扱う。メッセージ優先度としては、タスク優先度と同じ範囲（ (-16)〜255, ただし(-4)〜0を除く）の数を利用できることが必要である。ただし、範囲に関するエラーチェックを行うことによってオーバーヘッドを生じる可能性もあるので、上記の範囲外のメッセージ優先度を指定した場合の動作はインプリメント依存とする。具体的には、次のような仕様になる。
msgpri が (-16)〜(-5)の場合 :実行可能
msgpri が 1〜255 の場合 :実行可能
msgpri が 上記の範囲以外の場合 :インプリメントに依存して、実行可能な場合とエラー(E̲ILMSG) になる場合とがある。(-16)〜(-5), 1〜255 以外のメッセージ優先度を使ったアプリケーションでは、プログラムの互換性が保証されない。
互換性の高いプログラミングを行うためには、(-16)〜(-5), 1〜255 以外のメッセージ優先度を使わないようにする必要がある。
一方、TA̲MFIFO 属性のメイルボックスに送ったメッセージの場合は、メッセージ優先度 msgpri の入る領域を別の目的で使用している可能性があるので、この領域がいかなる値であってもエラーとはしない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦mbxid≦0）

E̲ILADR

不正アドレス（pk̲msgが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILMSG

不正メッセージ形式（msgtype≠0）

E̲NOEXS

オブジェクトが存在していない（mbxidのメイルボックスが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でmbxid＜(-4)）

第二章 ITRON 2基本機能

260

rcv̲msg

メイルボックスから受信する
rcv̲msg
rcv̲msg:

Receive Message from Mailbox【パラメータ】
mbxid

MailboxIdentifier

メイルボックスID

tmout

Timeout

タイムアウト指定【リターンパラメータ】
pk̲msgMessagePacket

受信メッセージの先頭アドレス【解説】
mbxid で示されたメイルボックスからメッセージを受信し、受信したメッセージの先頭アドレスをリターンパラメータとして返す。まだそのメイ
ルボックスにメッセージが到着していない場合には、本システムコール発
行タスクはメッセージ到着を待つ待ち行列につながれる。待ち行列へのつながれ方は、メールボックス生成時にmbxatr で指定した方法によるものであり、FIFO または タスク優先度のいずれかである。
pk̲msg は、メッセージヘッダをも含めたメッセージブロックの先頭アドレスである。メッセージヘッダには、メッセージの優先度やOSで使用する
予約領域が含まれており、実際にユーザがメッセージを入れることができるのは、ヘッダの後の部分である。メッセージヘッダの構成については、
snd̲msg の項を参照。
tmout により待ち時間のタイムアウト指定を行なうことができる。tmout
としては、正の値のみを指定することができる。タイムアウト指定が行なわれた場合、メッセージを受信できないまま tmout 時間が経過すると、タ
イムアウトエラー E̲TMOUT としてエラーリターンする。また、tmout として TMO̲POL を指定した場合は、メッセージが受信できない場合でも即時にリターンする。この場合、メッセージが受信できれば正常終了に、メッセージが無ければタイムアウトエラー E̲TMOUT になる。さらに、
tmout = TMO̲FEVR によりタイムアウト指定が行なわれないことを示す。
この場合は条件が満足されるまで永久に待つ。

第三部 ITRON 2

rcv̲msg

261【エラーコード (ercd)】
E̲OK

正常終了

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦mbxid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILTIME

不正時間指定（tmout≦-2）

E̲NOEXS

オブジェクトが存在していない（mbxidのメイルボックスが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でmbxid＜(-4)）

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

E̲DLT

待ちオブジェクトが削除された（待ちの間に対象メイル
ボックスが削除）E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第二章 ITRON 2基本機能

262

mbx̲sts

メイルボックス状態を参照する
mbx̲stsmbx̲sts:

Get Mailbox Status【パラメータ】
mbxid

MailboxIdentifier

メイルボックスID

pk̲mbxs

Packet of MailboxStatus

メイルボックス状態を返す
パケットの先頭アドレス【リターンパラメータ】
なし【解説】
mbxid で示されたメイルボックスの状態を読み出し、その結果を pk̲mbxs
以下の領域に返す。
pk̲mbxs に返される情報としては、次のようなものがある。
mbxatr/* メイルボックス属性 */wtskid/* 待ち行列先頭のタスクID */pk̲msg/* 次のメッセージのアドレス */wtskid には、待ち行列の先頭のタスクのIDが返る。すなわち、属性がTA̲TFIFO であれば、現在このメイルボックスを待っているタスクのうち、最も早く待ち状態になったタスクのIDが返る。また、属性が TA̲TPRI であれば、現在このメイルボックスを待っているタスクのうち、最も優先度の高いタスクのIDが返る。待ちタスクの無い時は FALSE = 0 が返る。
pk̲msg には、次に受信されるメッセージの先頭アドレスが返る。直後に
rcv̲msg を実行した場合には、同じ値が pk̲msg として戻される。メッセー
ジが無い時は、pk̲msg は NADR(-1) となる。また、どんな場合でも、
pk̲msg=NADR と wtskid=FALSE の少なくても一方は必ず成り立つ。
対象となるメイルボックスは、既に生成されたものでなければならない。

第三部 ITRON 2

mbx̲sts263【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦mbxid≦0）

E̲ILADR

不正アドレス（pk̲mbxsが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（mbxidのメイルボックスが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でmbxid＜(-4)）

第二章 ITRON 2基本機能

264

割込み管理機能ITRONの割込みハンドラは、タスク独立部として扱われる。タスク独立部でも、タスク部や準タスク部と同じ形式でシステムコールを発行することが可能である。しかし、タスク独立部では現在実行中のタスクを特定できないので、タスクの切り換え（ディスパッチング）は起らない。したがって、ディスパッチングが必要になっても、それはタスク独立部を抜けるまで遅らされる。これを遅延ディスパッチ (delayed dispatching) の原則と呼ぶ。
また、暗黙に自タスクを指定するシステムコール（自タスクを待ち状態にするシステムコールを含む） は、タスク独立部から発行することができず、E̲CTX のエラーになる。これ以外のシステムコールでも、インプリメ
ントの制限によってタスク独立部から発行できない場合がある。
タスク独立部から発行可能なシステムコール
ITRON2では、性能面を考え、割り込み禁止時間を減らすため、タスク
独立部から発行できる最低限のシステムコールを次の5個としている。
wup̲tsk, ret̲int, ret̲tmr, psw̲sts, get̲tid
この5個のシステムコールについては、タスク独立部からも発行できることが保証されている。これ以外のシステムコールがタスク独立部から発行可能かどうかは、インプリメント依存である。
拡張SVCを使ったユーザ定義のシステムコールについても、タスク独立部から利用できるかどうかはインプリメント依存である。これは、タスク
独立部から発行できるシステムコールが少ない場合に、いろいろなシステ
ムコールを含んだ拡張SVCハンドラをタスク独立部から発行するのはあまり意味が無いためである。また、ITRONでは割込みハンドラの起動時にOSが介入しないため、割込みハンドラと拡張SVCハンドラや例外ハンドラのコンテキストが混在した場合でも、OS側でその区別を行うことができない。
そのため、タスク独立部から拡張SVCを発行できるようにした場合、オーバーヘッドが大きくなったりする危険がある。

第三部 ITRON 2

265
割込み処理とシステムコールの不可分性
一般のシステムコールでは、各システムコールの処理がユーザから見て不可分に行われるというのが原則である。これに対して、割込みハンドラから発行されたシステムコールでは、システムコールの不可分性を保証できない（保証しない方が明らかに性能が上がる）場合がある。
割込みハンドラから発行可能なシステムコールがインプリメント依存となっているので、割込みハンドラから発行されたシステムコールと、タスクから発行されたシステムコールとの間の不可分性に関しても、ある程度
はインプリメント依存とならざるを得ない。これはやむを得ない問題だと考えられるので、割込みハンドラから発行したシステムコールに関しては、最低限発行可能なシステムコール（wup̲tsk等）を除き、必ずしも不可分性を保証しなくても良いことにする。もちろん、どのような場合にシステムコールの不可分性が保てないかということについては、インプリメント毎に明らかにして頂く必要がある。
結局、割込みハンドラから発行可能なシステムコールについての考え方は次のようになる。
― wup̲tsk, get̲tid, psw̲sts, ret̲int, ret̲tmr 以外のシステムコールの発行の可
否はインプリメント依存である。
― 割込みハンドラから上記以外のシステムコールを発行した場合には、シ
ステムコールの不可分性を保てない場合がある。この問題については、割込み禁止時間を短くするためにやむを得ない面があるので、インプリ
メント毎に状況を明らかにして頂く。例えば、次の（例1）（例2）程度であれば、許容範囲内であろう。
（ 例 1） TA̲VAR, TA̲CNT 属 性 の セ マ フ ォ A に 対 し て 、 タ ス ク Bがwai̲sem(rcnt=2) を発行、タスクCが wai̲sem(rcnt=2) を発行、タスクDがwai̲sem(rcnt=1) を発行し、この順に待ち状態にあるものとする［図3.16］。
セマフォA の現在カウント値 (semcnt) は 0 である。
ここで、タスクEがセマフォA に対して sig̲sem (rcnt=3) を発行した場合、次のような動作をする。
(1) semcnt =3 とする。
(2) タスクBを待ち解除にして semcnt = 1 とする。

第二章 ITRON 2基本機能

266

セマフォA
semcnt = 0

タスクB
rcnt = 2

タスクC
rcnt = 2

タスクD
rcnt = 1［図3.16］セマフォの動作例とシステムコールの不可分性(3) 待ち行列の次のタスクはタスクCであるが、タスクCは rcnt = 2 な
ので、rcnt＞semcnt であり、待ち解除にはできない。一方、セマフ
ォA の属性は TA̲CNT なので、待ち行列の次のタスクであるタス
クD をチェックすることになる。タスクDは rcnt = 1 なので、タス
クD を待ち解除とし、semcnt = 0 とする。
さて、この状況で、上記の sig̲sem (rnct=3) の前後に割込みが入り、割込
みハンドラの中で sig̲sem (rcnt=1) のシステムコールが発行されたものとする。この場合、次のような動作をすることが考えられる。
a. sig̲sem(rcnt=3) が発行される直前に割込みが入り、そこで sig̲sem(rcnt=1) が発行された場合。
割込みハンドラ中の sig̲sem (rcnt = 1) により、タスクDが待ち解除となる。
その後 sig̲sem (rcnt = 3) が実行された場合、タスクBは待ち解除となり、
semcnt = 1 となるが、タスクC は rcnt＞semcnt なので待ち解除にできない。
最終的な状態は、タスクC (rcnt = 2) が待ち状態のままであり、semcn=1となっている。
b. sig̲sem (rcnt = 3) が発行された直後に割込みが入り、そこで sig̲sem(rcnt = 1) が発行された場合。
上記の (1)〜(3) の動作の後でsig̲sem (rcnt = 1) が実行され、semcnt = 1 となる。しかし、やはりタスクC は rcnt＞semcnt なので待ち解除にできない。
最終的な状態は、タスクC (rcnt = 2) が待ち状態のままであり、semcnt =1 となっている。これは a. と同じである。
c. 上記の (1)〜(3) の処理時間が長くなるため、(2)と(3) の間で一旦割込みを許可することにした場合を考える。たまたま、(2)と(3) の間で割込み
第三部 ITRON 2

267
ハンドラが起動され、そこで sig̲sem(rcnt=1) が実行されると、次のよ
うな動作をする。
割込みハンドラ中の sig̲sem (rcnt = 1) によって semcnt =2 となるので、（タスクCの rcnt）=semcnt となる。すなわち、(3) の処理を行なう代わりに、タスクC を待ち解除にできる。タスクC を待ち解除にすると、
semcnt = 0 となる。
最 終 的 な 状 態 は 、 タ ス ク D (rcnt = 1) が 待 ち 状 態 の ま ま で あ り 、
semcnt=0 となっている。これは、a. b. と異なった状態である。
すなわち、かなり細かいケースではあるが、割込み禁止時間を短くすると、システムコールの不可分性を保証できない場合がある。
（例2） tsk̲sts をタスク独立部から発行できるシステムコールに含めた場合、このシステムコールの処理自体は特に難しくないが、そこで得られる情報の一貫性を正しく保とうとすると処理が複雑化する。
たとえば、タスクを SUSPEND 状態に入れる場合を考えると、カーネルの中で suscnt を増やし、tskstat を SUSPEND にするという処理が必要である。しかし、この2つの操作の間で割り込みが入り、そこでtsk̲sts が実行された場合には、そこで返る情報に矛盾が生じることになる。
それを防ぐためには、2つの操作の間を割込み禁止にしなければならない
が、それでは割込み禁止時間が増大し、性能低下の危険がある。
したがって、割込みハンドラから tsk̲sts を発行することが可能であるとしても、返す情報の一貫性は保証できない場合がある。

第二章 ITRON 2基本機能

268

def̲int

割込みハンドラを定義する
def̲int
def̲int:

Define Interrupt Handler【パラメータ】
intvecInterruptVector

割込みベクトル番号

inhatrInterruptHandlerAttribute

割込みアラームハンドラ属性

inthdrInterruptHandlerAddress

割込みハンドラアドレス

imaskInterruptMask

割込み処理開始時の割込みマスク【リターンパラメータ】
なし【解説】
割込みハンドラを定義し、使用可能にする。すなわち、inthdr で示される割込みハンドラのアドレスと、intvec で示される割込みベクトル番号との対応付けを行なう。
inhatr のサイズは標準で4バイトである。inhatr のフォーマットを［図3.17］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）は未使用であり、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16 のビット）はインプリメント依存の属性を表わし、下位ハーフワード（bit16〜bit31あるいは 2^15〜2^0 のビット）はシステム属性を表わす。

bit0
inhatrbit8
reserved(0)bit16インプリメント依存属性

bit31
システム属性［図3.17］inhatrのフォーマット

第三部 ITRON 2

def̲int

269

inhatr のシステム属性の部分では、次のような指定を行うことができる。
inhatr : = (TA̲ASM‖TA̲HLNG)TA̲ASM

ハンドラがアセンブラで書かれている

TA̲HLNG

ハンドラが高級言語で書かれている

TA̲HLNG の指定を行った場合には、ハンドラ起動時に直接 inthdr のア
ドレスにジャンプするのではなく、高級言語の環境設定プログラム（高級言語対応ルーチン）を通してから inthdr のアドレスにジャンプする。
TA̲HLNG の指定を行わない場合には、割込みハンドラの起動時にOSが介入しない。すなわち、ハードウエアの割込み処理メカニズムにより、このシステムコールで定義した割込みハンドラが直接起動される。したがって、割込みハンドラで使用するレジスタの退避と復帰は、ユーザが責任をもって行なう必要がある。
割込みハンドラは、ret̲int 等のシステムコール、またはアセンブラの割込みリターン命令により終了する。
割込みハンドラ内のシステムコール発行によりタスクのディスパッチを生じた場合は、割込みハンドラが終了して ret̲int 等のシステムコールによりOSにコントロールが戻ってくるまでディスパッチが遅らされる。したがって、割込みハンドラ内でディスパッチを生ずる可能性がある場合、一般には、アセンブラの割込みリターン命令ではなく、必ず ret̲int システムコールを使って割込みハンドラから復帰する必要がある。
inthdr = NADR (-1) の指定により、前に定義されていた割込みハンドラの定義が解除され、未定義の状態になる。ただし、前に定義されていた割込
みハンドラの定義解除を行わずに、直接新しいハンドラを定義しても、エラーにはならない。また、もともとハンドラが定義されていない状態（定義が解除された状態）で、inthdr=NADRの指定による定義解除の操作を行っても、エラーにはならない。後者の場合、このシステムコールは正常終了するが、割込みハンドラは未定義のままである。
割込みハンドラはタスク独立部として実行される。したがって、割込み
ハンドラの中では、待ちとなるシステムコールや、tskid = TSK̲SELF によって自タスクの指定を意味するシステムコールは実行することはできない。
imask は、割込みハンドラ起動時におけるプロセッサの割込みマスクの値を指定するものである。ただし、intvec や imask の詳細な意味は、プロセ

第二章 ITRON 2基本機能

270

def̲int

ッサ依存となる。また、プロセッサによっては、imask の指定が意味を持たない場合がある。
【エラーコード (ercd)】
E̲OK 正常終了
E̲NOSMEM

システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSATR

予約属性（inhatrが不正）

E̲ILADR

不正アドレス（inthdrが奇数、あるいは使用できない値）

E̲VECN

不正ベクトル番号（intvecが不正）

E̲IMS

不正IMASK（imaskが不正）

第三部 ITRON 2

ret̲int

271

割込みハンドラから復帰する
ret̲int
ret̲int:

Return from Interrupt Handler【パラメータ】
なし【リターンパラメータ】※ システムコールを発行したコンテキストには戻らない【解説】
割込みハンドラからのリターンの際に発行するシステムコールである。
割込みハンドラの中でシステムコールを実行してもディスパッチは起らず、このシステムコールが発行されて割込みハンドラを抜けるまで、ディスパッチが遅延させられる。
このシステムコールを呼び出した時の状態（スタック、レジスタ等）は、
割込みハンドラへ入った時の状態と同じでなければいけない。すなわち、
割込みハンドラで使用するレジスタの退避や復帰は、ユーザが行わなければならない。
また、レジスタの復帰をユーザが行なう関係で、このシステムコールでは機能コードを使用できない。したがって、このシステムコールの呼び出
しの際、一般には、他のシステムコールと別ベクトルのトラップ命令を用いる。
【エラーコード】※ 次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、
システムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合には、メッセージバッファへのロギングや、コンソールへのエラーメッセージの表示などを行うのが望ましいが、詳細な動作はインプリメント依存となる。
E̲CTX

コンテキストエラー（タスク部、準タスク部から実行）

第二章 ITRON 2基本機能

272

chg̲ims

割込みマスクを変更する
chg̲imschg̲ims:

Change Interrupt Mask

【パラメータ】
imask

InterruptMask

割込みマスク【リターンパラメータ】
なし【解説】
プロセッサの割込みマスクを、imask で指定した値に変更する。
通常、このシステムコールは、ユーザタスクの一部を割込み禁止にするために用いられる。
chg̲ims により割込みの禁止を行なっている間は、割込みハンドラ実行
中と同じように、割込みマスクが解除されるまでディスパッチを遅延する。
これは、割込みを禁止したままでディスパッチが行なわれると、割込み禁止の状態が中断したり、命令の実行に矛盾が起こったりするためである。
ただし、割込み禁止状態のタスクは、ディスパッチを遅延した状態にはなっているが、タスク独立部の扱いにはしない。
「ディスパッチ遅延区間」と「タスク独立部」は別のものとして考える。たとえば、割込み禁止状態のタ
スクが get̲tid を実行した場合、0ではなくそのタスクのタスクIDが返る。
【エラーコード (ercd)】
E̲OK

正常終了

E̲IMS

不正IMASK第三部 ITRON 2

273

例外管理機能例外の種類と例外クラス
ITRON2では、次のような例外事象に対して、その例外ハンドラを定義し、適切な処理を行なうことができる。例外ハンドラは、例外が発生した時に非同期に実行されるプログラムであり、例外発生前と同じリングレベ
ルで実行される。例外ハンドラには、タスク終了時に資源解放のために実行される終了ハンドラも含まれている。
― 終了要求他タスクが自タスクに対して ter̲tsk あるいは ras̲ter を発行することにより生じる例外が終了要求である。
終了要求に対する例外ハンドラを、特に終了ハンドラと呼ぶ。
タスクに対する終了ハンドラは、def̲ext により定義される。ハンドラ内
でタスクが終了するため、ハンドラから戻ることはない。
― 強制例外（タスク外から）
他タスクが自タスクに対して ras̲fex システムコールを発行することによって生じる例外が強制例外である。
タスクに対する強制例外ハンドラは、def̲fex により定義され、ret̲exc によりハンドラから戻る。
なお、強制例外の機能は拡張仕様である。
― CPU例外
機械命令レベルのエラー（ゼロ除算など）が発生した場合に生じる例外がCPU例外である。
タスクに対する CPU例外ハンドラは、def̲cex により定義され、ret̲exc
によりハンドラから戻る。CPU例外は、マスクすることができない。
― システムコール例外（拡張SVCによるエラーを含む）
システムコール実行に伴うエラー（パラメータエラーなど）が発生した場合に生じる例外がシステムコール例外である。
第二章 ITRON 2基本機能

274
タスクに対するシステムコール例外ハンドラは、def̲sex により定義され、
ret̲exc によりハンドラから戻る。
なお、システムコール例外の場合は、CPU例外と違って、システムコー
ルのリターン値として個別にエラーチェックが可能であり、例外ハンド
ラの必要性が少ない。また、高級言語への対応やハンドラ起動時に渡す情報が CPU例外と異なっている。CPU 例外とシステムコール例外を分けるのは、このためである。
上記の分類は、次に述べる例外クラスの分類に対応したものである。例
外と終了要求は、合わせて次のようにクラス分けされる。CPU例外を除き、それぞれの例外クラスに対して例外ハンドラの起動をマスク（あるいは遅延）させることができる。
EC̲TER

終了要求クラス

他タスクの発行した ter̲tsk, ras̲ter により発生する。
これに対するハンドラ（終了ハンドラ）は優先度を上げて実行される。
この例外がタスク実行中に発生した場合の例外ハンドラは def̲ext で定義され、この例外が拡張SVC中で発生した場合の例外ハンドラは sdef̲extで定義される。
原則として元のプログラムに戻らないが、拡張SVCハンドラ中で起動された終了ハンドラでは、戻る必要が生じる場合もある。
他の例外とは異なり、この終了要求は、現在実行中のハンドラに対する要求ではなく、タスク全体（そのタスクとタスクから起動されて実行中のハンドラ全部）に対する要求となる。例えば、タスクAが拡張SVCハン
ドラBを呼び、それを準タスクとして実行中に終了要求が受け付けられた場合、まず拡張SVCハンドラBに対する終了ハンドラが実行され、拡張
SVCハンドラからタスクに戻ってから、タスクに対する終了ハンドラが実行されることになる。すなわち、終了要求は、現在実行中の拡張SVC
ハンドラに影響を与えるだけではなく、それを呼んだタスクにも伝達されていく。
EC̲FEX

強制例外クラス

他タスクの発行した ras̲fex により発生する。
強制例外ハンドラは、タスクに対するもののみが存在する。拡張SVCハ
ンドラに対する強制例外ハンドラは無い。拡張SVCハンドラの実行中に
第三部 ITRON 2

275
強制例外を受けた場合、拡張SVCハンドラの中では強制例外ハンドラの起動が抑制されており、タスクに戻った時にタスクに対する強制例外ハンドラが起動される。これは、強制例外がタスクに対して要求されるものであり、ras̲fex を実行した時にたまたまそのタスクが拡張SVCを実行中だったとしても、それは直接関係しないという理由による。
タスクに対する強制例外ハンドラは、def̲fex によって定義される。
EC̲CEX

CPU例外クラス

ゼロ除算など、プロセッサによる自タスクのハードウエア的な例外により発生する。
この例外がタスク実行中に発生した場合の例外ハンドラは def̲cex で定義され、この例外が拡張SVC中で発生した場合の例外ハンドラは sdef̲cex
で定義される。
※ 以下はシステムコール実行中のエラーに対する例外（システムコール例外）を表わす例外クラスである。これらの例外がタスク実行中に発生した場合の例外ハンドラは def̲sex で定義され、この例外が拡張SVC中で発生した場合の例外ハンドラは sdef̲sex で定義される。
（EC̲SYS を除く）
EC̲SYS

システムエラー例外クラス

原因不明のエラー、システム全体に影響する重大なエラーなど
システムコールのエラーのうち、このエラーが発生した場合に限り、
idef̲sex で定義されたタスク独立部に対する例外ハンドラが起動される。
EC̲NOMEM

メモリ不足エラー例外クラス

EC̲RSV

予約機能エラー例外クラス

EC̲PAR

パラメータエラー例外クラス

主に、エラーがスタティックに（実行前に）判定できるものを含む。
EC̲OBJ 不正オブジェクト指定例外クラス
EC̲ACV

アクセス権違反例外クラス

EC̲CTX

コンテキストエラー例外クラス

EC̲EXEC

実行時エラー例外クラス

第二章 ITRON 2基本機能

276
EC̲EXCMP

実行終了時エラー例外クラス

EC̲RLWAI

待ち状態強制解除例外クラス

EC̲RSLT

処理実行結果を示す例外クラス

これらのニモニックは例外クラスを 0〜31 の番号で示したものであるが、例外ハンドラ起動のマスク等を指定するためには、これらの例外クラスをビット対応の表現にしたものを利用する。例外クラスをビット対応の表現にしたものは ECM̲xxxx のニモニックで表わされ、EC̲xxxx との関係は次のようになる。
ECM̲xxxx = (H'80000000 ≫ EC̲xxxx)※ '≫' は論理右シフトを示す。
例外ハンドラの独立性と例外ハンドラ定義環境
例外の処理を行う例外ハンドラは、その例外を発生する可能性のあるプ
ログラムと組にして提供されるべきである。例えば、入出力処理を行う拡張SVCハンドラのプログラムがあった場合、その拡張SVCハンドラに対する例外ハンドラを作成するためには、拡張SVCハンドラの内部構成がよく分かっていなければならない。しかし、拡張SVCハンドラのユーザの側では、単にそれを使って入出力ができれば良い。ユーザの側では、拡張SVC
ハンドラの内部仕様やインプリメント方法は知らないのが普通であり、また知る必要もないので、拡張SVCハンドラに対する例外ハンドラを作成することはできない。したがって、拡張SVCハンドラに対する例外ハンドラ
は、拡張SVCハンドラの作成と同時に行われ、同時に提供されなければならない。同じように、拡張SVCハンドラを利用する側のタスクに対する例
外ハンドラも、タスクの内部仕様やインプリメント方法を知らないと作成できないのが普通である。ところが、拡張SVCハンドラとタスクは全く独立して作成されることが多いので、それぞれに対する例外ハンドラも独立して定義できなければならない。また、拡張SVCハンドラ同士であっても、
機能コードが違えば、全く独立して作成されているかもしれない。そのため、異なる機能コードの拡張SVCハンドラに対する例外ハンドラも独立して定義できなければならない。もし、システム全体で一つの例外ハンドラ
しか定義できないものとすると、入出力処理の拡張SVCで例外ハンドラを

第三部 ITRON 2

277
使ってしまった場合には、他のタスクや拡張SVCハンドラでは例外ハンドラが使えない（入出力処理の拡張SVCに対する例外ハンドラが動いても無意味）ということになってしまう。
以上のような要求に対応するため、ITRON2では、例外発生時のコンテ
キスト（タスク実行中、拡張SVCハンドラ実行中など）によって、どの例外
ハンドラが起動されるかを切り換えるようになっている。具体的には、次のような例外ハンドラを独立して定義することができる。
A. タスクに対する例外ハンドラ
A-e. タスクに対する終了ハンドラ（def̲ext により定義）

A-f. タスクに対する強制例外ハンドラ（def̲fex により定義）

A-c. タスクに対するCPU例外ハンドラ（def̲cex により定義）

A-s. タスクに対するシステムコール例外ハンドラ （def̲sex により定義)
上記のハンドラは、各タスク毎に独立して定義することができる。また、各タスクに対するハンドラ以外に、全タスクで共通に使用されるハンドラを定義することができる。各タスクに対するハンドラが未定
義の場合は、全タスク共通のハンドラが起動される。
B. 拡張SVCに対する例外ハンドラ
B-e. 拡張SVCに対する終了ハンドラ(sdef̲ext により定義)

B-c. 拡張SVCに対するCPU例外ハンドラ(sdef̲cex により定義)

B-s. 拡張SVCに対するシステムコール例外ハンドラ (sdef̲sex により定義）
上記のハンドラは、各拡張SVCハンドラ（機能コード）毎に独立して定義することができる。また、各機能コードに対するハンドラ以外に、
全拡張SVCハンドラ（全機能コード）で共通に使用されるハンドラを定義することができる。各機能コードに対するハンドラが未定義の場合
は、全機能コード共通のハンドラが起動される。
拡張SVCハンドラ実行中は強制例外の起動が抑制されるため、拡張
SVCハンドラに対する強制例外ハンドラはない。
C. タスク独立部やOS内部（カーネル）に対する例外ハンドラ
C-e. タスク独立部に対する終了ハンドラ（idef̲ext により定義）

C-c. タスク独立部に対するCPU例外ハンドラ（idef̲cex により定義）

C-s. タスク独立部に対するシステムコール例外ハンドラ（idef̲sex により定義）

第二章 ITRON 2基本機能

278
例外ハンドラを定義するシステムコールがこのように分離されているのは、パラメータ等が異なるためである。拡張SVCハンドラに対する例外ハンドラの定義機能は、システム操作機能に分類されている。
上記のように、「現在例外が発生した場合にどこで定義された例外ハンドラが起動されるか」を区別する環境を例外ハンドラ定義環境と呼ぶ。例外ハンドラ定義環境は、タスク毎に異なり、また、タスクから呼ばれた拡張
SVC毎にも異なっている。逆に、タスクや拡張SVCから例外ハンドラが起動された場合には、例外ハンドラ定義環境は変わらない。また、異なるタスクから呼ばれた同一の拡張SVCでも、例外ハンドラ定義環境は同じになる。例えば、次のような状況では、bとc、fとd の例外ハンドラ定義環境が同じであり、a, b, d, e の例外ハンドラ定義環境はそれぞれ異なっている。
a. タスクAb. タスクAから呼ばれた拡張SVCのB
c. タスクAから呼ばれた拡張SVCのBの中で起動された例外ハンドラC
d. 例外ハンドラCの中から呼ばれた拡張SVCのD
e. タスクE
f. タスクBから呼ばれた拡張SVCのD※ この場合、a, b=c, d=f, e の異なる 4 つの例外ハンドラ定義環境が存在する。
例外ハンドラを起動する際は、例外ハンドラ定義環境が変わらないため、タスク中で終了要求を受け付けた場合と、タスクに対するCPU例外ハンド
ラの中で終了要求を受け付けた場合では、同じ終了ハンドラが起動されることになる。特に、例外の種類が同じである場合、例えば、システムコー
ル例外のハンドラの中で再度システムコール例外が発生したような場合には、同じハンドラが再帰的に呼び出されることになる。ただし、例外ハン
ドラの起動により、例外ハンドラの起動を許可するかどうかを示す例外マ
スク環境が別のものになるため、起動されるべき例外ハンドラは同じものであるが、実際には例外が発生しても例外ハンドラが起動されない場合がある。例外マスク環境については次の項で説明する。
例外マスク環境
例外ハンドラの実行中は、同じ種類の例外が発生しても例外ハンドラの再帰的な起動を行わないのが普通である。すなわち、例外ハンドラ実行中
のみ、一時的に例外ハンドラ起動の有無を変更したい場合がある。また、第三部 ITRON 2

279
例外ハンドラは、各タスクや個々の拡張SVCに対して別々のものが定義される。したがって、拡張SVCの要求タスクが例外ハンドラの起動を許可していても、拡張SVCの内部で一時的に例外をマスクしたい場合や、その逆の場合がある。したがって、例外ハンドラ起動の有無を決める例外マスク
は、こういった状況に応じて自動的に切り換わるものが望ましい。
そこで、「例外ハンドラ起動の有無」を表わす環境を「例外マスク環境」と呼ぶことにし、例外マスク環境は各タスクや各タスクから呼ばれた各ハ
ンドラ（拡張SVCハンドラ、例外ハンドラ）に対して独立して存在するものとする。したがって、例外マスク環境は、タスク毎に異なり、タスクから呼ばれた拡張SVC毎にも異なり、タスクや拡張SVCから呼ばれた例外ハン
ドラ毎にも異なっている。例えば、次のような状況では、a, b, c, d, e, fの例
外マスク環境はすべて異なったものになる。
a. タスクAb. タスクAから呼ばれた拡張SVCのB
c. タスクAから呼ばれた拡張SVCのBの中で起動された例外ハンドラC
d. 例外ハンドラCの中から呼ばれた拡張SVCのD
e. タスクE
f. タスクBから呼ばれた拡張SVCのD※ この場合、a, b, c, d, e, f の異なる 6 つの例外マスク環境が存在する。
例外マスクは、例外マスク環境毎に、emsptn (Exception Mask Pattern) というビットパターンによって表現される。emsptn は、例外クラス別に例外
ハンドラ起動の禁止 / 許可を表わしたものである。
なお、ここでは、タスク部や準タスク部に対する例外マスク環境についての説明を行っている。タスク独立部に対する例外マスク環境や emsptn も考えられるが、それについては後で説明を行う。
例外（終了処理要求、強制例外を含む）が発生した場合、発生した例外の例外クラスが、現在の例外処理環境の emsptn によってマスクされていれば、例外ハンドラは起動されない。この時、発生した例外がシステムコー
ル例外であれば、例外ハンドラ起動要求はキャンセルされる。この場合は、エラーコードを参照することによってのみ、エラーがあったということを知ることができる。
一方、発生した例外が終了処理要求や強制例外であり、emsptn によって第二章 ITRON 2基本機能

280
それがマスクされていた場合は、例外ハンドラ起動要求がキャンセルされるのではなく、マスクが解除されるまで例外ハンドラの起動が遅延させられる。この時、タスクが例外ハンドラ起動要求を覚えておく必要があるが、そのために次の項の「例外ペンディング環境」が利用される。
現在の例外マスク環境、すなわち自タスクや自ハンドラの emsptn は、
set̲ems, clr̲ems を使って動的に変更することができる。clr̲ems では、ペンディングになっていた終了処理要求、強制例外の有無がチェックされ、その結果によって、遅らせられていた終了ハンドラや強制例外ハンドラの起動が行なわれる。
拡張SVCハンドラ実行中に終了要求を受け付け、拡張SVCハンドラに対する終了ハンドラが起動された場合の動作例を［図3.18］に示す。

タスク {A}

拡張SVC {B}(def̲svcで定義)

拡張SVC {B} に対する
終了ハンドラ {BE}（sdef̲extで定義）

set̲ems（終了要求）

set̲ems（終了要求）

終了要求

cal̲svc(B)

拡張SVC {B} に対する
資源回収

clr̲ems（終了要求）☆
タスク {A} に対する
終了ハンドラ {AE}clr̲ems（終了要求）
タスク {A} に対する資源回収
ext̲tsk(ret̲exc)＊'' は、例外マスクの機能のために終了ハンドラの起動が遅廷させられている区間を示す。
拡張SVCハンドラに対する終了ハンドラ、タスクに対する終了
ハンドラとも、例外マスクによって起動が遅らされている。
＊要求タスクが例外をマスクしていても、そこから呼ばれた拡張
SVCでは例外マスクを解除したい場合がある。
＊拡張SVCハンドラに対する終了ハンドラ {BE} で ret̲exc が実行された場合には、ret̲svc が実行された場合と同様に、拡張SVCを呼んだ側のコンテキスト（終了ハンドラを起動したコンテキスト＝☆ではない）に戻る。この時の s̲ercd は E̲TER になる。

［図3.18］拡張SVCハンドラに対する終了ハンドラ

第三部 ITRON 2

ret̲svc(ret̲exc)281
この場合、タスク{A}からみると、終了要求がマスクされている間に拡張SVC{B}に対する終了ハンドラ{BE}が動いていることになる。しかし、{BE}で操作するオブジェクトは、拡張SVC{B}で使用していたオブジェ

クトに限られ、タスク{A}で操作していたオブジェクトを直接操作することは無いはずである。また、たとえ操作しても、矛盾の無い形に戻すように
プログラミングすることが可能なはずである。したがって、タスク{A}が終了要求をマスクしていても、これはタスク{A}に対する終了ハンドラ{AE}の起動の抑止を意味するものであり、拡張SVC{B}に対する終了ハンドラ{BE}の起動を抑止する必然性は無い。タスクに対する終了ハンドラ起動の例外マスクと、拡張SVCに対する終了ハンドラ起動の例外マスクとを別々に指定できるのは、こういった理由による。
また、上記のように、拡張SVCに対する終了ハンドラ{BE}とタスクに対する終了ハンドラ{AE}は、連続して動くとは限らない。その意味では、「拡張SVCに対する終了ハンドラ」を「拡張SVC中断ハンドラ」と考えることもできる。拡張SVCに対する終了ハンドラ{BE}の最後では、「終了要求により拡張SVCが中断した」といった意味のエラーを返すのが一般的である。
CPU例外はマスクすることができないため、emsptn のうち、CPU例外の例外クラスに対するビットは常にクリアされている。これは、タスクに対する例外マスク環境、拡張SVCハンドラに対する例外マスク環境、例外ハ
ンドラに対する例外マスク環境とも同様である。また、拡張SVCハンドラ
実行中は強制例外ハンドラの起動が遅延させられるため、拡張SVCハンドラに対する例外マスク環境、および拡張SVCハンドラから起動された例外
ハンドラに対する例外マスク環境では、強制例外の例外クラスに対する
emsptn のビットは常にセットされている。
タスク生成直後の例外マスク環境の emsptn の値は次のようになる。
終了処理(EC̲TER)

可

強制例外(EC̲FEX)

マスク

CPU例外(EC̲CEX)可（マスクをセットできない）

その他（システムコール例外） 全部マスク
すなわち、
emsptn = ˜( ECM̲CEX ¦ ECM̲TER ¦ ECM̲ABO ¦ ECM̲SUS )※ '&' はビット対応の論理積、'¦' はビット対応の論理和、' ˜ 'はビット対応の否定

第二章 ITRON 2基本機能

282と書くことができる。タスク起動時に終了要求をマスクしておきたい場
合は、cre̲tsk の実行後、sta̲tsk の実行前に set̲ems (setptn = ECM̲TER) を実行しておけば良い。なお、タスク終了時には emsptn の値がリセットされ、タスク生成直後と同じ値に戻る。
拡張SVCハンドラ起動時の例外マスク環境の emsptn の値は次のようになる。
終了処理(EC̲TER)

マスク

強制例外(EC̲FEX)

マスク（マスクをクリアできない）

CPU例外(EC̲CEX)可（マスクをセットできない）

その他（システムコール例外） 全部マスク
すなわち、
emsptn = ˜ ( ECM̲CEX ¦ ECM̲ABO )※ '&' はビット対応の論理積、'¦' はビット対応の論理和、' ˜ 'はビット対応の否定と書くことができる。拡張SVCハンドラ起動時の emsptn の値は、ハンドラ起動前の emsptn の値（拡張SVCハンドラを呼んだ側の emsptn の値）には関係しない。
タスク部、準タスク部で例外（終了）ハンドラが起動された時の emsptn の値は、ハンドラ起動前の例外マスク環境の emsptn の値に、その例外（終了）
ハンドラの起動要因となった例外の例外クラスのマスクを加えた（論理和をとった）ものである。たとえば、システムコール例外ハンドラ起動時のemsptn は、システムコール例外発生前の emsptn と、発生したシステムコー
ル例外の例外クラスビットパターンとの論理和になる。このような仕様になっているのは、同じ種類の例外の二重起動を禁止するためである。違う種類の例外については、例外ハンドラの二重起動は可能であり、同じ種類の例外については、例外ハンドラの二重起動は原則として禁止している。
ただし、終了ハンドラの起動時には、終了要求に対するマスクだけではな
く、強制例外に対するマスクも自動的にセットされる。これは、終了要求を受け付けた場合、強制例外の処理を行うことは無意味になることが多いためである。したがって、終了ハンドラ起動時の emsptn は、終了処理要求の受け付け前の emsptn と (ECM̲TER¦ ECM̲FEX) との論理和になる。一方、CPU例外はマスクすることができないので、CPU例外ハンドラ起動時のemsptn は、CPU例外発生前の emsptn と同じである。

第三部 ITRON 2

283
ハンドラの起動では、元の例外マスク環境の emsptn は変化しない。また、
ハンドラから戻る際には、emsptn も元の例外マスク環境のものに戻る。ハンドラから戻る際のハンドラ側の emsptn の値は、単に捨てられる。
例外（終了）ハンドラ起動時に終了処理要求や強制例外（起動が遅延させられる例外）に対する例外マスクがセットされていた場合には、例外（終了）
ハンドラの中でその例外マスクを解除することはできない。例えば、終了
ハンドラの起動をマスクしている間にCPU例外が発生した場合、そこで起動されたCPU例外ハンドラの中では、終了処理要求に対する例外マスクをクリアすることができない。これは、CPU例外ハンドラの実行中も終了ハ
ンドラに対するクリティカルセクションが続いており、終了ハンドラを起動すると、CPU例外発生直前に行われていた処理に関して矛盾を生じるためである。ここで、もしCPU例外ハンドラ実行中に ter̲tsk による終了要求を受けた場合には、CPU例外ハンドラから元のコンテキストに戻り、終了
処理要求に対する例外マスクが解除された後で終了ハンドラが起動される。
また、終了ハンドラの起動時には、自動的に終了ハンドラの再起動に対するマスク (ECM̲TER) がセットされるが、終了ハンドラの中でこのマスクを解除することはできない。これに対して、終了ハンドラや強制例外ハンドラの起動時に自動的にセットされる強制例外のマスク (ECM̲FEX) は、終了ハンドラや強制例外ハンドラの中で、必要に応じて解除することが可能である。
例外ハンドラの中で例外マスクをクリアできないケースについて、具体的な動作例を［図3.19］に示す。
一方、拡張SVCハンドラに関しては、終了ハンドラの起動がマスクされている間に呼び出された拡張SVCハンドラの中でも、終了処理要求に対する例外マスクを解除することが可能である。拡張SVCハンドラ実行中に終了要求を受けた場合は、拡張SVCに対する終了ハンドラが起動され、タスクに対する終了ハンドラが起動されるわけではないので、クリティカルセ
クションの問題は発生しない。この時、タスクに対する終了ハンドラは、
拡張SVCハンドラあるいは拡張SVCに対する終了ハンドラから元のタスクに戻り、終了処理要求に対する例外マスクが解除された後で起動される。
また、拡張SVCハンドラがネストしていた場合も同様である。すなわち、
拡張SVC{A}が終了ハンドラの起動をマスクしている間に拡張SVC{B}を呼び出した場合、拡張SVC{B}の中で終了処理要求に対する例外マスクを解除

第二章 ITRON 2基本機能

284
'
'
'

' 終了ハンドラ起動可' 終了ハンドラ起動マスク中（clr̲emsでマスク解除可）' 終了ハンドラ起動マスク中（マスク解除不可）

タスク

CPU例外ハンドラ

強制例外ハンドラ(1)☆強制例外発生
set̲ems(ECM̲TER)

ret̲exc
強制例外ハンドラ(2)☆強制例外発生
ret̲exc☆CPU例外発生システムコール例外ハンドラ
強制例外ハンドラ(3)ret̲exc
set̲ems(ECM̲TER)☆強制例外発生☆システムコール例外発生

ret̲exc
ret̲exc

clr̲ems(ECM̲TER)
終了ハンドラ
☆終了要求発生
ext̲tsk＊強制例外ハンドラ(1) (2) (3) は、途中で再定義が行われない限り、プログラムとしては同じものが動く。

［図3.19］例外マスクをクリアできないケース

することが可能である。拡張SVC{B}の実行中に終了要求を受けた場合は、
拡張SVC{B}に対する終了ハンドラが起動され、拡張SVC{A}に対する終了
ハンドラが起動されるわけではないので、やはりクリティカルセクションの問題は発生しない。この時、拡張SVC{A}に対する終了ハンドラは、拡張
SVC{B}あるいは拡張SVC{B}に対する終了ハンドラから拡張SVC{A}に戻り、終了処理要求に対する拡張SVC{A}の例外マスクが解除された後で起動される。

第三部 ITRON 2

285

'
'
'

' 終了ハンドラ起動可' 終了マスク中（clr̲emsでマスク解除可）' 終了マスク中（マスク解除不可）

タスクまたは
拡張SVCハンドラ {A}

拡張SVCハンドラ {B}clr̲ems(ECM̲TER)
拡張SVC {B} に対するCPU例外ハンドラ(1)☆CPU例外発生
ret̲exc

set̲ems(ECM̲TER)
set̲ems(ECM̲TER)

拡張SVC {B} に対するCPU例外ハンドラ(2)cal̲svc()☆CPU例外発生

ret̲exc

clr̲ems(ECM̲TER)
ret̲svc＊拡張SVC {B} に対するCPU例外ハンドラ(1)(2)は、途中で再定義が行われない限り、プログラムとしては同じものが動く。

［図3.20］拡張SVCハンドラと例外マスク

ただし、拡張SVCに対する例外（終了）ハンドラの起動時に、終了処理要求や強制例外に対する拡張SVCの例外マスクがセットされていた場合には、
拡張SVCに対する例外（終了）ハンドラの中で、それらの例外マスクを解除することはできない。これは、タスクの場合と同様である。
拡張SVCハンドラの起動と終了要求に対する例外マスクとの関係について、具体的な動作例を［図3.20］に示す。

第二章 ITRON 2基本機能

286
例外ペンディング環境
拡張SVC処理中にシステムコール例外や CPU例外が発生した場合は、拡張SVCに対する例外ハンドラのみが起動されれば良く、要求タスクに影響を与える必要はない。エラーの原因やそれに対する処理が、拡張SVCだけで閉じたものになるからである。一方、拡張SVC処理中に強制例外が発生した場合は、拡張SVCからタスクに戻るまで、その要求を保持しておく必要がある。また、拡張SVC処理中に終了処理要求が発生した場合は、まず拡張SVC処理に対する終了ハンドラを起動し、そこから戻った後に要求タ
スクの終了ハンドラも起動する必要がある。これは、拡張SVCハンドラがネストした場合にも同様である。
そこで、「終了要求や強制例外要求の有無」を表わす環境を「例外ペンディング環境」と呼ぶことにし、この中の epndptn (Pending ExceptionClass
Pattern) というビットパターンによってペンディング中の例外を表現することにする。epndptn で対象となる例外クラスは終了処理要求と強制例外に対する例外クラスのみであり、ECM̲TER と ECM̲FEX の2ビットで表現される。上記のような理由により、例外ペンディング環境はハンドラ毎に存在するのではなく、各タスクに対してただ一つのみ存在する。例えば、次のような状況では、a, b, c, d の例外ペンディング環境がすべて同じであり、a,e, f の例外ペンディング環境は異なったものになる。
a. タスクAb. タスクAから呼ばれた拡張SVCのB
c. タスクAから呼ばれた拡張SVCのBの中で起動された例外ハンドラC
d. 例外ハンドラCの中から呼ばれた拡張SVCのD
e. タスクE
f. タスクBから呼ばれた拡張SVCのD※ この場合、a=b=c=d, e, f の異なる 3 つの例外ペンディング環境が存在する。
ECM̲TER に対する epndptn は、ter̲tsk や ras̲ter により一度セットされると、タスクが終了するまでクリアされない。一方、ECM̲FEX に対する
epndptn は、ras̲fex によりセットされた後、強制例外に対するマスクが解除
されて強制例外ハンドラが起動されると、クリアされてしまう。これは、両者の性質が次のように異なるためである。

第三部 ITRON 2

287
終了ハンドラ (ECM̲TER):― 終了要求受付時にネストした状態の拡張SVCハンドラを実行している
場合は、実行中の各レベルの拡張SVCハンドラに対する終了ハンドラと、タスクレベルに対する終了ハンドラをすべて起動する必要がある。
つまり、1回の ter̲tsk, ras̲ter に対して起動されるハンドラは複数であり、1つの終了ハンドラを起動しても、要求をクリアすることができない。
― 終了要求が一度受け付けられた後は、最終的にタスクを終了するしかあ
り得ないので、終了要求をクリアする必要はない。
強制例外ハンドラ (ECM̲FEX):― 要求が起きる度に何度でも起動される。強制例外ハンドラからリターンした後は、完全に元の状態に戻る。したがって、強制例外ハンドラを起動した後は要求をクリアしておかないと、次の強制例外を受け付けられる体制にならない。
― 拡張SVCハンドラに対する強制例外ハンドラが無いため、1回の ras̲fex
に対して起動されるハンドラはタスクレベルに対する強制例外ハンドラのみである。つまり、1回発行された ras̲fex に対して、起動される強制
例外ハンドラは1つだけである。そのため、強制例外ハンドラ起動直後に要求をクリアしても、問題はない。
タスク起動時の epndptn の値は、ECM̲TER と ECM̲FEX とも要求無しになっている。epndptn は DORMANT 状態になる毎にクリアされる。
epndptn は、各タスクおよび各例外（終了と強制例外）に対して1ビットずつしか用意されていないため、終了要求同士、あるいは強制例外起動要求同士の複数キューイングはできない。たとえば、同じタスクを対象とした
ter̲tsk が2回発行されても、終了ハンドラは1回しか起動されない。ただし、終了ハンドラが受け取る例外コード exccd は、それぞれの ter̲tsk で渡された例外コードの論理和をとったものになる。また、この場合、先の強制例
外（終了要求）を起こした ter̲tsk, ras̲ter, ras̲fex にも、後の強制例外（終了要求）を起こしたter̲tsk, ras̲ter, ras̲fex にもエラーは返らない。

第二章 ITRON 2基本機能

288
例外関係の各機能の処理概要
以下に、例外関係のシステムコール等の処理方法を述べ、仕様の確認およびインプリメントのヒントとする。なお、以下の説明はあくまでも処理の概要を述べたものであり、詳細な点や例外が多重に発生した場合の処理、
SUSPEND 要求の遅延などは考慮していない。
― ras̲fex の処理
if（対象タスク/ハンドラの emsptn ->ECM̲FEXがクリア
and. 対象タスクが待ち状態でない）
then
対象タスクの強制例外ハンドラを起動;
else
対象タスクのepndptn->ECM̲FEXをセット;
endif― ras̲ter の処理
対象タスクのepndptn->ECM̲TERをセット;
if（対象タスク/ハンドラの emsptn->ECM̲TERがクリア.and. 対象タスクが待ち状態でない） then
対象タスク/ハンドラの終了ハンドラを起動;
endif― ter̲tsk の処理
対象タスクのepndptn->ECM̲TERをセット;
if（対象タスク/ハンドラのemsptn->ECM̲TERがクリア）then
対象タスク/ハンドラの終了ハンドラを起動;※ 待ち状態の時もそうでない時も含む
else if（対象タスクが待ち状態）then
待ち状態を解除しE̲RLWAIを返す;
endif― 待ち解除時の処理
if（対象タスクの epndptn->ECM̲TERがセット.and. 対象タスク/ハンドラのemsptn->ECM̲TERがクリア）
then
対象タスク/ハンドラの終了ハンドラを起動;
第三部 ITRON 2

289
endif
if（対象タスクのepndptn->ECM̲FEXがセット.and. 対象タスク/ハンドラのemsptn->ECM̲FEXがクリア）
then
対象タスクのepndptn->ECM̲FEXをクリア;
対象タスクの強制例外ハンドラを起動;
endif― ret̲svc の処理
if（epndptn->ECM̲TERがセット.and. 戻り先の環境のemsptn->ECM̲TERがクリア）
then
戻り先の環境の終了ハンドラを起動;
endif
if （epndptn->ECM̲FEXがセット.and. 戻り先の環境のemsptn->ECM̲FEXがクリア）
then
epndptn->ECM̲FEXをクリア;
戻り先の環境の強制例外ハンドラを起動;
endif― ret̲exc の処理/* 例外マスク環境を戻す。後の処理は clr̲ems と同じ */― clr̲ems の処理パラメータに応じてemsptnを変更;
if （epndptn->ECM̲TERがセット .and. emsptn->ECM̲TERがクリア）
then
終了ハンドラを起動;
endif
if（epndptn->ECM̲FEXがセット .and. emsptn->ECM̲FEXがクリア）
then
epndptn->ECM̲FEXをクリア;
強制例外ハンドラを起動;
endif

第二章 ITRON 2基本機能

290
なお、拡張SVCハンドラの実行中は強制例外ハンドラが起動されない。
しかし、emsptn->ECM̲FEX がクリアされた状態であれば、このタスクは拡
張SVC以外の部分を実行中 (ring1〜3) であることが保証されるので、拡張
SVCハンドラ実行中かどうかというチェックを別に行う必要はない。
例外ハンドラが未定義の場合の動作
例外ハンドラは、個々のタスクあるいは拡張SVC毎に定義することが可能である。しかし、こういった個別の例外ハンドラを定義したくない場合には、タスク間あるいは拡張SVC間で共通に使用される例外ハンドラを定義することができる。タスクあるいは拡張SVCに対する個別の例外ハンド
ラが未定義で、かつタスク間あるいは拡張SVC間で共通の例外ハンドラが定義されていれば、例外発生時にそれが起動される。
また、個別の例外ハンドラも共通の例外ハンドラも未定義で、しかも対応する例外クラスのマスクがセットされていない場合には、システムデフォル
トの例外ハンドラを起動すると考える。システムデフォルトの例外ハンドラの中では、次のような処理を行うことを推奨しているが、詳細はインプリメ
ント依存である。互換性の高いプログラムを書くためには、システムデフォ
ルトの例外ハンドラの機能を利用せず、例外ハンドラの起動をマスクしておくか、例外ハンドラのプログラムをきちんと定義しておくのが望ましい。
例外マスクがクリアされており、かつ対応する例外ハンドラが未定義であった場合において、例外発生時の実行環境や発生した例外の種類とそれに対する動作（推奨仕様）との関係は次のようになる。強制例外の場合を除けば、例外ハンドラ未定義の場合は終了要求に置換する（終了ハンドラ未定
義の場合は即座にタスクやハンドラを終了する）というのが原則である。
また、発生した例外の種類、例外マスクの有無、例外ハンドラ定義の有無と、その時の動作との関係をまとめて整理すると、次のようになる。
システムコール例外ハンドラ、あるいはCPU例外ハンドラが未定義で例
外が発生し、それが終了要求に置き換わった場合は、システムデフォルトの例外ハンドラから abo̲tsk を発行すると考える。したがって、この場合は終了マスクが無視される。この時の例外コード（abo̲tskのパラメータである例外コードexccdに相当する値）としては、次の値が使用される。
CPU例外の場合

ECM̲CEX H'10000000

システムコール例外の場合 ECM̲SEX H'08000000 /* ECM̲SYS と同じ値 */第三部 ITRON 2

291
実行環境

→

タスク実行中拡張SVCハンドラ実行中
タスクから呼ばれた例外ハンドラ実行中 拡張SVCから呼ばれた例外ハンドラ実行中

終了要求
タスク終了 [ext̲tsk]
強制例外
何もしない
CPU例外
終了要求に置換 [abo̲tsk]
システムコール例外 終了要求に置換 [abo̲tsk]

拡張SVCハンドラ終了 [ret̲svc]
何もしない
終了要求に置換 [abo̲tsk]
終了要求に置換 [abo̲tsk]＊[〜] 内は、例外ハンドラの中で [〜] 内のシステムコールを発行するのと等価の動作をするということを示す。
＊例外発生時のデバッガの起動については、別の方法で指定する。

［表3.3］例外ハンドラ未定義の場合の動作

マスク
→ 有り
無し
例外ハンドラ → 定義／未定義
定義
実行環境→ タスク内／ハンドラ内 タスク内／ハンドラ内
ペンディング
終了要求
ペンディング強制例外（マスク不可）CPU例外
システムコール例外 キャンセル

無し
未定義
タスク内

無し
未定義
拡張SVCハンドラ内

終了ハンドラ起動
タスク終了
拡張SVCハンドラ終了
強制例外ハンドラ起動
何もしない
何もしない
CPU例外ハンドラ起動
終了要求に置換 終了要求に置換
システムコール例外ハンドラ起動 終了要求に置換 終了要求に置換［表3.4］例外発生時の動作と例外マスクや例外ハンドラ定義状態との関係

結局、システムデフォルトの例外ハンドラは次のように書くことができる。
/* 強制例外に対するデフォルトのハンドラ */EXCHDR fex̲hdr( T̲EXC *pk̲exc, T̲REGS *pk̲regs, T̲EIT *pk̲eit ){/* 何もしない */ret̲exc( );}/* CPU例外に対するデフォルトのハンドラ */EXCHDR cex̲hdr( T̲EXC *pk̲exc, T̲REGS *pk̲regs, T̲EIT *pk̲eit ){abo̲tsk( ECM̲CEX );}/* システムコール例外に対するデフォルトのハンドラ */EXCHDR sex̲hdr( T̲EXC *pk̲exc, T̲REGS *pk̲regs, T̲EIT *pk̲eit ){abo̲tsk( ECM̲SEX );}第二章 ITRON 2基本機能

292
タスク｛A｝

CPU 例外発生
exccd=EITINF

システムデフォルト
CPU 例外ハンドラ

タスク｛A｝に対する終了ハンドラabo̲tsk
exccd=ECM̲CEX［図3.21］システムデフォルトのCPU例外ハンドラ

たとえば、CPU例外ハンドラが未定義でCPU例外が発生した場合には、
システムデフォルトの例外ハンドラにより、［図3.21］のような動作を行うことになる。
システムコール例外の場合に、エラーコードをそのまま終了要求の例外コードとして使用するのではなく、例外クラスビットパターン（対応する例外
クラスを2のべき乗のパターンにしたもの）を例外コードとして使用しているのは、複数の終了要求が重なった場合に、例外コードがビットパターンの論
理和をとる仕様になっているからである。また、システムコール例外の場合に、例外クラスに対応した別々の例外クラスビットパターンではなく、
ECM̲SEX を共通の例外コードとして使用するのは、デフォルトの例外ハンドラで使用する例外コードの範囲を狭くし、ユーザの使用する例外コードと競合する可能性を少なくするためである。ユーザ側では、ter̲tsk,ras̲ter など
に対する終了コードとして、ECM̲CEX, ECM̲SEX 以外のビットを利用する
ことにより、ビット対応にすべての要求を区別することが可能になる。ただし、将来システムで定義される例外コードが増えた場合には、上位ビット（上位1〜2バイト）を使用する予定なので、ユーザが利用する終了コードとしては、下位ビット（下位2バイト）を使用するのが望ましい。
なお、上記のケースで、終了ハンドラからCPU例外やシステムコール例
外に関する詳しい情報を知りたければ、hdr̲sts を使って、システムデフォ
ルトの例外ハンドラ（上記の cex̲hdr, sex̲hdr）の環境に対する例外コード(pk̲exc->exccd) を参照すればよい。また、例外発生時のレジスタの値（パラメータ）などを知りたい場合にも、hdr̲sts を使って、上記の cex̲hdr,
sex̲hdr の環境に対する pk̲regs を参照すればよい。

第三部 ITRON 2

293
一方、タスクに対する終了ハンドラが未定義で終了要求が発生した場合は、即座にタスクを終了する。また、拡張SVCハンドラに対する終了ハン
ドラが未定義で終了要求が発生した場合は、即座に拡張SVCハンドラからリターンする。この場合のエラーコードは E̲TER となる。
結局、システムデフォルトの終了ハンドラは次のように書くことができる。
/* タスクに対するデフォルトの終了ハンドラ */EXCHDR ext̲hdr( T̲EXC *pk̲exc, T̲REGS *pk̲regs, T̲EIT *pk̲eit ){/* タスク終了 */ext̲tsk( );}/* 拡張SVCハンドラに対するデフォルトの終了ハンドラ */EXCHDR sext̲hdr( T̲EXC *pk̲exc, T̲REGS *pk̲regs, T̲EIT *pk̲eit ){/* 拡張SVCハンドラから戻る */ret̲svc(s̲ercd=E̲TER);}
複数の例外が同時に発生した場合の動作
ITRON2で同時に発生する可能性のある例外は、他タスクから要求の出る終了要求、強制例外、および自タスクから要求の出るシステムコール例
外の3つである。これらの例外は、すべてOSレベルで発生する例外である。
これに対して、CPU例外は機械命令レベルで発生し、即座に起動されるため、上記の例外と同時に検出されることはない。また、OSレベルの例外であっても、複数のシステムコール例外が同時に発生することはない。
（シス
テムコールの複数のエラーが同時に検出される可能性はあるが、それらの間の優先度はエラーの検出順序といった問題で処理されるため、複数のシステムコール例外が発生するわけではない。システムコールから返ってくるエラーコードはただ一つである。
）
終了ハンドラを起動する時には、終了要求に対するマスクだけではなく、強制例外に対するマスクも自動的にセットされる。したがって、終了要求と強制例外が同時に受け付けられた場合でも、タスクに対する終了ハンド
ラのスタックフレームを形成した後は、強制例外ハンドラの起動は行われず、スタックフレームも形成されない。強制例外については PENDING 状
態のままとなる。
第二章 ITRON 2基本機能

294
強制例外、終了、システムコール例外をマスクしていないタスクが拡張
SVCを呼びだし、その拡張SVCが強制例外と終了をマスクしている間に強制 例 外 と 終 了 要 求 を 受 け 付 け 、 両 者 の 要 求 が PENDING 状 態 の ま まret̲svc(s̲ercd＜0) を実行した場合、終了要求、強制例外、システムコール
例外の3つの例外が重なることになる。この場合、「システムコール例外→終了要求→強制例外の順にネストしたスタックフレームを作り、その逆順にハンドラが起動される」というのが推奨仕様である。
たとえば、強制例外、終了、システムコール例外をマスクしていないタスクが拡張SVCを呼びだし、その拡張SVCが強制例外と終了をマスクしている間に強制例外と終了要求を受け付け、両者の要求が PENDING 状態のまま ret̲svc (s̲ercd＜0) を実行した場合のOSの推奨動作は次のようになる。
1) タスクのシステムコール例外ハンドラに対するスタックフレームを形成
2) タスクの終了ハンドラに対するスタックフレームを形成
この後は、タスクに対して定義された終了ハンドラが起動され、その中でタスクを終了してしまうため、システムコール例外ハンドラは起動されないことになる。また、終了ハンドラの中で clr̲ems (ECM̲FEX) を実行することにより、強制例外ハンドラが起動される。これらの動作を図で示すと［図3.22］のようになる。
なお、［図3.22］のような場合、拡張SVCに対する終了ハンドラは起動されない。拡張SVCから戻る前の環境では終了ハンドラの起動がマスクされており、また拡張SVCから戻った後の環境では、例外ハンドラ定義環境も元のコンテキスト（タスク）のものに戻っている。例外マスク環境と例外ハンドラ定義環境の切り換えは不可分に行われるため、拡張SVCに対する終了ハンドラが起動されることはない。

第三部 ITRON 2

295: ユーザープログラム（タスク、ハンドラ）の処理: OSによる処理

タスク

clr̲ems(˜(ECM̲TER I ECM̲FEX I ECM̲xxx) )cal̲svc

拡張SVCハンドラ
拡張SVCに対する
スタックフレーム生成

set̲ems(ECM̲TER)
強制例外要求（マスク中）
終了要求（マスク中）
ret̲svc(s̲ercd<0)（強制例外と終了要求のマスク解除）
タスクに対して定義された
システムコール例外ハンドラ
システムコール例外に対するスタックフレーム生成

タスクに対して定義された終了ハンドラ
終了要求に対する
スタックフレーム生成（強制例外マスク）終了
ハンドラ
clr̲ems〜ECM̲FEX
強制例外に対する
スタックフレーム生成
強制例外
ハンドラ
ret̲exc
ext̲tsk［図3.22］終了要求と強制例外とシステムコール例外が重なった場合の動作

第二章 ITRON 2基本機能

296
タスク独立部に対する例外処理
タスク独立部（割込みハンドラ）に対しても、idef̲cex, idef̲sex システム
コールによって例外ハンドラを定義することができる。ただし、性能面への配慮から、多重割込み（外部割り込み）の入り口や出口で例外マスク環境や例外ハンドラ定義環境を切り換えることは無理がある。したがって、割込みハンドラ同士であれば、優先度が異なっていても、すべて共通の例外
ハンドラと例外マスク環境を持つことになる。また、割込みハンドラ中から起動された例外ハンドラや拡張SVCハンドラについても、その中でさらに優先度の高い割込みを受け付けるケースを考えると、別々の例外ハンド
ラ定義環境や例外マスク環境を持つことはできない。結局、割込みハンドラ（タスク独立部）は、その中から呼ばれた拡張SVCハンドラや例外ハンド
ラを含めて、全体で共通の例外ハンドラ定義環境と例外マスク環境を持つということになる。
たとえば、割込みハンドラから拡張SVCハンドラAが呼ばれ、そこで例
外が発生した場合でも、拡張SVCハンドラAに対する例外ハンドラではなく、
idef̲Xexで定義されたタスク独立部に対する例外ハンドラが起動される。また、割込みハンドラに対するシステムコール例外の各例外クラスに対するマスクは、割込みハンドラ全体として共通の値を取ることになる。したがって、タスク独立部から発行される拡張SVCとタスク部から発行される拡張SVCとでは、システムコール例外の処理について区別して扱うことが必要になる。
タスク独立部に対する例外マスク環境の設定は、clr̲ems, set̲ems でtskid=TSK̲INDP(-2) を指定することによって行う。タスク独立部に対する
emsptn の初期値は次のようになる。
終了処理 (ECM̲TER)

可（マスクをセットできない）

強制終了 (ECM̲FEX)

マスク（マスクをクリアできない）

CPU 例外 (ECM̲CEX)可（マスクをセットできない）

システムコール例外

全部マスク

なお、タスク独立部に対する終了例外や強制例外の機能は無いし、CPU
例外はマスク不可なので、タスク独立部に対する例外マスク環境が意味を持つのは、システムコール例外に限られる。また、タスク独立部に対するシステムコール例外の機能は、必要性が少なく、インプリメントの負担も

第三部 ITRON 2

297
大きいので、インプリメント依存の機能とする。
タスク独立部に対する例外マスク環境は一つ（システム共通）なので、割込みが多重に発生しても、例外マスクは共通に使用される。したがって、
タスク独立部でシステムコール例外が発生した場合には、タスク部あるいは準タスク部でシステムコール例外が発生した場合とは異なり、対応する
例外マスクはセットされないものとする。タスク独立部に対する例外マス
ク の 値 が 変 化 す る の は 、 明 示 的 に clr̲ems(tskid=TSK̲INDP),
set̲ems(tskid=TSK̲INDP) を実行した場合のみ（システムダウンの前のタス
ク独立部用終了ハンドラの起動時に終了要求に対する例外マスクがセットされるケースを除く）である。もし、割込みハンドラの中でシステムコール
例外が発生した場合に例外マスクをセットする仕様にすると、割込みハン
ドラAの実行中に別の割込みが発生して割込みハンドラBが起動された場合に、割込みハンドラAに対するシステムコール例外ハンドラを実行中かどうかによって、割込みハンドラBに対する例外マスクの値が変わってくることになる。しかし、割込みハンドラBは割込みハンドラAとは全く無関係なので、これは不合理である。なお、タスク独立部（割込みハンドラ）に対するシステムコール例外の機能はインプリメント依存であり、この仕様が適用されるのは、タスク独立部に対するシステムコール例外の機能がインプリメントされた場合に限られている。
タスク独立部に対する例外マスクがクリアされており、かつ例外ハンド
ラが未定義の状態でタスク独立部の例外が発生した場合の動作は、タスク
部/準タスク部の動作に準じたものとすることを推奨する。具体的には、上記の場合に、タスク独立部に対する終了ハンドラ（idef̲extで定義したハンドラ）が定義されていれば、それが起動された後にシステムダウンとなる。
タスク独立部に対する終了ハンドラが定義されていなければ、即座にシス
テムダウンとなる。

第二章 ITRON 2基本機能

298

def̲ext

def̲cexdef̲sex

タスク用終了ハンドラの定義
def̲ext

タスク用CPU例外ハンドラの定義
def̲cex

タスク用システムコール例外ハンドラの定義
def̲sexdef̲ext:

Define ExitHandlerdef̲cex:

Define CPUExceptionHandlerdef̲sex:

Define SystemcallExceptionHandler【パラメータ】
tskid

TaskIdentifier

タスクID

exhatrExceptionHandlerAttribute

例外ハンドラ属性＜1＞exthdr ExitHandlerAddress

終了ハンドラアドレス＜2＞cexhdr CPUExceptionHandlerAddress

CPU例外ハンドラアドレス＜3＞sexhdr SystemCallExceptionHandlerAddress システムコール例外ハン
ドラアドレス［＜1＞def̲ext のみ］［＜2＞def̲cex のみ］［＜3＞def̲sex のみ］【リターンパラメータ】
なし【解説】
自タスクの例外ハンドラ、終了ハンドラを定義する。あるいは、
DORMANT 状態の他タスクの例外ハンドラ、終了ハンドラを定義する。
例外ハンドラでは、例外の原因となった情報を、スタックを通じて例外
コード exccd として受け取ることができる。exccd の内容は、終了ハンドラの場合は ter̲tsk, ras̲ter, abo̲tsk システムコールで指定したexccd であり、第三部 ITRON 2

def̲ext

def̲cexdef̲sex299

CPU例外の場合はプロセッサの例外処理の際に得られる情報（ベクトル番号など）であり、システムコール例外の場合はシステムコールのリターン値（エラーコード）である。
exhatr のサイズは標準で4バイトである。exhatr のフォーマットを［図3.23］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）は未使用であり、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16 のビット）はインプリメント依存の属性を表わし、下位ハーフワード（bit16〜bit31あるいは 2^15〜2^0 のビット）はシステム属性を表わす。
exhatr のシステム属性の部分では、次のような指定を行うことができる。
exhatr : = (TA̲ASM ‖ TA̲HLNG)TA̲ASM

ハンドラがアセンブラで書かれている

TA̲HLNG

ハンドラが高級言語で書かれている

TA̲HLNG の指定を行った場合には、ハンドラ起動時に直接 exthdr,
cexhdr, sexhdr のアドレスにジャンプするのではなく、高級言語の環境設定
プログラム（高級言語対応ルーチン）を通してから exthdr, cexhdr, sexhdrのア
ドレスにジャンプする。
exthdr,cexhdr,sexhdr = NADR(-1) の指定により、前に定義されていた例外（終了）ハンドラの定義が解除され、未定義の状態になる。ただし、前に定義されていた例外（終了）ハンドラの定義解除を行わずに、直接新しいハンドラを定義しても、エラーにはならない。また、もともとハンドラが定義されていない状態（定義が解除された状態）で、exthdr,cexhdr,sexhdr=NADRの指定による定義解除の操作を行っても、エラーにはならない。後者の場
合、このシステムコールは正常終了するが、例外（終了）ハンドラは未定義のままである。

bit0
exhatrbit8
reserved(0)bit16インプリメント依存属性

bit31
システム属性［図3.23］exhatrのフォーマット

第二章 ITRON 2基本機能

300

def̲ext

def̲cexdef̲sextskid = TSK̲SELF により、自タスクのハンドラを指定する。また、
tskid=TSK̲CMN によりタスク間で共通の例外（終了）ハンドラを指定する。
タスク実行中に例外が発生した場合には、OSはタスク固有の例外ハンドラ
が定義してあるかどうかを調べ、定義してあればそれを実行する。定義してなければ、次にタスク間共通の例外ハンドラが定義してあるかどうかを調べ、定義してあればそれを実行する。タスク間共通の例外ハンドラのコードは、システム全体に一つ（終了要求、強制例外、CPU例外、システムコール例外に対して一つずつ）である。
tskid が他タスクを示し（tskid≠TSK̲SELF かつ tskid≠自タスクのID）、か
つ tskid のタスクが DORMANT 状態でない場合には、E̲NODMT のエラーとなる。
例外ハンドラ起動の際は、OS側で汎用レジスタの退避を行う。OSから
例外ハンドラに渡す情報としては、次のようなものがある。
発生した例外の例外クラス、例外コード（エラーコード）
例外の発生したアドレス（PC）
例外発生時のレジスタの内容（例外を発生したシステムコールのパラメー
タを含む）
その他例外に応じた情報
他タスクの例外（終了）ハンドラは、対象タスクが DORMANT 状態の場
合にのみ設定可能である。
終了ハンドラも例外ハンドラの一つとして扱われるため、例外コードの引き渡し、例外のマスクによるハンドラ起動の遅延、終了要求がネストした場合の動作、拡張SVCハンドラ実行中の終了ハンドラ起動などのメカニ
ズムは、例外処理と同様である。
（例外処理全体の説明参照）
終了ハンドラの場合、終了要求の受け付け後は自動的にタスクの優先度が高くなる（ter̲tskの説明参照）。したがって、終了ハンドラは優先的に実行されることになる。タスクに対する終了ハンドラの最後では、ext̲tskまたは exd̲tsk システムコールの発行により、自タスクを正常終了させる。タスクに対する終了ハンドラでret̲exc を発行した場合には、ext̲tsk 相当の動作をする。
例外ハンドラ、終了ハンドラは、例外を起こしたコンテキスト（あるいは終了要求を受け付けたコンテキスト）の実行モード（リング、レベル）と、

第三部 ITRON 2

def̲ext

def̲cexdef̲sex301

同じ実行モード（リング、レベル）で実行される。これは、タスク間共通の例外ハンドラを実行する場合も同様である。タスク間共通の例外ハンドラを実行する場合に、自動的に実行モード（リング、レベル）が上がるというわけではない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦tskid≦-2、タスク独立部の発行でtskid=0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲NODMT

タスクがDORMANTでない（tskidが他タスクの場合）

E̲RSATR

予約属性（exhatrが不正）

E̲ILADR

不正アドレス（exthdr,cexhdr,sexhdrが奇数、あるいは使用できない値）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

第二章 ITRON 2基本機能

302

ret̲exc

例外ハンドラから復帰
ret̲exc
ret̲exc:

Return from ExceptionHandler【パラメータ】
なし【リターンパラメータ】※ システムコールを発行したコンテキストには戻らない【解説】
例外ハンドラ（終了ハンドラを除く）から例外発生前のコンテキストに復帰する。
例外ハンドラから戻る際には、自動的にレジスタの復帰を行なう。したがって、機能コードを使ったインタフェースが可能である。
このシステムコールにより、実行モード（リング、レベル）は不変である。
例外ハンドラや拡張SVCハンドラの中でサブルーチンを呼び、そのサブルーチンの中で直接 ret̲exc やret̲svc を実行した場合でも、エラーとはならず、そのまま例外ハンドラや拡張SVCハンドラ起動前のコンテキストに復帰するものとする。すなわち、サブルーチンに対するスタックを残したま
ま、ret̲exc や ret̲svc によって直接例外ハンドラや拡張SVCハンドラから戻ることが可能である。この場合、ret̲exc や ret̲svc の処理の中で、自動的にサブルーチンに対するスタックフレームの解放が行われることになる。
例外ハンドラからサブルーチンを呼び、その中で ret̲exc を実行した場合の動作は、［図3.24］のようになる。
なお、タスク独立部である割込みハンドラやタイマハンドラの場合は、トラップ命令ではなくサブルーチンリターン命令を使ったインタフェースとなっているため、このようなことはできない。スタックフレームを残したままリターンできるのは、拡張SVCハンドラと例外（終了）ハンドラに限られる。
タスクに対する終了ハンドラの中で ret̲exc が実行された場合は、ext̲tskと同等の処理を行う。また、拡張SVCハンドラに対する終了ハンドラの中第三部 ITRON 2

ret̲exc

タスクA

例外ハンドラ303

例外ハンドラの中のサブルーチンfunc

例外発生
func()
ret̲exc［図3.24］サブルーチン中で実行したret̲exc

で ret̲exc が実行された場合には、ret̲svc (s̲ercd=E̲TER) と同等の処理を行う。いずれの場合も、ret̲exc によって終了ハンドラが起動された場所に戻るわけではない。
元のコンテキストに戻らない ret̲XXX 系のシステムコールでエラーが発生した場合、システムコールの例外ハンドラが定義され、それがマスクされていなければ、原則としてそれを起動する。システムコールに対する例
外ハンドラによって、元のコンテキストに戻らないシステムコールに対す
るエラーの処理もある程度可能になる。
システムコールの例外ハンドラから戻った後の動作、あるいはシステムコールの例外ハンドラを起動しなかった時の動作は、厳密にはインプリメ
ント依存である。ただし、エラーの被害をできるだけ局所化するという意
味で、タスクであれば終了要求を発生し、タスク独立部であればその状態から抜ける（ret̲int相当）のが望ましいと考える。また、これとは別に、メッセージバッファへのロギングやコンソールへのエラーの表示などを行う
ことを推奨している。
【エラーコード】※ 次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、
システムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合には、メッセージバッファへのロギングや、コンソールへのエラーメッセージの表示などを行うのが望ましいが、詳細な動作はインプリメント依存となる。
E̲CTX

コンテキストエラー（例外ハンドラ実行中ではない）

第二章 ITRON 2基本機能

304

end̲exc

例外ハンドラの終了
end̲exc
end̲exc:

End ExceptionHandler【パラメータ】
なし【リターンパラメータ】
なし【解説】
例外ハンドラを終了し、元の環境に復帰する。ただし、このシステムコールでは、例外処理環境の復帰やスタックのクリアを行なうだけで、プログラムカウンタはそのままである。したがって、ret̲exc とは異なり、シス
テムコールを発行したコンテキストに戻ってくる。
end̲exc と ret̲exc との違いは、システムコール後の実行環境（プログラ
ムカウンタを含む）が例外発生点に戻る (ret̲exc) か、システムコール(end̲exc) 発生点に戻るかの違いだけである。ネストした例外ハンドラの中で end̲exc を実行した場合にも、ret̲exc と同様に、1段分の例外ハンドラ環
境のみが復帰する。
この機能は、元の場所（例外発生点）に戻りたくない場合に使用する機能であり、終了処理やエラー回復などの場合に使用される。このシステムコールの発行後は、アセンブラのジャンプ命令や C言語の longjmp ( ) によって、例外発生タスクやハンドラの例外発生点以外の場所（初期化や処理再実行を行う部分など）にジャンプするのが普通である。
このシステムコールは、タスクに対する例外ハンドラでも、拡張SVCハ
ンドラに対する例外ハンドラでも利用することができる。
end̲exc の利用イメージを［図3.25］に示す。
end̲exc を実行すると例外ハンドラに対するスタックフレームが削除されるため、スタックポインタの値は変更され、例外発生前の値に戻る。したがって、end̲exc 実行以後は、ローカル変数のアクセスはできなくなる。
これはITRONの問題というよりも言語環境の問題である。また、同じ理由

第三部 ITRON 2

end̲exc

305

により、end̲exc の高級言語インタフェースルーチンではスタック上にリターンアドレスを保持することができないため、リターンアドレスを保持するために何らかの工夫が必要になる。たとえば、高級言語の関数呼び出しにおいて値の保存を保証しなくてもよいレジスタ（R1など-コンパイラにより異なる）にリターンアドレスを退避しておく、といった方法が考えられる。
また、end̲exc の場合、ret̲exc とは異なり、例外ハンドラの起動時に保存していたレジスタ内容の復帰は行わない。end̲exc 実行後のレジスタ（SPを除く）の内容は、例外ハンドラ起動前のレジスタの内容に戻るのではなく、
end̲exc 実行前のレジスタの内容がそのまま保存される。例外ハンドラ起動
前のレジスタ（PCを含む）の内容は、捨てられる。

タスク
set jmp ()＜1＞

例外発生時はここに戻る

再実行のための初期設定などサブルーチンtsk̲subr()例外ハンドラ例外発生＜2＞
exc̲subr ()サブルーチンend̲exc
スタックポインタや例外環境が＜2＞の状態に戻る（ローカル変数アクセス不可）
longjmp ()スタックポインタやPCが＜1＞の状態に戻る※この例では、例外発生前にサブルーチン tsk̲subr() を呼んだり、例外ハンドラの中でサブルーチン exc̲subr() を呼んだりしているが、tsk̲subr() や exc̲subr() のサブルーチン呼びだしが無くても同様の動作になる。

［図3.25］end̲excの利用イメージ

第二章 ITRON 2基本機能

306

end̲exc

end̲exc は例外環境を切り替えるので、end̲exc の発行により、ペンディ
ングになっていた例外が起動される場合がある。例えば、次のようなプログラムでは、end̲exc と longjmp の間で強制例外ハンドラが起動されることがある。この場合、end̲exc と longjmp が連続して実行されるとは限らない。
EXCHDR exchdr( ){...
set̲ems(ECM̲FEX);...

/* 強制例外マスク */←他タスクによる強制例外要求（マスク中なのでペンディングになる）

end̲exc( );→ここで強制例外ハンドラ起動（exchdr 起動前の例外環境で ECM̲FEX がクリアされていた場合）
longjmp(buf,val);}
終了ハンドラの中で end̲exc を実行した場合には、E̲CTX のエラーとなる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲CTX

コンテキストエラー（例外ハンドラ実行中ではない、あるいは終了ハンドラ実行中である）

第三部 ITRON 2

clr̲ems

307

例外処理マスククリア
clr̲emsclr̲ems:

Clear ExceptionMask【パラメータ】
tskid

TaskIdentifier

clrptnClearExceptionMaskPattern クリアする例外マスクのタスクID
ビットパターン【リターンパラメータ】
なし【解説】
自タスク、あるいは、DORMANT 状態の他タスクの例外処理環境の
emsptn をクリアし、対応する例外クラスの例外（終了）ハンドラの起動を許可する。
具体的な動作としては、現在の emsptn に対して、clrptn の論理積をとる。その後、ペンディングになっていた終了処理要求、強制例外の有無がチェックされ、その結果によって、遅らせられていた例外ハンドラの起動が行なわれる。
tskid = TSK̲SELF の指定により自タスクの例外マスクを操作する。自タスクが現在例外ハンドラあるいは拡張SVCハンドラを実行中である場合には、自タスクのハンドラ起動前の例外マスクではなく、自タスクから呼ばれている現在実行中のハンドラに対する例外マスクをセットする。拡張
SVCを呼んだ側や例外を起こした側の例外マスクは無変化である。
tskidが他タスクを示し（tskid≠TSK̲SELF かつ tskid≠自タスクのID）、か
つ tskid のタスクが DORMANT 状態でない場合には、E̲NODMT のエラーとなる。このシステムコールの対象となる他タスクは必ず DORMANT 状態
なので、対象タスクがハンドラ実行中であるということはない。
clr̲ems, set̲ems で tskid=TSK̲INDP(-2) を指定することにより、タスク独立部(Task Independent Portion) に対する例外マスクの操作を行うことができる。この機能により、タスク独立部の例外マスク環境を操作することが可

第二章 ITRON 2基本機能

308

clr̲ems

能になる。ただし、タスク独立部に対する例外マスクが意味を持つのは、システムコール例外に限られている。また、タスク独立部に対するシステ
ムコール例外の機能はインプリメント依存である。tskid = TSK̲INDP を指定した clr̲ems や set̲ems は、タスク部や準タスク部から発行することも可能である。
clr̲ems によってクリアできない例外マスクをクリアしようとした場合
や、set̲ems によってセットできない例外マスクをセットしようとした場合には、E̲PAR のエラーとなる。具体的には、以下の操作を行った場合にE̲PAR のエラーとなる。
clr̲emsでE̲PARとなる場合 :ECM̲NONE

すべての場合ECM̲FEX

拡張SVCハンドラ内での自タスク指定
強制例外がマスクされた状態から起動された例外（終了）
ハンドラ内での自タスク指定
タスク独立部に対する指定

ECM̲TER

終了ハンドラ内での自タスク指定
終了要求がマスクされた状態から起動された例外（終了）
ハンドラ内での自タスク指定

ECM̲ABO

終了ハンドラ実行中での自タスク指定

ECM̲SUSSUSPEND要求がマスクされた状態から起動された例外（終了）あるいは拡張SVCハンドラ内での自タスク指定

一方、clr̲ems や set̲ems が何も意味のない操作を行う場合（ECM̲CEXをクリアしようとした場合、終了ハンドラ内でECM̲TERをセットしようとした場合、clrptnの全ビットを1としてclr̲emsを実行しようとした場合、
setptnの全ビットを0としてset̲emsを実行しようとした場合など）には、特にエラーとはしない。

第三部 ITRON 2

clr̲ems309【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦-3、tskid=(-1)、タスク独立部の発行でtskid=0）

E̲PAR

一般的なパラメータエラー（クリアできないビットの指定）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）
E̲NODMT

タスクがDORMANTでない（tskidが他タスクの場合）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

第二章 ITRON 2基本機能

310

set̲ems

例外処理マスクセット
set̲emsset̲ems:

Set ExceptionMask【パラメータ】
tskid

TaskIdentifier

タスクID

setptnSetExceptionMaskPattern

セットする例外マスクのビットパターン【リターンパラメータ】
なし【解説】
自タスク、あるいは、DORMANT 状態の他タスクの例外処理環境の
emsptn をセットし、対応する例外クラスの例外（終了）ハンドラの起動を禁止する。
具体的な動作としては、現在の emsptn に対して、setptn の論理和をとる。
tskid = TSK̲SELF の指定により自タスクの例外マスクを操作する。自タスクが現在例外ハンドラあるいは拡張SVCハンドラを実行中である場合には、自タスクのハンドラ起動前の例外マスクではなく、自タスクから呼ばれている現在実行中のハンドラに対する例外マスクをセットする。拡張
SVCを呼んだ側や例外を起こした側の例外マスクは無変化である。
tskid が他タスクを示し（tskid≠TSK̲SELF かつ tskid≠自タスクのID）、か
つ tskid のタスクが DORMANT 状態でない場合には、E̲NODMT のエラーとなる。このシステムコールの対象となる他タスクは必ず DORMANT 状態
なので、対象タスクがハンドラ実行中であるということはない。
clr̲ems, set̲ems で tskid=TSK̲INDP (-2) を指定することにより、タスク独立部 (Task Independent Portion) に対する例外マスクの操作を行うことができる。この機能により、タスク独立部の例外マスク環境を操作することが可能になる。ただし、タスク独立部に対する例外マスクが意味を持つのは、シス
テムコール例外に限られている。また、タスク独立部に対するシステムコー
ル例外の機能はインプリメント依存である。tskid=TSK̲INDP を指定した

第三部 ITRON 2

set̲ems

311

clr̲ems や set̲ems は、タスク部や準タスク部から発行することも可能である。
このシステムコールを使っても、CPU例外に対するマスクを行うことはできない。
clr̲ems によってクリアできない例外マスクをクリアしようとした場合
や、set̲ems によってセットできない例外マスクをセットしようとした場合には、E̲PAR のエラーとなる。具体的には、以下の操作を行った場合にE̲PAR のエラーとなる。
set̲emsでE̲PARとなる場合 :ECM̲TER

タスク独立部に対する指定

ECM̲CEX

すべての場合ECM̲ABO

終了ハンドラ実行中でない場合の自タスク指定
他タスク（DORMANT状態）に対する指定

ECM̲SUS

タスク部での自タスク指定
他タスク（DORMANT状態）に対する指定

一方、clr̲ems や set̲ems が何も意味のない操作を行う場合（ECM̲CEXをクリアしようとした場合、終了ハンドラ内でECM̲TERをセットしようとした場合、clrptnの全ビットを1としてclr̲emsを実行しようとした場合、
setptnの全ビットを0としてset̲emsを実行しようとした場合など）には、特にエラーとはしない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦-3、tskid=(-1)、タスク独立部の発行でtskid=0）

E̲PAR

一般的なパラメータエラー（セットできないビットの指定）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）
E̲NODMT

タスクがDORMANTでない（tskidが他タスクの場合）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でtskid＜(-4)）

第二章 ITRON 2基本機能

312

idef̲ext

idef̲cex

idef̲sex

タスク独立部用終了ハンドラの定義
idef̲ext

タスク独立部用CPU例外ハンドラの定義
idef̲cex

タスク独立部用システムコール例外ハンドラの定義
idef̲sex
idef̲ext:

Define ExitHandler for TaskIndependentPortion

idef̲cex:

Define CPUExceptionHandler for TaskIndependentPortion

idef̲sex:

Define SystemcallExceptionHandler for TaskIndependentPortion【パラメータ】
exhatrExceptionHandlerAttribute

例外ハンドラ属性＜1＞exthdr

ExitHandlerAddress

終了ハンドラアドレス＜2＞cexhdr

CPUExceptionHandlerAddress

CPU例外ハンドラ＜3＞sexhdr

SystemCallExceptionHandlerAddress システムコール例外

アドレス
ハンドラアドレス［＜1＞idef̲ext のみ］［＜2＞idef̲cex のみ］［＜3＞idef̲sex のみ］【リターンパラメータ】
なし【解説】
タスク独立部（割込みハンドラ、タイマハンドラ、OS）に対する例外ハ
ンドラ、終了ハンドラを定義する。
各システムコールでは、次のようなハンドラを定義する。

第三部 ITRON 2

idef̲ext

idef̲cex

idef̲sex313

・idef̲ext により定義されるハンドラ― タスク独立部から発行したシステムコールにおいて、システムを終了
せざるをえないような重大なエラーが発生した場合に起動される。タスク独立部でCPU例外が発生し、CPU例外に対するハンドラが未定義の場
合もこれに含まれる。ハンドラを実行した後は、システムダウンとなる。
― OSの内部で、システムを終了せざるをえないような原因不明の重大なエラーが発生した場合に起動される。ハンドラを実行した後は、システムダウンとなる。
・idef̲cex により定義されるハンドラ― タスク独立部でCPU例外が発生した場合に起動される。ハンドラを実行した後は、元のコンテキスト（タスク独立部）に戻れる場合がある。
・idef̲sex により定義されるハンドラ―（エラーコードが E̲SYS 以外の場合）タスク独立部から発行したシス
テムコールにおいて、システムコール例外が発生した場合に起動される。ハンドラを実行した後は、元のコンテキスト（タスク独立部）に戻れる場合がある。
なお、タスク独立部でシステムコール例外が発生した場合には、タス
ク部あるいは準タスク部でシステムコール例外が発生した場合とは異なり、対応する例外マスクはセットされない。システムコール例外ハ
ンドラ実行中の emsptn の値は、例外発生前と同じ値をとる。
―（エラーコードが E̲SYS の場合）OSの内部で、回復できるかもしれな
い程度の原因不明のエラーが発生した場合に起動される。OSの内部で、OSだけでは対処できないようなCPU例外が発生した場合も、これに含まれる。ハンドラを実行した後は、元のコンテキスト(OS)に戻れる場
合がある。
このうち、idef̲ext で定義される「タスク独立部に対する終了ハンドラ」
は、システム全体に対する終了ハンドラを意味するものであり、システム
ダウン時に一度だけ起動されるハンドラである。タスク独立部に対する例
外ハンドラが未定義のため一般の例外が終了要求に置き換わった場合や、その他の異常によるシステムダウンの場合には、このシステム終了ハンド
ラを実行した後でシステムを停止する。このハンドラにより、メッセージ
第二章 ITRON 2基本機能

314

idef̲ext

idef̲cex

bit0
exhatridef̲sex

bit8
reserved(0)bit16インプリメント依存属性

bit31
システム属性［図3.26］exhatrのフォーマット

の表示や状況の解析がある程度可能になる。
e x h a t r の サ イ ズ は 標 準 で 4 バ イ ト で あ る 。 e x h a t rの フ ォ ー マ ッ ト を［図3.26］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24のビット）は未使用であり、第二上位バイト（bit8〜bit15 あるいは 2^23〜
2^16 のビット）はインプリメント依存の属性を表わし、下位ハーフワード（bit16〜bit31 あるいは 2^15〜2^0 のビット）はシステム属性を表わす。
exhatr のシステム属性の部分では、次のような指定を行うことができる。
exhatr : = (TA̲ASM ‖ TA̲HLNG)TA̲ASM

ハンドラがアセンブラで書かれている

TA̲HLNG

ハンドラが高級言語で書かれている

TA̲HLNG の指定を行った場合には、ハンドラ起動時に直接 exthdr,
cexhdr, sexhdr のアドレスにジャンプするのではなく、高級言語の環境設定
プログラム（高級言語対応ルーチン）を通してから exthdr, cexhdr, sexhdrのア
ドレスにジャンプする。
exthdr,cexhdr,sexhdr = NADR (-1) の指定により、前に定義されていた例外（終了）ハンドラの定義が解除され、未定義の状態になる。ただし、前に定義されていた例外（終了）ハンドラの定義解除を行わずに、直接新しいハンドラを定義しても、エラーにはならない。また、もともとハンドラが定義されていない状態（定義が解除された状態）で、exthdr,cexhdr,sexhdr=NADRの指定による定義解除の操作を行っても、エラーにはならない。後者の場
合、このシステムコールは正常終了するが、例外（終了）ハンドラは未定義のままである。
これらの例外ハンドラや終了ハンドラは、例外を起こした実行モード（リング、レベル）と同じ実行モード（リング、レベル）で実行される。
idef̲XXX ではOS内部で発生したエラーに対する例外ハンドラを定義で第三部 ITRON 2

idef̲ext

idef̲cex

idef̲sex

315

きるが、ここで定義される例外ハンドラは、OS自身がエラー回復を行うことを妨げるものではなく、OS自身が何らかの処置を行い、それでもエラーを回復できない場合に起動されるハンドラという意味である。当然のことながら、OS内部でエラーが発生した場合には、idef̲XXX で定義されるハンドラの有無にかかわらず、できる限りOS内部でエラーの回復に努めるべきである。
【エラーコード (ercd)】
E̲OK
E̲NOSMEM

正常終了
システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSATR

予約属性（exhatrが不正）

E̲ILADR

不正アドレス（exthdr,cexhdr,sexhdrが奇数、あるいは使用できない値）

第二章 ITRON 2基本機能

316

メモリプール管理機能

この章の「メモリプール管理機能」で対象としているのは、ソフトウエ
アによるメモリプールやメモリブロックの管理機能である。MMU に関する操作（MMUサポート機能）は、ここには含まれない。
ITRON2では、MMUの有無にかかわらず、タスクがローカルに使用するメモリブロックを扱うシステムコールと、タスク間で共有されるメモ
リブロックを扱うシステムコールとを完全に分離している。これは、MMU 版への移行をスムーズにするためであり、共有メモリブロックに対するメモリプール（共有メモリプール）とローカルメモリブロックに対するメモリプール（ローカルメモリプール）は別のオブジェクトとして扱われる。このうち、この章では、タスク間で共有される共有メモリプールについての説明を行う。
タスクがローカルに使用するローカルメモリプールについては、拡張機能の「ローカルメモリプール管理機能」の項で説明を行う。ただし、ローカルメモリプール管理機能がインプリメントされない場合には、本章で説明する共有メモリプール管理機能により、ローカルメモリプールの機能を代用することになる。
メモリプールには、固定長メモリプールと可変長メモリプールがある。
両者はメモリプールの属性として区別される。固定長メモリプールから獲得されるメモリブロックはサイズが固定されているのに対して、可変長メモリプールから獲得されるメモリブロックでは、基本サイズの整数倍といった形でブロックサイズを指定することができる。
mplid=TMPL̲OS (-4) のメモリプールは、OS（システム）用のメモリプールとして扱い、余っているメモリはそこに所属するものと考える。
mplid = TMPL̲OS (-4) のメモリプールに対して状態参照のシステムコー
ル (mpl̲sts) を発行することにより、OSの残りのメモリ容量などを知ることができる。
このほか、mplid=(-3)〜(-2) のメモリプールを、インプリメント依存のOS用メモリプール（スタック専用のメモリプールなど）として利用することができる。この機能は、残りのメモリ容量に関してより詳しい情報
第三部 ITRON 2

317を提供する時に利用できる機能であるが、機能の有無や詳細はインプリ
メント依存である。mplid = (-3)〜(-2) のメモリプールを細かく使い分け
れば、より詳細な情報をユーザに提供することができる。なお、mplid =(-1), mplid = 0 は reserved である。

第二章 ITRON 2基本機能

318

cre̲mpl

メモリプールの生成
cre̲mplcre̲mpl:Create MemoryPool【パラメータ】
mplid

MemoryPoolIdentifier

メモリプールID

mplatr

MemoryPoolAttribute

メモリプール属性

mplsz

MemoryPoolSize

メモリプール全体のサイズ

blksz

MemoryBlockSize

メモリブロック基本サイズ【リターンパラメータ】
なし【解説】
cre̲mpl では、mplid で指定された ID 番号を持つメモリプールを生成する。次に、生成されたメモリプールに対して管理ブロックを割り付ける。
メモリプールの生成時には、mplatr によって、固定長メモリプール/可変長メモリプールの区別を指定する。
メモリプール全体の大きさは、mplsz によって指定する。メモリプール
生成に必要なメモリ領域の確保は、システム生成時などに行なわれる。
可変長のメモリプールの場合、blksz により、メモリ獲得、解放の最小単位が決められる。固定長のメモリプールであれば、blkszの大きさでのメモ
リ獲得、解放しかできない。
ID 番号が (-4)〜0 のメモリプールは生成できない。また、負の ID 番号のメモリプールは、システム用のものである。
mplatr のサイズは標準で4バイトである。mplatr のフォーマットを［図3.27］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット） はユーザ属性を表わし、第二上位バイト（bit8〜bit15 あるいは
2^23〜2^16 のビット）はインプリメント依存の属性を表わし、下位ハーフ
ワード（bit16〜bit31 あるいは 2^15〜2^0 のビット）はシステム属性を表わす。ユーザは、メモリプールに関する情報を入れておくために、mplatr の最上位バイトを自由に使用することができる。

第三部 ITRON 2

cre̲mpl
bit0
mplatr

bit8
ユーザ属性

bit16

インプリメント依存属性

319
bit31

システム属性［図3.27］mplatrのフォーマット

cre̲mpl で指定した mplatr は、mpl̲sts により読み出すことができる。
mplatr のシステム属性の部分では、次のような指定を行うことができる。
mplatr: = (TA̲TFIFO‖TA̲TPRI) ｜ (TA̲FIRST‖TA̲CNT)｜ (TA̲VAR‖ A̲FIX)TA̲TFIFO

待ちタスクのキューイングは FIFOTA̲TPRI

待ちタスクのキューイングは優先度順

TA̲FIRST

行列先頭のタスクを優先扱い

TA̲CNT

要求数の少ないタスクを優先扱い

TA̲VAR

可変長メモリブロック用のメモリプール

TA̲FIX

固定長メモリブロック用のメモリプール

TA̲TPRI, TA̲TFIFO の属性により、タスクがメモリ獲得の待ち行列に並ぶ際の並び方を指定することができる。属性が TA̲TFIFO であればタスクの待ち行列は FIFO となり、属性がTA̲TPRI であればタスクの待ち行列はタスクの優先度順となる。
さらに、TA̲CNT と TA̲FIRST の属性指定により、要求メモリ数の少ないタスクを優先扱いにするか、メモリ待ち行列先頭のタスクを優先扱いにするかが指定できる。TA̲CNT の属性を指定した場合には、要求メモリ数によって、行列途中のタスクから先に待ち解除になる場合がある。例えば、ある可変長メモリプールに対して要求ブロック数 = 5 のタスク A と要求ブロック数=1 のタスクB がこの順で待っており、rel̲blk により空きブロックの数が 1 になった場合、行列先頭にあるタスクA は要求ブロック数が多い
ので、行列の後にあるタスクB の方が先にメモリを獲得する。
一方、TA̲FIRST の属性を指定した場合には、要求ブロック数にかかわらず、必ず行列先頭のタスクからメモリが割り当てられる。これは、要求ブロック数よりも優先度を重視した考え方である。上の例では、rel̲blk 実
第二章 ITRON 2基本機能

320

cre̲mpl

行後もタスクB は待ち解除にならず、さらに rel̲blkが実行されて連続した空きブロックの数が 5 以上になった時にはじめてタスクA にメモリが割り当てられる。タスクB には、その後の rel̲blk によってメモリが割り当てられる。
な お 、 TA̲FIX 属 性（ 固 定 長 メ モ リ プ ー ル ）の 場 合 は TA̲CNT とTA̲FIRST の属性の違いが無くなってしまうが、これに関しては何もチェックしない。(TA̲FIX ¦ TA̲CNT) の指定と (TA̲FIX ¦ TA̲FIRST) の指定はどちらもエラーにはならず、同じ動作を行なう。
【エラーコード (ercd)】
E̲OK 正常終了
E̲NOSMEM

システムメモリ不足（管理ブロック用の領域が確保できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲NOMEM

メモリ不足（メモリプール用の領域が確保できない）※ E̲NOSMEMとE̲NOMEMとの厳密な区別はインプリメ
ント依存である。

E̲RSID

予約ID番号（-4≦mplid≦0）

E̲RSATR

約属性（mplatrの下位3バイトが不正）E̲PAR一般的なパラメータエラー（mplsz,blkszが不正）

E̲IDOVR

ID範囲外（mplidがシステムで利用できる範囲を越えた）

E̲EXS

オブジェクトが既に存在している（同一ID番号のメモリプールが存在）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタスク
からの発行でmplid＜(-4)）

第三部 ITRON 2

321

del̲mpl

メモリプールを削除する
del̲mpldel̲mpl:Delete MemoryPool【パラメータ】
mplid

MemoryPoolIdentifier

メモリプールID【リターンパラメータ】
なし【解説】
mplid で示されるメモリプールを削除する。
このメモリプールからメモリを獲得しているタスクに対しては、何の保証もしない。すべてのメモリブロックが返却されていなくても、このシス
テムコールは正常終了する。
このメモリプールにおいてメモリ獲得を待っているタスクがある場合にも、本システムコールは正常終了するが、メモリ獲得を待っていたタスクにはエラー E̲DLT が返される。
本システムコール発行後は、そのID番号のメモリプールを再び新しく生成することができる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦mplid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（mplidのメモリプールが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でmplid＜(-4)）

第二章 ITRON 2基本機能

322

get̲blk

共有メモリブロックを獲得する
get̲blkget̲blk:

Get Shared Memory Block【パラメータ】
mplid

MemoryPoolIdentifier

メモリプールID

bcnt

ContinuousBlockCount

連続領域のブロック数

tmout

Timeout

タイムアウト指定【リターンパラメータ】
blk

BlockStartAddress

メモリブロックの先頭アドレス【解説】
mplid で示されるメモリプールから、共有メモリブロック（固定長/可変長）を獲得する。獲得したメモリブロックの先頭アドレスが blk に返される。
get̲blk で獲得したメモリのゼロクリアは特に行われない。獲得されたメ
モリブロックの内容は不定である。
可変長メモリプールを対象とした場合は、このシステムコールにより、（cre̲mpl で指定した blksz）×bcnt の大きさのメモリブロックが確保される。
また、固定長メモリプールを対象とした場合は、bcnt の指定は無視され、常に（cre̲mpl で指定した blksz）の大きさのメモリブロックが確保される。
指定したメモリプールから、指定した大きさのメモリブロックがすぐに確保できない場合には、タスクはそのメモリプールのメモリ獲得待ち行列につながれ、確保できるようになるまで待つ。
tmout により待ち時間のタイムアウト指定を行なうことができる。tmout
としては、正の値のみを指定することができる。タイムアウト指定が行なわれた場合、メモリブロックを獲得できないまま tmout 時間が経過すると、タイムアウトエラー E̲TMOUT としてエラーリターンする。また、tmout として TMO̲POL を指定した場合は、メモリブロックが獲得できない場合でも即時にリターンする。この場合、メモリブロックが獲得できれば正常終了になり、メモリブロックが獲得できなければタイムアウトエラー
E̲TMOUT になる。さらに、tmout =TMO̲FEVR によりタイムアウト指定が行なわれないことを示す。この場合は条件が満足されるまで永久に待つ。
第三部 ITRON 2

get̲blk323【補足事項】
資源獲得を行うシステムコールのうち、get̲blk (TMO̲POL) に限っては、
次のような理由により、例外的にタスク独立部からも実行可能な場合がある。
（実際に実行可能かどうかはインプリメント依存である）― 一般的には、セマフォカウント値やメモリブロックなどの「資源」は、タスクに与えられるものであるということになっている。したがって、
割込みハンドラ等のタスク独立部では、資源を確保することができず、タスク独立部から wai̲sem 等を発行することはできない。
― しかし、タスク独立部が資源を確保したとしても、リターンの前に資源を返してしまう（あるいは他のタスクやメイルボックスに渡してしまう）
ことにすれば、特に矛盾は生じない。実際、割込みハンドラの中からメッセージを送る場合には、その前に get̲blk を実行する必要が生じる。もちろん、割込みハンドラでは待ち状態になることはできないので、tmout= TMO̲POL を指定しなければならない。
―

get̲blk 以 外 のwai̲flg(TMO̲POL), wai̲sem(TMO̲POL),

rsv̲msg(TMO̲POL) などをタスク独立部から実行する必要性は無い。
get̲blk 以外のシステムコールに関しては、やはり E̲CTX のエラーとする。
OS用メモリプール(TMPL̲OS) に対して直接 get̲blk, rel̲blk を行う機能を提供することが考えられるが、以下の理由により、この機能は提供していない。mplid=TMPL̲OS に対して get̲blk, rel̲blk を実行した場合には、
E̲RSID のエラーとなる。
― 機能が増えて仕様が複雑化する。また、メモリプールの位置付けが瞹昧になる。
「メモリブロックは必ずメモリプールから確保する」という原則が崩れる。また、OS用メモリプール (TMPL̲OS) のブロックサイズをユーザ側から自由に指定することはできないので、ブロックサイズの値に関しては、ユーザ側で特殊な扱いをする必要が生じる。
たとえば、システム（初期化時の設定値など）とユーザプログラムとの間でブロックサイズの値を合意しておくか、必要メモリ容量（バイト数）と mpl̲sts の実行結果から、ユーザプログラムの側で動的に要求ブロック
数 bcnt を計算する必要がある。
第二章 ITRON 2基本機能

324

get̲blk― MMU をサポートした場合には、この機能を導入することによってインプリメントの負担が増える可能性がある。
空きメモリがOS用メモリプール(TMPL̲OS) に属するという考え方は、メ
モリ全体に対するメモリプールの管理方法と、各メモリプール内におけるメモリブロックの管理方法とを一本化するというインプリメント方針に基づいたものである。
しかし、MMU をサポートした場合には、マッピング（ページテーブル）の設定などが必要になるので、メモリプールあるいは空きメモリの管理と、メモリブロックの管理とを一本化するのは無理がある。すなわち、
TMPL̲OS に対して get̲blk, rel̲blk を行う機能を導入した場合、それだけのために OS 側の特殊な処理が増えてしまう。
なお、mplid = TMPL̲OS (-4) のメモリプールに対して状態参照のシステ
ムコール (mpl̲sts) を発行することは可能である。
【エラーコード (ercd)】
E̲OK
E̲TNOSPTE̲RSIDE̲PAR
E̲IDOVR
E̲ILTIME
E̲NOEXSE̲OACV
E̲CTX
E̲DLT

正常終了
タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。
予約ID番号（-4≦mplid≦0）
一般的なパラメータエラー（bcnt≦0）
ID範囲外（インプリメント依存）
不正時間指定（tmout≦-2）
オブジェクトが存在していない（mplidのメモリプールが存在しない）
オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でmplid＜(-4)）
コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行,インプリメント依存）
待ちオブジェクトが削除された（待ちの間に対象メモリ
プールが削除）E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第三部 ITRON 2

rel̲blk325

共有メモリブロックを返却する
rel̲blkrel̲blk:

Release Shared Memory Block【パラメータ】
mplid

MemoryPoolIdentifier

メモリプールID

blk

BlockStartAddress

メモリブロックの先頭アドレス【リターンパラメータ】
なし【解説】
blk で示されるメモリブロックを、mplidで示されるメモリプールへ返却する。
メモリブロックの返却を行うメモリプールは、メモリブロックの獲得を行ったメモリプールと同じものでなければならない。メモリブロックを、前と異なるメモリプールへ返却していることが検出された場合には、
E̲ILBLK のエラーとなる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦mplid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（mplidのメモリプールが存在しない）E̲ILBLKE̲OACV

不正メモリブロックの返却、操作
オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でmplid＜(-4)）

第二章 ITRON 2基本機能

326

mpl̲sts

メモリプールの状態を参照する
mpl̲sts
mpl̲sts:

Get MemoryPool Status【パラメータ】
mplid

MemoryPoolIdentifier

メモリプールID

pk̲mpls

Packet of MemoryPoolStatus

メモリプール状態を返す
パケットの先頭アドレス【リターンパラメータ】
なし【解説】
mplid で示されたメモリプールの状態を読み出し、その結果を pk̲mpls 以下の領域に返す。
pk̲mpls に返される情報としては、次のようなものがある。
mplatr/* メモリプール属性 */wtskid/* 待ち行列先頭のタスクID */frbcnt/* 空き領域全体のブロック数 */maxbcnt/* 最大の連続空き領域のブロック数 */mplsz/* メモリプール全体のサイズ */blksz/* メモリブロックのサイズ */fragcnt/* 空きブロックのフラグメント数 */wtskid には、待ち行列の先頭のタスクのIDが返る。すなわち、属性がTA̲TFIFO であれば、現在このメモリプールを待っているタスクのうち、最も早く待ち状態になったタスクのIDが返る。また、属性が TA̲TPRI であれば、現在このメモリプールを待っているタスクのうち、最も優先度の高いタスクのIDが返る。
frbcnt はメモリの空き領域の合計ブロック数であり、maxbcnt は空き領域のうちで最大の連続領域のブロック数である。固定長メモリプールの場合
は、maxbcnt は意味を持たず、常に1が返される。また、mplsz, blkszには、
cre̲mpl で指定した値がそのまま返される。
第三部 ITRON 2

mpl̲sts327

fragcnt は、メモリ空きブロックのフラグメント数（空きブロックがいく
つの連続領域に分かれているか）を示す情報である。この情報は、対象メモ
リプールからどの程度の大きさの連続ブロックが取れるかということを知るための目安になる。固定長メモリプールに対する fragcnt の値としては、
frbcnt と同じ値がセットされる。
対象となるメモリプールは、既に生成されたものでなければならない。
mplid = TMPL̲OS (-4) のメモリプールに対して mpl̲sts を発行することにより、OSの残りのメモリ容量などを知ることができる。この場合、pk̲mplsには次のような値を返す。
mplatr不定（意味がない）

wtskid不定 （意味がない）

frbcnt空き領域全体のブロック数
frbcnt*blksz により空き領域全体のバイト数になる

maxbcnt

最大の連続空き領域のブロック数
maxbcnt*blksz により最大の連続空き領域のバイト数になる

mplsz

OS用メモリプール全体のバイト数
ITRON2で管理しているメモリ全体のバイト数

blksz

インプリメント依存
MMUをサポートしない場合は、1あるいはOSのインプリメントで使用している具体的なメモリブロックサイズになる。
MMUをサポートしている場合は、ページサイズになる。

fragcnt

空き領域のフラグメント数

blksz がインプリメント依存であるため、ユーザ側でメモリの空き領域のサイズを調べるためには、必ず(frbcnt×blksz) の演算を行う必要がある。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-3≦mplid≦0、ただし(-3)≦mplid≦(-2)はインプリメント依存）

E̲ILADR

不正アドレス（pk̲mplsが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（mplidのメモリプールが存在しない）
第二章 ITRON 2基本機能

328

mpl̲sts

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でmplid＜(-4)）※ mplid=TMPL̲OS(-4) に対する get̲blk, rel̲blk, mpl̲sts を
ユーザタスクから発行することは可能である。

第三部 ITRON 2

blk̲sts329

共有メモリブロックの状態参照
blk̲stsblk̲sts:

Get Shared Memory Block Status【パラメータ】
blk

BlockStartAddress

メモリブロックの先頭アドレス【リターンパラメータ】
mplid

MemoryPoolIdentifier

メモリプールID

bcnt

ContinuousBlockCount

連続領域のブロック数【解説】
blk で示されるメモリブロックの状態を参照する。具体的には、そのメモ
リブロックの属するメモリプールID mplid と、メモリブロックの大きさ（連続ブロック数）bcnt を返す。
固定長メモリプールから得られたメモリブロックに対して blk̲sts が実行された場合には、bcnt として1が返る。
【エラーコード (ercd)】
E̲OK

正常終了

E̲ILBLK

不正メモリブロックの返却、操作

第二章 ITRON 2基本機能

330

時間管理機能第三部 ITRON 2

set̲tim

331

システムクロックを設定する
set̲timset̲tim:

Set Time【パラメータ】
utime

UpperCurrentDateTime

現在の年月日時刻データ
（上位）

ltime

LowerCurrentDateTime

現在の年月日時刻データ（下位）【リターンパラメータ】
なし【解説】
システムが保持しているシステムクロックの現在の値を、utime, ltime で示される値に設定する。システムクロックは、48 ビット(utime:16 bit + ltime:32 bit) で表現されるのが標準である。
システムクロックの意味や単位としては、1985年1月1日0時 (GMT) からの通算のミリ秒数とすることを推奨する。
32ビットの時間指定パラメータ（タイムアウト等）、48ビットの時間指定
パラメータ（絶対時間等）とも、符号付きの数として扱われる。したがって、
set̲tim の utime で負の数を指定した場合には E̲ILTIME のエラーとなる。
システムの動作中に set̲tim を使ってシステムクロックを変更した場合には、それまで時間待ちをしていたタスクや、起動を待っていたハンドラ（周期起動ハンドラやアラームハンドラ）の動作のタイミングが狂う可能性がある。このような場合の動作はインプリメント依存である。これは、OS
内部の時間管理で相対時間を使っているような場合に、set̲tim でこれらの時間の補正を行ったり、過ぎた時刻を待つタスクを待ち解除にしたりするのは難しい可能性があるためである。
【エラーコード (ercd)】
E̲OK

正常終了

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲ILTIME

不正時間指定（utime,ltimeが不正）
第二章 ITRON 2基本機能

332

get̲tim

システムクロックの値を読み出す
get̲timget̲tim:Get Time【パラメータ】
なし【リターンパラメータ】
utime

UpperCurrentDateTime

現在の年月日時刻データ（上位）

ltime

LowerCurrentDateTime

現在の年月日時刻データ（下位）【解説】
システムが保持しているシステムクロックの現在の値を読み出し、utime,
ltime に返す。システムクロックは、48 ビット (utime:16bit+ltime:32bit) で表現されるのが標準である。
システムクロックの意味や単位としては、1985年1月1日0時 (GMT) からの通算のミリ秒数とすることを推奨している。
【エラーコード (ercd)】
E̲OK

正常終了

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

第三部 ITRON 2

dly̲tsk333

タスクの遅延を行う
dly̲tsk
dly̲tsk:

Delay Task

【パラメータ】
dtime

DelayTime

遅延時間【リターンパラメータ】
なし【解説】
自タスクの実行を一時的に停止し、時間経過待ちの状態に入る。タスクの実行を停止する時間は、dtime により指定される。
このシステムコールは、wai̲tsk とは異なり、遅延して終了する方が正常終了になる。また、遅延期間中にwup̲tsk が実行されても、待ち解除とはならない。指定時間以前に dly̲tsk が終了するのは、ter̲tsk やrel̲wai が発行された場合のみである。
こ の シ ス テ ム コ ー ル を 発 行 し た タ ス ク が S U S P E N D 状 態（ W A I T SUSPEND状態）になっている間も、時間経過のカウントは行われる。
【エラーコード (ercd)】
E̲OK
E̲NOSMEM

正常終了
システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲ILTIME

不正時間指定(dtime＜0)

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

E̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第二章 ITRON 2基本機能

334

cyc̲wup

タスクを周期起床する
cyc̲wupcyc̲wup:

Cyclic Wakeup Task

【パラメータ】
tskid

TaskIdentifier

タスクID

rptcntRepeatCount

起床回数

cytimeCycleTime

周期起床時間間隔

utime

UpperInitialTime

初期起床時刻（上位）

ltime

LowerInitialTime

初期起床時刻（下位）tmmodeTimeMode

初期時刻指定モード【リターンパラメータ】
なし【解説】tskid で示されたタスクの周期起床を行なう。すなわち、対象タスクに対して、初期指定時刻から一定時間毎に起床要求（wup̲tsk と同じもの）を発行する。tskid = TSK̲SELF により自タスクの指定になる。
utime, ltime により、最初に起床要求を出す時間を指定する。標準では、
utime16ビット、ltime 32ビットの計48ビットを使って時刻の指定が行われる。
tmmode により、次のようにして絶対時刻と相対時刻の指定が可能である。
tmmode : = (TTM̲ABS ‖ TTM̲REL)
TTM̲ABS

絶対時刻での指定

TTM̲REL

相対時刻での指定

指定した時刻が過去の時刻であった場合には、エラー E̲ILTIME となる。
rptcnt = 0 で無限回数の指定となる。この場合は、can̲cyc により要求が解除されるか、対象タスクが削除されるまで、永久に起床要求を出し続ける。rptcnt < 0 は reserved であり、指定した場合にはエラー E̲PARとなる。
cytime は周期起床の時間間隔であり、標準では 32 ビットで表現される。
cytime ≦ 0 も reserved である。cytime ≦ 0 の指定を行った場合には、エラ
ー E̲ILTIME となる。
周期的なタスクの実行は、本システムコールと slp̲tsk システムコールを
第三部 ITRON 2

cyc̲wup335

組み合わることによって実現される。
rptcnt = 1 により、指定時刻に一度だけタスクを起床するという遅延起床の機能が実現できる。この場合、cytime のパラメータは意味を持たないことになるが、E̲ILTIME のエラーを避けるため、何らかの正の値を指定しておく必要がある。
cyc̲wup システムコールは、時間が経過してから実際の動作をするので、
wup̲tsk とは異なり、システムコール発行時に対象タスクが DORMANT 状態であったとしてもエラーとはしない。また、時間が経過して実際に起床要求が出る時になって、対象タスクが DORMANT 状態や存在しない状態であったり、起床要求カウントのオーバーフローエラー E̲QOVR が検出されたりしても、エラーの通知先がない。cyc̲wup により、こういった通知先のないエラーが発生した場合、システムのエラーログ用のメッセージバッ
ファが用意されていれば、そこにエラーが記録される。
【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSMD

予約モード、予約オプション（tmmodeが不正）

E̲RSID

予約ID番号（-4≦tskid≦-1、タスク独立部の発行でtskid=0）

E̲PAR

一般的なパラメータエラー(rptcnt＜0)E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILTIME

不正時間指定（cytime≦0、utime,ltimeが不正）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタ
スクからの発行でtskid＜(-4)）※ 以下のエラーは、cyc̲wup の実行時にすぐに検出されるものではなく、時間が経過してから発生する可能性のあるエラーである。
E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲QOVR

キューイングのオーバーフロー（wupcntのオーバーフロー）第二章 ITRON 2基本機能

336

can̲cyc

タスクに出された周期起床要求を解除する
can̲cyccan̲cyc:

Cancel Cyclic Wakeup Task

【パラメータ】
tskid

TaskIdentifier

タスクID【リターンパラメータ】
なし【解説】tskid で示されるタスクに対して発せられている周期起床要求を取り消す。
対象タスクに複数の周期起床要求が出ていても、それらはすべて取り消される。周期起床要求の出ていないタスクに対してこのシステムコールを発行すると、エラー E̲NOCYC となる。
tskid = TSK̲SELF により自タスクの指定になる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦-1、タスク独立部の発行でtskid=0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタ
スクからの発行でtskid＜(-4)）

E̲NOCYC

タスクに対してcyc̲wupが発行されていない

第三部 ITRON 2

337

システム管理機能

第二章 ITRON 2基本機能

338

def̲svc

拡張SVCハンドラを定義する
def̲svc
def̲svc:

Define SupervisorCall Handler【パラメータ】s̲fncdSVCFunctionCode

拡張機能コード

svhatr

SVCHandlerAttribute

拡張SVCハンドラ属性

svchdr

SVCHandlerAddress

拡張SVCハンドラアドレス【リターンパラメータ】
なし【解説】
ユーザが書いた拡張システムコールハンドラ（拡張SVCハンドラと呼ぶ）
を定義する。拡張SVCハンドラは、ITRONのシステムコールを拡張する働きを持つ。
def̲svc では、ユーザ定義のサービスルーチンである拡張SVCハンドラをOSに登録し、svchdr で示される拡張SVCハンドラのアドレスと、s̲fncd で示される拡張機能コードとの対応付けを行なう。def̲svc 実行の結果、
ITRONのシステムコールを呼び出すのと同様のインタフェースで、その拡
張SVCハンドラが実行されるようになる。
svhatr のサイズは標準で4バイトである。svhatr のフォーマットを［図3.28］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）は未使用であり、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16 のビット）はインプリメント依存の属性を表わし、下位ハーフワード（bit16〜bit31あるいは 2^15〜2^0 のビット）はシステム属性を表わす。
svhatr のシステム属性の部分では、次のような指定を行うことができる。
svhatr : = (TA̲ASM‖TA̲HLNG)TA̲ASM

ハンドラがアセンブラで書かれている

TA̲HLNG

ハンドラが高級言語で書かれている

TA̲HLNG の指定を行った場合には、拡張SVCハンドラ起動時に直接
svchdr のアドレスにジャンプするのではなく、高級言語の環境設定プログラ
第三部 ITRON 2

339

def̲svc

bit0
svhatrbit8
reserved(0)bit16インプリメント依存属性

bit31
システム属性［図3.28］svhatrのフォーマット

ム（高級言語対応ルーチン）を通してから svchdr のアドレスにジャンプする。
svchdr = NADR (-1) の指定により、前に定義されていた拡張SVCハンドラの定義が解除され、未定義の状態になる。ただし、前に定義されていた拡張SVCハンドラの定義解除を行わずに、直接新しいハンドラを定義しても、エラーにはならない。また、もともとハンドラが定義されていない状態（定義が解除された状態）で、svchdr=NADR の指定による定義解除の操作を行っても、エラーにはならない。後者の場合、このシステムコールは正常終了するが、拡張SVCハンドラは未定義のままである。
拡張SVCハンドラ起動時には、常に終了ハンドラの起動がマスクされた状態になっている。拡張SVCハンドラの中で終了要求を受けた時に、
sdef̲ext で定義した終了ハンドラを起動したい場合には、拡張SVCハンドラの中で、終了要求に対する clr̲ems を実行しておく必要がある。また、拡張
SVCハンドラ起動時には、強制例外ハンドラの起動もマスクされた状態になっている。拡張SVCハンドラ実行中は、clr̲ems を使っても強制例外に対する例外マスクを解除することはできず、強制例外ハンドラの起動は拡張
SVCハンドラを抜けるまで遅らされる。
なお、SVCハンドラといった名称は、このシステムコールで定義されるサービスルーチンに限って用いられており、普通のシステムコールは SVCハン
ドラとは呼ばない。これは、ユーザの定義する拡張システムコールと、ITRONの仕様書に載っている標準システムコールを別の名称で扱うためである。
一般に、標準システムコールは、ユーザにとってそれが不可分に実行されるように見えなくてはならない。例えば、システムコール実行中に割込みが入った場合でも、システムコールの実行前、または実行後に割り込まれたのと同じ動作をする必要がある。これに対して、拡張システムコール
では内部が全部ユーザに見えているので、「不可分の実行」というわけにはいかない。また、標準システムコールの処理はOSが行なうため、OS内部のデータ構造（レディキュー、ウエイトキューなど）を自由に操作できるのに第二章 ITRON 2基本機能

340

def̲svc

対して、拡張SVCハンドラではこれらのデータを直接操作することはできず、OS内部の状態を変更するには、必ず標準システムコールを通す必要がある。標準システムコールと拡張システムコールでは、この2つの点で大きな違いがあるので、注意する必要がある。
拡張SVCハンドラの運用上の問題として、内部で待ち状態に入る拡張
SVCハンドラは、タスク独立部から呼び出された場合に、E̲CTX のエラーを返すのが望ましい。タスク独立部から拡張SVCハンドラが呼ばれ、その中で待ちに入るシステムコールを発行した場合には、自然に E̲CTX のエラーが返るので、拡張SVCハンドラ内で E̲CTX のエラーが起きた場合にそれをそのまま要求元に返せば、結果的にこのようなチェックが行われることになる。なお、タスク独立部から拡張SVCハンドラを呼び出す機能はインプリメント依存である。
【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲ILFN

不正機能コード番号（s̲fncd≦0）

E̲RSATR

予約属性（svhatrが不正）

E̲ILADR

不正アドレス（svchdrが奇数、あるいは使用できない値）

第三部 ITRON 2

ret̲svc

341

拡張SVCハンドラから復帰する
ret̲svc
ret̲svc:

Return from SupervisorCall Handler【パラメータ】s̲ercdSVCErrorCode

SVCからのエラーコード【リターンパラメータ】※ システムコールを発行したコンテキストには戻らない【解説】
拡張SVCハンドラから、要求元のタスクまたはハンドラに戻る。要求元には、リターンコード（エラーコード）として s̲ercd の値が返される。
s̲ercd は、正の値でも良い。
拡張SVCハンドラの中から、拡張システムコールを実行することも可能である。すなわち、拡張SVCハンドラはネストすることができる。
ret̲svc で要求元のシステムコール例外を起動したい場合には、s̲ercd の2^8〜2^12 のビットに、起動すべきシステムコール例外の例外クラス番号の補数を設定する。この場合、拡張SVCハンドラを呼んだコンテキストの例
外マスク環境において、s̲ercdで指定した例外クラスに対するマスクがクリアされていれば、システムコール例外が起動される。s̲ercd が正の場合には、システムコール例外は起動されない。
（エラーコードの説明の章を参照）
また、s̲ercd で指定したエラーコードの例外クラスが EC̲TER, EC̲FEX,
EC̲CEX であった場合にも、システムコール例外は起動されない。すなわ
ち、終了例外、強制例外、CPU例外に相当するエラーコードを使ってシス
テムコール例外を発生することはできない。たとえば、拡張SVCを呼んだ側の例外マスクの ECM̲TER がクリアされた状態で ret̲svc(s̲ercd=E̲TER)
を実行しても、システムコール例外は発生しない。
拡張SVCハンドラや例外（終了）ハンドラの中でサブルーチンを呼び、そのサブルーチンの中で直接 ret̲svc や ret̲exc を実行した場合でも、エラーとはならず、そのまま拡張SVCハンドラや例外（終了）ハンドラ起動前のコンテキストに復帰するものとする。すなわち、サブルーチンに対するスタ

第二章 ITRON 2基本機能

342

ret̲svc

タスクA

拡張SVCハンドラ

拡張SVCハンドラの中のサブルーチンfunc

SVC呼び出しfunc ()
ret̲svc［図3.29］サブルーチンの中で実行したret̲svc

ックを残したまま、ret̲svc やret̲exc によって直接拡張SVCハンドラや例外
ハンドラから戻ることが可能である。この場合、ret̲svc やret̲exc の処理の中で、自動的にサブルーチンに対するスタックフレームの解放が行われることになる。
拡張SVCハンドラからサブルーチンを呼び、その中で ret̲svc を実行した場合の動作は、［図3.29］のようになる。
また、拡張SVCに対する例外（終了）ハンドラで ret̲svc を発行した場合
は、まず例外（終了）ハンドラから拡張SVCハンドラへの環境復帰が行われ、次に元のコンテキストへの環境復帰が行われる。エラーとはならない。この場合、ret̲svc のみで、end̲exc+ret̲svc と同等の動作を行うことになる。
この機能は、拡張SVC中で回復不可能なエラーが発生し、拡張SVCを続行しても意味が無いので元のタスクに戻る場合や、拡張SVC実行中に終了要求を受け付けたので、拡張SVCを中断して元のタスクに戻る場合（この時タスクの終了ハンドラが起動される）などに有効である。
拡張SVCハンドラ実行中に例外が発生し、拡張SVCハンドラに対する例
外ハンドラの中で ret̲svc を実行した場合の動作は、［図3.30］のようになる。
また、拡張SVCハンドラ実行中に終了要求が受け付けられ、拡張SVCハン
ドラに対する終了ハンドラの中でret̲svc を実行した場合の動作は、［図3.31］のようになる。なお、タスクA は終了ハンドラの起動をマスクしていない（ECM̲TER をクリアしている）ものとする。
一方、拡張SVCが終了ハンドラの起動をマスクしている間に終了要求を受け付け、終了要求がペンディング状態のまま ret̲svc を実行した場合、第三部 ITRON 2

ret̲svc

タスクA

拡張SVCハンドラ

SVC呼び出し例外発生

343

拡張SVCハンドラの例外ハンドラ（拡張SVCで獲得した資源を解放）
ret̲svc［図3.30］拡張SVCハンドラに対する例外ハンドラ中で実行したret̲svc

タスクA

拡張SVCハンドラ

拡張SVCハンドラの終了ハンドラSVC呼び出し（拡張SVCで獲得した資源を解放）

タスクAに対するter̲tsk
タスクAの終了ハンドラ

ret̲svc（タスクAで獲得した資源を解放）

ext̲tsk/exd̲tsk［図3.31］拡張SVCハンドラに対する終了ハンドラ中で実行したret̲svc

第二章 ITRON 2基本機能

344

ret̲svc

ret̲svc の実行後も拡張SVCハンドラに対する終了ハンドラは起動されない。
この場合、拡張SVCから戻る前の環境では終了ハンドラの起動がマスクされており、また拡張SVCから戻った後の環境では、例外ハンドラ定義環
境も元のコンテキスト（タスク）のものに戻っている。したがって、例外マ
スク環境と例外ハンドラ定義環境の切り換えが不可分に行われると考えれば、拡張SVCに対する終了ハンドラが起動されることはない。終了要求をマスクしておけば、abo̲tsk 発行時を除いて、その環境に対する終了ハンドラが起動されることは無いということになる。
【エラーコード】※ 次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、
システムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合には、メッセージバッファへのロギングや、コンソールへのエラーメッセージの表示などを行うのが望ましいが、詳細な動作はインプリメント依存となる。
E̲CTX

コ ン テ キ ス ト エ ラ ー（ 拡 張 S V C ハ ン ド ラ 実 行 中
ではない）

E̲PAR

一般的なパラメータエラー（s̲ercdが不正）

第三部 ITRON 2

get̲ver345

ITRONのバージョン番号を得る
get̲verget̲ver:

Get Version NO【パラメータ】
pk̲verPacket of Version Numbers バージョン管理情報を返す
パケットの先頭アドレス【リターンパラメータ】
なし【解説】
現在実行中のITRON仕様OSやμITRON仕様OSのスペックの概要、OSの形式番号、バージョン番号などを得る。
このシステムコールは、OSのメーカーおよびバージョン番号を、プログ
ラムから読み出すことを目的としたものである。
バージョンの読み出しは、次のようなパケットを用いて行なわれる。なお、以下で、UH は 16ビット符号無し整数のデータタイプを表わす。
typedef struct t̲ver {UHmaker;/* メーカー */

UH

id;

/* 形式番号 */UH

spver;/* 仕様書バージョン */UH

prver;/* 製品バージョン */UH

prno[4];/* 製品管理情報 */

UH

cpu;

/* CPU情報 */

UH

var;

/* バリエーション記述子 */} T̲VER;
T̲VER*pk̲ver; /* バージョン管理ブロックへのポインタ */パケットの形式や構造体の各メンバのフォーマットは、プロセッサ間で、あるいはITRON1、ITRON2、μITRON、BTRONの間でほぼ共通になっている。以下では、各メンバのフォーマットや意味について説明を行う。

第二章 ITRON 2基本機能

346

get̲ver[maker]＜1＞ 0 0 0 0 0 0 0 0＜2＞

MAKER1

MAKER2

MAKER : メーカー番号
B' 00000000
B' 00000001...
B' 00001001
B' 00001010
B' 00001011
B' 00001100
B' 00001101
B' 00001110
B' 00001111
B' 00010000〜B' 11111111

バージョンなし（実験システムなど）
University of TOKYO＊以下はABC順
FUJITSUHITACHIMATSUSHITAMITSUBISHINECOKITOSHIBA
reserved［図3.32 (a)］get̲verで得られるmakerのフォーマット
maker では、この製品 (ITRON、BTRON、TRONCHIP) を作ったメーカーを表わす。maker のフォーマットを［図3.32 (a)］に示す。
ITRON、BTRON、TRONCHIPのうちの複数のプロジェクトに参加しているメーカーに対しては、協議の上［図3.32 (a)］＜1＞のフォーマットを割り当てる。この場合、MAKER1 のコードは、ITRON、BTRON、TRONCHIP
で共通になる。それ以外のメーカーの場合は、［図3.32 (a)］＜2＞のフォーマットを使用し、B'0000000100000001〜 のコードを割り当てる。MAKER2 のコ ー ド は 登 録 制 と な る 。 MAKER2 の コ ー ド は 、 ITRON、 BTRON、
TRONCHIPの間で異なったものになる。
なお、MAKER1 のコードを持つメーカーの子会社や関連会社の場合は、そのメーカーの判断によって、MAKER1のコード番号を使うか、新しく登録する MAKER2 のコードを使うかということを決める。
id は、OS や VLSI の種類を区別する番号である。id のフォーマットを［図3.32 (b)］に示す。1つのメーカーの中で、MMU対応版とMMU非対応版のような複数の種類の製品を作った場合、それらを区別するためにidを用いることができる。

第三部 ITRON 2

3-2 4/28/98 4:08 PM ページ 347

get̲ver

347

[id]
id

［図3.32 (b)］get̲verで得られるidのフォーマット

MAGIC

SpecVer

MAGIC : TRONのシリーズを区別する番号
H' 0
H' 1
H' 2
H' 3
H' 4
H' 5
H' 6

TRON共通（TAD等）
ITRON1, ITRON2
BTRON
CTRON
reserved
μITRONμBTRONSpecVer : この製品のもとになったTRON仕様書のバージョン番号。
3桁のパックト形式コードで入れる。

［図3.32 (c)］get̲verで得られるspverのフォーマット

idの番号の付け方はメーカーの自由とする。ただし、製品の区別はあくまでもこの番号のみで行なうので、各メーカーにおいて番号の付け方を十分に検討した上、体系づけて使用するようにしなければならない。
spverでは、ITRON, μITRON, BTRON, CTRON, TRONCHIPの区別と、この製品のもとになった仕様書のバージョン番号を表わす。spver のフォーマットを［図3.32 (c)］に示す。
ITRON2の最初のバージョンに対応する spver は次のようになる。
MAGIC = H'1(ITRON)SpecVer = H'200(Ver 2.00)

spver= H'1200

また、たとえば ITRON2 Ver 2.34.xx.xx の仕様書をインプリメントした製品の場合、spver = H'1234となる。
prverでは、内部インプリメント上のバージョン番号を表わす。prver のフ

第二章

ITRON2基本機能

348

get̲ver[prver]
MAJOR

MINOR

［図3.32 (d)］get̲verで得られるprverのフォーマット
[prno]
prno[0]prno[1]
prno[2]prno[3]［図3.32 (e)］get̲verで得られるprnoのフォーマット

ォーマットを［図3.32 (d)］に示す。MAJOR はバージョン番号の大きな区
別、MINOR はバージョン番号の小さな区別を表わす。番号の付け方はメーカーの自由である。
prno は、製品管理情報や製品番号などを入れるために、各メーカーが自由に使用してもよい部分である。prnoのフォーマットを［図3.32 (e)］に示す。
cpu は、このITRONを実行するプロセッサを表わす。cpu のフォーマット
を［図3.32 (f)］に示す。TRONCHIP、モトローラM68000系、インテル
iAPX86系、ナショセミNS32000系、NEC-Vシリーズのプロセッサの場合は［図3.32(f)］＜1＞のフォーマットを使用し、それ以外の各社独自アーキテク
チャのプロセッサの場合には、［図3.32(f)］＜2＞のフォーマットを使用する。
［図3.32(f)］＜1＞のフォーマットにおける CPU1 のコード割当ては、
ITRONとBTRONで共通である。また、BTRON/CHIP標準オブジェクトフォ
ーマットのCPUタイプの部分にも、これと同じ番号が入る。
一方、［図3.32(f)］＜2＞のフォーマットは、主としてμITRON で用いられるものである。この場合、MAKER1 のコードの割当ては、maker の項で説明したものと同じになる。また、CPU2 のコードの割当ては MAKER1 のメーカーが決める。

第三部 ITRON 2

get̲ver

349

[cpu]
＜1＞ 0 0 0 0 0 0 0 0＜2＞

MAKER1

CPU1
CPU2

CPU1:
B'00000000 (H'00) CPUを特定しない、CPU情報を持たない
B'00000001 (H'01) TRONCHIP32共通
B'00000010 (H'02) reserved
B'00000011 (H'03) reserved
B'00000100 (H'04) reserved
B'00000101 (H'05) reserved（《L1R》仕様のTRONCHIIP）
B'00000110 (H'06) reserved（《L1》仕様のTRONCHIIP）
B'00000111 (H'07) reserved （LSIDの機能を持つTRONCHIIP）＊B' 00000000〜00000111 の場合、CPUのメーカーを特定しない。
B'00001000 (H'08) rreserved
B'00001001 (H'09) GMICRO/100
B'00001010 (H'0a) GMICRO/200
B'00001011 (H'0b) GMICRO/300
B'00001100 (H'0c) reserved
B'00001101 (H'0d) TX1
B'00001110 (H'0e) reserved
B'00001111 (H'0f) TX3
B'00010000 (H'10) reserved
B'00010001 (H'11) reserved
B'00010010 (H'12) reserved
B'00010011 (H'13) 032
B'00010100 (H'14) reserved
B'00010101 (H'15) MN10400
B'00010110 (H'16) reserved
B'00010111 (H'17) reserved
B'00011000〜B'00111111(H'18〜H'3f) - reserved＊GMICRO拡張用、TXシリーズ拡張用、TRONCHIP64用［図3.32 (f)］get̲verで得られるcpuのフォーマット（前半）

第二章 ITRON 2基本機能

350

get̲ver
B'01000000 (H'40) 68000
B'01000001 (H'41) 68010
B'01000010 (H'42) 68020
B'01000011 (H'43) 68030
B'01000000〜B'01001111(H'40〜H'4f) - 6800 系

B'01010000 (H'50) 32032
B'01010000〜B'01001111(H'50〜H'5f) - NS32000 系

B'01100000 (H'60) 8086. 8088
B'01100001 (H'61) 80186
B'01100010 (H'62) 80286
B'01100011 (H'63) 80386
B'01100000〜B'01101111(H'60〜H'6f) - 86 系

B'01110000〜B'01111111(H'70〜H'7f) - NEC Vシリーズ＊割り当てはＶシリーズ関連メーカーが決める。

B'10000000〜B'11111111(H'80〜H'ff) - reserved［図3.32 (f)］get̲verで得られるcpuのフォーマット（後半）var では、このITRON2、μITRONで利用できる機能の概要を表わす。varのフォーマットを［図3.32 (g)］に示す。
なお、製品の種類の区別はあくまでも idの部分で行なう。var, cpu による表示は便宜的なものに過ぎない。すなわち、var, cpu が異なり、かつ id の等
しい製品が存在してはいけない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲ILADR

不正アドレス（pk̲verが使用できない値）

第三部 ITRON 2

get̲ver

[var]
−

−:
LEV:

M=1:
M=0:
V=1:
P=1:
FIL:

IO:

LEV

− M V P −FIL

IO − −

reserved（0 が返る）
カーネル仕様のレベル分け
B' 000 μITRON
B' 001 reserved
B' 010 reserved
B' 011 ITRON2基本仕様（≪I1≫仕様）
B' 100 ITRON2一部拡張仕様（一部≪I2≫仕様）
B' 101 ITRON2拡張仕様（≪I2≫仕様）
マルチプロセッササポート
B' 110 reserved
シングルプロセッサ用
B' 111 reserved
仮想記憶サポート
MMU対応版
B' 000
サポートなしファイル仕様のレベル分け
B' 001 ≪FI0≫仕様
B' 010 ≪FI1≫仕様
B' 011〜111 reserved
B' 00
サポートなし
入出力仕様
B' 01
標準仕様
B' 10
reservedB' 11
reserved［図3.32 (g)］get̲verで得られるvarのフォーマット

第二章 ITRON 2基本機能

351

352

psw̲sts

プロセッサ状態語を参照する
psw̲stspsw̲sts:

Get Processor Status Word

【パラメータ】
なし【リターンパラメータ】
psw

Processor Status Word

プロセッサ状態語【解説】
CPU のプロセッサ状態語 (PSW) を参照する。
一般に、このシステムコールにより、次のような情報を得ることができる。
― マスクされている割込みの優先度（割込みマスク、割込みレベル）― 現在実行中のリングやモード（スーパバイザモード等）
また、これらの情報により、現在実行中のコンテキストがタスク独立部
なのか、準タスク部なのか、タスク部なのかを知ることができる。
プロセッサによっては、PSW のうちの一部のフィールドしか意味を持たない場合や、PSW のうちの一部のフィールドしか参照できない場合がある。
【エラーコード (ercd)】
E̲OK

正常終了

第三部 ITRON 2

第三部 第三章

ITRON2拡張機能

この章では、ITRON2で拡張、追加された機能（≪I2≫レベルのシ
ステムコール）に関する説明を行う。

354

拡張同期・通信機能

第三部 ITRON 2

cre̲mbf

355

メッセージバッファを生成する
cre̲mbfcre̲mbf:

Create MessageBuffer【パラメータ】
mbfid

MessageBufferIdentifier

メッセージバッファID

mbfatrMessageBufferAttribute

メッセージバッファ属性

bufsz

BufferSize

メッセージバッファのサイズ

maxbmsz

MaxBufferedMessageSize

メッセージの最大長【リターンパラメータ】
なし【解説】
cre̲mbf では、mbfid で指定されたID番号を持つメッセージバッファを生成する。次に、生成されたメッセージバッファに対して管理ブロックを割り付ける。
メッセージバッファは、可変長メッセージの送受信の管理を行うオブジ
ェクトであり、リングバッファにより構成される。メイルボックス (mbx)との大きな違いは、送信時と受信時にメッセージの内容がコピーされるということである。リアルタイム性確保のため、生成時にメッセージの最大長を指定し、それ以上のサイズのメッセージを送信した場合はエラー
E̲SZOVR とする。リングバッファの大きさは bufsz で指定される。メッセージの順番は FIFO のみである。
ID 番号が (-4)〜0 のメッセージバッファは生成できない。また、負の ID
番号のメッセージバッファは、システム用のものである。このうち、特にmbfid=TMBF̲OS (-4) のメッセージバッファは、システム (OS) のエラーロ
グ用（どこにも通知できないエラーの記録用）として用いられる。また、
mbfid = TMBF̲DB (-3) のメッセージバッファは、デバッグサポート機能との情報交換のために用いられる。
mbfatrのサイズは標準で4バイトである。mbfatrのフォーマットを［図3.33］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）

第三章 ITRON 2拡張機能

356

cre̲mbfはユーザ属性を表わし、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16のビット）はインプリメント依存の属性を表わし、下位ハーフワード（bit16〜bit31 あるいは 2^15〜2^0 のビット）はシステム属性を表わす。ユーザは、メッセージバッファに関する情報を入れておくために、mbfatr の最上位バ
イトを自由に使用することができる。
cre̲mbf で指定した mbfatr は、mbf̲sts により読み出すことができる。
mbfatr のシステム属性の部分では、次のような指定を行うことができる。
mbfatr : = (TA̲TFIFO‖TA̲TPRI)TA̲TFIFO

待ちタスクのキューイングは FIFOTA̲TPRI

待ちタスクのキューイングは優先度順

TA̲TFIFO の属性を指定した場合には、メッセージを待つタスクは FIFOの待ち行列を作り、TA̲TPRI の属性を指定した場合には、メッセージを待つタスクはタスクの優先度順の待ち行列を作る。メッセージの待ち行列は
FIFO のみである。
ITRONの基本方針として、TCB を軽くするために、できるだけタスク従属の機能を設けないという考え方がある。メッセージバッファをタスク従属にしないのは、このためである。また、エラーログの目的では、タスク独立にした方が良い。
また、メイルボックスとメッセージバッファは、似た用途で使用されるが、別のオブジェクトとして扱っている。これは、両者の内部構成、使い方、システムコールのパラメータなどがかなり異なっているためである。

bit0
mbfatr

bit8
ユーザ属性

bit16

インプリメント依存属性

bit31
システム属性［図3.33］mbfatrのフォーマット

第三部 ITRON 2

cre̲mbf

357【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足（管理ブロック用の領域が確保できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲NOMEM

メモリ不足（リングバッファ用の領域が確保できない）※ E̲NOSMEMとE̲NOMEMとの厳密な区別はインプリメ
ント依存である。

E̲RSID

予約ID番号（-4≦mbfid≦0）

E̲RSATR

予約属性（mbfatrの下位3バイトが不正）E̲PAR一般的なパラメータエラー（bufsz,maxbmszが不正）

E̲IDOVR

ID範囲外（mbfidがシステムで利用できる範囲を越えた）

E̲EXS

オブジェクトが既に存在している（同一ID番号のメッセー
ジバッファが存在）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でmbfid＜(-4)）

第三章 ITRON 2拡張機能

358

del̲mbf

メッセージバッファを削除する
del̲mbfdel̲mbf:

Delete MessageBuffer【パラメータ】
mbfid

MessageBufferIdentifier

メッセージバッファID【リターンパラメータ】
なし【解説】mbfid で示されるメッセージバッファを削除する。
そのメッセージバッファへのメッセージの到着を待っているタスクがある場合にも本システムコールは正常終了するが、メッセージの到着を待っていたタスクにはエラー E̲DLT が返される。
また、メッセージバッファの中にメッセージが残っている場合にも、
del̲mbf ではメッセージバッファの削除が行われ、中にあったメッセージは消滅する。
本システムコール発行後は、そのID番号のメッセージバッファを再び新しく生成することができる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦mbfid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（mbfidのメッセージバッ
ファが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でmbfid＜(-4)）

第三部 ITRON 2

snd̲mbf

359

メッセージバッファへ送信する
snd̲mbfsnd̲mbf:

Send Message to MessageBuffer【パラメータ】
mbfid

MessageBufferIdentifier

メッセージバッファID

bmsgszBufferedMessageSize

送信メッセージのサイズ

pk̲bmsg

BufferdMessagePacket

送信メッセージの先頭アドレス【リターンパラメータ】
なし【解説】mbfid で示されたメッセージバッファに、pk̲bmsg のアドレスに入っているメッセージを送信する。メッセージのサイズは bmsgsz で指定される。
すなわち、pk̲bmsg 以下の bmsgsz バイトが、mbfid で指定されたメッセー
ジバッファにコピーされる。
bmsgszが、cre̲mbfで指定したmaxbmszよりも大きい場合は、エラー
E̲SZOVRとなる。また、メッセージバッファが一杯の時は、即座にエラー
E̲QOVRとしてリターンする。このシステムコールで待ち状態になることはない。
長さが0のメッセージは送信することができない。bmsgsz≦0の場合には、
エラー E̲PAR となる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦mbfid≦0）

E̲PAR

一般的なパラメータエラー（bmsgsz≦0）

E̲ILADR

不正アドレス（pk̲bmsgが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲SZOVR

パラメータのサイズが制限を越えた（bmsgsz＞maxbmsz）

第三章 ITRON 2拡張機能

360

snd̲mbf

E̲NOEXS

オブジェクトが存在していない（mbfidのメッセージバッ
ファが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でmbfid＜(-4)）

E̲QOVR

キューイングのオーバーフロー（リングバッファのオー
バーフロー）

第三部 ITRON 2

rcv̲mbf

361

メッセージバッファから受信する
rcv̲mbfrcv̲mbf:

Receive Message from MessageBuffer【パラメータ】
mbfid

MessageBufferIdentifier

メッセージバッファID

tmout

Timeout

タイムアウト指定

pk̲bmsg

BufferedMessagePacket

受信メッセージを入れるアドレス【リターンパラメータ】
bmsgszBufferedMessageSize

受信したメッセージのサイズ【解説】
mbfid で示されたメッセージバッファからメッセージを受信し、pk̲bmsg
で指定した領域に入れる。すなわち、mbfid で指定されたメッセージバッフ
ァの先頭のメッセージが、pk̲bmsg 以下の bmsgsz バイトにコピーされる。
受信時にもメッセージのコピーが行われるため、pk̲bmsg はリターンパラ
メータではなくパラメータとなっている。
mbfid で示されたメッセージバッファにまだメッセージが到着していな
い場合には、本システムコール発行タスクはメッセージ到着を待つ待ち行
列につながれる。待ち行列へのつながれ方は、メッセージバッファ生成時に mbfatr で指定した方法によるものであり、FIFO または タスク優先度のいずれかである。
tmout により待ち時間のタイムアウト指定を行うことができる。tmout としては、正の値のみを指定することができる。タイムアウト指定が行われた場合、条件が満足されぬまま tmout 時間が経過すると、タイムアウトエ
ラー E̲TMOUT としてエラーリターンする。また、tmout として TMO̲POLを指定した場合は、メッセージが受信できない場合でも即時にリターンする。この場合、メッセージが受信できれば正常終了に、メッセージが無け
ればタイムアウトエラー E̲TMOUT になる。さらに、tmout =TMO̲FEVR
によりタイムアウト指定が行われないことを示す。この場合は条件が満足されるまで永久に待つ。

第三章 ITRON 2拡張機能

362

rcv̲mbf【エラーコード (ercd)】
E̲OK

正常終了

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-3≦mbfid≦0、ただし mbfid = (-3) はインプリメント依存）E̲ILADR

不正アドレス（pk̲bmsgが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILTIME

不正時間指定（tmout≦-2）

E̲NOEXS

オブジェクトが存在していない（mbfidのメッセージバッ
ファが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行で mbfid＜(-3)）※ mbfid = TMBF̲OS (-4) に対する rcv̲mbf をユーザタス
クから発行することはできない。

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

E̲DLT

待ちオブジェクトが削除された（待ちの間に対象メッセー
ジバッファが削除）

E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第三部 ITRON 2

mbf̲sts363

メッセージバッファ状態を参照する
mbf̲sts
mbf̲sts:

Get MessageBuffer Status【パラメータ】
mbfid

MessageBufferIdentifier

pk̲mbfs

Packet of MessageBufferStatus メッセージバッファ状態を返す

メッセージバッファID
パケットの先頭アドレス【リターンパラメータ】
なし【解説】mbfidで示されたメッセージバッファの状態を読み出し、その結果をpk̲mbfs 以下の領域に返す。
pk̲mbfs に返される情報としては、次のようなものがある。
mbfatr/* メッセージバッファ属性 */wtskid/* 待ち行列先頭のタスクID */bmsgsz/* 次のメッセージのサイズ */maxbmsz/* メッセージの最大サイズ */frbufsz/* 空きバッファサイズ */bufsz/* バッファ全体のサイズ */wtskid には、待ち行列の先頭のタスクのIDが返る。すなわち、属性がTA̲TFIFO であれば、現在このメッセージバッファを待っているタスクのうち、最も早く待ち状態になったタスクのIDが返る。また、属性がTA̲TPRI であれば、現在このメッセージバッファを待っているタスクのうち、最も優先度の高いタスクのIDが返る。待ちタスクの無い時は FALSE=0が返る。
bmsgsz には、次に受信されるメッセージのサイズが返る。メッセージが無い時は 0 が返る。bmsgsz とwtskid の少なくても一方は必ず 0 となる。なお、サイズが0のメッセージを送ることはできない。

第三章 ITRON 2拡張機能

364

mbf̲sts

frbufsz は、メッセージバッファを構成するリングバッファの空き領域のサイズを示すものである。この値は、あとどの程度の量のメッセージが受け付けられるかを知る手掛かりになる。
mbfatr, maxbmsz, bufsz には、cre̲mbf で指定された値がそのまま返る。
対象となるメッセージバッファは、既に生成されたものでなければならない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-3≦mbfid≦0、ただしmbfid = (-3) はインプリ
メント依存）E̲ILADR

不正アドレス（pk̲mbfsが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（mbfidのメッセージバッ
ファが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でmbfid＜(-3)）※ mbfid = TMBF̲OS (-4) に対する mbf̲sts をユーザタス
クから発行することはできない。

第三部 ITRON 2

cre̲por

365

ランデブ用のポートを生成する
cre̲porcre̲por:Create Port for Rendezvous【パラメータ】
porid

PortIdentifier

ポートID

poratr

PortAttribute

ポート属性【リターンパラメータ】
なし【解説】
cre̲por では、porid で指定された ID 番号を持つポートを生成する。ポートは、ランデブを実現するためのプリミティブとなるオブジェクトである。
次に、生成されたポートに対して管理ブロックを割り付ける。
ID 番号が (-4)〜0 のポートは生成できない。また、負の ID 番号のポートは、システム用のものである。
poratr のサイズは標準で4バイトである。poratr のフォーマットを［図3.34］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）はユーザ属性を表わし、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16の ビ ッ ト ）は イ ン プ リ メ ン ト 依 存 の 属 性 を 表 わ し 、 下 位 ハ ー フ ワ ー ド（bit16〜bit31 あるいは 2^15〜2^0 のビット）はシステム属性を表わす。ユー
ザは、ポートに関する情報を入れておくために、poratr の最上位バイトを自由に使用することができる。
なお、poratr のシステム属性の部分は、現在はすべて reserved となっていbit0
poratr

bit8
ユーザ属性

bit16

インプリメント依存属性

bit31
システム属性［図3.34］poratrのフォーマット

第三章 ITRON 2拡張機能

366

cre̲por

るため、TA̲NULL (0) を入れておく必要がある。cre̲por で指定した poratr
は、por̲sts により読み出すことができる。
ITRON2のポートにより実現されるランデブは、ADA のランデブとは異なり、タスク独立である。すなわち、cal̲por によるランデブ呼び出し時には、相手タスクの指定は行わず、ポートの指定のみを行う。また、一つのポートで複数のランデブを同時に行うことも可能である。すなわち、前に成立したランデブの rpl̲por が実行される前に、同じポートに対して別のタスクが acp̲por を実行することも可能である。さらに、ITRON2のランデブ
では、呼び出し側 (cal̲por) のタスク、受け付け側 (acp̲por) のタスクがともに待ち行列を作ることができる。
呼び出し側の待ち行列、受け付け側の待ち行列はともに FIFO であるが、後述する条件付きランデブの機能により、必ずしも行列先頭のタスクから待ち解除になるとは限らない。同一条件のタスク間でのみ FIFO の規則が適用される。条件付きランデブ機能は、ADA の選択受付機能 (select) を実現するためのものである。
ランデブの機能は、他の同期・通信機能の組み合せで実現することも可能だが、サーバ等の用途に用いた場合には、他の同期・通信機能を組み合せるよりも効率を上げることができると考えられる。
ポートをタスク独立としたのは、ITRONにおいて、タスク付属の機能をあまり入れないという方針に基づいている。
【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦porid≦0）

E̲RSATR

予約属性（poratrの下位3バイトが不正）

E̲IDOVR

ID範囲外（poridがシステムで利用できる範囲を越えた）

E̲EXS

オブジェクトが既に存在している（同一ID番号のポートが存在）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でporid＜(-4)）

第三部 ITRON 2

del̲por367

ランデブ用のポートを削除する
del̲pordel̲por:

Delete Port for Rendezvous【パラメータ】
porid

PortIdentifier

ポートID【リターンパラメータ】
なし【解説】
porid で示されるランデブ用のポートを削除する。
そのポートに対して、受付待ち (acp̲por) や呼出待ち (cal̲por) を行っているタスクがある場合にも、本システムコールは正常終了するが、待ち状態にあったタスクにはエラー E̲DLT が返される。
del̲por により、現在ランデブ中のタスクが存在するポートを削除した場
合、ランデブ終了待ちのタスクには E̲DLT が返り、ランデブを受け付けた側のタスク（待ち状態ではない）には何も通知されないものとする。この場
合、ランデブを受け付けた側のタスクには、rpl̲por を実行した段階でE̲NORDV のエラーが返ることになる。
本システムコール発行後は、そのID番号のランデブ用ポートを再び新しく生成することができる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦porid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（poridのポートが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でporid＜(-4)）

第三章 ITRON 2拡張機能

368

cal̲por

ポートに対するランデブの呼び出し
cal̲porcal̲por:Call Port for Rendezvous【パラメータ】
porid

PortIdentifier

ポートID

calptnCallBitPattern

呼出側選択条件を表わすビット
パターン

pk̲rmsg

RendezvousMessagePacket

メッセージアドレス

maxrmsz Max RendezvousMessageSize

返答メッセージ受信領域のサイズ

tmout

タイムアウト指定

Timeout【リターンパラメータ】
なし【解説】
ポートに対するランデブ呼び出しを行う。
具体的な動作は次のようになる。porid で指定したポートの受け付け待ちを行っているタスクと、このタスクとの間で、ランデブ成立条件が満たされた場合は、ランデブ成立となる。この場合、受け付け待ちだったタスク
は実行可能状態となり、cal̲por 発行タスクはランデブ処理終了待ちの状態になる。また、porid で指定したポートの受け付け待ちタスクが無かった場
合や、タスクがあってもランデブ成立条件が満たされなかった場合には、
cal̲por 発行タスクは呼び出し側待ち行列の最後に入り、ランデブ呼出待ちの状態となる。
ランデブ成立条件は、受付側タスクの acpptn と呼び出し側タスクのcalptn との論理積が 0 かどうかによって判定される。論理積が 0 でない場合にランデブ成立となる。
ランデブ成立時には、呼び出し側タスクから受付側タスクに対してメッセージを送ることができる。メッセージは、［図3.35］のような形式であり、
cal̲por ではその先頭アドレス pk̲rmsg を指定する。

第三部 ITRON 2

cal̲por369

pk̲rmsg
rmsgsz 4バイト
rmsgsz

メッセージサイズ（このワードを含む）

rmsgcont(rmsgsz-4) バイト［図3.35］ランデブで送られるメッセージの形式

ランデブが成立した場合は、受付側タスクが acp̲por の pk̲rmsg パラメータで指定した領域に対して、上記のメッセージがコピーされる。
逆に、ランデブ終了時には、受付側タスクから呼びだし側タスクに対してメッセージを送ることができる。具体的には、rpl̲por の pk̲rmsg パラメータ以下のアドレスに置かれたメッセージが、cal̲por の pk̲rmsg パラメー
タ以下の領域コピーされる。メッセージの形式はランデブ成立時と同じく
上記の形式である。結局、cal̲por で指定した pk̲rmsg 以下のメッセージ領
域は、rpl̲por 実行の際に送られてくるメッセージによって破壊されることになる。
maxrmsz により、ランデブ終了時にメッセージを受け取る領域（pk̲rmsg
以下の空き領域）のサイズを指定する。ランデブ終了時にこれを越えるサイズのメッセージが送られてきた場合（cal̲porのmaxrmsz＜rpl̲porのrmsgsz）には、rpl̲porのpk̲rmsg で指定されたメッセージのうち、maxrmsz のサイズ
までの分のみがコピーされ、それ以降はコピーされない。この場合、
cal̲por を 発 行 し た タ ス ク（ rpl̲por を 発 行 し た タ ス ク で は な い ）に はE̲AROVR のエラーが返る。E̲AROVR のエラーになった場合でも、ランデブの終了はエラーの無い場合と同じように行われる。また、cal̲por でE̲AROVR になった場合（cal̲porのmaxrmsz＜rpl̲porのrmsgsz）、pk̲rmsg>rmsgsz に格納されるサイズは rpl̲por で指定された rmsgsz（元のメッセー
ジサイズ）であり、cal̲por で指定された maxrmsz ではない。

第三章 ITRON 2拡張機能

370

cal̲portmoutにより待ち時間のタイムアウト指定を行うことができる。tmout としては、正の値のみを指定することができる。タイムアウト指定が行われた場合、ランデブが成立しないまま tmout 時間が経過すると、タイムアウ
トエラー E̲TMOUT としてエラーリターンする。
tmoutとして TMO̲POL を指定した場合は、cal̲por 実行時に既にランデブ成立条件が満たされていないと、E̲TMOUT として即時にリターンする。
tmout として TMO̲POL を指定し、cal̲por 実行時に既にランデブ成立条件が満たされていれば、cal̲por を実行したタスクはランデブ受け付けタスクが rpl̲por を実行するまでランデブ終了待ちの状態になる。この場合は、タ
イムアウト指定が無い時と同様に、ランデブ受け付けタスクの rpl̲por の実行により cal̲por は正常終了する。
tmout = TMO̲FEVR により、タイムアウト指定が行われないことを示す。
この場合はランデブ成立条件が満足されるまで永久に待つ。
いずれの場合も、tmout の指定はランデブ成立までの時間に関するタイムアウトを意味するものであり、ランデブ成立からランデブ終了までの時間には関係しない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦porid≦0）

E̲PAR

一般的なパラメータエラー（rmsgsz＜4）

E̲ILADR

不正アドレス（pk̲rmsgが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILTIME

不正時間指定（tmout≦-2）

E̲NOEXS

オブジェクトが存在していない（poridのポートが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でporid＜(-4)）

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

第三部 ITRON 2

cal̲por
E̲DLT

371

待ちオブジェクトが削除された（ランデブ呼出待ち、ある
いは終了待ちの間に対象ポートが削除）

E̲AROVR

用意した領域のサイズが小さすぎる（rpl̲porのpk̲rmsg中のrmsgsz＞maxrmsz）

E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第三章 ITRON 2拡張機能372

acp̲por

ポートに対するランデブの受け付け
acp̲poracp̲por:Accept Port for Rendezvous【パラメータ】
porid

PortIdentifier

ポートID

acpptnAcceptBitPattern

受付側選条件を表わすビット
パターン

pk̲rmsg

RendezvousMessagePacket

メッセージアドレス

maxrmsz

Max RendezvousMessageSize

メッセージ受信領域のサイズ

tmout

Timeout

タイムアウト指定【リターンパラメータ】
ctskidCallTaskIdentifier

呼出タスクID【解説】
ポートに対するランデブ受け付けを行う。
具体的な動作は次のようになる。poridで指定したポートの呼び出し側
待ち行列に入っているタスクと、このタスクとの間で、ランデブ成立条件が満たされた場合は、ランデブ成立となる。この場合、呼び出し側待ち行列にあったタスクは行列から外れ、ランデブ呼出待ち（成立待ち）状態からランデブ処理終了待ちの状態に変わる。acp̲por の発行タスクは、実行を継続する。
porid で指定したポートの呼び出し側待ち行列にタスクが無かった場合
や、タスクがあってもランデブ成立条件が満たされなかった場合は、
acp̲por 発行タスクがそのポートに対する受け付け待ち行列につながれる。
porid で指定したポートに対して、受け付け待ちタスクが既に存在した場
合でも、エラーとはならない。また、ITRON2では、一つのポートで複数のタスクが同時にランデブを行うことが可能であるため、poridで指定したポートで別のタスクがランデブ中の場合（前のランデブに関する rpl̲porがまだ実行されてない場合）に次のランデブを行っても、エラーとはならない。

第三部 ITRON 2

acp̲por373

ランデブ成立条件は、受付側タスクの acpptn と呼び出し側タスクのcalptn との論理積が 0 かどうかによって判定される。論理積が 0 でない場合にランデブ成立となる。先頭のタスクが条件を満たさなければ、待ち行列の次のタスクについて順にチェックを行う。calptn と acpptn に 0 以外の同じ値を指定すれば、条件が無い（無条件）のと同じになる。calptn, acpptn が0 の場合は、決してランデブが成立しなくなるので、パラメータエラー
E̲PAR とする。ランデブ成立までの処理に関しては、呼び出し側と受け付
け側で完全に対称である。
この機能により、選択受け付け（ADA の select）の処理が実現可能となる。具体的には、次のようにして実現される。
≪ADA でのプログラム例≫
selectwhen condition̲A
accept entry̲A do ... end;orwhen condition̲B
accept entry̲B do ... end;orwhen condition̲C
accept entry̲C do ... end;
end select;≪ITRONのランデブ機能による上記プログラムの実現方法≫― entry̲A, entry̲B, entry̲C がそれぞれ一つのポートになるのではなく、
select 文全体が一つのポートに対応する。
― entry̲A, entry̲B, entry̲C を、calptn, acpptn の 2^0, 2^1, 2^2 の ビ ッ ト に対応させる。
―上記の select 文は、次のようになる。
ptn : = 0;
if conditon̲A then ptn :=ptn+2^0 endif;
if conditon̲B then ptn :=ptn+2^1 endif;
if conditon̲C then ptn :=ptn+2^2 endif;
第三章 ITRON 2拡張機能374

acp̲poracp̲por(acpptn :=ptn);―もし、上記の文以外に、select 無しの単なる entry̲A の accept があれば、
acp̲por (acpptn : = 2^0);
を実行すれば良い。また、entry̲A, entry̲B, entry̲C を無条件に OR で待ちたい時は、
acp̲por(acpptn :=2^2+2^1+2^0);
を実行すれば良い。
―一方、これを呼び出す側は、entry̲A の call であれば
cal̲por (calptn : = 2^0);を実行し、entry̲C の call であれば
cal̲por (calptn : = 2^2);を実行すれば良い。
ADA であれば、選択機能は受け付け側にしか用意されていないが、
ITRONのランデブでは、calptn で複数のビットを指定することにより、呼び出し側に選択機能を持たせることも可能である。
acp̲por のリターンパラメータのうち、ctskid は、ランデブの成立した相手タスク（呼び出し側タスク）のタスクID である。一つのタスクが複数のランデブを同時に行うことが可能であるため、rpl̲por でランデブを終了する際には、ctskid の情報を指定する必要がある。ctskid は、ランデブID（ポートIDではなく、その上で成立した複数のランデブを区別するID）であると考えることができる。
acp̲por の pk̲rmsg 以下の領域には、cal̲por の pk̲rmsg 以下の領域で指定したメッセージがコピーされる。メッセージのサイズは、このメッセー
ジの先頭ワードに置かれている。
maxrmsz により、ランデブ成立時にメッセージを受け取る領域（pk̲rmsg
以下の空き領域）のサイズを指定する。ランデブ成立時にこれを越えるサイズのメッセージが送られてきた場合（acp̲porのmaxrmsz＜cal̲porのrmsgsz）には、cal̲por の pk̲rmsg で指定されたメッセージのうち、maxrmsz のサイズまでの分のみがコピーされ、それ以降はコピーされない。この場合、
acp̲por を発行したタスク（cal̲por を発行したタスクではない）にはE̲AROVR のエラーが返る。E̲AROVR のエラーになった場合でも、ランデブの終了はエラーの無い場合と同じように行われる。また、acp̲por で第三部 ITRON 2

acp̲por

375

E̲AROVR になった場合（acp̲porのmaxrmsz＜cal̲porのrmsgsz）、pk̲rmsg>rmsgsz に格納されるサイズは cal̲por で指定された rmsgsz（元のメッセー
ジサイズ）であり、acp̲por で指定された maxrmsz ではない。
tmoutにより待ち時間のタイムアウト指定を行うことができる。tmout としては、正の値のみを指定することができる。タイムアウト指定が行われた場合、条件が満足されぬまま tmout 時間が経過すると、タイムアウトエ
ラー E̲TMOUT としてエラーリターンする。また、tmout として TMO̲POLを指定した場合は、ランデブ成立条件が満たされていない場合でも即時にリターンする。この場合、ランデブが成立していれば正常終了に、ランデブ成立条件が満たされていなければタイムアウトエラー E̲TMOUT になる。
さらに、tmout = TMO̲FEVR によりタイムアウト指定が行われないことを示す。この場合は条件が満足されるまで永久に待つ。
ランデブ受け付け側のタスクが、同時に複数のランデブを行うことも可能である。具体的には、acp̲por によりあるランデブを受け付けたタスクが、
rpl̲porを実行する前に、もう一度 acp̲por を実行しても構わない。また、同時に成立している複数のランデブは、同じポートを対象としたものであっても、異なるポートを対象としたものであっても構わない。
ランデブを受け付けたタスクが、何らかの理由でランデブ終了前（rpl̲por実行前）に異常終了したような場合は、cal̲por を実行したランデブ
呼出側のタスクがランデブ終了待ち状態から解放されないまま残ることになる。このようなケースを避けるためには、ランデブ受付側タスクの終了
ハンドラで rpl̲por または rel̲wai を実行し、ランデブがエラーで終了した
ことをランデブ呼出側のタスクに通知しておく必要がある。
【エラーコード (ercd)】
E̲OK

正常終了

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦porid≦0）

E̲PAR

一般的なパラメータエラー（maxrmsz＜4,

E̲ILADR

不正アドレス（pk̲rmsgが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

第三章 ITRON 2拡張機能376

acp̲porE̲ILTIME

不正時間指定（tmout≦-2）

E̲NOEXS

オブジェクトが存在していない（poridのポートが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でporid＜(-4)）

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

E̲DLT

待ちオブジェクトが削除された（待ちの間に対象ポートが削除）

E̲AROVR

用意した領域のサイズが小さすぎる（cal̲porあるいはfwd̲porのpk̲rmsg中の rmsgsz＞maxrmsz）

E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第三部 ITRON 2

fwd̲por377

ポートに対するランデブの回送
fwd̲porfwd̲por:Forward Port for Rendezvous【パラメータ】
porid

PortIdentifier

ポートID

ctskidCallTaskIdentifier

呼出タスクID

calptnCallBitPattern

呼出側選択条件を表わすビッpk̲rmsg

RendezvousMessagePacket メッセージアドレス

トパターン【リターンパラメータ】
なし【解説】
一旦受け付けたランデブを別のポートに回送する。
このシステムコールを発行したタスク（タスクX）は、あるポート（ポートA）において ctskidで示されるタスク（タスクY）のランデブ呼び出しを受け付け、現在ランデブ中の状態でなければならない。その状態でこのシス
テムコールを実行すると、ポートAにおけるタスクXとタスクYとのランデブ状態が解除され、porid で示される別のポート（ポートB）に対してタスク
Yがランデブ呼び出しを行ったのと同じ状況になる。
fwd̲por の具体的な動作は次のようになる。
1. ctskid で示されるタスクとのランデブ状態を解除する。
2. ctskid で示されるタスクを、porid のポートに対してランデブ呼びだし待ちの状態にする。この時、ランデブ成立条件の calptn は、cal̲por で指定したものではなく、fwd̲por で指定したものが使用される。ctskid のタス
クから見ると、ランデブ終了待ちの状態からランデブ受付待ちの状態に戻ることになる。
3. その後、porid のポートに対するランデブが受け付けられれば、それを受け付けたタスクと ctskid のタスクとの間でランデブ成立となる。もちろん、ランデブ成立条件が合っていれば、fwd̲por の実行により即座にラン

第三章 ITRON 2拡張機能

378

fwd̲por

デブ成立となることもある。ここで、ランデブ成立時に受付側に送られるメッセージは、cal̲por で指定したものではなく、fwd̲por で指定したものになる。fwd̲por を実行したタスクは、この新しいランデブとは全く関係しない。
4. 新しいランデブが終了した際に rpl̲por で返されるメッセージは、fwd̲porで指定した pk̲rmsg 以下の領域ではなく、cal̲por で指定した pk̲rmsg 以下の領域にコピーされる。これは、ランデブを呼び出した側に対して、ランデブが回送されたことを見せないようにするために必要な仕様である。
fwd̲por の実行は即座に終了する。このシステムコールで待ち状態になることはない。
一旦回送されてきたランデブを、さらに回送することも可能である。
fwd̲por を使ったサーバタスクの動作イメージを以下の図に示す。
fwd̲por を実行する際、fwd̲por で送信されるメッセージは cal̲por のpk̲rmsg で指定されたメッセージ領域にコピーされる。したがって、ランデブ成立時には、ランデブが回送されたものかどうかにかかわらず、cal̲porの pk̲rmsg に置かれたメッセージが受付側に渡される。すなわち、ランデブが回送された場合でも、ランデブが成立するまで、cal̲por で指定したメッセージ領域をメッセージバッファとして使うことになる。このため、
fwd̲por の実行後は、回送されたランデブの成立前であっても、fwd̲por のpk̲rmsg で示されるメッセージ領域の内容を変更することが可能になる。
fwd̲por で指定したメッセージのサイズ（fwd̲porのpk̲rmsg->rmsgsz）が、
cal̲por を実行した側で確保しているメッセージ領域の大きさ（cal̲porのmaxrmsz）よりも大きい場合は、cal̲por の maxrmsz の大きさまでのメッセージがコピーされ、ランデブの回送は行われるが、fwd̲por に対しては
E̲AROVR のエラーが返るものとする。
タスク独立部から fwd̲por, rpl̲por を発行した場合には E̲CTX のエラーになるが、ディスパッチ遅延中（割込み禁止中）のタスクから fwd̲por,rpl̲por を発行することは可能である。この機能は、fwd̲por や rpl̲por と不可分に何らかの処理を行う場合に利用できる。
fwd̲por により、ランデブ終了待ち状態であったタスクAがランデブ成立
待ちの状態に戻った場合、次にランデブが成立するまでのタイムアウトは、
常に永久待ち(TMO̲FEVR) として扱われるものとする。これは、タスクAが cal̲por でタイムアウト指定を行っていた場合でも同様である。

第三部 ITRON 2

379

fwd̲por
ユーザタスクX

拡張SVC

XXX̲YYY

cal̲por

SVC
受付
ポート

サーバ分配タスク
acp̲por
前処理...

fwd̲por fwd̲por fwd̲por
処理A 処理B 処理C
サーバ用 サーバ用 サーバ用 ...
ポート ポート ポート
acp̲por acp̲por acp̲por

処理A
サーバ
タスク

処理B
サーバ
タスク

処理C
サーバ
タスク

rpl̲por rpl̲por rpl̲por...

＊太枠内はポート（ランデブエントリ）を表わす。
＊
は待ちを表わす。
＊fwd̲por の代りに cal̲por を使うことも可能であり、その場合はランデブがネストすることになる。しかし、処理A〜C のサーバタ
スクの処理終了後にそのままユーザタスクX の実行を再開して良け＝桝ｾ枠内はポート（ランデブエントリ）を表わす。
＊
は待ちを表わす。
＊ の代り［図3.36］fwd̲porを使ったサーバタスクの動作イメージ【補足事項】
fwd̲por で送信するメッセージを cal̲por で指定したメッセージ領域にコピーするのは、次のような理由による。
一般に、fwd̲por を実行するのはサーバ分配タスクなどであるため、メッセージ領域を再利用して別の回送などを行いたいことが多い。ところが、
fwd̲por を実行した側では、回送したランデブがいつ成立するか分からない。
そのため、fwd̲por で指定したメッセージを別の場所にコピーせず、ポイン
タだけを保持する仕様にしておくと、fwd̲por を実行した側では、pk̲rmsg

第三章 ITRON 2拡張機能

380

fwd̲porで指定したメッセージ領域がいつ再利用（変更）可能になるかということが分からない。したがって、fwd̲por を実行したサーバ分配タスクは、別の要求の回送を行うことができない。
一方、cal̲por を実行したタスクはランデブ終了まで待ち状態なので、
cal̲por のメッセージ領域をランデブ成立までのバッファとして使っても、特に問題はない。
メッセージのサイズが大きすぎる場合、cal̲por → acp̲por, rpl̲por →cal̲por では、いずれもメッセージを受け取る側に E̲AROVR のエラーを返している。しかし、fwd̲por では、メッセージを送る側（fwd̲porを実行した側）が E̲AROVR のエラーとなることもある。このような仕様になっているのは、fwd̲por で送られるメッセージが、一旦他の領域にコピーされるためである。
fwd̲por により回送されたランデブが成立するまでのタイムアウトを常に永久待ちとして扱うのは、次のような理由による。cal̲por で指定するタ
イムアウトは、最初にランデブが成立するまでのタイムアウトであり、ランデブ終了までのタイムアウトを意味しているわけではない。ランデブ終了までのタイムアウトは、常に永久待ちとして扱われている。fwd̲por 実行
後のランデブ成立待ちの時間は、cal̲por を実行したタスクから見た場合、ランデブが成立するまでの時間ではなく、ランデブが終了するまでの時間に含めて考えるのが自然である。したがって、fwd̲por 実行後のランデブ成立待ちのタイムアウトも、永久待ちとして扱う。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦porid≦0、-4≦ctskid≦0）

E̲PAR

一般的なパラメータエラー（rmsgsz＜4,

E̲ILADR

不正アドレス（pk̲rmsgが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（poridのポートが存在しない、ctskidのタスクが存在しない）

E̲DMT

タスクがDORMANTである（ctskidのタスクがDORMANT）

E̲NORDV

現在ランデブ中のタスクではない（ctskidで現在ランデブ
中ではないタスクを指定）

第三部 ITRON 2

fwd̲porE̲CTX

コンテキストエラー（タスク独立部から発行）

E̲AROVR

用意した領域のサイズが小さすぎる

381（fwd̲porのpk̲rmsg中のrmsgsz＞cal̲porのmaxrmsz）
E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でporid＜(-4)）※ ctskid に関しては E̲OACV をチェックしない

第三章 ITRON 2拡張機能

382

rpl̲por

ポートに対するランデブの返答
rpl̲porrpl̲por:

Reply Port for Rendesvous【パラメータ】
ctskidCallTaskIdentifierpk̲rmsg

RendezvousMessagePacket メッセージアドレス

呼び出しタスクID【リターンパラメータ】
なし【解説】
ランデブ中のポートに対して返答を返し、ランデブを終了する。
このシステムコールを発行したタスク（タスクX）は、あるポート（ポートA）において ctskid で示されるタスク（タスクY）のランデブ呼び出しを受け付け、現在ランデブ中の状態でなければならない。その状態でこのシス
テムコールを実行すると、ポートAにおけるタスクXとタスクYとのランデブ状態が解除され、ランデブ終了待ち状態にあった呼出側タスクYを実行可能状態に移す。
このシステムコールを使ってランデブを終了する時、受付側タスクXから呼出側タスクYに対してメッセージを送ることができる。rpl̲por のpk̲rmsg のパラメータでメッセージの先頭アドレスを指定することにより、
そのメッセージが cal̲por の pk̲rmsg のパラメータで指定した領域にコピーされる。メッセージの形式はcal̲por で指定したものと同じである。
タスク独立部から fwd̲por, rpl̲por を発行した場合には E̲CTX のエラーになるが、ディスパッチ遅延中（割込み禁止中）のタスクから fwd̲por,rpl̲por を発行することは可能である。この機能は、fwd̲por や rpl̲por と不可分に何らかの処理を行う場合に利用できる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦ctskid≦0）

E̲PAR

一般的なパラメータエラー（rmsgsz＜4）

第三部 ITRON 2

rpl̲por

383

E̲ILADR

不正アドレス（pk̲rmsgが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（ctskidのタスクが存在し
ない）

E̲DMT

タスクがDORMANTである（ctskidのタスクがDORMANT）

E̲NORDV

現在ランデブ中のタスクではない（ctskidで現在ランデブ
中ではないタスクを指定）

E̲CTX

コンテキストエラー（タスク独立部から発行）※ ctskid に関しては E̲OACV をチェックしない

第三章 ITRON 2拡張機能

384

por̲sts

ポート状態を参照する
por̲stspor̲sts:

Get Port Status【パラメータ】
porid

PortIdentifier

ポートID

pk̲pors

Packet of PortStatus

ポート状態を返すパケットの先頭アドレス【リターンパラメータ】
なし【解説】
porid で示されたポートの状態を読み出し、その結果を pk̲pors 以下の領域に返す。
pk̲pors に返される情報としては、次のようなものがある。
poratr/* ポート属性 */wtskid/* 呼出側待ち行列先頭のタスクID */atskid/* 受付側待ち行列先頭のタスクID */wtskid には、呼出側待ち行列の先頭のタスクのIDが返る。また、atskidには、受付側待ち行列の先頭のタスクのIDが返る。待ち行列にタスクが無い時には、それぞれ FALSE = 0 が返る。
このシステムコールでは、現在ランデブ中のタスクに関する情報を知ることはできない。wtskid, atskid で示されるタスクは、このポートに関して
まだランデブが成立していないタスクに限られる。現在ランデブ中のタス
クに関する情報を知りたい場合には、rdv̲sts を利用する。
対象となるポートは、既に生成されたものでなければならない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦porid≦0）

E̲ILADR

不正アドレス（pk̲porsが使用できない値）

第三部 ITRON 2

por̲sts

385

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（poridのポートが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でporid＜(-4)）

第三章 ITRON 2拡張機能

386

rdv̲sts

ランデブ状態を参照する
rdv̲sts
rdv̲sts:

Get Rendesvous Status【パラメータ】
porid

PortIdentifier

ポートID

ar̲rdvsArray of Rendesvous

ランデブ情報を返す配列へのポインタ

rvstartStartEntry of Rendesvous 状態参照を開始するランデブの順番

rvcnt

Count of Rendesvous

状態参照を行うランデブの個数【リターンパラメータ】
なし【解説】
porid で示されたポートでランデブ中のタスク（複数）に関する情報を読
み出し、その結果を ar̲rdvs 以下の領域に返す。
porid で起こっている個々のランデブに対しては、ランデブ成立順に順番が付いている。この順番は、このシステムコールでのみ意味を持つものである。rdv̲sts では、このうちの (rvstart+1) 番目から rvcnt 個のランデブに関する情報を配列にして、ar̲rdvs 以下の領域に返す。
個々のランデブに対して、このシステムコールにより得られる情報としては、次のようなものがある。
ctskid/* ランデブ中の呼出側タスクのID */atskid/* ランデブ中の受付側タスクのID */pk̲rmsg/* 返答時に渡されるメッセージを受取るアドレス */maxrmsz/* 受け取ることのできるメッセージの最大長 */※ pk̲rmsg は、rpl̲por で送られるメッセージを入れるアドレスである。したがって、一旦回送されたランデブの場合でも、
pk̲rmsg は fwd̲por で指定した値ではなく、cal̲por で指定した値になる。
一つのランデブに対して、これらの情報を含んだ一つの構造体が対応する。

第三部 ITRON 2

rdv̲sts387

その構造体を配列にしたもの（要素数はrvcnt個）が ar̲rdvs に返される。
成立中のランデブの個数が (rvstart+rvcnt) よりも少なかった場合には、
ar̲rdvs の配列のその次の要素の ctskid が FALSE = 0 となる。すなわち、ランデブ成立の個数を N とすると、ar̲rdvs[N-rvstart].ctskid が FALSE = 0 となる。この場合、ar̲rdvs の配列のそれ以下の要素に対する ctskid、すなわち
ar̲rdvs[N-rvstart+1].ctskid, ar̲rdvs[N-rvstart+2].ctskid, ... ar̲rdvs[rvcnt-1].ctskidの値は不定である。
一方、(rvstart+rvcnt) で指定した数よりも成立中のランデブの個数が多い
場合には、用意した配列の長さが短すぎるということであるから、
E̲AROVR のエラーとする。なお、エラー発生の場合にはできるだけ元の状態に戻すという一般原則とは異なり、このエラーの場合は、rvcnt 個までのランデブの情報が ar̲rdvs に返される。また、rvcnt が 0 の場合にも同様の動作をするが、この場合は、エラーコードが E̲AROVR かどうかによって、ランデブの個数が rvstart より多いかどうかをチェックすることになる。
rvcnt が 0 であれば、ar̲rdvsの指す領域の内容は変化しない。
rdv̲sts で得られる ctskid, atskid, pk̲rmsg の情報は、既にランデブ中のタスクに関する情報であり、ランデブ呼出待ちやランデブ受付待ち状態のタスクに関する情報ではない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦porid≦0）

E̲PAR

一般的なパラメータエラー（rvstart＜0、rvcnt＜0）

E̲ILADR

不正アドレス（ar̲rdvsが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（poridのポートが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でporid＜(-4)）

E̲AROVR

用意した領域のサイズが小さすぎる

第三章 ITRON 2拡張機能

388

強制例外機能第三部 ITRON 2

def̲fex389

タスク用強制例外ハンドラの定義
def̲fexdef̲fex:

Define ForcedExceptionHandler【パラメータ】
tskid

TaskIdentifier

タスクID

exhatrExceptionHandlerAttribute

例外ハンドラ属性

fexhdrForcedExceptionHandlerAddress

強制例外ハンドラ
アドレス【リターンパラメータ】
なし【解説】
タスクの強制例外ハンドラを定義する。
強制例外ハンドラでは、例外の原因となった情報を、スタックを通じて
例外コード exccd として受け取ることができる。強制例外ハンドラの場合の exccd の内容は、ras̲fex で指定した exccd である。
exhatrのサイズは標準で4バイトである。exhatrのフォーマットを［図3.37］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）は未使用であり、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16 のビット）はインプリメント依存の属性を表わし、下位ハーフワード（bit16〜
bit31 あるいは 2^15〜2^0 のビット）はシステム属性を表わす。

bit0
exhatrbit8
reserved(0)bit16インプリメント依存属性

bit31
システム属性［図3.37］exhatrのフォーマット

第三章 ITRON 2拡張機能

390

def̲fexexhatr のシステム属性の部分では、次のような指定を行うことができる。
exhatr : = (TA̲ASM‖TA̲HLNG)TA̲ASM

ハンドラがアセンブラで書かれている

TA̲HLNG

ハンドラが高級言語で書かれている

TA̲HLNG の指定を行った場合には、ハンドラ起動時に直接 fexhdr のア
ドレスにジャンプするのではなく、高級言語の環境設定プログラム（高級言語対応ルーチン）を通してから fexhdr のアドレスにジャンプする。
fexhdr = NADR (-1) の指定により、前に定義されていた強制例外ハンドラの定義が解除され、未定義の状態になる。ただし、前に定義されていた強制例外ハンドラの定義解除を行わずに、直接新しいハンドラを定義しても、エラーにはならない。また、もともとハンドラが定義されていない状態（定義が解除された状態）で、fexhdr=NADR の指定による定義解除の操作を行っても、エラーにはならない。後者の場合、このシステムコールは正常終了するが、強制例外ハンドラは未定義のままである。
tskid = TSK̲SELF により、自タスクのハンドラを指定する。また、tskid= TSK̲CMN によりタスク間で共通の強制例外ハンドラを指定する。タスク
実行中に強制例外が発生した場合には、OSはタスク固有の例外ハンドラが定義してあるかどうかを調べ、定義してあればそれを実行する。定義してなければ、次にタスク間共通の強制例外ハンドラが定義してあるかどうかを調べ、定義してあればそれを実行する。
強制例外ハンドラは、強制例外を受けたタスク（ras̲fexの対象タスク）の一部として、強制例外を受けたタスクの実行モード（リング、レベル）と同じ実行モード（リング、レベル）で実行される。強制例外ハンドラの実
行モード（リング、レベル）は、強制例外を起こしたタスク（ras̲fexを実行
したタスク）の実行モード（リング、レベル）には関係しない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦tskid≦-2、タスク独立部の発行でtskid=0）

第三部 ITRON 2

def̲fex

391

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在しない）

E̲RSATR

予約属性（exhatrが不正）

E̲ILADR

不正アドレス（fexhdrが奇数、あるいは使用できない値）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でtskid＜(-4)）

第三章 ITRON 2拡張機能

392

ras̲fex

他タスクに対する強制例外の発生
ras̲fexras̲fex:

Raise ForcedException【パラメータ】
tskid

TaskIdentifier

強制例外発生タスクID

exccd

ExceptionCode

例外コード【リターンパラメータ】
なし【解説】
他タスクに対して強制例外を発生する。
ras̲fex では、tskid として自タスクを指定することはできない。自タスクを指定した場合には、E̲SELF のエラーとなる。
強制例外では、待ち状態や強制待ち状態（SUSPEND状態）の解除は行わない。ras̲fex の対象タスクが待ち状態であった場合、強制例外ハンドラが起動されるのは、待ち状態が解除された後になる。待ち状態を強制的に解除して強制例外ハンドラを起動する必要がある場合には、ras̲fex と rel̲wai
や frsm̲tsk を併用する必要がある。
ras̲fex による複数の強制例外起動要求のキューイングは行わない。すな
わち、強制例外ハンドラの起動前に、同じタスクを対象とした ras̲fex が複数回発行されても、強制例外ハンドラは1回しか起動されない。ただし、この場合は、各 ras̲fex で指定された exccd の論理和がとられていき、pk̲excの exccd ではこの論理和の値が返る。したがって、exccd をビット対応で使うことにより、疑似的に複数の要求を区別することができる。たとえば、
例外コードとしての情報が1ビットで良ければ、32種類の独立した要求を区別することができる。起動された強制例外ハンドラでは、exccd を見て複数の起動要求があるかどうかを判断し、内部の処理を振り分ければ良い。
強制例外ハンドラの起動時には、次の強制例外ハンドラ起動に備えて強制例外要求 epndptn がクリアされるが、同様に、それまで論理和をとっていた例外コード exccd も0 にクリアされる。
（強制例外ハンドラ中でpk̲exc の中の exccd を参照した場合には、0 ではなく、クリア直前の値が返る。
）
第三部 ITRON 2

ras̲fex

393【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦tskid≦-1、タスク独立部の発行でtskid=0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（tskidのタスクが存在し
ない）

E̲DMT

タスクがDORMANTである（tskidのタスクがDORMANT）

E̲SELF

自タスク、自プロセスの指定（tskidが自タスク、タスク部
や準タスク部の発行で tskid = 0）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でtskid＜(-4)）

第三章 ITRON 2拡張機能

394

ローカルメモリプール管理機能

ここでは、タスクがローカルに使用するローカルメモリブロックのためのローカルメモリプールについて説明を行う。ローカルメモリプール管理のシステムコールは、基本機能のメモリプール管理（共有メモリプール管理）のシステムコールとほぼ同じになっている。ただし、ローカルメモリプ
ールの場合は、MMUのページング機能を生かすため、ブロックサイズの値に制限を設けることがある。
ローカルメモリプールのオブジェクト名称は lmp、またローカルメモリ
ブロックの名称は lbl となる。いずれも、共有メモリプールや共有メモリブ
ロックの名称の最初に ' l ' を付けたものになっている。
1タスクのみ、あるいは1つの論理空間のみが使用するローカルメモリプ
ールというのはあまり意味がないので、ローカルメモリプールであっても、ローカルメモリプール自体は複数のタスクや論理空間から共用されるものと考える。すなわち、一つのローカルメモリプールから得られたいくつかのローカルメモリブロックが、複数の論理空間に分かれて使用される可能性がある。ローカルメモリプールであっても、それがどの論理空間に属するものかをあらかじめ指定しておく必要はない。インプリメント上は、ローカルメモリプール生成時に物理メモリの確保のみを行い、メモリブロッ
ク獲得時に、要求タスクの論理空間のページテーブルを操作して、獲得したメモリブロックを要求タスクの論理空間に割り付けるということになる。
メモリプールからメモリを確保する際には、タスクがローカルで使用するローカルメモリか、タスク間で共有する共有メモリかによって、システ
ムコールが分かれることになる。この区別は、non-MMU 版ではインプリメ
ント上の意味を持たず、プログラミング作法としての意味だけになるが、MMU 版への移行をスムーズにするために役立つ。
ローカルメモリプールには、共有メモリプールと同様に、固定長メモリ
プールと可変長メモリプールがある。両者はローカルメモリプールの属性として区別される。

第三部 ITRON 2

cre̲lmp

395

ローカルメモリプールの生成
cre̲lmpcre̲lmp:

Create LocalMemoryPool【パラメータ】
lmpid

LocalMemoryPoolIdentifier ローカルメモリプールID

lmpatrLocalMemoryPoolAttribute ローカルメモリプール属性

lmpsz

LocalMemoryPoolSize

ローカルメモリプール全体のサイズ

blksz

MemoryBlockSize

メモリブロック基本サイズ【リターンパラメータ】
なし【解説】
cre̲lmp では、lmpid で指定された ID 番号を持つローカルメモリプールを生成する。次に、生成されたローカルメモリプールに対して管理ブロッ
クを割り付ける。
ローカルメモリプールの生成時には、lmpatr によって、固定長ローカル
メモリプール / 可変長ローカルメモリプールの区別を指定する。
ローカルメモリプール全体の大きさは、lmpsz によって指定する。ロー
カルメモリプール生成に必要なメモリ領域の確保は、システム生成時などに行われる。
可変長のローカルメモリプールの場合、blksz により、メモリ獲得、解放の最小単位が決められる。固定長のローカルメモリプールであれば、blkszの大きさでのメモリ獲得、解放しかできない。
ID 番号が (-4)〜0 のローカルメモリプールは生成できない。また、負のID 番号のローカルメモリプールは、システム用のものである。
lmpatrのサイズは標準で4バイトである。lmpatrのフォーマットを［図3.38］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）はユーザ属性を表わし、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16の ビ ッ ト ）は イ ン プ リ メ ン ト 依 存 の 属 性 を 表 わ し 、 下 位 ハ ー フ ワ ー ド（bit16〜bit31 あるいは 2^15〜2^0 のビット）はシステム属性を表わす。ユー

第三章 ITRON 2拡張機能

396

cre̲lmpbit0
lmpatr

bit8
ユーザ属性

bit16

インプリメント依存属性

bit31
システム属性［図3.38］lmpatrのフォーマット

ザは、ローカルメモリプールに関する情報を入れておくために、lmpatr の最上位バイトを自由に使用することができる。
cre̲lmp で指定した lmpatr は、lmp̲sts により読み出すことができる。
lmpatr のシステム属性の部分では、次のような指定を行うことができる。
lmpatr : = (TA̲TFIFO‖TA̲TPRI) ｜ (TA̲FIRST‖TA̲CNT)｜ (TA̲VAR‖TA̲FIX)TA̲TFIFO

待ちタスクのキューイングは FIFOTA̲TPRI

待ちタスクのキューイングは優先度順

TA̲FIRST

行列先頭のタスクを優先扱い

TA̲CNT

要求数の少ないタスクを優先扱い

TA̲VAR

可変長メモリブロック用のローカルメモリプール

TA̲FIX

固定長メモリブロック用のローカルメモリプール

TA̲TPRI, TA̲TFIFO の属性により、タスクがメモリ獲得の待ち行列に並ぶ際の並び方を指定することができる。属性が TA̲TFIFO であればタスクの待ち行列は FIFO となり、属性がTA̲TPRI であればタスクの待ち行列はタスクの優先度順となる。
さらに、TA̲CNT と TA̲FIRST の属性指定により、要求メモリ数の少ないタスクを優先扱いにするか、メモリ待ち行列先頭のタスクを優先扱いにするかが指定できる。TA̲CNT の属性を指定した場合には、要求メモリ数によって、行列途中のタスクから先に待ち解除になる場合がある。例えば、ある可変長ローカルメモリプールに対して要求ブロック数=5 のタスク A と要求ブロック数=1 のタスクBがこの順で待っており、rel̲lbl により空きブ
ロックの数が1になった場合、行列先頭にあるタスクA は要求ブロック数が多いので、行列の後にあるタスクB の方が先にメモリを獲得する。

第三部 ITRON 2

cre̲lmp

397

一方、TA̲FIRST の属性を指定した場合には、要求ブロック数にかかわらず、必ず行列先頭のタスクからメモリが割り当てられる。これは、要求ブロック数よりも優先度を重視した考え方である。上の例では、rel̲lbl 実行後もタスクB は待ち解除にならず、さらに rel̲lbl が実行されて連続した空きブロ
ックの数が 5 以上になった時にvはじめてタスクA にメモリが割り当てられる。タスクB には、その後の rel̲lbl によってメモリが割り当てられる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足（管理ブロック用の領域が確保できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲NOMEM

メモリ不足（ローカルメモリプール用の領域が確保できない）※ E̲NOSMEMとE̲NOMEMとの厳密な区別はインプリメ
ント依存である。

E̲RSID

予約ID番号（-4≦lmpid≦0）

E̲RSATR

予約属性（lmpatrの下位3バイトが不正）E̲PAR一般的なパラメータエラー（lmpsz,blkszが不正）

E̲IDOVR

ID範囲外（lmpidがシステムで利用できる範囲を越えた）

E̲EXS

オブジェクトが既に存在している（同一ID番号のローカ
ルメモリプールが存在）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でlmpid＜(-4)）

第三章 ITRON 2拡張機能

398

del̲lmp

ローカルメモリプールを削除する
del̲lmpdel̲lmp:

Delete LocalMemoryPool【パラメータ】
lmpid

LocalMemoryPoolIdentifier ローカルメモリプールID【リターンパラメータ】
なし【解説】
lmpid で示されるローカルメモリプールを削除する。
このローカルメモリプールからメモリを獲得しているタスクに対しては、何の保証もしない。すべてのメモリブロックが返却されていなくても、このシステムコールは正常終了する。
このローカルメモリプールにおいてメモリ獲得を待っているタスクがある場合にも、本システムコールは正常終了するが、メモリ獲得を待っていたタスクにはエラー E̲DLT が返される。
本システムコール発行後は、そのID番号のローカルメモリプールを再び
新しく生成することができる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦lmpid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（lmpidのローカルメモリ
プールが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でlmpid＜(-4)）

第三部 ITRON 2

get̲lbl399

ローカルメモリブロックを獲得する
get̲lblget̲lbl:Get Local Memory Block【パラメータ】
lmpid

LocalMemoryPoolIdentifier ローカルメモリプールID

bcnt

ContinuousBlockCount

連続領域のブロック数

tmout

Timeout

タイムアウト指定【リターンパラメータ】
blk

BlockStartAddress

メモリブロックの先頭アドレス【解説】
lmpid で示されるローカルメモリプールから、ローカルメモリブロック（固定長 / 可変長）を獲得する。獲得したメモリブロックの先頭アドレスがblk に返される。
get̲lbl で獲得したメモリのゼロクリアは特に行われない。獲得されたメ
モリブロックの内容は不定である。
可変長ローカルメモリプールを対象とした場合は、このシステムコール
により、（cre̲lmpで指定したblksz）×bcntの大きさのローカルメモリブロッ
クが確保される。また、固定長ローカルメモリプールを対象とした場合は、
bcnt の指定は無視され、常に（cre̲lmp で指定した blksz）の大きさのローカ
ルメモリブロックが確保される。
指定したローカルメモリプールから、指定した大きさのメモリブロック
がすぐに確保できない場合には、タスクはそのローカルメモリプールのメモリ獲得待ち行列につながれ、確保できるようになるまで待つ。
tmout により待ち時間のタイムアウト指定を行うことができる。tmout としては、正の値のみを指定することができる。タイムアウト指定が行われた場合、メモリブロックを獲得できないまま tmout 時間が経過すると、タ
イムアウトエラー E̲TMOUT としてエラーリターンする。また、tmout として TMO̲POL を指定した場合は、メモリブロックが獲得できない場合でも即時にリターンする。この場合、メモリブロックが獲得できれば正常終了

第三章 ITRON 2拡張機能

400

get̲lblになり、メモリブロックが獲得できなければタイムアウトエラー
E̲TMOUT になる。さらに、tmout=TMO̲FEVR によりタイムアウト指定が行われないことを示す。この場合は条件が満足されるまで永久に待つ。
【エラーコード (ercd)】
E̲OK
E̲TNOSPT

正常終了
タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦lmpid≦0）

E̲PAR

一般的なパラメータエラー（bcnt≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILTIME

不正時間指定（tmout≦-2）

E̲NOEXS

オブジェクトが存在していない（lmpidのローカルメモリ
プールが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でlmpid＜(-4)）

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

E̲DLT

待ちオブジェクトが削除された（待ちの間に対象ローカル
メモリプールが削除）

E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第三部 ITRON 2

rel̲lbl

401

ローカルメモリブロックを返却する
rel̲lblrel̲lbl:Release Local Memory Block【パラメータ】
lmpid

LocalMemoryPoolIdentifier ローカルメモリプールID

blk

BlockStartAddress

メモリブロックの先頭アドレス【リターンパラメータ】
なし【解説】
blk で示されるメモリブロックを、lmpid で示されるローカルメモリプー
ルへ返却する。
メモリブロックの返却を行うローカルメモリプールは、メモリブロックの獲得を行ったローカルメモリプールと同じものでなければならない。メ
モリブロックを異なるローカルメモリプールへ返却していることが検出された場合には、E̲ILBLK のエラーとなる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦lmpid≦0）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（lmpidのローカルメモリ
プールが存在しない）

E̲ILBLK

不正メモリブロックの返却、操作

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でlmpid＜(-4)）

第三章 ITRON 2拡張機能

402

lmp̲sts

ローカルメモリプールの状態を参照する
lmp̲stslmp̲sts:

Get LocalMemoryPool Status【パラメータ】
lmpid

LocalMemoryPoolIdentifier

ローカルメモリプールID

pk̲lmps

Packet of LocalMemoryPoolStatus

ローカルメモリプール状態を返すパケットの先頭アドレス【リターンパラメータ】
なし【解説】
lmpid で示されたローカルメモリプールの状態を読み出し、その結果を
pk̲lmps 以下の領域に返す。
pk̲lmps に返される情報としては、次のようなものがある。
lmpatr/* ローカルメモリプール属性 */wtskid/* 待ち行列先頭のタスクID */frbcnt/* 空き領域全体のブロック数 */maxbcnt/* 最大の連続空き領域のブロック数 */lmpsz/* ローカルメモリプール全体のサイズ */blksz/* メモリブロックのサイズ */fragcnt/* 空きブロックのフラグメント数 */wtskid には、待ち行列の先頭のタスクのIDが返る。すなわち、属性がTA̲TFIFO であれば、現在このローカルメモリプールを待っているタスクのうち、最も早く待ち状態になったタスクのIDが返る。また、属性がTA̲TPRI であれば、現在このローカルメモリプールを待っているタスクのうち、最も優先度の高いタスクのIDが返る。
frbcnt はメモリの空き領域の合計ブロック数であり、maxbcnt は空き領域のうちで最大の連続領域のブロック数である。固定長ローカルメモリプー
ルの場合は、maxbcnt は意味を持たず、常に1が返される。また、lmpsz,

第三部 ITRON 2

lmp̲sts403

blksz には、cre̲lmp で指定した値がそのまま返される。
fragcnt は、メモリ空きブロックのフラグメント数（空きブロックがいく
つの連続領域に分かれているか）を示す情報である。この情報は、対象のローカルメモリプールからどの程度の大きさの連続ブロックが取れるかということを知るための目安になる。固定長ローカルメモリプールに対する
fragcnt の値としては、frbcnt と同じ値がセットされる。
対象となるローカルメモリプールは、既に生成されたものでなければならない。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦lmpid≦0）

E̲ILADR

不正アドレス（pk̲lmpsが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（lmpidのローカルメモリ
プールが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でlmpid＜(-4)）

第三章 ITRON 2拡張機能404lbl̲sts

ローカルメモリブロックの状態参照
lbl̲stslbl̲sts:

Get Local Memory Block Status【パラメータ】
blk

BlockStartAddress

ローカルメモリブロックの先頭アドレス【リターンパラメータ】
lmpid

LocalMemoryPoolIdentifier

ローカルメモリプールID

bcnt

ContinuousBlockCount

連続領域のブロック数【解説】
blk で示されるローカルメモリブロックの状態を参照する。具体的には、そのローカルメモリブロックの属するローカルメモリプールID lmpid と、
メモリブロックの大きさ（連続ブロック数）bcnt を返す。
固定長メモリプールから得られたメモリブロックに対して lbl̲sts が実行された場合には、bcnt として1が返る。
【エラーコード (ercd)】
E̲OK

正常終了

E̲ILBLK

不正メモリブロックの返却、操作

第三部 ITRON 2

405

資源管理サポート機能「資源管理サポート機能」では、資源操作と不可分にメモリの更新を行う。
ここで言うシステムコールの不可分性には、「A. 他のタスクに対する不可分性」と「B. 割込みハンドラに対する不可分性」とが考えられ、B.は A. よりも強い意味を持つ。A. は、資源管理サポート機能として当然必要な機能である。
ところが、B. を完全に保証しようとするとどうしても割込み禁止時間が長くなってしまうし、割込みハンドラから発行できるシステムコール自体もインプリメント依存となっている。また、資源管理サポート機能は、主に終了ハンドラとの不可分性を保つために導入された機能であり、割込み
ハンドラとの不可分性について強い要求があったわけではない。
そこで、「B. 割込みハンドラに対する不可分性」については、インプリメ
ント依存の扱いとする。割込みハンドラからのシステムコール発行を許す
オブジェクトであっても、割込みハンドラに対する uXXX̲YYY の不可分性は保証されない場合がある。もちろん、どのような場合に uXXX̲YYYの不可分性が確保できないかということについては、インプリメント毎に明らかにして頂く必要がある。

第三章 ITRON 2拡張機能

406

usig̲sem

セマフォに対する信号操作（メモリ更新有）usig̲sem:usig̲sem

Signal Semaphore with Memory Update【パラメータ】
semid

SemaphoreIdentifier

セマフォID

rcnt

ResourceCount

増カウント値p̲rcntPointer to ResourceCount

不可分のカウント値操作を行うメモリアドレス【リターンパラメータ】
なし【解説】
sig̲sem の処理を行い、それと不可分に、アドレス p̲rcnt で指定したメ
モリの内容（標準4バイト）からrcnt で指定したカウント数を減らす。
この機能は、ユーザレベルで資源割り当て状況を管理したい場合に使用する。usig̲sem の前後で割込み処理に入ったり、タスクが強制終了させられたりした場合でも、p̲rcnt の内容を見ることによって、usig̲sem の処理が終わったかどうかを知ることができる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦semid≦0）

E̲PAR

一般的なパラメータエラー（rcnt≦0）

E̲ILADR

不正アドレス（p̲rcntが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（semidのセマフォが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でsemid＜(-4)）

E̲QOVR

キューイングのオーバーフロー（semcntのオーバーフロー）第三部 ITRON 2

uwai̲sem407

セマフォに対する待ち操作（メモリ更新有）uwai̲sem:uwai̲sem

Wait on Semaphore with Memory Update【パラメータ】
semid

SemaphoreIdentifier

セマフォID

rcnt

ResourceCount

減カウント値

tmout

Timeout

タイムアウト指定p̲rcntPointer to ResourceCount

不可分のカウント値操作を行うメモリアドレス【リターンパラメータ】
なし【解説】
wai̲sem の処理を行い、それと不可分に、アドレス p̲rcnt で指定したメ
モリの内容（標準4バイト）に rcntで指定したカウント数を加える。資源獲
得待ち状態の間は、p̲rcnt の内容は変化しない。
この機能は、ユーザレベルで資源割り当て状況を管理したい場合に使用する。uwai̲sem の前後で割込み処理に入ったり、タスクが強制終了させられたりした場合でも、p̲rcnt の内容を見ることによって、uwai̲sem の資源獲得処理が終わったかどうかを知ることができる。
【エラーコード (ercd)】
E̲OK
E̲TNOSPT

正常終了
タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦semid≦0）

E̲PAR

一般的なパラメータエラー（rcnt≦0）

E̲ILADR

不正アドレス（p̲rcntが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILTIME

不正時間指定（tmout≦-2）

第三章 ITRON 2拡張機能

408

uwai̲semE̲NOEXS

オブジェクトが存在していない（semidのセマフォが存在しない）

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でsemid＜(-4)）

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

E̲DLT

待ちオブジェクトが削除された（待ちの間に対象セマフォ
が削除）

E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第三部 ITRON 2

usnd̲msg

409

メイルボックスへ送信する（メモリ更新有）usnd̲msg:

usnd̲msg

Send Message to Mailbox with Memory Update【パラメータ】
mbxid

MailboxIdentifier

メイルボックスID

ppk̲msg

Pointer to MessagePacket

送信メッセージの先頭アドレス
へのポインタ【リターンパラメータ】
なし【解説】
アドレス ppk̲msg の指す領域の内容をメッセージアドレスとして、
snd̲msg の処理を行い、それと不可分に、アドレス ppk̲msg の指す領域の内容を NADR (-1) とする。
この機能は、ユーザレベルで資源割り当て状況を管理したい場合に利用するものであり、メモリプールから獲得したメモリブロックをメッセージとして使用する場合に効果がある。usnd̲msg の前後で割込み処理に入った
り、タスクが強制終了させられたりした場合でも、ppk̲msg の内容を見ることによって、usnd̲msg の処理が終わったかどうかを知ることができる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦mbxid≦0）

E̲ILADR

不正アドレス（ppk̲msg、あるいはppk̲msgの内容が使用できない値）E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILMSG

不正メッセージ形式（msgtype≠0）

E̲NOEXS

オブジェクトが存在していない（mbxidのメイルボックスが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でmbxid＜(-4)）

第三章 ITRON 2拡張機能

410

urcv̲msg

メイルボックスから受信する（メモリ更新有）urcv̲msg:

urcv̲msg

Receive Message from Mailbox with Memory Update【パラメータ】
mbxid

MailboxIdentifier

メイルボックスID

tmout

Timeout

タイムアウト指定ppk̲msg

Pointer to MessagePacket

受信メッセージの先頭アドレス
へのポインタ【リターンパラメータ】
なし【解説】rcv̲msg の処理を行い、それと不可分に、受信したメッセージの先頭ア
ドレスを ppk̲msg の指す領域に設定する。メッセージ待ち状態の間は、
ppk̲msg の内容は変化しない。
この機能は、ユーザレベルで資源割り当て状況を管理したい場合に利用するものであり、メモリプールから獲得したメモリブロックをメッセージとして使用する場合に効果がある。urcv̲msg の前後で割込み処理に入った
り、タスクが強制終了させられたりした場合でも、ppk̲msg の内容を見ることによって、urcv̲msg の処理が終わったかどうかを知ることができる。
【エラーコード (ercd)】
E̲OK
E̲TNOSPT

正常終了
タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦mbxid≦0）

E̲ILADR

不正アドレス（ppk̲msgが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILTIME

不正時間指定（tmout≦-2）

第三部 ITRON 2

urcv̲msg
E̲NOEXS

411

オブジェクトが存在していない（mbxidのメイルボックスが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でmbxid＜(-4)）

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

E̲DLT

待ちオブジェクトが削除された（待ちの間に対象メイル
ボックスが削除）E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第三章 ITRON 2拡張機能

412

uget̲blk

uget̲lbl

共有メモリブロックを獲得する（メモリ更新有）uget̲blk

ローカルメモリブロックを獲得する（メモリ更新有）uget̲lbl

uget̲blk:

Get Shared Memory Block with Memory Update

uget̲lbl:

Get Local Memory Block with Memory Update【パラメータ】＜1＞mplid

MemoryPoolIdentifier

メモリプールID＜2＞lmpid

LocalMemoryPoolIdentifier ローカルメモリプールID

bcnt

ContinuousBlockCount

連続領域のブロック数

tmout

Timeout

タイムアウト指定p̲blk

Pointer to BlockStartAddress メモリブロックの先頭アドレス
へのポインタ［＜1＞uget̲blk のみ］［＜2＞uget̲lbl のみ］【リターンパラメータ】
なし【解説】get̲blk, get̲lbl の処理を行い、それと不可分に、獲得したメモリブロックの先頭アドレスをp̲blk の指す領域に設定する。メモリブロック獲得待ち状態の間は、p̲blk の内容は変化しない。
この機能は、ユーザタスク側で資源管理を行う場合に利用できる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSID

予約ID番号（-4≦mplid≦0、-4≦lmpid≦0）

第三部 ITRON 2

uget̲blk

uget̲lbl

413

E̲PAR

一般的なパラメータエラー（bcnt≦0）

E̲ILADR

不正アドレス（p̲blkが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

E̲ILTIME

不正時間指定（tmout≦-2）

E̲NOEXS

オブジェクトが存在していない（mplid,lmpidのメモリプー
ルが存在しない）E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタス
クからの発行でmplid,lmpid＜(-4)）

E̲CTX

コンテキストエラー（タスク独立部あるいはディスパッチ
遅延中のタスクから発行）

E̲DLT

待ちオブジェクトが削除された（待ちの間に対象メモリ
プールが削除）E̲TMOUT

タイムアウトE̲RLWAI

待ち状態強制解除（待ちの間にter̲tsk,rel̲waiを受け付け）

第三章 ITRON 2拡張機能

414

urel̲blkurel̲lbl

共有メモリブロックを返却する（メモリ更新有）urel̲blk

ローカルメモリブロックを返却する（メモリ更新有）urel̲lbl

urel̲blk:

Release Shared Memory Block with Memory Updateurel̲lbl:

Release Local Memory Block with Memory Update【パラメータ】＜1＞mplid

MemoryPoolIdentifier

メモリプールID＜2＞lmpid

LocalMemoryPoolIdentifier ローカルメモリプールIDp̲blk

Pointer to BlockStartAddress メモリブロックの先頭アドレス
へのポインタ［＜1＞urel̲blk のみ］［＜2＞urel̲lbl のみ］【リターンパラメータ】
なし【解説】p̲blk の指す領域の内容を返却すべきメモリブロックの先頭アドレスとして rel̲blk, rel̲lbl の処理を行い、それと不可分に、p̲blk の指す領域をNADR (-1) とする。メモリブロック未返却の間は、p̲blk の内容は変化しない。この機能は、ユーザタスク側で資源管理を行う場合に利用できる。
【エラーコード (ercd)】
E̲OK

正常終了

E̲RSID

予約ID番号（-4≦mplid≦0、-4≦lmpid≦0）

E̲ILADR

不正アドレス（p̲blkが使用できない値）

E̲IDOVR

ID範囲外（インプリメント依存）

第三部 ITRON 2

urel̲blk
E̲NOEXS

urel̲lbl

415

オブジェクトが存在していない（mplid,lmpidのメモリプー
ルが存在しない）E̲ILBLK

不正メモリブロックの返却、操作

E̲OACV

オブジェクトアクセス権違反（拡張SVC以外のユーザタ
スクからの発行でmplid,lmpid＜(-4)）

第三章 ITRON 2拡張機能

416

タイマハンドラ機能

第三部 ITRON 2

def̲cyc417

周期起動ハンドラを定義する
def̲cycdef̲cyc:

Define Cyclic Handler【パラメータ】
cyhno

CyclicHandlerNumber

周期起動ハンドラ指定番号

cyhatrCyclicHandlerAttribute

周期起動ハンドラ属性

cychdrCyclicHandlerAddress

周期起動ハンドラアドレス

cyhactCyclicHandlerActivation

周期起動ハンドラ活性状態

cytimeCycleTime

周期起動時間間隔【リターンパラメータ】
なし【解説】
周期起動ハンドラは、指定した時間間隔で動くタスク独立部のハンドラである。このシステムコールでは、周期起動ハンドラを定義する。
cyhno は複数の周期起動ハンドラを区別するための番号であり、act̲cyc,cyh̲sts 等で使用される。また、cychdr は周期起動ハンドラの先頭アドレス、
cytime は周期起動の時間間隔、cyhact は周期起動ハンドラの一時的な ON /OFF の選択（活性状態）を表わす。cyhact では、次のような値を指定する。
cyhact : = (TCY̲OFF‖TCY̲ON)TCY̲OFF

周期起動ハンドラは起動されない

TCY̲ON

周期起動ハンドラは起動される

cyhact = TCY̲OFF は周期起動ハンドラの一時的な中断を意味し、この間はハンドラが起動されない。
def̲cyc の実行により周期カウントがクリアされるため、def̲cyc を実行
してからちょうど指定周期経った後に、最初のハンドラ起動が起こることになる。
cyhatr のサイズは標準で4バイトである。cyhatrのフォーマットを［図3.39］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）

第三章 ITRON 2拡張機能

418

def̲cyc

bit0
cyhatrbit8
reserved(0)bit16インプリメント依存属性

bit31
システム属性［図3.39］cyhatrのフォーマット

は未使用であり、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16 のビット）はインプリメント依存の属性を表わし、下位ハーフワード（bit16〜bit31あるいは 2^15〜2^0 のビット）はシステム属性を表わす。
def̲cyc で指定した cyhatr は、cyh̲sts により読み出すことができる。
cyhatr のシステム属性の部分では、次のような指定を行うことができる。
cyhatr : = (TA̲ASM‖TA̲HLNG)TA̲ASM

ハンドラがアセンブラで書かれている

TA̲HLNG

ハンドラが高級言語で書かれている

TA̲HLNG の指定を行った場合には、ハンドラ起動時に直接 cychdr のア
ドレスにジャンプするのではなく、高級言語の環境設定プログラム（高級言語対応ルーチン）を通してから cychdr のアドレスにジャンプする。
なお、cyhatr では、def̲cyc 実行後に変更されない静的な情報を扱う。これに対して、cyhact では動的な情報を扱うという点が異なっている。
cychdr=NADR (-1) の指定により、前に定義されていた周期起動ハンドラの定義が解除され、未定義の状態になる。ただし、前に定義されていた周期起動ハンドラの定義解除を行わずに、直接新しいハンドラを定義しても、エラーにはならない。また、もともとハンドラが定義されていない状態（定義が解除された状態）で、cychdr=NADR の指定による定義解除の操作を行っても、エラーにはならない。後者の場合、このシステムコールは正常終了するが、周期起動ハンドラは未定義のままである。
def̲cyc では回数の指定が無いので、act̲cyc によって cyhact を TCY̲OFFにするか、ハンドラを定義解除（あるいは同じcyhnoに対して別の周期起動
ハンドラを定義）するまで周期起動が繰り返される。
周期起動ハンドラでのレジスタ退避、復帰はユーザの責任である。
周期起動ハンドラやアラームハンドラをタスク独立部と考えているのは、

第三部 ITRON 2

def̲cyc419

周期起動ハンドラやアラームハンドラの定義が有効な間に 、def̲cyc,def̲alm を発行したタスクが終了、削除される可能性があるためである。
周期起動ハンドラはオブジェクトではないため、IDではなく、cyhno により複数ハンドラの区別を行っている。
【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSMD

予約モード、予約オプション（cyhactが不正）

E̲RSATR

予約属性（cyhatrが不正）

E̲PAR

一般的なパラメータエラー（cyhnoが不正）

E̲ILADR

不正アドレス（cychdrが奇数、あるいは使用できない値）

E̲ILTIME

不正時間指定（cytimeが不正）

第三章 ITRON 2拡張機能

420

act̲cyc

周期起動ハンドラの活性制御を行う
act̲cycact̲cyc:

Activate Cyclic Handler【パラメータ】
cyhno

CyclicHandlerNumber

周期起動ハンドラ指定番号

cyhactCyclicHandlerActivation

周期起動ハンドラ活性状態【リターンパラメータ】
なし【解説】
周期起動ハンドラの活性状態 (cyhact) を変更する。
cyhact の具体的な指定方法は次のようになる。
cyhact : = (TCY̲OFF‖TCY̲ON) ｜ [TCY̲INI]TCY̲OFF

周期起動ハンドラは起動されない

TCY̲ON

周期起動ハンドラは起動される

TCY̲INI

周期起動ハンドラのカウントが初期化される

cyhact = TCY̲ON の指定を行うと、周期の経過とは独立に活性状態を
ON にする。OS内部の動作としては、活性状態が OFF の間も指定周期のカ
ウントを行っているため、act̲cyc を実行してから最初に周期起動ハンドラが実行されるまでの時間は一定しない。
一方、cyhact = (TCY̲ON ¦ TCY̲INI) の指定を行うと、活性状態を ON にするのと同時に周期カウントをクリアする。したがって、act̲cyc を実行してからちょうど指定周期経った後に、最初のハンドラ起動が起こることになる。
cyhact = (TCY̲OFF ¦ TCY̲INI) の指定も可能である。この機能を使うことは少ないかもしれないが、次にTCY̲ON を指定してから周期起動ハンドラが起動されるまでのタイミングを調整するために利用できる可能性がある。

第三部 ITRON 2

act̲cyc421【エラーコード (ercd)】
E̲OK

正常終了

E̲RSMD

予約モード、予約オプション（cyhactが不正）

E̲PAR

一般的なパラメータエラー（インプリメント依存）

E̲NOEXS

オブジェクトが存在していない（cyhnoの周期起動ハンド
ラが存在しない）

第三章 ITRON 2拡張機能

422

cyh̲sts

周期起動ハンドラの状態を参照する
cyh̲stscyh̲sts:

Get Cyclic Handler Status【パラメータ】
cyhno

CyclicHandlerNumber

周期起動ハンドラ指定番号pk̲cyhs

Packet of CyclicHandlerStatus

周期起動ハンドラ状態を返す
パケットの先頭アドレス【リターンパラメータ】
なし【解説】
cyhno で指定した周期起動ハンドラの状態を参照し、その結果を pk̲cyhs
以下の領域に返す。
pk̲cyhs に返される情報としては、次のようなものがある。
cyhatr/* 周期起動ハンドラ属性 */cyhact/* 周期起動ハンドラ活性状態 */cytime/* 周期 */

lftime/* 次の周期起動ハンドラ起動までの残り時間 */このうち、cyhact では、TCY̲ON と TCY̲OFF の区別のみが返され、
TCY̲INI の情報が返ることはない。
【エラーコード (ercd)】
E̲OK 正常終了
E̲PAR

一般的なパラメータエラー（インプリメント依存）

E̲ILADR

不正アドレス（pk̲cyhsが使用できない値）

E̲NOEXS

オブジェクトが存在していない（cyhnoの周期起動ハンド
ラが存在しない）

第三部 ITRON 2

423

def̲alm

アラームハンドラを定義する
def̲almdef̲alm:

Define Alarm Handler【パラメータ】
alhno

AlarmHandlerNumber

アラームハンドラ指定番号

alhatrAlarmHandlerAttribute

アラームハンドラ属性

almhdrAlarmHandlerAddress

アラームハンドラアドレス

utimeUpper AlarmTime

ハンドラ起動時刻（上位）

ltime

Lower AlarmTime

ハンドラ起動時刻（下位）tmmodeTimeMode

初期時刻指定モード【リターンパラメータ】
なし【解説】
アラームハンドラ（指定時刻起動ハンドラ）は、指定した時刻に起動されるタスク独立部のハンドラである。このシステムコールでは、指定時刻起動ハンドラを定義する。
alhno は複数のアラームハンドラを区別するための番号である。almadr は起動されるアラームハンドラの先頭アドレスを表わす。
alhatr のサイズは標準で4バイトである。alhatr のフォーマットを［図3.40］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）は未使用であり、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16 のビット）はインプリメント依存の属性を表わし、下位ハーフワード（bit16〜bit31あるいは 2^15〜2^0 のビット）はシステム属性を表わす。

bit0
alhatrbit8
reserved(0)bit16インプリメント依存属性

bit31
システム属性［図3.40］alhatrのフォーマット

第三章 ITRON 2拡張機能

424

def̲almdef̲alh で指定した alhatr は、alh̲sts により読み出すことができる。
alhatr のシステム属性の部分では、次のような指定を行うことができる。
alhatr : = (TA̲ASM‖TA̲HLNG)TA̲ASM

ハンドラがアセンブラで書かれている

TA̲HLNG

ハンドラが高級言語で書かれている

TA̲HLNG の指定を行った場合には、ハンドラ起動時に直接 almhdr のア
ドレスにジャンプするのではなく、高級言語の環境設定プログラム（高級言語対応ルーチン）を通してから almhdr のアドレスにジャンプする。
utime, ltime により、アラームハンドラの起動時刻を指定する。標準では、
utime 16 ビット、ltime 32 ビットの計 48 ビットを使って時刻の指定が行われる。tmmode により、次のようにして絶対時刻と相対時刻の指定が可能である。
tmmode : = (TTM̲ABS‖TTM̲REL)
TTM̲ABS

絶対時刻での指定

TTM̲REL

相対時刻での指定

指定した時刻が過去の時刻であった場合には、エラー E̲ILTIME となる。
def̲alm で相対時刻を指定し、時刻 0 を指定した場合には、即座にアラー
ムハンドラが呼び出される。また、def̲alm で指定した時刻が現在時刻に近い場合の def̲alm の動作は、即座にアラームハンドラを起動するか（同時刻あるいはわずかに未来の時刻を指定した場合）、def̲alm が E̲ILTIME のエラーになるか（わずかに過去の時刻を指定した場合）のどちらかである。
def̲alm が正常終了した場合には、必ずアラームハンドラが起動されなければならない。
almhdr = NADR (-1) の指定により、前に定義されていたアラームハンド
ラの定義が解除され、未定義の状態になる。ただし、前に定義されていた
アラームハンドラの定義解除を行わずに、直接新しいハンドラを定義しても、エラーにはならない。また、もともとハンドラが定義されていない状態（定義が解除された状態）で、almhdr = NADR の指定による定義解除の操作を行っても、エラーにはならない。後者の場合、このシステムコールは正常終了するが、アラームハンドラは未定義のままである。
アラームハンドラでのレジスタ退避、復帰はユーザの責任である。

第三部 ITRON 2

def̲alm425

アラームハンドラの中で rel̲wai を発行することにより、タイムアウトに似た機能を実現することができる。
アラームハンドラが起動された後は、自動的にアラームハンドラの定義が解除されるものとする。定義の解除はアラームハンドラ起動時に行われ、アラームハンドラの実行中は、既に定義が解除された状態になっている。
たとえば、アラームハンドラの中で自分自身の alhno に対して alh̲sts を実行すると、E̲NOEXS のエラーになる。
（自分自身の alhno は、アラームハン
ドラ起動時のパラメータとして知ることができる。）【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存である。

E̲TNOSPT

タイマ関係の未サポート機能（タイマが利用できない）※ このエラーが発生するかどうかはインプリメント依存である。

E̲RSMD

予約モード、予約オプション（tmmodeが不正）

E̲RSATR

予約属性（alhatrが不正）

E̲PAR

一般的なパラメータエラー（alhnoが不正）

E̲ILADR

不正アドレス（almhdrが奇数、あるいは使用できない値）

E̲ILTIME

不正時間指定（utime,ltimeが不正）

第三章 ITRON 2拡張機能

426

alh̲sts

アラームハンドラの状態を参照する
alh̲stsalh̲sts:

Get Alarm Handler Status【パラメータ】
alhno

AlarmHandlerNumber

アラームハンドラ指定番号pk̲alhs

Packet of AlarmHandlerStatus

アラームハンドラ状態を返す
パケットの先頭アドレス【リターンパラメータ】
なし【解説】alhno で指定したアラームハンドラの状態を参照し、その結果を pk̲alhs
以下の領域に返す。
pk̲alhs に返される情報としては、次のようなものがある。
alhatr/* アラームハンドラ属性 */lfutime/* アラームハンドラ起動までの残り時間（上位） */lfltime/* アラームハンドラ起動までの残り時間（下位） */【エラーコード (ercd)】
E̲OK

正常終了

E̲PAR

一般的なパラメータエラー（インプリメント依存）

E̲ILADR

不正アドレス（pk̲alhsが使用できない値）

E̲NOEXS

オブジェクトが存在していない（alhnoのアラームハンドラが存在しない）

第三部 ITRON 2

ret̲tmr

427

タイマハンドラから復帰する
ret̲tmrret̲tmr:

Return from Timer Handler【パラメータ】
なし【リターンパラメータ】※ システムコールを発行したコンテキストには戻らない【解説】
タイマハンドラ（周期起動ハンドラ、アラームハンドラ）から戻る。
ret̲int 同様、ディスパッチの起こる可能性がある。
同じタスク独立部からの戻りシステムコールである ret̲int と統合しないのは、ハンドラ起動時にOSが介入するかどうかという点で違いがあるためである。すなわち、ret̲int がハードウエアで直接起動されたタスク独立のハンドラからのリターンを表わすのに対して、ret̲tmr はOSから起動された
タスク独立のハンドラからリターンを表す。
【エラーコード】※ 次のようなエラーを検出する可能性があるが、エラーを検出した場合でも、システムコールを発行したコンテキストには戻らない。したがって、
システムコールのリターンパラメータとして直接エラーコードを返すことはできない。万一エラーを検出した場合には、メッセージバッファへのロギングや、コンソールへのエラーメッセージの表示などを行うのが望ましいが、詳細な動作はインプリメント依存となる。
E̲CTX

コンテキストエラー（タスク部、準タスク部から実行）

第三章 ITRON 2拡張機能

第三部 第四章

ITRON2システム操作機能

この章では、ITRON2のシステム操作機能に関する説明を行う。
システム操作機能とは、実行環境の整備などのために必要となる機能である。システム操作機能は、一般ユーザには非公開とするのが普通である。

430

拡張SVCサポート機能

第三部 ITRON 2

sdef̲ext

sdef̲cex

sdef̲sex

431

拡張SVC用終了ハンドラの定義
sdef̲ext

拡張SVC用CPU例外ハンドラの定義
sdef̲cex

拡張SVC用システムコール例外ハンドラの定義
sdef̲sex
sdef̲ext:

Define ExitHandler for SVC

sdef̲cex:

Define CPUExceptionHandler for SVC

sdef̲sex:

Define SystemcallExceptionHandler for SVC【パラメータ】s̲fncdSVCFunctionCode

拡張SVC機能コード

exhatrExceptionHandlerAttribute

例外ハンドラ属性＜1＞exthdr

ExitHandlerAddress

終了ハンドラアドレス＜2＞cexhdr

CPUExceptionHandlerAddress

CPU例外ハンドラ
アドレス＜3＞sexhdr

SystemCallExceptionHandlerAddress システムコール例外
ハンドラアドレス［＜1＞sdef̲ext のみ］［＜2＞sdef̲cex のみ］［＜3＞sdef̲sex のみ］【リターンパラメータ】
なし【解説】
拡張SVCハンドラに対する例外ハンドラや終了ハンドラを定義する。
拡張SVCハンドラに対する例外ハンドラや終了ハンドラの実行モード（リング、レベル）は、元の拡張SVCハンドラの実行モード（リング、レベル）と同じである。

第四章 ITRON 2 システム操作機能

432

sdef̲ext

sdef̲cex

sdef̲sex

exhatrのサイズは標準で4バイトである。exhatrのフォーマットを［図3.41］に示す。このうち、最上位バイト（bit0〜bit7 あるいは 2^31〜2^24 のビット）は未使用であり、第二上位バイト（bit8〜bit15 あるいは 2^23〜2^16 のビット）はインプリメント依存の属性を表わし、下位ハーフワード（bit16〜bit31あるいは 2^15〜2^0 のビット）はシステム属性を表わす。
exhatr のシステム属性の部分では、次のような指定を行うことができる。
exhatr : = (TA̲ASM‖TA̲HLNG)TA̲ASM

ハンドラがアセンブラで書かれている

TA̲HLNG

ハンドラが高級言語で書かれている

TA̲HLNG の指定を行った場合には、ハンドラ起動時に直接 exthdr,
cexhdr, sexhdr のアドレスにジャンプするのではなく、高級言語の環境設定
プログラム（高級言語対応ルーチン）を通してから exthdr, cexhdr, sexhdrのア
ドレスにジャンプする。
exthdr, cexhdr, sexhdr = NADR (-1) の指定により、前に定義されていた例
外（終了）ハンドラの定義が解除され、未定義の状態になる。ただし、前に定義されていた例外（終了）ハンドラの定義解除を行わずに、直接新しいハンドラを定義しても、エラーにはならない。また、もともとハンドラが定義されていない状態（定義が解除された状態）で、exthdr, cexhdr, sexhdr =NADR の指定による定義解除の操作を行っても、エラーにはならない。後者の場合、このシステムコールは正常終了するが、例外（終了）ハンドラは
未定義のままである。
s̲fncd=TFN̲CMN により、拡張SVCハンドラに対する共通の例外ハンドラが定義される。

bit0
exhatrbit8
reserved(0)bit16インプリメント依存属性

bit31
システム属性［図3.41］exhatrのフォーマット

第三部 ITRON 2

sdef̲ext

sdef̲cex

sdef̲sex433【補足事項】
拡張SVCハンドラに対する例外ハンドラを機能コード別に定義しているのは、メーカー提供の拡張SVCハンドラ（入出力、ファイルなどを含む）
に対する例外ハンドラと、ユーザ定義の拡張SVCハンドラに対する例外ハンドラを分けて定義できるようにするためである。拡張SVCハンドラに対する例外ハンドラを一つにまとめてしまった場合、例えば、入出力管理の拡張SVCで例外ハンドラを使ってしまうと、ユーザ定義の拡張SVCでは例
外ハンドラが使えない、ということになってしまう。
【エラーコード (ercd)】
E̲OK

正常終了

E̲NOSMEM

システムメモリ不足※ このエラーが発生するかどうかはインプリメント依存
である。

E̲PAR

一般的なパラメータエラー（インプリメント依存）

E̲ILFN

不正機能コード番号（s̲fncd=0, s̲fncd≦-2）

E̲NOEXS

オブジェクトが存在していない（s̲fncdの拡張SVCが未定義）

E̲RSATR

予約属性（exhatrが不正）

E̲ILADR

不正アドレス（exthdr, cexhdr, sexhdrが奇数、あるいは使用できない値）

第四章 ITRON 2 システム操作機能

第三部 第五章

ITRON2標準インタフェース

この章では、ITRON2のシステムコールインタフェースのうち、プロセッサに依存しない部分の仕様に関する説明を行う。具体的には、機能コード、エラーコード、言語Cインタフェースなどの説明がここに含まれる。

436

タスク管理情報とID番号

ITRON2で使用するID番号のサイズは、アセンブラや言語Cのインタフェー ス 上 は 4 バ イ ト（ 3 2 ビ ッ ト ）と す る 。 I D 番 号 を 4 バ イ ト と し た の は 、
ITRON2が32ビットのプロセッサを対象としていること、将来の拡張性を考慮したこと等による。ただし、ユーザが利用できるID番号の範囲をターゲット毎に制限することは構わないので、一般には、ID番号の内部表現は2バ
イトで済む。ID番号の内部表現を2バイトとした場合、リターンパラメータとしてID番号を返すシステムコール（get̲tidなど）では、2バイトのID番号を符号拡張して4バイトとすれば良い。
ITRON2では、タスクID番号の割り当て方法について、次のような約束を設けておく。
［最小値］〜(-5) --(-4)〜(-1)

システムタスク用ID番号---

reserved
0 以外にも reserved が欲しいため。

0---

1〜［最大値］ ---自タスクを表わす(TSK̲SELF)
ユーザタスク用ID番号※［最小値］,［最大値］の具体的な値は、インプリメン
トやターゲットに依存して決まる。普通は、OSのジェ
ネレーション時にこれらの値を指定する。
ITRON2のタスク優先度は2バイトで表現され、(-16)〜255［ (-4)〜0 は reserved］

を使用可能な優先度とする。数字の小さい方が高い優先度になる。(-16)〜
255 という値は、(-16)〜15 の32個の優先度を別扱いして高速化することを考慮したものであるが、実際のインプリメント方法はもちろん自由である。
また、タスク優先度の割り当て方法についても、タスクIDと同じように
次のような約束を設けておく。

第三部 ITRON 2

437(-32768)〜(-17)---

reserved(-16)〜(-5)---

システム用優先度(-4)〜(-1)---

reserved0---

自タスクの優先度を表わす

1〜255

---

ユーザ用優先度

256〜32767---

reserved

0 以外にも reserved が欲しいため。

ここで、優先度もタスクIDと同様に負の値がシステム用となっているが、これは一応の目安（運用方法のガイドライン）に過ぎないものである。ユー
ザが負の優先度を使っても構わない。優先度は、ID番号と違って大小関係に意味を持っており、ユーザタスクの優先度が、必ずしもシステムタスクの優先度より低いとは限らないためである。一般のユーザタスクは正の優先度を使用し、入出力タスク、ファイル管理タスク、デバッガタスク等のシステムタスクは絶対値の小さい負の優先度を使用し、ユーザタスクで特にシステムタスクよりも優先度を高くしたいものは絶対値の大きな負の優先度を使用する、という優先度の割当て方を行えば良い。

第五章 ITRON 2 標準インタフェース

438

アセンブラインタフェース

アセンブラインタフェース共通原則
・ITRON2のアセンブラインタフェースは、原則としてレジスタを使ったイ
ンタフェースとし、パケットを使用しない。これは、以下の理由による。
― コンパイラやOSのインプリメントでの最適化に成功すれば、最高の性能が出せる可能性を持っている。
― パケット領域の確保が要らないので、使いやすい場合が多い。
― ITRONのシステムコールのパラメータはあまり多くないため、パラメ
ータをレジスタに置いても、レジスタが足りなくなるということはない。
cre̲tsk, cyc̲wup, def̲cyc など一部のシステムコールでは、パラメータが多いものもあるが、パラメータが多いといっても 5〜6個なので、レジスタ渡しの仕様とする。ただし、XXX̲sts, get̲ver のシステムコー¦
ルで返す情報については、すべてパケットを使用するものとする。
・レジスタの使い方は、できる限り次の原則に合わせる。
R0:

機能コード(fncd)、エラーコード(ercd =)R1:

ID番号(XXXid)、識別コード(XXXno,intvec) など

R2:

パケットアドレス(pk̲XXX)、属性(XXXatr)、ビットパターン(XXXptn)、コード(XXXcd) など

R3:

ハンドラアドレス(XXXhdr)、スタートアドレス、タイムアウト(tmout) など

ここで、R0, R1, R2... は一般的な汎用レジスタの名称を表わしたものであるが、当然のことながら、正確な名称や数はプロセッサによって異なっている。最もパラメータの多いシステムコール(cyc̲wup, def̲alm) では、
パラメータを置くレジスタとして、R0〜R6 まで使用することがある。
システムコール実行後のフラグ変化
システムコール実行後のフラグの値については、特に規定せず、不定値になるものとする。

第三部 ITRON 2

439
ITRON1では、エラーの有無に応じてゼロフラグのセットを行うことを推奨していた。しかし、OSがせっかくフラグをセットしても、必ずしも参照されるとは限らないし、言語Cを使えば全く不要な機能である。また、フラグセットのためのオーバーヘッドも無視できない。
プロセッサによっては、OSで特にフラグの操作をしない場合に、トラッ
プ命令のハードウエア処理によって自然にフラグを保存できることがある。
しかし、将来システムコールをハードウエア化することがあれば、フラグのセットを行う方が望ましいということになる可能性もあり、必ずしもフラグを保存するように規定するのが良いとは言えない。そこで、現段階では、システムコール実行後のフラグ値に関して規定を設けないことにする。
機能コード
ITRONでは、システムコールの種類を区別する番号として、「機能コード」を用いている。機能コードをあるレジスタ（通常はR0）に置き、それからト
ラップ命令を発行することによって、対応するシステムコールが実行される。
ITRON2およびμITRONにおける機能コードの割当方針を以下に示す。
【機能コードの割当て方針】― TRONの全体方針に合わせて、機能コードの標準値には負の値を使用している。
― 8の倍数に対するアライメントや、共通機能(cre̲XXX, XXX̲sts,
uXXX̲YYY, sXXX̲YYY など) に対する共通ビットパターンを考慮した。
― 必ずしも、仕様書の出現順に機能コードを割り当てるわけではない。
ただし、仕様書の機能グループ毎には、まとまった範囲の機能コードを割当てるようにする。
（強制例外などシステムコール数が少ないものについては、他のグループにまとめられる場合もある。
）
また、仕様書での説明の順序は、機能コードとは直接関係しない。
― μITRONで使用する iXXX̲YYY, pXXX̲YYY は、それぞれ一つのグループを作るので、一般のシステムコールと混在させるのではなく、番号を飛ばした別グループとしている。
ITRON2の機能コードは、μITRONに適用することも可能である。実際の機能コードの値（ITRON2とμITRONで共通）を、巻末のレファレンスに示す。

第五章 ITRON 2 標準インタフェース

440

言語Cインタフェースとニモニック

μITRONやITRON2では、ニモニックの付与に関して、以下のような共通原則を設けている。
・データタイプの名称
データタイプの名称としては、構造体も含めてすべて大文字を使用する。
ポインタのデータタイプは 〜P の名称とする。
構造体については、T̲〜 の名称とする。
・定数のニモニック
エラーコードは E̲〜 の名称とする。
例外クラスの番号(0〜31)は EC̲〜 の名称、例外クラスのマスク（2のべき乗を使ったビットパターン）は ECM̲〜 の名称とする。
オブジェクト、ハンドラの属性は、TA̲〜 の名称とする。
特定のシステムコールやパラメータでのみ使用するモードなどの名称は、Txy̲〜 とする。xy の部分は、システムコールやパラメータに応じて変化する。
・パラメータ、リターンパラメータの名称
パラメータ、リターンパラメータの名称に関しては、次のような原則を設ける。
p̲

リターンパラメータを入れる領域へのポインタ

pk̲

パケットアドレス

〜cd

〜コード

ar̲

配列へのポインタ

i〜

初期値

〜sz

サイズ

・パラメータ名が同じであれば、原則として同じデータタイプを持つようにする。

第三部 ITRON 2

441
また、ITRON2の言語Cインタフェースでは、次のような共通原則を設けている。
・ITRON2では、プログラムの書きやすさを考えて、できるだけパケットを使用しない方針とする。これは、アセンブラインタフェースをレジスタ主導型とすることにも対応している。
・関数としての戻り値は、原則としてシステムコールのエラーコード(ercd)となる。正常終了の場合には ercd は 0 となり、エラーが発生した場合には ercd は負となる。
・エラーコード以外のリターンパラメータ(XXX)を返す場合には、リター
ンパラメータを入れる領域へのポインタ(p̲XXX)をパラメータとして指定する。
・リターンパラメータへのポインタは、パラメータよりも先に置くものとする。
アセンブラインタフェースでの指定がポインタ（パケットアドレス）になっているものについても、意味的にリターンパラメータに相当するものであれば、この原則が適用される（XXX̲sts など）。
また、uXXX̲YYY のシステムコールで使用するメモリ更新用のポインタについても、この原則が適用される。そのため、例えば、rcv̲msg とurcv̲msg や get̲blk と uget̲blk の言語Cインタフェースが全く同じになる。
・リターンパラメータへのポインタ、およびパラメータの中での順番は、原則としてアセンブラインターフェースのレジスタ番号(R0, R1...) の順番と同じになるようにする。
ただし、次の原則が適用される場合には、そちらの方を優先する。
― tmout は最後のパラメータとする。(wai̲flg, cal̲por, rcv̲mbf)― メッセージのアドレスとサイズを両方指定する場合は、アドレスを先に、サイズを後にする。(snd̲mbf, rcv̲mbf)
ITRON2で使用する標準データタイプ、および言語Cインタフェースの標
準仕様を巻末のレファレンスに示す。また、システムで共通に使用する定数のニモニックや標準値、それらの共通定数の適用されるシステムコール、および構造体のパケット形式を巻末のレファレンスに示す。

第五章 ITRON 2 標準インタフェース

442
ITRON1において、タスクや例外ハンドラをすべて高級言語で書こうとした場合には、OSを作る際に、特定の高級言語の実行環境（関数のパラメータの渡し方など）を仮定しておく必要があった。それと異なった環境をもつ高級言語（例えば他社製のCコンパイラ）を利用しようとすると、高級言語の関数名を直接 cre̲tsk や def̲extのパラメータとすることは難しくなる。
場合によっては、ユーザに高級言語のスタートアップ処理ルーチンを見せて、タスクやハンドラ毎に個別に対応してもらわなければならない。これに対する対策として、高級言語対応ルーチンが用意されていたが、あまり活用されていなかった。
そこで、ITRON2では、高級言語に対応するためにオプジェクト属性やハンドラ属性の機能を利用する方針とした。具体的には、タスクやハンドラの属性として、タスクやハンドラが高級言語で書かれているかアセンブラで書かれているかの区別を行う。後者であれば、タスクやハンドラをス
タートアドレスから直接起動するが、前者であれば、最初に高級言語のス
タートアップ処理ルーチン（高級言語対応ルーチン）を起動し、その中からユーザの定義したタスクスタートアドレスやハンドラアドレスに間接ジャンプすることになる。この場合、OSから見ると、タスクスタートアドレス
やハンドラアドレスは高級言語対応ルーチンに対するパラメータとなる。
こういった方法により、異なる言語環境にも容易に対応できるようにした。
また、ITRON2では、タスクやハンドラを言語Cの関数として書いた場合に、単なる関数のリターン（return や "}"）を行うだけでも、タスクを終了するシステムコールやハンドラから戻るシステムコールが自動的に実行されるものとしている。このため、最後の ext̲tsk や ret̲XXX を書き忘れたとしても、できるだけ正常な実行を続けることが可能になっている。インプリ
メント上は、高級言語対応ルーチン(h̲XXXhdr) において、高級言語で書かれたユーザ定義ハンドラ(XXXhdr) の呼び出しをサブルーチンジャンプとし、そこから戻ってきた後でret̲XXX や ext̲tsk を実行するようにすれば良い。
なお、アセンブラの場合はオーバーヘッドを避けることが重要なので、
ret̲XXX を発行するトラップ命令(TRAPA) の代わりにサブルーチンリター
ン命令(RTS) を書いたとしても、正常なリターンは行われない。

第三部 ITRON 2

443

エラーコードとシステムコール例外

ITRON2では、各システムコールで発生するエラーに対して、それを表わすニモニックとエラーコード値を標準化している。また、これらの標準は、μITRONとITRON2で共通化されている。
エラーコードの標準値は負の数になっており、その中に ercls（例外クラス）と errno の情報を含んでいる。例外クラスは、例外の重要度や分類を示すものである。ITRON2においては、システムコール例外の起動の有無を決めるために例外クラスが利用されている。
ITRON2で使用するエラーコードのフォーマットを［図3.42］に示す。
― excls (4≦excls≦31) により、発生するシステムコール例外の例外クラスを表わす。
― errno (1≦errno≦255) により、同じ例外クラスに属する複数のエラーを区別する。
― エラー発生の場合の ercd の値は (- (excls ≪ 8) - errno) によって表わされ、原則として ercd＜4＞のフォーマットを使用する。ただし、'≪' は左シフトである。

ercd＜1＞ 0

RETURN̲CODE

正常終了

ercd＜2＞ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

正常終了

ercd＜3＞ 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

ERRNO

エラー発生

ercd＜4＞ 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 EXCLS

ERRNO

エラー発生

＊EXCLSはexclsの1の補数、ERRNOはerrnoの2の補数である。

［図3.42］ITRON2におけるエラーコードのフォーマット

第五章 ITRON 2 標準インタフェース

444― excls が異なるのに errno が等しくなる組み合せが生じないようにする。
つまり、excls の部分が無くても、errno のみで ercd の識別を可能とする。（errno には、excls と独立にシーケンシャルな番号を与える。
）― ercd＜1＞のフォーマットは、μITRONでは使用していない。ITRON2
では、ファイル管理で ercd＜1＞のフォーマットを使用している。
― デバッガ等で ercd の値を直接見る場合に、errno の部分のみの値を知りたければ、ercd を1バイトの符号付きの数として扱えば良い。
― システムコール例外が発生するのは、ercd＜4＞の場合のみである。
― ret̲svc のパラメータで指定する s̲ercd も、同じフォーマットに従う。
すなわち、s̲ercd の excls 部分のフィールドで指定した値によって、拡張SVC終了時に起動されるシステムコール例外の例外クラスが決まる。
なお、システムコール例外を発生しない ercd＜3＞のフォーマットは、
ITRON2の場合、拡張SVCからの戻り値 (s̲ercd) としてのみ使用されている。
ITRON2およびμITRONで使用する例外クラス (excls) を、巻末のレファ
レンスに示す。
ret̲svc で指定した s̲ercd の excls が EC̲NONE の場合（EXCLSフィール
ドがすべて1の場合）には、s̲ercd全体の値が 0 でなくても、拡張SVCから戻る際のシステムコール例外は発生しない。すなわち、EC̲NONE の例外
クラスのエラー (-256≦s̲ercd≦-1) に対する emsptn は、clr̲ems 実行の有無にかかわらず、常にマスクされた状態となっている。また、ret̲svc で指定
した s̲ercd の excls が、EC̲TER, EC̲FEX, EC̲CEX など特別な意味をもった例外クラスであった場合にも、システムコール例外は発生しない。
拡張SVCから返されるエラーコード s̲ercd で示される例外クラスと、例
外マスクの値、システムコール例外の発生の有無との関係は、［表3.5］のようになる。
μITRONやITRON2では、エラーコードのニモニックの付与に関して、
以下のような共通原則を設けている。
― 汎用的に使用されるエラーは汎用的な名称とする。特殊な意味を持つ
エラーは、誤解が起きないように、特殊な意味を持つことが想像できるようにする。― 他のオブジェクトでも発生することが予想されるが、実際は一種類のオブジェクトにのみ関連して発生するエラーがある。

第三部 ITRON 2

445s̲ercd の例外クラス
EC̲NONEEC̲TEREC̲FEXEC̲CEXEC̲SYS

[0]
[1]
[2]
[3]
[4]

対応する例外マスク (emsptn) の意味
ECM̲NONEはクリア不可
ECM̲TERは終了例外に対するマスク
ECM̲FEXは強制例外に対するマスク
ECM̲CEXはCPU例外に対するマスク、セット不可
ECM̲SYSはシステムコール例外に対するマスク（EC̲SYSのシステムコール例外の場合に限り
タスク独立部に対する例外ハンドラを起動）

ret̲svc によるシステムコール例外
発生しない
発生しない
発生しない
発生しない
ECM̲SYSに依存して発生

EC̲NOMEM [5]EC̲RSV[6]
EC̲PAR[7]ECM̲NOMEMはシステムコール例外に対するマスク ECM̲NOMEMに依存して発生
ECM̲RSVはシステムコール例外に対するマスク
ECM̲RSVに依存して発生
ECM̲PARはシステムコール例外に対するマスク
ECM̲PARに依存して発生

EC̲FILE[20]

ECM̲FILEはシステムコール例外に対するマスク

ECM̲FILEに依存して発生[21]

システムコール例外に対するマスク

例外マスクに依存して発生（今後の拡張のために予約された例外クラス）[23]

システムコール例外に対するマスク

例外マスクに依存して発生[24]

システムコール例外に対するマスク

例外マスクに依存して発生（インプリメンタが自由に利用できる例外クラス）[27]

システムコール例外に対するマスク

例外マスクに依存して発生[28]

システムコール例外に対するマスク

例外マスクに依存して発生（ユーザが自由に利用できる例外クラス）[29]

システムコール例外に対するマスク

例外マスクに依存して発生

[30]
[31]

ECM̲ABOは終了ハンドラ実行中を示す
ECM̲SUSはサスペンド遅延要求を示す

発生しない
発生しない

＊EC̲SYSについてもシステムコール例外を発生可能としている。
この場合は、idef̲sexで定義されたタスク独立部に対する例外
ハンドラが起動される。
＊例外クラス 21〜23 は今後のために予約しておき、24〜27 をインプリメンタに解放する例外クラス、28〜29をユーザに解放する例外クラスとした。

［表3.5］拡張SVCから返されるエラーとシステムコール例外

第五章 ITRON 2 標準インタフェース

446
このような場合は、誤解を防ぐために、エラー名称にそのオブジェク
トの名称を含めるようにする。
例えば、ファイルのアクセス権違反を示すエラーは、メモリのアクセス権違反と区別するために 'F'の名称を含める。
― ITRON1で使っていたエラーコードとの連続性、整合性を考慮する。
―「不正エラー（意味的に間違った操作）」と「予約機能エラー（将来の機能追加によりエラーとならなくなるもの）」の区別がはっきりしている部分は、その区別を行う。
― 例外クラスについては、エラーの内容や意味だけではなく、そのエラーに対する対応方法（例えばシステムコール例外ハンドラを起動することに意味があるかどうか）まで考慮して分類を行う。
ITRON2およびμITRONで使用するエラーコードのニモニックとその標準値を、巻末のレファレンスに示す。
ITRON2において、インプリメント依存のエラーコード、およびユーザ
用（拡張SVC専用）のエラーコードとしては、次の値を使用する。
インプリメント依存 :errno = 225〜255, ERRNO = B'000XXXXX
ercd = B'1111111111111111111YYYYY000XXXXX
ユーザ用（拡張SVC用）:
errno = 193〜223, ERRNO = B'001XXXXX
ercd = B'1111111111111111111YYYYY001XXXXX
拡張SVC用として 193〜223 の errno を割当ててあるが、拡張SVCでは、
これ以外のエラーコード（1〜96の標準エラーコードを含む）を返しても構わない。193〜223 の番号の割当ては、拡張SVC用以外の目的ではこの番号を使わないという意味である。
個々のエラーに対応するエラークラス (ercls) については、エラーの種類や意味に応じて、0 または適当な値を入れる。
97〜128, 129〜192 の errno については、標準入出力機能、MMUサポート
機能、ファイル管理機能などのために予約されている。

第三部 ITRON 2

m

I

O
TR

N

第 四 部

レファレンス

I T

R

O

N

第四部 第一章

μITRON・ITRON2共通レファレンス

450

機能コード

【機能コードの範囲】
reserved:

H'fe00〜H'fe7f (-512)〜(-385)

128個

ファイル管理、デバイス管理:

H'fe80〜H'febf (-384)〜(-321)

64個

デバッグサポート:H'fec0〜H'feff(-320)〜(-257)

64個

システム構成用:H'ff00〜H'ff1f(-256)〜(-225)

32個(-224)〜(-5)

220個(-4)〜05個

標準システムコール（I/O,MMU含）: H'ff20〜H'fffb
reserved:

H'fffc〜H'0000

ユーザ用（拡張SVC）:

H'0001〜

1〜【機能コードの標準値】※ '-' は、予約または機能コード不要の可能性があるシステムコールである。
※ 'μ' は、ITRON2で使用せず、μITRONでのみ使用するシステムコールである。
※「システム構成用」の［公開］と［非公開］の区別は、厳密なものではない。

第四部 レファレンス

451

＋H'0

＋H'4

＋H'8

＋H'c

H'ff00システム構成用、インプリメント依存 [公開]

H'ff10システム構成用、インプリメント依存 [非公開]（タスク独立部専用システムコール iXXX̲YYY）
μi
μi
μi
μi μi μi
μi
μi μi
μi μi
snd
sus reirot chg- snd- snd sig set wup - rsm tmb
mbf
msg sem flg tsk
tsk
tsk wai
rdq pri（ポーリング機能 pXXX̲YYY）（タスク付属メッセージ XXX̲tmb）（割込み）
H'ff30μp μp μp μp μp μp μ μc
μ
μ μ
μ
μ
rcv get rcv get rcv req pol pol
rcv tmb ret def- snd
tmb lbl mbf blk msg sem flg flg
tmb
tmb sts
rst rst
標準入出力管理
reserved
H'ff40
H'ff20

put
lin

get
lin

put
chr

get
chr

-

-

cio
ctl

-

-

-

-

-

-

-

-

-

H'ff50

H'ff80

H'ff90H'ffa0H'ffb0H'ffc0H'ffd0H'ffe0

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

MMUサポートH'ff60

H'ff70cio reqsts gioreserved- mov get set spc
sha trf
map set del cre
map map sts prt map map
dat dat dat sts
ランデブ（ポート）ローカルメモリプール管理uu
rel rel get get lmp lbl del cre fwd rpl
acp cal por rdv
lbl lbl lbl lbl
sts sts lmp lmp
sts sts
メッセージバッファ
拡張SVCサポート
-s
-s -s
s
- snd
- rcv mbf
del creend ret def def
sts
fex ext
例外管理、強制例外
iii- ems def def def ras
set clr refend ret def def
ems ems exd
sts ext sex cex fex
fex ext
時間管理
タイマハンドラ- act ret cyh alh def def can cyc
dly get set
cyc tmr sts sts cyc alm cyc wup
tsk tim tim
メモリプール管理
割込み管理
u
u
μ μ
μ
rel rel get get mpl blk del cre dis ena ret ret iXX chg
blk blk blk blk sts sts
int int
wup int sts ims
メイルボックス
セマフォ
u
u
u
u
sng
del cre sig sig wai wai sem snd snd rcv rcv mbx sts
msg msg msg msg sts
イベントフラグ
タスク付属同期μc
f
set clr wai wai flg
del cre can wup slp wai rsm rsm
sts
wup
タスク管理

- rot
rel
chg abo ter getwai
rdq pritid
システム管理、拡張SVCサポート
H'fff0s
get
def def- ret psw ver
svc sts
svc svc
ras
ext

del crespc spc
del

cre

s
s
def def
sex cexdef def
sex cex
-

-

-

def
int

del

cre

-

sus

sta

exd ext tsk
sts
reserved

hdr
sts

del

cre

-

-

=

=

=

-

第一章 μITRON・ITRON2共通レファレンス

=

452

例外クラス

excls:EC̲NONE0/* システムコール例外を発生しないクラス */EC̲TER1/* 終了要求クラス */EC̲FEX

2/* 強制例外クラス */EC̲CEX

3/* CPU例外クラス */EC̲SYS

4/* システムエラー例外クラス */EC̲NOMEM

5/* メモリ不足エラー例外クラス */EC̲RSV6/* 予約機能エラー例外クラス */EC̲PAR7/* パラメータエラー例外クラス */EC̲OBJ

8/* 不正オブジェクト指定例外クラス */EC̲ACV9/* アクセス権違反例外クラス */EC̲CTX10/* コンテキストエラー例外クラス */EC̲EXEC

11/* 実行時エラー例外クラス */EC̲EXCMP

12/* 実行終了時エラー例外クラス */EC̲RLWAI

13/* 待ち状態強制解除例外クラス */EC̲RSLT14/* 処理実行結果を示す例外クラス */

EC̲IO

15

/* 標準入出力(GIO/CIO)関連例外クラス */EC̲MMU16/* MMUサポート関連例外クラス */EC̲xxxx17/* 予備（ネットワーク関連など）*/

EC̲xxxx18/* 予備（ネットワーク関連など）*/

EC̲xxxx

19/* 予備（ネットワーク関連など）*/

EC̲FILE20/* ファイル管理関連例外クラス（デバイス管理を含む）*/

第四部 レファレンス

453

eclsptn:/* excls を2のべき乗のパターンにしたもの *//* 以下、'≫' は論理右シフトを示す */ECM̲TER((UW) H'80000000 ≫ EC̲TER)/* H'40000000 */ECM̲FEX((UW) H'80000000 ≫ EC̲FEX)/* H'20000000 */ECM̲CEX((UW) H'80000000 ≫ EC̲CEX)/* H'10000000 */ECM̲SYS((UW) H'80000000 ≫ EC̲SYS)/* H'08000000 */ECM̲NOMEM ((UW) H'80000000 ≫ EC̲NOMEM) /* H'04000000 */ECM̲RSV((UW) H'80000000 ≫ EC̲RSV)/* H'02000000 */ECM̲PAR((UW) H'80000000 ≫ EC̲PAR)/* H'01000000 */ECM̲OBJ((UW) H'80000000 ≫ EC̲OBJ)/* H'00800000 */ECM̲ACV((UW) H'80000000 ≫ EC̲ACV)/* H'00400000 */ECM̲CTX((UW) H'80000000 ≫ EC̲CTX)/* H'00200000 */ECM̲EXEC((UW) H'80000000 ≫ EC̲EXEC)/* H'00100000 */ECM̲EXCMP ((UW) H'80000000 ≫ EC̲EXCMP)/* H'00080000 */ECM̲RLWAI ((UW) H'80000000 ≫ EC̲RLWAI)/* H'00040000 */ECM̲RSLT((UW) H'80000000 ≫ EC̲RSLT)/* H'00020000 */ECM̲IO((UW) H'80000000 ≫ EC̲IO)/* H'00010000 */ECM̲MMU((UW) H'80000000 ≫ EC̲MMU)/* H'00008000 */ECM̲FILE((UW) H'80000000 ≫ EC̲FILE)/* H'00000800 */ECM̲SEX

H'08000000 = ECM̲SYS

ECM̲ABO

H'00000002

ECM̲SUS

H'00000001※ EC̲NONE に対応する eclsptn (ECM̲NONE = H'80000000) は、必要性が無いので用意されていない。

第一章 μITRON・ITRON2共通レファレンス

454

エラーコード●システムコール例外を発生しないクラス (EC̲NONE=0)
ニモニック
E̲OK

ercd

説明

0

正常終了

errno: 0

ITRON1の TE̲OK に対応する。
●終了要求に対応する例外クラス (EC̲TER=1)

errno: 1※ 通常のシステムコールでこのエラーコードを返すことはない。終了要求の発生などによって、拡張SVCハンドラから強制的に戻るような場合にこのエラーコードを返すことがある。
※ 拡張SVCハンドラからこのエラーコードを返した場合、ECM̲TER がクリアされていても、このエラーコードに対するシステムコール例外は発生しない。
ニモニック

ercd

説明

E̲TER

-H'101

終了要求発生(-(EC̲TER≪8)-1)●CPU例外に対応する例外クラス (EC̲CEX=3)

errno: 3※ 通常のシステムコールでこのエラーコードを返すことはない。CPU例外
ハンドラが未定義の状態でCPU例外が発生し、終了ハンドラが起動された場合に、終了ハンドラへのパラメータがこのエラーコードになる。
※ 拡張SVCハンドラからこのエラーコードを返した場合でも、このエラー
コードに対するシステムコール例外は発生しない。
ニモニック

ercd

説明

E̲CEX

-H'303

CPU例外発生(-(EC̲CEX≪8)-3)

第四部 レファレンス

455●システムエラー例外クラス (EC̲SYS=4)
ニモニック

ercd

説明

E̲SYS

-H'405

システムエラー(-(EC̲SYS≪8)-5)

errno: 5〜8

原因不明のエラーであり、システム全体に影響するエラーである。
ITRON2では、このエラーが発生した場合に限り、idef̲sex で定義されたタスク独立部に対する例外ハンドラが起動される。
ITRON1の TE̲SYSに対応する。

●メモリ不足エラー例外クラス (EC̲NOMEM=5)
ニモニック
E̲NOSMEM

ercd

説明-H'509システムメモリ不足(-(EC̲NOMEM≪8)-9)errno: 9〜16

オブジェクト管理ブロック確保時などの一般的なメモリ不足(no system memory)
ITRON1の TE̲MEM に対応する。

E̲NOMEM-H'50a(-(EC̲NOMEM≪8)-10)

メモリ不足
ユーザスタック領域、メモリプール領域、
メッセージバッファ領域獲得時のメモリ不足(no memory)
ITRON1の TE̲MEM, (TE̲MPLSZ) に対応する。

●予約機能エラー例外クラス (EC̲RSV=6)
ニモニック
E̲NOSPT

ercd-H'611(-(EC̲RSV≪8)-17)

errno: 17〜32

説明
未サポート機能
システムコールの一部の機能がサポートされていない場合に、その機能を指定すると、E̲RSMD, E̲RSATR またはE̲NOSPTのエラーを発生する。

第一章 μITRON・ITRON2共通レファレンス

456
E̲RSMD, E̲RSATR に該当しない場合には、E̲NOSPT のエラーとなる。
μITRONの場合、システムコールの一部の機能のみをインプリメントすることも許しているため、このエラーを発生する可能性がある。μITRONやデバッ
グ関連機能のようにインプリメント依
存部分の多いシステムコールにおいて、仕様書で定義できないようなエラーを検出した場合に、このエラーを返す。
ITRON2の基本機能や拡張機能では、
E̲RSFN, E̲RSMD, E̲RSATR などのエラーコードを使えば十分なので、原則として E̲NOSPT のエラーを返す必要はない。
E̲INOSPT-H'612(-(EC̲RSV≪8)-18)
E̲TNOSPT-H'613(-(EC̲RSV≪8)-19)
E̲RSFN-H'614(-(EC̲RSV≪8)-20)

ITRON/FILEでの未サポート機能
ITRON1の E̲INOSPT に対応する。
タイマ関係の未サポート機能
ITRON1の TE̲NOTMR に対応する。
予約機能コード番号
予約機能コード（未定義の機能コード）を指定してシステムコールを実行しようとした場合に、このエラーが発生する。未定義の拡張SVCハンドラを実行しようとした場合（機能コードが正の場合）にも、このエラーが発生する。
なお、このエラーはシステムコール全体がサポートされていない場合に発生するエラーである。システムコールの一部の機能のみがサポートされていない場合には、E̲RSMD, E̲RSATR,E̲NOSPTなどのエラーを発生する。
ITRON1の TE̲UDF に対応する。

第四部 レファレンス

457
E̲RSSFN-H'615

予約サブ機能コード/予約デバイス番号(-(EC̲RSV≪8)-21)
E̲RSMD-H'616(-(EC̲RSV≪8)-22)E̲RSID-H'617(-(EC̲RSV≪8)-23)

予約モード、予約オプション
ITRON1の TE̲OPT に対応する。
予約ID番号
0〜(-4)のID番号を指定した場合などに発生する。
ITRON1の TE̲IDOVR に対応する。

E̲RSATR-H'618(-(EC̲RSV≪8)-24)

予約属性
未定義のシステム用オブジェクト属性を指定した場合などに発生する。

E̲XNOSPT-H'619(-(EC̲RSV≪8)-25)

このコンテキストでの実行はサポートしていない。
インプリメントの都合により、タスク
独立部（割込みハンドラ等）から発行できなくなっているシステムコールを発行しようとした場合に、このエラーが返る。各システムコールにおいて、
E̲XNOSPT が発生するかどうかはイン
プリメント依存である。
なお、自タスクを待ち状態にするようなシステムコールがタスク独立部から発行できないのは、インプリメントの都合ではなく意味的な問題なので、このエラーではなく E̲CTX が返る。

●パラメータエラー例外クラス (EC̲PAR=7)

errno: 33〜48※ ほぼ静的にチェック可能なエラーである。
ニモニック

ercd

E̲PAR

-H'721(-(EC̲PAR≪8)-33)

説明
一般的なパラメータエラー
ITRON1の TE̲PAR、(TE̲MPLSZ)に対応する。

第一章 μITRON・ITRON2共通レファレンス

458
E̲ILADR-H'722(-(EC̲PAR≪8)-34)

不正アドレス
スタートアドレスが奇数の場合など
ITRON1の TE̲MA,TE̲SA,TE̲PA に対応する。

E̲IDOVR-H'723(-(EC̲PAR≪8)-35)

ID範囲外
オブジェクトを指定するIDが、システムで利用できる最大値を越えた。
なお、E̲IDOVR や E̲RSID は、ID 番号を持つオブジェクトに対してのみ発生
するエラーであるため、割込みベクトル
番号やハンドラ番号に関してはこれらのエラーが発生することはない。割込み
ベクトル番号やハンドラ番号に関して、範囲外や予約番号といった静的なエラーが検出された場合には、E̲PARのエラーを返す。
ITRON1の TE̲IDOVR（オブジェクト生
成時）に対応する。

E̲SZOVR-H'724

パラメータのサイズが制限を越えた。

(-(EC̲PAR≪8)-36)
E̲PPRI-H'725

不正プロセス優先度(-(EC̲PAR≪8)-37)
E̲TPRI-H'726(-(EC̲PAR≪8)-38)
E̲ILTIME-H'727(-(EC̲PAR≪8)-39)

不正タスク優先度
ITRON1の TE̲TPRI に対応する。
不正時間指定ltime, utime, cytime, tmout の指定におけるエラーITRON1の TE̲PAR に対応する。

E̲ILFN-H'728(-(EC̲PAR≪8)-40)

不正機能コード番号
拡張SVC定義などの際に発生する
ITRON1の TE̲SVC に対応する。

第四部 レファレンス

459
E̲ILMSG-H'729(-(EC̲PAR≪8)-41)

不正メッセージ形式
メッセージの msgtype が 0 でない場合などに発生する。

E̲VECN-H'72a(-(EC̲PAR≪8)-42)
E̲IMS-H'72b(-(EC̲PAR≪8)-43)
E̲ILSFN-H'72c(-(EC̲PAR≪8)-44)

不正ベクトル番号
ITRON1の TE̲VECN に対応する。
不正IMASKITRON1の TE̲IPRI に対応する。
不正サブ機能コード番号
拡張SVC定義の際のサブ機能コードが不正であった場合に発生する。
なお、E̲ILSFN は定義時に、E̲RSSFN
は実行時に発生するエラーである。

●不正オブジェクト指定例外クラス (EC̲OBJ=8)

errno: 49〜64

ニモニック

ercd

説明

E̲SELF-H'831

自タスク、自プロセスの指定(-(EC̲OBJ≪8)-49)
E̲NOPRC-H'832ITRON1の TE̲SELF に対応する。
プロセスがまだ存在していない。

(-(EC̲OBJ≪8)-50)
E̲EXS-H'833(-(EC̲OBJ≪8)-51)
E̲NOEXS-H'834(-(EC̲OBJ≪8)-52)

オブジェクトが既に存在している
ITRON1の TE̲EXSに対応する。
オブジェクトが存在していない
sdef̲sexで指定した拡張SVCが未定義の場合なども含まれる。
なお、オブジェクトを操作する一般のシステムコールにおいて対象オブジェクトが存在していない時は、E̲NOEXS のエラーになる場合と E̲IDOVR のエラーになる場合とがある。E̲IDOVRとE̲NOEXS の違いは、E̲IDOVR が静的に検出可能なエラーであるのに対して、
E̲NOEXS は動的な検出を必要とするエ第一章 μITRON・ITRON2共通レファレンス

460
ラーであるという点である。ただし、利用可能な ID 番号の範囲にインプリメ
ント依存の点があるので、両者の厳密な区別もインプリメント依存である。
ITRON1の TE̲NOEXS に対応する。
E̲DMT-H'835

タスクがDORMANTである。

(-(EC̲OBJ≪8)-53)
E̲NODMTITRON1の TE̲DMT に対応する。

-H'836

タスクがDORMANTでない。

(-(EC̲OBJ≪8)-54)
E̲NOCYC

ITRON1の TE̲NODMT に対応する。

-H'837

タスクに対してcyc̲wupが発行されて(-(EC̲OBJ≪8)-55)

いない。
ITRON1の TE̲NOCYC に対応する。

E̲NOSUS-H'838

タスクがSUSPENDでない。

(-(EC̲OBJ≪8)-56)
E̲ILSEMITRON1の TE̲NOSUS に対応する。

-H'839

セマフォに対する不正操作(-(EC̲OBJ≪8)-57)E̲ILAKEY-H'83aセマフォアクセスキーが不正(-(EC̲OBJ≪8)-58)
E̲ILBLK-H'83b

不正メモリブロックの返却、操作(-(EC̲OBJ≪8)-59)
E̲NORDVITRON1の TE̲ILBLK に対応する。

-H'83c現在ランデブ中のタスクではない(-(EC̲OBJ≪8)-60)
E̲NOWAI-H'83e

タスクが待ち状態でない。

(-(EC̲OBJ≪8)-62)
E̲OBJ-H'83f

オブジェクト状態に関するその他のエラー(-(EC̲OBJ≪8)-63)●アクセス権違反例外クラス (EC̲ACV=9)※ Access Violation

errno: 65〜68※ オブジェクト、メモリのアクセス違反を含む。ファイルのアクセス違反は除く。
※ μITRONでは発生しない。

第四部 レファレンス

461
ニモニック

ercd

説明

E̲MACV-H'941(-(EC̲ACV≪8)-65)

メモリアクセス権違反
バスアクセスエラー等も含む。
ITRON1の TE̲ACCES に対応する。

E̲OACV-H'942(-(EC̲ACV≪8)-66)

オブジェクトやハンドラのアクセス権違反
ユーザタスク（拡張SVCハンドラ内を除く）がシステムオブジェクトを操作した
場合など

E̲ULEVV-H'943(-(EC̲ACV≪8)-67)

ユーザレベル違反●コンテキストエラー例外クラス (EC̲CTX=10)
ニモニック

ercd

E̲CTX
-H'a45(-(EC̲CTX≪8)-69)

errno: 69〜72

説明
コンテキストエラー
このシステムコールを発行できるコン
テキスト（タスク部/タスク独立部の区
別やハンドラ実行状態）にはないということを示すエラーである。自タスクを待ち状態にするシステムコールをタス
ク独立部から発行した場合のように、システムコールの発行コンテキストに関して意味的な間違いのある場合にE̲CTX のエラーが発生する。
ITRON2の場合、E̲CTX の発生条件にインプリメント依存性はなく、仕様書の各システムコールの説明の項に
E̲CTX の記述が無いシステムコール
では、このエラーが発生することはない。
一方、μITRONの場合はエラーコードの返し方にインプリメント依存性がある。そのため、意味的な間違いではな
く、インプリメントの都合でタスク独立部から発行できなくなっているシス
テムコールを発行しようとした場合にも、E̲XNOSPT のエラーの代わりに
E̲CTX のエラーを返す場合がある。

第一章 μITRON・ITRON2共通レファレンス

462
ITRON1の TE̲CTX に対応する。
●実行時エラー例外クラス (EC̲EXEC=11)
ニモニック
E̲QOVR

errno: 73〜80

ercd

説明

-H'b49キューイングのオーバーフロー(-(EC̲EXEC≪8)-73)

ITRON1の TE̲QOVR, TE̲MBOVR に対応する。

E̲OOVR-H'b4aオブジェクト数のオーバーフロー(-(EC̲EXEC≪8)-74)●実行終了時エラー例外クラス (EC̲EXCMP=12)

errno: 81〜84※ Execution Completed
ニモニック

ercd

説明

E̲DLT

-H'c51

待ちオブジェクトが削除された。

(-(EC̲EXCMP≪8)-81)

ITRON1の TE̲DLT に対応する。

E̲INIHDR-H'c52

初期化ハンドラエラー(-(EC̲EXCMP≪8)-82)●待ち状態強制解除例外クラス (EC̲RLWAI=13)

errno: 85〜88※ Release Wait
ニモニック
E̲TMOUTercd

説明-H'd55

タイムアウト(-(EC̲RLWAI≪8)-85)
E̲RLWAI-H'd56ITRON1の TE̲TMOUT に対応する。
待ち状態強制解除(-(EC̲RLWAI≪8)-86)●処理実行結果を示す例外クラス (EC̲RSLT=14)
ニモニック
E̲PLFAIL

errno: 89〜96

ercd

説明

-H'e59

ポーリング失敗（メッセージ/セマフォが(-(EC̲RSLT≪8)-89)

無い）(Polling Fail)第四部 レファレンス

463
E̲AROVR-H'e5a(-(EC̲EXEC≪8)-90)
E̲MPURG-H'e5b

用意した領域のサイズが小さすぎる(Area Over)
メモリブロックが削除された(-(EC̲RSLT≪8)-91)
E̲MRELOC-H'e5cメモリブロックが再配置された(-(EC̲RSLT≪8)-92)

第一章 μITRON・ITRON2共通レファレンス第四部 第二章

μITRONレファレンス

466

システムコール一覧 (μITRON)'=' の記号のついているものは、リターンパラメータである。

■ タスク管理機能
レベル

システム
コール

パラメータ/リターン
パラメータ（=印）

2
2
3
3
#3

sta̲tskext̲tskter̲tskchg̲priichg̲pri

tskid

3
#3

rot̲rdqirot̲rdq

5#5

rel̲waiirel̲wai33

get̲tidtsk̲sts

機能説明

タスクを起動する
自タスクを正常終了する
tskid
他タスクを強制的に異常終了させる
tskid tskpri
タスク優先度を変更する
tskid tskpri
タスク優先度を変更する（タスク独立部専用）tskpri
タスクのレディキューを回転する
tskpri
タスクのレディキューを回転する（タスク独立部専用）
tskid
タスクの待ち状態を強制解除する
tskid
タスクの待ち状態を強制解除する（タスク独立部専用）tskid=
自タスクのIDを得る
tskid tskpri= tskstat=
タスクの状態を見る■ タスク付属同期機能
レベル

システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

3
#3

sus̲tskisus̲tsk

tskid
tskid

3
#3

rsm̲tsk
irsm̲tsk

tskid
tskid

タスクを強制待ち状態へ移行する
タスクを強制待ち状態へ移行する（タスク独立部専用）
強制待ち状態のタスクを再開する
強制待ち状態のタスクを再開する（タスク独立部専用）

第四部 レファレンス

467
4

frsm̲tsk

tskid

1
3

slp̲tsk
wai̲tsk

tmout

1
#1

wup̲tskiwup̲tsk

tskid
tskid

3

can̲wuptskid wupcnt=

強制待ち状態のタスクを強制再開
する
タスクを待ち状態へ移行する
タスクを一定時間待ち状態に移行する
待ち状態のタスクを起床する
待ち状態のタスクを起床する（タスク独立部専用）
タスクの起床要求を無効にする■ 同期・通信機能
レベル

システム
コール

パラメータ/リターン
パラメータ（=印）

3A#3A

set̲flgiset̲flg

flgid setptn
flgid setptn

3A
3A

clr̲flg
wai̲flg

flgid
flgid

3A

pol̲flg

flgid

4A

flg̲sts

flgid

3B
#3B

set̲flgiset̲flg

flgid
flgid

3B
3B

clr̲flg
wai̲flg

flgid
flgid

3B

cwai̲flg

flgid

3B

pol̲flg

flgid

3B

cpol̲flg

flgid

機能説明

1ワードイベントフラグをセットする
1ワードイベントフラグをセットする（タスク独立部専用）
clrptn1ワードイベントフラグをクリアする
waiptn flgptn= wfmode
1ワードイベントフラグを待つ
waiptn flgptn= wfmode
1ワードイベントフラグを得る
wtskid= flgptn=
1ワードイベントフラグ状態を参照
する
1ビットイベントフラグをセットする
1ビットイベントフラグをセットする（タスク独立部専用）
1ビットイベントフラグをクリアする
1ビットイベントフラグを待つ（クリア無）
1ビットイベントフラグを待つ（クリア有）
1ビットイベントフラグを得る（クリア無）
1ビットイベントフラグを得る（クリア有）

第二章 μITRON レファレンス

468
4B

flg̲sts

1#1

sig̲semisig̲sem

1
1
4

wai̲sempreq̲semsem̲sts2#2

snd̲msg
isnd̲msg

2
2
4

rcv̲msg
prcv̲msg
mbx̲sts

5

snd̲tmb#5

isnd̲tmb

5

rcv̲tmb

5

prcv̲tmb

5

tmb̲sts

flgid

wtskid= flgptn=
1ビットイベントフラグ状態を
参照する
semid
セマフォに対する信号操作（V命令）semid
セマフォに対する信号操作（タスク独立部専用）semid
セマフォに対する待ち操作（P命令）semid
セマフォ資源を得る
semid wtskid= semcnt=
セマフォ状態を参照する
mbxid pk̲msg
メイルボックスへ送信する
mbxid pk̲msg
メイルボックスへ送信する（タスク独立部専用）
mbxid pk̲msg= メイルボックスからの受信を待つ
mbxid pk̲msg= メイルボックスから受信する
mbxid wtskid= pk̲msg=
メイルボックス状態を参照する
tskid pk̲msg
タスク付 属 メイルボックスへ送信する
tskid pk̲msg
タスク付属メイルボックスへ送信する（タスク独立部専用）pk̲msg=タスク付属メイルボックスからの受信を待つpk̲msg=タスク付属メイルボックスから受信する
tskid tmbwait= pk̲msg=
タスク付属メイルボックスの状態
を参照する

第四部 レファレンス

469■ 割込み管理機能
レベル

システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

#1
#1
3
#5

def̲int
ret̲int
ret̲wupdef̲rstintno

inthdr

tskid
tskid

rstadr5

ret̲rst

tskid

2A
2A
2B

dis̲int
ena̲intchg̲iXX

intno
intno
iXXXX

3B

iXX̲stsiXXXX=

割込みハンドラを定義する
割込みハンドラから復帰する
割込処理復帰とタスク起床を行う
タスクリスタートアドレスを定義
する
割込処理復帰とタスクリスタートを行う
割込みを禁止する
割込みを許可する
割込みマスク（レベル,優先度）を変更する
割込みマスク（レベル,優先度）を参照する■ メモリプール管理機能
レベル

システム
コール

パラメータ/リターン
パラメータ（=印）

4get̲blk

mplid blk=3
3
4

pget̲blkrel̲blk
mpl̲sts

機能説明

固定長メモリブロックの獲得待ちを行う
mplid blk=
固定長メモリブロックを獲得する
mplid blk
固定長メモリブロックを返却する
mplid wtskid= frbcnt=
メモリプールの状態を参照する■ 時間管理・タイマハンドラ機能
レベル

システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

2
2
#4

set̲timget̲timdef̲cyc4

act̲cyctime
システムクロックを設定する
time=
システムクロックの値を読み出す
cyhno cychdr cyhact cytime
周期起動ハンドラを定義する
cyhno cyhact
周 期 起 動 ハンドラの 活 性 制 御 を行なう
第二章 μITRON レファレンス

470
4cyh̲sts#4

def̲alm4#4alh̲sts
ret̲tmrcyhno cyhact= lftime=
周期起動ハンドラの状態を参照する
alhno almhdr time tmmodeアラームハンドラを定義する
alhno lftime=
アラームハンドラの状態を参照する
タイマハンドラから復帰する■ システム管理機能
レベル

システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

1get̲verpk̲verITRON,μITRONのバージョン番号を得る※「レベル」の項に示されている数字は、インプリメントの必要性の度合いを示すものである。数字の小さい方が必要性の高いことを表わす。
※「レベル」の項の数字に A, B の記号が付いているシステムコールは、インプリメンタの側で、A, B のどちらかの仕様を選択してインプリメント
することを示す。なお、可能であれば、A, B 両方の仕様をインプリメン
トしても構わない。
※「レベル」の項の数字に # の記号が付いているシステムコールは、他の方法で代替できる可能性のあるシステムコールを示す。例えば、def̲int には # が付いているが、これは、割込みハンドラ定義の機能が他の方法（例えばシステム起動時の静的な定義）で代替できれば、そのシステムコールが不要であることを示す。
※割込みマスク（レベル,優先度）の変更や参照を行うシステムコール
chg̲iXX, iXX̲sts では、プロセッサのアーキテクチャに合わせて 'XX' の部分の名称を決める。
※ オブジェクトの状態を見るシステムコール XXX̲sts のリターンパラメー
タは、インプリメントによってかなり違いがある。この一覧表に書かれているインタフェースは、1つの例である。
※ 必要があれば、この一覧表に無いシステムコールを追加して設けることも可能である。ただし、追加した機能がITRON2でサポートする機能に含まれるものであれば、ITRON2のシステムコール名やシステムコールイン
タフェースと矛盾の無い仕様にしなければならない。

第四部 レファレンス

471

データタイプ (μITRON)

typedef chartypedef short
typedef long
typedef unsigned chartypedef unsigned short
typedef unsigned long
typedef long
typedef short
typedef chartypedef void
typedef void

B;
H;
W;
UB;
UH;
UW;
VW;

/* 符号付き8ビット整数 *//* 符号付き16ビット整数 *//* 符号付き32ビット整数 *//* 符号無し8ビット整数 *//* 符号無し16ビット整数 *//* 符号無し32ビット整数 *//*データタイプが一定しないもの（32ビットサイズ） */VH;/*データタイプが一定しないもの（16ビットサイズ) */VB;/*データタイプが一定しないもの（8ビットサイズ） */*VP;/*データタイプが一定しないものへのポインタ */(*FP)( ); /* プログラムのスタートアドレス一般 */※ VB, VH, VW と B, H, W との違いは、前者がビット数のみがわかっており、データタイプの中味がわからないものを表すのに対して、後者は整数を表しているという点である。例えば、メッセージの中身やメモリブ
ロックはバイトの配列であるが、中に入れるデータの実際のデータタイ
プは場合によって異なっているので、VB のデータタイプを使っている。
また、パケットの中でリザーブ領域を確保する場合は、データのサイズはわかっているが整数であるとは言えないため、VH, VW のデータタイ
プを使っている。
/* パラメータの意味を明確にし、また対象プロセッサのビット数に依しない記述を行うため、出現頻度の高いデータタイプや特殊な意味を持つ
データタイプとして、以下のような名称を使用する */BOOL
ID/* ブール値、FALSE（0 - 偽）または TRUE（1 - 真）*//* オブジェクトのID (XXXid) */第二章 μITRON レファレンス

472
HNO
ER
TMO
TIME
FN
TPRI
T̲MSG
INT
UINT

/* ハンドラ番号 *//* エラーコード - 一般には符号付きである *//* タイムアウト *//* 時間指定 - 実際には上位と下位に分けて扱うことが多い *//* 機能コード *//* タスク優先度 *//* メッセージパケットの構造体 *//* 符号付き整数（プロセッサのビット幅）*//* 符号無し整数（プロセッサのビット幅）*/※ これらのデータタイプのビット数、値の範囲、符号の有無などは、対象
プロセッサおよびインプリメントに依存する。
※ μITRONでは対象プロセッサのビット数を固定していないため、言語C
インタフェースの説明の中では、ビット数を明確にした W, H, UW, UHのような記述はあまり使用せず、INT, UINT を使用している場合が多い。
ただし、μITRONの個々のインプリメントでは対象プロセッサのビット数がわかっているので、μITRONの製品のマニュアル等において、INT,UINT の代りに W, H, UW, UH 等を使用することは構わない。
※ 例えば、16ビットのプロセッサを対象とした場合には、INT と H、および UINT と UH が同じ意味を表わす。つまり、以下のように書くことができる。
typedef H
typedef UH

INT;
UINT;

/* 16ビットプロセッサの場合 *//* 16ビットプロセッサの場合 */※ 上記のデータタイプと実際のビット数との対応については、インプリメ
ント毎に明らかにしておく必要がある。
【記述例】
ER ercd = sta̲tsk ( ID tskid );第四部 レファレンス

473

言語Cインタフェース (μITRON)●タスク管理機能ER ercd = sta̲tsk ( ID tskid );void

ext̲tsk ( );ER ercd = ter̲tsk ( ID tskid );ER ercd = chg̲pri ( ID tskid, TPRI tskpri );ER ercd = ichg̲pri ( ID tskid, TPRI tskpri );ER ercd = rot̲rdq ( TPRI tskpri );ER ercd = irot̲rdq ( TPRI tskpri );ER ercd = rel̲wai ( ID tskid );ER ercd = irel̲wai ( ID tskid );ER ercd = get̲tid ( ID *p̲tskid );ER ercd = tsk̲sts ( UINT *p̲tskstat, TPRI *p̲tskpri, ID tskid );※ tsk̲sts のインタフェースはパケットを使用する場合もある●タスク付属同期機能
ER ercd = sus̲tsk ( ID tskid );ER ercd = isus̲tsk ( ID tskid );ER ercd = rsm̲tsk ( ID tskid );ER ercd = irsm̲tsk ( ID tskid );ER ercd = frsm̲tsk ( ID tskid );ER ercd = slp̲tsk ( );ER ercd = wai̲tsk ( TMO tmout );ER ercd = wup̲tsk ( ID tskid );ER ercd = iwup̲tsk ( ID tskid );ER ercd = can̲wup ( INT *p̲wupcnt, ID tskid );第二章 μITRON レファレンス

474●同期・通信機能【1ワードイベントフラグの場合】
ER ercd = set̲flg ( ID flgid, UINT setptn );ER ercd = iset̲flg ( ID flgid, UINT setptn );ER ercd = clr̲flg ( ID flgid, UINT clrptn );ER ercd = wai̲flg ( UINT *p̲flgptn, ID flgid, UINT waiptn, UINT wfmode );ER ercd = pol̲flg ( UINT *p̲flgptn, ID flgid, UINT waiptn, UINT wfmode );ER ercd = flg̲sts ( ID *p̲wtskid, UINT *p̲flgptn, ID flgid );※ flg̲sts のインタフェースはパケットを使用する場合もある【1ビットイベントフラグの場合】
ER ercd = set̲flg ( ID flgid );ER ercd = iset̲flg ( ID flgid );ER ercd = clr̲flg ( ID flgid );ER ercd = wai̲flg ( ID flgid );ER ercd = cwai̲flg ( ID flgid );ER ercd = pol̲flg ( ID flgid );ER ercd = cpol̲flg ( ID flgid );ER ercd = flg̲sts ( ID *p̲wtskid, BOOL *p̲flgptn, ID flgid );※ flg̲sts のインタフェースはパケットを使用する場合もある
ER ercd = sig̲sem ( ID semid );ER ercd = isig̲sem ( ID semid );ER ercd = wai̲sem ( ID semid );ER ercd = preq̲sem ( ID semid );ER ercd = sem̲sts ( ID *p̲wtskid, INT *p̲semcnt, ID semid );※ sem̲sts のインタフェースはパケットを使用する場合もある
ER ercd = snd̲msg ( ID mbxid, T̲MSG *pk̲msg);
ER ercd = isnd̲msg ( ID mbxid, T̲MSG *pk̲msg);
ER ercd = rcv̲msg ( T̲MSG **ppk̲msg, ID mbxid );ER ercd = prcv̲msg ( T̲MSG **ppk̲msg, ID mbxid );ER ercd = mbx̲sts ( ID *p̲wtskid, T̲MSG **ppk̲msg, ID mbxid );※ mbx̲sts のインタフェースはパケットを使用する場合もある

第四部 レファレンス

475
ER ercd = snd̲tmb ( ID tskid, T̲MSG *pk̲msg);
ER ercd = isnd̲tmb ( ID tskid, T̲MSG *pk̲msg);
ER ercd = rcv̲tmb ( T̲MSG **ppk̲msg );ER ercd = prcv̲tmb ( T̲MSG **ppk̲msg );ER ercd = tmb̲sts ( BOOL *p̲tmbwait, T̲MSG **ppk̲msg, ID tskid );※ tmb̲sts のインタフェースはパケットを使用する場合もある●割込み管理機能ER ercd = def̲int ( UINT intno, FP inthdr );void

ret̲int ( );voidret̲wup ( ID tskid );ER ercd = def̲rst ( ID tskid, FP rstadr );void

ret̲rst ( ID tskid );ER ercd = dis̲int ( UINT intno );ER ercd = ena̲int ( UINT intno );ER ercd = chg̲iXX ( UINT iXXXX );ER ercd = iXX̲sts ( UINT *p̲iXXXX );※ intno, iXXXX のデータタイプは UINT にならない場合もある●メモリプール管理機能
ER ercd = get̲blk ( VP *p̲blk, ID mplid );ER ercd = pget̲blk ( VP *p̲blk, ID mplid );ER ercd = rel̲blk ( ID mplid, VP blk );ER ercd = mpl̲sts ( ID *p̲wtskid, INT *p̲frbcnt, ID mplid );※ mpl̲sts のインタフェースはパケットを使用する場合もある●時間管理・タイマハンドラ機能
ER ercd = set̲tim ( TIME time );ER ercd = get̲tim ( TIME *p̲time );※ set̲tim, get̲tim のインタフェースはパケットを使用する場合もある
ER ercd = def̲cyc ( HNO cyhno, FP cychdr, UINT cyhact, TIME cytime );ER ercd = act̲cyc ( HNO cyhno, UINT cyhact );第二章 μITRON レファレンス

476
ER ercd = cyh̲sts ( UINT *p̲cyhact, TIME *p̲lftime, HNO cyhno );ER ercd = def̲alm ( HNO alhno, FP almhdr, TIME time, UINT tmmode );ER ercd = alh̲sts ( TIME *p̲lftime, HNO alhno );※ def̲cyc, cyh̲sts, def̲alm, alh̲sts のインタフェースはパケットを使用する
場合もある
void

ret̲tmr ( );●システム管理機能
ER ercd = get̲ver ( T̲VER *pk̲ver );第四部 レファレンス

477

共通定数と構造体のパケット形式 (μITRON)/*------------------------------------------------------------------------------------------------*/（共通に使用する定数）
全体:
NADR

(-1)

/* アドレスやポインタ値が無効 */

TRUE

1

/* 真 */

FALSE

0/* 偽 */

tskid, wtskid:
TSK̲SELF

0/* 自タスク指定 */

FALSE

0

/* タスク独立部、あるいは待ちタスク無しを表わす（リターンパラメータのみ）*/

tskpri:TPRI̲INI

0/* タスク起動時の初期優先度を指定 (chg̲pri) */TPRI̲RUN

0/* その時実行中の最高優先度を指定 (rot̲rdq) */TTM̲ABS0/* 絶対時刻での指定 */TTM̲REL1/* 相対時刻での指定 */tmmode:tskstat:
TTS̲RUN

H'00000001/* RUN */TTS̲RDY

H'00000002/* READY */TTS̲WAI

H'00000004/* WAIT */TTS̲SUS

H'00000008/* SUSPEND */TTS̲WAS

H'0000000c/* WAIT-SUSPEND */TTS̲DMT

H'00000010/* DORMANT */※ tskstat によるタスク状態の表現はビット対応になっているため、和集合の判定を行う（例えば、WAIT または READY であることを判定する）
場合に便利である。

第二章 μITRON レファレンス

478
cyhact:TCY̲OFF0/* 周期起動ハンドラが起動されない */TCY̲ON1/* 周期起動ハンドラが起動される */TCY̲INI2/* 周期のカウントが初期化される *//*------------------------------------------------------------------------------------------------*/
typedef struct t̲msg {...
/* インプリメントによっては、ここにOSの予約領域が入る */...
VB

msgcont[ ];} T̲MSG;/*------------------------------------------------------------------------------------------------*/
typedef struct t̲ver {UHmaker;/* メーカー */

UH

id;

/* 形式番号 */UH

spver;/* 仕様書バージョン */UH

prver;/* 製品バージョン */UH

prno[4];/* 製品管理情報 */

UH

cpu;

/* CPU情報 */

UH

var;

/* バリエーション記述子 */} T̲VER;/*------------------------------------------------------------------------------------------------*/

第四部 レファレンス第四部 第三章

ITRON2レファレンス

480

システムコール一覧 (ITRON2)'=' の記号のついているものは、リターンパラメータである。
ITRON2基本機能■ タスク管理機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

cre̲tsktskid tskatr stadr itskpri stksz
タスクを生成する

sta̲tsktskid stacd

del̲tsk

tskid

タスクを起動する
タスクを削除する

ext̲tsk

自タスクを正常終了する

exd̲tsk

自タスクを正常終了後、削除する

abo̲tsk

exccd

自タスクを異常終了させる

ter̲tsktskid exccd

他タスクを強制的に異常終了

ras̲tertskid exccd

他タスクに対して終了要求を出す

chg̲pritskid tskpri

タスク優先度を変更する

rot̲rdqtskpri

タスクのレディキューを回転する

rel̲wai

tskid

タスクの待ち状態を強制解除する

get̲tid

tskid=

自タスクのIDを得る

tsk̲sts

tskid pk̲tsks

タスクの状態を見る

hdr̲sts

tskid ar̲hdrs hdstart hdcnt

させる

ハンドラ実行環境を参照する■ タスク付属同期機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

sus̲tsk

tskid

タスクを強制待ち状態へ移行する

第四部 レファレンス

481
rsm̲tsktskid

強制待ち状態のタスクを再開
する

frsm̲tsk

tskid

強制待ち状態のタスクを強制再開する

slp̲tsk
wai̲tsk

タスクを待ち状態へ移行する
tmout

タスクを一定時間待ち状態に移行する

wup̲tsk

tskid

待ち状態のタスクを起床する

can̲wuptskid wupcnt=

タスクの起床要求を無効にする■ 同期・通信機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

cre̲flg

flgid flgatr

イベントフラグを生成する

del̲flg

flgid

イベントフラグを削除する

set̲flg

flgid setptn

イベントフラグをセットする

clr̲flg

flgid clrptn

イベントフラグをクリアする

wai̲flg

flgid waiptn

flg̲sts

flgid pk̲flgs

cre̲semsemid sematr isemcnt

セマフォを生成する

del̲semsemid

セマフォを削除する

sig̲semsemid rcnt

セマフォに対する信号操作

wai̲semsemid rcnt tmout

flgptn= tmout wfmode
イベントフラグを待つ
イベントフラグ状態を参照する（V命令）
セマフォに対する待ち操作（P命令）
sem̲sts

semid pk̲sems

セマフォ状態を参照する

cre̲mbxmbxid mbxatr

メイルボックスを生成する

del̲mbxmbxid

メイルボックスを削除する

snd̲msg

mbxid pk̲msg

メイルボックスへ送信する

rcv̲msg

mbxid pk̲msg= tmout

メイルボックスから受信する

mbx̲stsmbxid pk̲mbxs

メイルボックス状態を参照する

第三章 ITRON 2 レファレンス

482■ 割込み管理機能
システム
コール

パラメータ/リターン
パラメータ（=印）

def̲int

intvec inhatr inthdr imask 割込みハンドラを定義する

ret̲intchg̲ims

機能説明

割込みハンドラから復帰する
imask

割込みマスクを変更する■ 例外管理機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

def̲ext

tskid exhatr exthdr

タスク用終了ハンドラの定義

def̲cextskid exhatr cexhdr

タスク用CPU例外ハンドラの定義

def̲sextskid exhatr sexhdr

タスク用システムコール例外ハン
ドラの定義

ret̲exc

例外ハンドラから復帰

end̲exc

例外ハンドラの終了

clr̲emstskid clrptn

例外処理マスククリア

set̲emstskid setptn

例外処理マスクセット

idef̲ext

exhatr exthdr

タスク独立部用終了ハンドラの定義

idef̲cex

exhatr cexhdr

タスク独立部用CPU例外ハン
ドラの定義

idef̲sex

exhatr sexhdr

タ ス ク 独 立 部 用 システムコール
例外ハンドラの定義■ メモリプール管理機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

cre̲mplmplid

del̲mplmplid

get̲blk

mplid

bcnt blk= tmout 共有メモリブロックを獲得する

rel̲blk

mplid

blk

共有メモリブロックを返却する

mpl̲sts

mplid

pk̲mpls

メモリプールの状態を参照する

blk̲sts

mplid= blk bcnt=

共有メモリブロックの状態参照

mplatr mplsz blksz
メモリプールの生成
メモリプールを削除する

第四部 レファレンス

483■ 時間管理機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

set̲timutime ltime

システムクロックを設定する

get̲timutime= ltime=

システムクロックの値を読み出す

dly̲tsk

dtime

タスクの遅延を行う

cyc̲wuptskid rptcnt cytime utime ltime tmmodecan̲cyctskid

タスクを周期起床する
タスクに出された周期起床要求を解除する■ システム管理機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

def̲svcs̲fncd svhatr svchdr

拡張SVCハンドラを定義する

ret̲svcs̲ercd

拡張SVCハンドラから復帰する

get̲verpk̲verITRONのバージョン番号を得る

psw̲stspsw=

プロセッサ状態語を参照する

ITRON2拡張機能■ 拡張同期・通信機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

cre̲mbfmbfid mbfatr bufsz maxbmsz

del̲mbf

mbfid

メッセージバッファを削除する

snd̲mbfmbfid bmsgsz pk̲bmsg

メッセージバッファへ送信する

rcv̲mbfmbfid bmsgsz= tmout pk̲bmsg

メッセージバッファを生成する

メッセージバッファから受信する
mbf̲sts

mbfid pk̲mbfs

メッセージバッファ状態を参照

cre̲porporid poratr

ランデブ用のポートを生成する

del̲por

porid

ランデブ用のポートを削除する

する

第三章 ITRON 2 レファレンス

484
cal̲porporid calptn pk̲rmsg maxrmsz tmout
ポートに対するランデブの呼び出し

acp̲porporid acpptn ctskid = pk̲rmsg maxrmsz tmout

fwd̲porporid ctskid calptn pk̲rmsg

rpl̲porctskid pk̲rmsg

ポートに対するランデブの返答

por̲sts

porid pk̲pors

ポート状態を参照する

rdv̲sts

porid ar̲rdvs rvstart rvcnt

ポートに対するランデブの受け付け
ポートに対するランデブの回送

ランデブ状態を参照する■ 強制例外機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

def̲fextskid exhatr fexhdr

タスク用強制例外ハンドラの定義

ras̲fextskid exccd

他タスクに対する強制例外の発生■ ローカルメモリプール管理機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

cre̲lmplmpid lmpatr lmpsz blksz
ローカルメモリプールの生成

del̲lmplmpid

ローカルメモリプールを削除する

get̲lbllmpid bcnt blk= tmout

ローカルメモリブロックを獲得する

rel̲lbllmpid blk

ローカルメモリブロックを返却する

lmp̲sts

lmpid pk̲lmps

ローカルメモリプールの状態を参照する

lbl̲sts

lmpid= blk bcnt=

ローカルメモリブロックの状態参照■ 資源管理サポート機能
システム
コール
usig̲sem

パラメータ/リターン
パラメータ（=印）
semid rcnt p̲rcnt

機能説明

セマフォに対する信号操作（メモリ更新有）第四部 レファレンス

485uwai̲sem

semid rcnt tmout p̲rcnt
セマフォに対する待ち操作（メモリ更新有）usnd̲msg

mbxid ppk̲msg

メイルボックスへ送信する（メモリ更新有）urcv̲msg

mbxid tmout ppk̲msg

メイルボックスから受信する（メモリ更新有）uget̲blk

mplid bcnt tmout p̲blk
共有メモリブロックを獲得する（メモリ更新有）uget̲lbl

lmpid bcnt tmout p̲blk
ローカルメモリブロックを獲得する（メモリ更新有）urel̲blk

mplid

p̲blk

共有メモリブロックを返却する（メモリ更新有）urel̲lbl

lmpid p̲blk

ローカルメモリブロックを返却する（メモリ更新有）■ タイマハンドラ機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

def̲cyccyhno cyhatr cychdr cyhact cytime
周期起動ハンドラを定義する

act̲cyccyhno cyhact

周期起動ハンドラの活性制御を行なう

cyh̲sts

cyhno pk̲cyhs

周期起動ハンドラの状態を参

def̲alm

alhno alhatr almhdr utime ltime tmmodealh̲sts

alhno pk̲alhs

照する
アラームハンドラを定義する
アラームハンドラの状態を参照する
ret̲tmrタイマハンドラから復帰する

第三章 ITRON 2 レファレンス

486

ITRON2システム操作機能■ 拡張SVCサポート機能
システム
コール

パラメータ/リターン
パラメータ（=印）

機能説明

sdef̲exts̲fncd exhatr exthdr

拡張SVC用終了ハンドラの定義

sdef̲cexs̲fncd exhatr cexhdr

拡張SVC用CPU例外ハンドラの定義

sdef̲sexs̲fncd exhatr sexhdr

拡張SVC用システムコール例外
ハンドラの定義

第四部 レファレンス

487

データタイプ (ITRON2)

typedef charB;/* 符号付き8ビット整数 */typedef shortH;/* 符号付き16ビット整数 */typedef longW;/* 符号付き32ビット整数 */typedef unsigned char

UB;/* 符号無し8ビット整数 */typedef unsigned shortUH;/* 符号無し16ビット整数 */typedef unsigned long

UW;/* 符号無し32ビット整数 */typedef long

VW;/* データタイプが一定しないもの

typedef short

VH;/* データタイプが一定しないもの

typedef char

VB;/* データタイプが一定しないもの（32ビットサイズ） */（16ビットサイズ） */（8ビットサイズ） */typedef void

*VP;/* データタイプが 一 定 し な い も の へ のポインタ */

typedef void(*FP)( ); /* プログラムのスタートアドレス一般 */※ VB, VH, VW と B, H, W との違いは、前者がビット数のみがわかっており、データタイプの中味がわからないものを表すのに対して、後者は整数を表しているという点である。例えば、メッセージの中身やメモリブ
ロックはバイトの配列であるが、中に入れるデータの実際のデータタイ
プは場合によって異なっているので、VB のデータタイプを使っている。
また、パケットの中でリザーブ領域を確保する場合は、データのサイズはわかっているが整数であるとは言えないため、VH, VW のデータタイ
プを使っている。
/* パラメータの意味を明確にするため、出現頻度の高いデータタイプや特殊な意味を持つデータタイプをあらかじめ用意しておく */typedef W

BOOL;/* ブール値、FALSE（0 - 偽）または
TRUE（1 - 真） */第三章 ITRON 2 レファレンス

488
typedef W

ID;/* オブジェクトのID (XXXid) *//* 値の範囲はシステムに依存して決まる *//* 値の範囲は2バイト以下だが、データタイプは4バイトである */（理由）2バイトとすると、ポインタを使う時に紛らわしくなる。
将来は4バイトへの拡張を考えることができる。
typedef W

HNO;/* ハンドラ番号 *//* 値の範囲は2バイトだが、データタイプは4バイトである。*/
typedef W

ER;/* エラーコード *//* 0 か負の値しかとらないので、正の値を持つ他のタイプと合成可能である *//* 値の範囲は2バイトだが、データタイプは4バイトである */typedef W

TMO;/* タイムアウト *//* 範囲は (-1)〜(2^31-1)、0でポーリング、(-1)で永久待ち */typedef UW

ATR;/* オブジェクト属性 */typedef UW

HATR;/* ハンドラ属性 *//* 以下は4バイトへの拡張の必要性が少ないことと、パケットに入ることがあるため、2バイトとする */typedef H

FN;/* 機能コード */typedef H

TPRI;/* タスク優先度、範囲は (-16)〜255 *//* 値の範囲は（1バイト+α）だが、データタイプは2バイトである *//* タスクやハンドラのデータタイプ *//* ハンドラやタスクを表わす関数に対して、戻り値の有無やハンド
ラ終了（戻り）システムコールとの対応に着目し、以下のようなデータタイプを設ける。*/
typedef void

TASK;/* タスク - ext̲tsk, exd̲tsk で終了 */typedef void

INTHDR;/* 割込みハンドラ - ret̲int で終了 */typedef ER

SVCHDR;/* 拡張SVCハンドラ - ret̲svc で終了 */typedef void

TMRHDR;/* タイマハンドラ - ret̲tmr で終了 */typedef void

EXCHDR;/* 終了,例外ハンドラ - ret̲exc で終了 */typedef void

INIHDR;/* 初期化ハンドラ */※ 初期化ハンドラは、カーネルが起動される際に1回だけ実行されるハンドラである。このハンドラを定義することで、初期オブジェクトの生成や

第四部 レファレンス

489
例外環境の定義などを行なうことができる。初期化ハンドラの有無や実
行コンテキスト(タスク部、準タスク部、タスク独立部) の区別はインプリメント依存である。
typedef TASK(*TASKP)( );/* タスクスタートアドレス */typedef INTHDR(*INTHDRP)( ); /* 割込みハンドラスタートアドレス */typedef SVCHDR(*SVCHDRP)( ); /*拡張SVCハンドラスタートアドレス */typedef TMRHDR(*TMRHDRP)( );/* タイマハンドラスタートアドレス */typedef EXCHDR(*EXCHDRP)( ); /* 例外ハンドラスタートアドレス */typedef INIHDR(*INIHDRP)( ); /* 初期化ハンドラスタートアドレス *//* プロセッサのアーキテクチャに関連したデータタイプ */typedef UW

PSW;/* PSW */【記述例】
ER ercd = sta̲tsk ( ID tskid, W stacd );第三章 ITRON 2 レファレンス

490

言語Cインタフェース (ITRON2)●動的機能コードによるシステムコール呼び出し
ER ercd = sys̲cal( FN fncd, VW par1, VW par2, VW par3, VW par4 );※ インタフェースルーチンを用意せずに拡張SVCを実行する場合などに利用する。
※ パラメータは最大4個で制限する。parN が Reg N に入る。パラメータがそれより多い場合は、パケットを利用する必要がある。また、パケット
以外のリターンパラメータは戻せない。
※ サブ機能コード(sfncd) がある場合には、par1 が sfncd を表わす。
●タスク管理機能ER ercd = cre̲tsk ( ID tskid, ATR tskatr, TASKP stadr, TPRI itskpri, W stksz );ER ercd = sta̲tsk ( ID tskid, W stacd );ER ercd = del̲tsk ( ID tskid );void

ext̲tsk ( );voidexd̲tsk ( );voidabo̲tsk ( UW exccd );ER ercd = ter̲tsk ( ID tskid, UW exccd );ER ercd = ras̲ter ( ID tskid, UW exccd );ER ercd = chg̲pri ( ID tskid, TPRI tskpri );ER ercd = rot̲rdq ( TPRI tskpri );ER ercd = rel̲wai ( ID tskid );ER ercd = get̲tid ( ID *p̲tskid );ER ercd = tsk̲sts ( T̲TSKS *pk̲tsks, ID tskid );ER ercd = hdr̲sts ( T̲HDRS *ar̲hdrs, ID tskid, W hdstart, W hdcnt );●タスク付属同期機能
ER ercd = sus̲tsk ( ID tskid );第四部 レファレンス

491
ER ercd = rsm̲tsk ( ID tskid );ER ercd =frsm̲tsk ( ID tskid );ER ercd = slp̲tsk ( );ER ercd = wai̲tsk ( TMO tmout );ER ercd = wup̲tsk( ID tskid );ER ercd = can̲wup( W *p̲wupcnt, ID tskid );●同期・通信機能ER ercd = cre̲flg ( ID flgid, ATR flgatr );ER ercd = del̲flg ( ID flgid );ER ercd = set̲flg ( ID flgid, UW setptn );ER ercd = clr̲flg ( ID flgid, UW clrptn );ER ercd = wai̲flg ( UW *p̲flgptn, ID flgid, UW waiptn, UW wfmode,
TMO tmout );ER ercd = flg̲sts ( T̲FLGS *pk̲flgs, ID flgid );ER ercd = cre̲sem( ID semid, ATR sematr, W isemcnt );ER ercd = del̲sem( ID semid );ER ercd = sig̲sem ( ID semid, W rcnt );ER ercd = wai̲sem( ID semid, W rcnt, TMO tmout );ER ercd = sem̲sts ( T̲SEMS *pk̲sems, ID semid );ER ercd = cre̲mbx ( ID mbxid, ATR mbxatr );ER ercd = del̲mbx ( ID mbxid );ER ercd = snd̲msg ( ID mbxid, T̲MSG *pk̲msg);
ER ercd = rcv̲msg ( T̲MSG **ppk̲msg, ID mbxid, TMO tmout );ER ercd = mbx̲sts( T̲MBXS *pk̲mbxs, ID mbxid );●割込み管理機能ER ercd = def̲int ( UH intvec, HATR inhatr, INTHDRP inthdr, PSW imask );void

ret̲int ( );ER ercd = chg̲ims( PSW imask );●例外管理機能ER ercd = def̲ext ( ID tskid, HATR exhatr, EXCHDRP exthdr );ER ercd = def̲cex ( ID tskid, HATR exhatr, EXCHDRP cexhdr );第三章 ITRON 2 レファレンス

492
ER ercd = def̲sex ( ID tskid, HATR exhatr, EXCHDRP sexhdr );void

ret̲exc ( );ER ercd = end̲exc( );ER ercd = clr̲ems ( ID tskid, UW clrptn );ER ercd = set̲ems ( ID tskid, UW setptn );ER ercd =idef̲ext ( HATR exhatr, EXCHDRP exthdr );ER ercd =idef̲cex ( HATR exhatr, EXCHDRP cexhdr );ER ercd =idef̲sex ( HATR exhatr, EXCHDRP sexhdr );●メモリプール管理機能
ER ercd = cre̲mpl ( ID mplid, ATR mplatr, W mplsz, W blksz );ER ercd = del̲mpl ( ID mplid );ER ercd = get̲blk ( VP *p̲blk, ID mplid, W bcnt, TMO tmout );ER ercd = rel̲blk ( ID mplid, VP blk );ER ercd = mpl̲sts ( T̲MPLS *pk̲mpls, ID mplid );ER ercd = blk̲sts ( ID *p̲mplid, W *p̲bcnt, VP blk );●時間管理機能ER ercd = set̲tim ( H utime, UW ltime );ER ercd = get̲tim ( H *p̲utime, UW *p̲ltime );ER ercd = dly̲tsk ( W dtime );ER ercd = cyc̲wup ( ID tskid, W rptcnt, W cytime, H utime, UW ltime,
UW tmmode);ER ercd = can̲cyc ( ID tskid );●システム管理機能
ER ercd = def̲svc ( FN s̲fncd, HATR svhatr, SVCHDRP svchdr );void

ret̲svc ( ER s̲ercd );ER ercd = get̲ver ( T̲VER *pk̲ver );ER ercd = psw̲sts ( PSW *p̲psw );●拡張同期・通信機能
ER ercd = cre̲mbf( ID mbfid, ATR mbfatr, W bufsz, W maxbmsz );ER ercd = del̲mbf( ID mbfid );ER ercd = snd̲mbf( ID mbfid, VP pk̲bmsg, W bmsgsz );第四部 レファレンス

493
ER ercd = rcv̲mbf( VP pk̲bmsg, W *p̲bmsgsz, ID mbfid, TMO tmout );ER ercd = mbf̲sts ( T̲MBFS *pk̲mbfs, ID mbfid );ER ercd = cre̲por ( ID porid, ATR poratr );ER ercd = del̲por ( ID porid );ER ercd = cal̲por ( T̲RMSG *pk̲rmsg, ID porid, UW calptn, W maxrmsz,
TMO tmout );ER ercd = acp̲por ( ID *p̲ctskid, T̲RMSG *pk̲rmsg, ID porid, UW acpptn,
W maxrmsz, TMO tmout );ER ercd = fwd̲por( ID porid, ID ctskid, T̲RMSG *pk̲rmsg, UW calptn );ER ercd = rpl̲por ( ID ctskid, T̲RMSG *pk̲rmsg );ER ercd = por̲sts ( T̲PORS *pk̲pors, ID porid );ER ercd = rdv̲sts ( T̲RDVS *ar̲rdvs, ID porid, W rvstart, W rvcnt );●強制例外機能ER ercd = def̲fex ( ID tskid, HATR exhatr, EXCHDRP fexhdr );ER ercd = ras̲fex ( ID tskid, UW exccd );●ローカルメモリプール管理機能〕
ER ercd = cre̲lmp ( ID lmpid, ATR lmpatr, W lmpsz, W blksz );ER ercd = del̲lmp ( ID lmpid );ER ercd = get̲lbl ( VP *p̲blk, ID lmpid, W bcnt, TMO tmout );ER ercd = rel̲lbl ( ID lmpid, VP blk );ER ercd = lmp̲sts ( T̲LMPS *pk̲lmps, ID lmpid );ER ercd = lbl̲sts ( ID *p̲lmpid, W *p̲bcnt, VP blk );●資源管理サポート機能
ER ercd =usig̲sem ( W *p̲rcnt, ID semid, W rcnt );ER ercd =uwai̲sem ( W *p̲rcnt, ID semid, W rcnt, TMO tmout );ER ercd =usnd̲msg ( T̲MSG **ppk̲msg, ID mbxid );ER ercd =urcv̲msg ( T̲MSG **ppk̲msg, ID mbxid, TMO tmout );ER ercd =uget̲blk ( VP *p̲blk, ID mplid, W bcnt, TMO tmout );ER ercd =uget̲lbl( VP *p̲blk, ID lmpid, W bcnt, TMO tmout );ER ercd =urel̲blk( VP *p̲blk, ID mplid );ER ercd =urel̲lbl( VP *p̲blk, ID lmpid );第三章 ITRON 2 レファレンス

494●タイマハンドラ機能
ER ercd = def̲cyc ( HNO cyhno, HATR cyhatr, TMRHDRP cychdr,
UW cyhact, W cytime );ER ercd = act̲cyc ( HNO cyhno, UW cyhact );ER ercd = cyh̲sts ( T̲CYHS *pk̲cyhs, HNO cyhno );ER ercd = def̲alm ( HNO alhno, HATR alhatr, TMRHDRP almhdr, H utime,
UW ltime, UW tmmode );ER ercd = alh̲sts ( T̲ALHS *pk̲alhs, HNO alhno );void

ret̲tmr ( );●拡張SVCサポート機能
ER ercd =sdef̲ext ( FN s̲fncd, HATR exhatr, EXCHDRP exthdr );ER ercd =sdef̲cex ( FN s̲fncd, HATR exhatr, EXCHDRP cexhdr );ER ercd =sdef̲sex ( FN s̲fncd, HATR exhatr, EXCHDRP sexhdr );第四部 レファレンス

495

共通定数のニモニックと標準値(ITRON2)/*------------------------------------------------------------------------------------------------*/
全体:
NADR

(-1)

/* アドレスやポインタ値が無効 */

TRUE

1

/* 真 */

FALSE

0/* 偽 */

TMO̲POL0/* ポーリング */TMO̲FEVR(-1)/* 永久待ち */TSK̲SELF

0/* 自タスク指定 */TSK̲CMN(-1)/* タスク間共通の例外ハンドラの定義 */TSK̲INDP(-2)/* タスク独立部の指定 */

FALSE

0

/ * タスク独 立 部 、 あ る い は 待 ち タ ス ク 無 し を

tmout:

tskid, wtskid:

表わす（リターンパラメータのみ）*/
tskpri:TPRI̲INI

0/* タスク起動時の初期優先度を指定 (chg̲pri) */TPRI̲RUN

0/* その時実行中の最高優先度を指定 (rot̲rdq) */(-4)/* OS用のメモリプール */TMBF̲OS(-4)/* OSのエラーログ用のメッセージバッファ */TMBF̲DB(-3)/* デバッグ用のメッセージバッファ */TTM̲ABS0/* 絶対時刻での指定 */TTM̲REL1/* 相対時刻での指定 */(-1)/* 拡張SVC共通の例外ハンドラの定義 */mplid:
TMPL̲OSmbfid:

tmmode:s̲fncd:TFN̲CMN第三章 ITRON 2 レファレンス

496
spcid:
TSP̲SELF

0/* 自タスクの属する空間 */TSP̲CMN(-1)/* 共通空間 */0/* 特別な属性を指定しない */poratr:TA̲NULL※ TA̲NULLは、属性などの機能を OFF にする場合に、0 の代わりに使用するニモニックである。
inhatr,exhatr,cyhatr,alhatr,svhatr:
TA̲HLNG

H'00000100/* 高級言語によるプログラム */TA̲ASM

H'00000000/* アセンブラによるプログラム */※ TA̲ASM は、タスクやハンドラがアセンブラレベルから直接起動されることを表わす。TA̲ASM は TA̲HLNG と反対の意味を持つ属性である。
/*------------------------------------------------------------------------------------------------*//* システムコール xxx̲yyy を呼び出すための機能コードをニモニックで表わす場合には、TFN̲XXX̲YYY のニモニックを使用する。
代表的なシステムコールの機能コードに対するニモニックは次のようになる。*/
TFN̲CRE̲TSK (-17)

H'ffef

タスクを生成する

TFN̲STA̲TSK (-23)

H'ffe9

タスクを起動する

H'ffbf

割込みハンドラを定義する...
TFN̲DEF̲INT (-65)...
/*------------------------------------------------------------------------------------------------*/

第四部 レファレンス

497

共通定数の適用システムコール(ITRON2)

前項のレファレンスに出てくる定数と、それを適用できるシステムコー
ルとの関係を以下に示す。○はその組み合せが可能である（意味がある）ことを示し、E̲xxxx は表記のエラーが発生することを示す。ただし、発生するエラーコードの詳細にはインプリメント依存の部分がある。
●tmout:TMO̲POL

TMO̲FEVR

wai̲tsk○○wai̲flg○○

wai̲sem○○rcv̲msg○○get̲blk○○rcv̲mbf○○cal̲por○○acp̲por○○get̲lbl○○uwai̲sem○○urcv̲msg○○

uget̲blk○○

uget̲lbl○○●tskid:TSK̲SELF

TSK̲CMN （参考）自タスクのIDを指定

cre̲tsk

E̲RSIDE̲RSIDE̲EXS

sta̲tsk

E̲RSIDE̲RSID

E̲NODMTdel̲tsk

E̲RSIDE̲RSID

E̲NODMTter̲tskE̲SELFE̲RSIDE̲SELFras̲ter

E̲SELFE̲RSIDE̲SELFchg̲pri○

E̲RSIDrel̲waiE̲RSIDE̲RSIDtsk̲sts○

E̲RSID○
E̲NOWAI○第三章 ITRON 2 レファレンス

498
sus̲tskE̲SELFE̲RSIDE̲SELFrsm̲tskE̲SELFE̲RSIDE̲SELFfrsm̲tsk E̲SELF

E̲RSIDE̲SELFwup̲tskE̲SELFE̲RSIDE̲SELF

can̲wup○E̲RSID○def̲ext○○○

def̲cex○○○def̲sex○○○clr̲ems○

E̲RSID○set̲ems○

E̲RSID○cyc̲wup○E̲RSID○can̲cyc○

E̲RSID○def̲fex○○○ras̲fexE̲SELFE̲RSIDE̲SELF※ 上記のうち、E̲SELF は、自タスク操作と他タスク操作を区別するという方針に基づいたエラーを示す。E̲SELF は、自タスクのIDを指定した場合にも TSK̲SELF を指定した場合にも共通して発生する。
●tskpri:chg̲pri

TPRI̲INI

TPRI̲RUN○

rot̲rdq○※ TPRI̲INI と TPRI̲RUN は値が同じである。
●mplid:

TMPL̲OScre̲mplE̲RSIDdel̲mplE̲RSIDget̲blk○rel̲blk○

mpl̲sts○

uget̲blk○urel̲blk○●mbfid:TMBF̲OScre̲mbf

E̲RSIDdel̲mbf

E̲RSID
第四部 レファレンス

499
snd̲mbf

E̲RSIDrcv̲mbf○

mbf̲sts○●tmmode:TTM̲ABS

TTM̲RELcyc̲wup○○def̲alm○○●s̲fncd:

TFN̲CMN

def̲svc

E̲ILFNsdef̲ext○

sdef̲cex○

sdef̲sex○●XXhatr:TA̲HLNGdef̲int○

def̲ext○

def̲cex○def̲sex○idef̲ext○

idef̲cex○

idef̲sex○def̲svc○

def̲fex○def̲cyc○def̲alm○sdef̲ext○

sdef̲cex○

sdef̲sex○/*------------------------------------------------------------------------------------------------*/

第三章 ITRON 2 レファレンス

500

構造体のパケット形式 (ITRON2)

typedef struct t̲tsks {ATRtskatr;/* タスク属性 */ID

spcid;/* スペースID、共通空間では TSP̲CMN(-1) */UWtskstat;/* タスク状態 */UW

epndptn;/* ペンディング中の終了要求と強制例外 */UW

tskwait;/* 待ち要因 */

ID

wid;

/* 待ちオブジェクトID */W

suscnt;/* SUSPEND要求カウント、0≦ suscnt＜ 2^31 */W

wupcnt;/* 起床要求カウント、0≦ wupcnt＜ 2^31 */TASKP

stadr;/* タスクスタートアドレス */

VW

isp;

/* 初期SP値 */TPRI

itskpri;/* 初期優先度 */TPRI

tskpri;/* 現在優先度 */} T̲TSKS;
tskatr:TA̲ASM

H'00000000/* アセンブラによるプログラム */TA̲HLNG

H'00000100/* 高級言語によるプログラム */TA̲COP0

H'00000080/* ID=0 のコプロセッサを使用 */TA̲COP1

H'00000040/* ID=1 のコプロセッサを使用 */TA̲COP2

H'00000020/* ID=2 のコプロセッサを使用 */TA̲COP3

H'00000010/* ID=3 のコプロセッサを使用 */TA̲COP4

H'00000008/* ID=4 のコプロセッサを使用 */TA̲COP5

H'00000004/* ID=5 のコプロセッサを使用 */TA̲COP6

H'00000002/* ID=6 のコプロセッサを使用 */TA̲COP7

H'00000001/* ID=7 のコプロセッサを使用 */H'00000001/* RUN */tskstat:
TTS̲RUN

第四部 レファレンス

501
TTS̲RDY

H'00000002/* READY */TTS̲WAI

H'00000004/* WAIT */TTS̲SUS

H'00000008/* SUSPEND */TTS̲WAS

H'0000000c/* WAIT-SUSPEND */TTS̲DMT

H'00000010/* DORMANT */TTS̲DBG

H'00000020/* デバッグ待ち */tskwait:
TTW̲SLP

H'00000001/* slp̲tsk, wai̲tsk による待ち */TTW̲DLY

H'00000002/* dly̲tsk による待ち */TTW̲FLG

H'00000010/* wai̲flg による待ち */TTW̲SEM

H'00000020/* wai̲sem, uwai̲sem による待ち */TTW̲MBX

H'00000040/* rcv̲msg, urcv̲msg による待ち */TTW̲MPL

H'00000080/* get̲blk, uget̲blk による待ち */TTW̲MBF

H'00000100/* rcv̲mbf による待ち */TTW̲CAL

H'00000200/* ランデブ呼出待ち */TTW̲ACP

H'00000400/* ランデブ受付待ち */TTW̲RPL

H'00000800/* ランデブ終了待ち */TTW̲LMP

H'00001000/* get̲lbl, uget̲lbl による待ち */※ tskstat, tskwait によるタスク状態の表現はビット対応になっているため、和集合の判定を行う（例えば、WAIT または READY であることを判定する）場合に便利である。
typedef struct t̲hdrs {/* ハンドラ実行環境 */UW

emsptn;/* 例外マスク */T̲EXC*pk̲exc;/* 例外情報 */T̲REGS *pk̲regs;/* ハンドラ起動時のレジスタ */T̲EIT/* ハンドラ起動時の PC, PSW */*pk̲eit;} T̲HDRS;
typedef struct t̲exc {/* 例外情報 */UW

eclsptn;/* 例外クラスビットパターン */UW

exccd;/* 例外コード（エラーコード）*/

FN

fncd;

/* 例外発生システムコール機能コード */VW̲Wrsv̲10;/* インプリメント依存追加情報 */第三章 ITRON 2 レファレンス

502
...
} T̲EXC;※ システムコール例外でない場合は、fncd は 0 となる。
※ fncd は、拡張SVCからの戻り時に発生するシステムコール例外の時にも有効である。例えば、拡張SVC{S} から ret̲svc で戻る際には、s̲ercd の値により、戻り先のコンテキストでシステムコール例外を発生する場合がある。この時、そのシステムコール例外ハンドラに対して渡される情報(T̲EXC)の中の fncdの値は、{S}の機能コードになる。なお、この時の s̲ercd の値は、exccd あるいは pk̲regs の中の r0 を参照することによって得ることができる。
typedef struct t̲regs {
VW

r0;

VW

r1;

VW

r2;

VW

r3;

VW

r4;

VW

r5;

VW

r6;

VW

r7;

VW

r8;

VW

r9;

VW

r10;

VW

r11;

VW

r12;

VW

r13;

VW

r14;

VW

sp;

} T̲REGS;※ システムコール例外の発生時にこのパケットを参照した場合、r0 は ercd
なので pk̲exc のexccd と等しくなる。
※ システムコール例外の発生時にこのパケットを参照した場合、r1〜 の内容が例外を発生したシステムコールのパラメータとなる。
第四部 レファレンス

503※ 一部のシステムコールでは、r2 などでリターンパラメータとパラメータを兼ねている場合があり、リターンパラメータを返すとパラメータの情報が失われる場合がある。しかし、エラー発生の際は、できるだけエラ
ー発生前の状態に戻すのが原則である。つまり、エラーコード以外のリ
ターンパラメータは返さず、システムコール実行前のレジスタの値をそのまま残すのが望ましい。そうなれば、システムコールのパラメータはレジスタ上に保存されることになるので問題はない。
（インプリメントとの関係で検討を要する。どうしても問題がある場合は、pk̲exc の後ろの追加情報を利用する。
）
なお、r0 では ercd により fncd が必ず破壊されるので、fncd の情報のみ
は pk̲exc で別に用意している。
typedef struct t̲eit {/* ハンドラ起動時の PC,PSW（EIT情報） */PSW
psw;
EITINF eitinf;/* 終了例外や強制例外の場合は不定値 */
FP
pc;
FP
expc;
/* 無い場合もあり */IOINF
ioinf;/* 無い場合もあり */VP
eraddr;/* 無い場合もあり */VWerdata;/* 無い場合もあり */} T̲EIT;/*------------------------------------------------------------------------------------------------*/
typedef struct t̲flgs {ATR flgatr;IDwtskid;UW flgptn;} T̲FLGS;/* イベントフラグ属性 *//* 待ち行列先頭のタスクID *//* 現在のフラグ値 */flgatr:TA̲WMUL

H'00000000

TA̲WSGL

H'00000008/* 複数タスクの待ちを許す(Wait Multiple Task) *//* 複数タスクの待ちを許さない(Wait Single Task) */wfmode:TWF̲CLR1/* クリア指定 */第三章 ITRON 2 レファレンス

504
TWF̲ANDW

0/* AND待ち */TWF̲ORW

2/* OR待ち *//*------------------------------------------------------------------------------------------------*/
typedef struct t̲sems {ATR sematr;/* セマフォ属性 */ID

wtskid;/* 待ち行列先頭のタスクID */W

semcnt;/* 現在のカウント値 */} T̲SEMS;
sematr:TA̲TFIFO

H'00000000/* 待ちタスクのキューイングはFIFO */TA̲TPRI

H'00000001/* 待ちタスクのキューイングは優先度順 */TA̲FIRST

H'00000000/* 行列先頭のタスクを優先扱い */TA̲CNT

H'00000002/* 要求数の少ないタスクを優先扱い */TA̲VAR

H'00000000/* 要求/返却資源数を指定可能 */TA̲FIX

H'00000004/* 要求/返却資源数は1のみ *//*------------------------------------------------------------------------------------------------*/
typedef struct t̲mbxs {ATR

mbxatr;/* メイルボックス属性 */ID

wtskid;/* 待ち行列先頭のタスクID */T̲MSG*pk̲msg;/* 次に受信されるメッセージのアドレス */TA̲TFIFO

H'00000000/* 待ちタスクはFIFO */TA̲TPRI

H'00000001/* 待ちタスクは優先度順 */TA̲MFIFO

H'00000000/* メッセージはFIFO */TA̲MPRI

H'00000002/* メッセージは優先度順 */} T̲MBXS;
mbxatr:typedef struct t̲msg {VP

msgsent;

VP

̲Wrsv̲04;UH

msgtype;/* 現在は reserved、0 を入れる必要あり */Hmsgpri;/* メッセージ優先度 */VB

msgcont[ ];第四部 レファレンス

505} T̲MSG;/*------------------------------------------------------------------------------------------------*/
typedef struct t̲mpls {ATR mplatr;/* メモリプール属性 */ID

wtskid;/* 待ち行列先頭のタスクID */W

frbcnt;/* 空き領域全体のブロック数 */Wmaxbcnt;/* 最大の連続空き領域のブロック数 */Wmplsz;/* メモリプール全体のサイズ */W

blksz;/* メモリブロックのサイズ */W

fragcnt;/* 空きブロックのフラグメント数 */} T̲MPLS;
mplatr:TA̲TFIFO

H'00000000/* 待ちタスクはFIFO */TA̲TPRI

H'00000001/* 待ちタスクは優先度順 */TA̲FIRST

H'00000000/* 行列先頭のタスクを優先扱い */TA̲CNT

H'00000002/* 要求数の少ないタスクを優先扱い */TA̲VAR

H'00000000/* 可変長メモリブロック用のメモリプール */TA̲FIX

H'00000004/* 固定長メモリブロック用のメモリプール *//*------------------------------------------------------------------------------------------------*/
typedef struct t̲mbfs {ATR mbfatr;/* メッセージバッファ属性 */ID

wtskid;/* 待ち行列先頭のタスクID */W

bmsgsz;/* 次に受信されるメッセージのサイズ */W

maxbmsz;/* メッセージの最大サイズ */W

frbufsz;/* 空きバッファサイズ */Wbufsz;/* バッファ全体のサイズ */} T̲MBFS;
mbfatr:TA̲TFIFO

H'00000000/* 待ちタスクはFIFO */TA̲TPRI

H'00000001/* 待ちタスクは優先度順 *//*------------------------------------------------------------------------------------------------*/
typedef struct t̲pors {ATR
poratr;/* ポート属性 */第三章 ITRON 2 レファレンス

506
ID
wtskid;ID
atskid;} T̲PORS;
typedef struct t̲rdvs {ID
ctskid;ID
atskid;T̲RMSG *pk̲rmsg;/* 呼出側待ち行列先頭のタスクID *//* 受付側待ち行列先頭のタスクID *//* ランデブ中の呼出側タスクのID *//* ランデブ中の受付側タスクのID *//*返答時に渡されるメッセージを受取る
アドレス *//* 受け取ることのできるメッセージの最大長 */Wmaxrmsz;} T̲RDVS;
typedef struct t̲rmsg {W
rmsgsz;/* メッセージサイズ */VB
rmsgcont[ ];/* メッセージの中身 */} T̲RMSG;/*------------------------------------------------------------------------------------------------*/
typedef struct t̲lmps {ATR

lmpatr;/* ローカルメモリプール属性 */ID

wtskid;/* 待ち行列先頭のタスクID */W

frbcnt;/* 空き領域全体のブロック数 */Wmaxbcnt;/* 最大の連続空き領域のブロック数 */Wlmpsz;/* メモリプール全体のサイズ */W

blksz;/* メモリブロックのサイズ */W

fragcnt;/* 空きブロックのフラグメント数 */} T̲LMPS;
lmpatr:TA̲TFIFO

H'00000000/* 待ちタスクはFIFO */TA̲TPRI

H'00000001/* 待ちタスクは優先度順 */TA̲FIRST

H'00000000/* 行列先頭のタスクを優先扱い */TA̲CNT

H'00000002/* 要求数の少ないタスクを優先扱い */TA̲VAR

H'00000000/* 可変長メモリブロック用のメモリプール */TA̲FIX

H'00000004/* 固定長メモリブロック用のメモリプール *//*------------------------------------------------------------------------------------------------*/
typedef struct t̲cyhs {HATR
cyhatr;/* 周期起動ハンドラ属性 */第四部 レファレンス

507
W
VW
W
UW
} T̲CYHS;

cytime;̲Wrsv̲08;
lftime;cyhact;/* 周期 */

cyhatr:TA̲ASMTA̲HLNG

H'00000000
H'00000100/* アセンブラによるプログラム *//* 高級言語によるプログラム */cyhact:TCY̲OFF
TCY̲ON
TCY̲INI012/* 周期起動ハンドラが起動されない *//* 周期起動ハンドラが起動される *//* 周期のカウントが初期化される */typedef struct t̲alhs {HATR
alhatr;VW
̲Wrsv̲04;
VH
̲Hrsv̲08;
H
lfutime;UW
lfltime;} T̲ALHS;/* 次の起動までの残り時間(LeftTime) *//* 活性状態 *//* アラームハンドラ属性 *//* 次の起動までの残り時間（上位） *//* 次の起動までの残り時間（下位） */alhatr:TA̲ASM
H'00000000/* アセンブラによるプログラム */TA̲HLNG
H'00000100/* 高級言語によるプログラム *//*------------------------------------------------------------------------------------------------*/
typedef struct t̲ver {UH maker;/* メーカー */UH id;/* 形式番号 */UH spver;/* 仕様書バージョン */UH prver;/* 製品バージョン */UH prno[4];/* 製品管理情報 */UH cpu;/* CPU情報 */UH var;/* バリエーション記述子 */} T̲VER;/*------------------------------------------------------------------------------------------------*/

第三章 ITRON 2 レファレンス

μITRONシステムコール索引509

この索引は、本書で説明されるμITRONシステムコールのアルファベット順索引である。

act̲cyc［4］

周期起動ハンドラの活性制御を行なう152

alh̲sts［4］

アラームハンドラの状態を参照する

157

can̲wup［3］

タスクの起床要求を無効にする

92

chg̲iXX ［2B］

割込みマスク（レベル, 優先度）を変更する

136

chg̲pri［3］

タスク優先度を変更する

74

clr̲flg［3A］

1ワードイベントフラグをクリアする

94

clr̲flg［3B］

1ビットイベントフラグをクリアする

100

cpol̲flg ［3B］

1ビットイベントフラグを得る（クリア有）102

cwai̲flg ［3B］

1ビットイベントフラグを待つ（クリア有）102

cyh̲sts［4］

周期起動ハンドラの状態を参照する

153

def̲alm［#4］

アラームハンドラを定義する

154

def̲cyc［#4］

周期起動ハンドラを定義する

149

def̲int［#1］

割込みハンドラを定義する

126

def̲rst［#5］

タスクリスタートアドレスを定義する

131

dis̲int［2A］

割込みを禁止する134

ena̲int［2A］

割込みを許可する

135

ext̲tsk［2］

自タスクを正常終了する

72

flg̲sts［4A］

1ワードイベントフラグ状態を参照する

99

flg̲sts［4B］

1ビットイベントフラグ状態を参照する

105

frsm̲tsk［4］

強制待ち状態のタスクを強制再開する

86

get̲blk［4］

固定長メモリブロックの獲得待ちを行う

140

get̲tid［3］

自タスクのIDを得る

80

get̲tim［2］

システムクロックの値を読み出す

148

get̲ver［1］

ITRON,μITRONのバージョン番号を得る

160

iXX̲sts ［3B］

割込みマスク（レベル, 優先度）を参照する

137

ichg̲pri ［#3］

タスク優先度を変更する（タスク独立部専用）

74

irel̲wai［#5］

タスクの待ち状態を強制解除する（タスク独立部専用）

78

irot̲rdq［#3］

タスクのレディキューを回転する（タスク独立部専用）

76

510
86

irsm̲tsk ［#3］

強制待ち状態のタスクを再開する（タスク独立部専用）

iset̲flg ［#3A］

1ワードイベントフラグをセットする（タスク独立部専用） 94

iset̲flg ［#3B］

1ビットイベントフラグをセットする（タスク独立部専用） 100

isig̲sem ［#1］

セマフォに対する信号操作（タスク独立部専用）106

isnd̲msg ［#2］メイルボックスへ送信する（タスク独立部専用）112

isnd̲tmb ［#5］タスク付属メイルボックスへ送信する（タスク独立部専用） 119

isus̲tsk

タスクを強制待ち状態へ移行する（タスク独立部専用）

84

iwup̲tsk ［#1］

待ち状態のタスクを起床する（タスク独立部専用）

90mbx̲sts［4］

メイルボックス状態を参照する

117

mpl̲sts［4］

メモリプールの状態を参照する

144

pget̲blk［3］

固定長メモリブロックを獲得する

140

pol̲flg［3A］

1ワードイベントフラグを得る

96

pol̲flg［3B］

1ビットイベントフラグを得る（クリア無）102

prcv̲msg ［2］メイルボックスから受信する

115

prcv̲tmb ［5］タスク付属メイルボックスから受信する

121

preq̲sem ［1］セマフォ資源を得る

109

rcv̲msg［2］

メイルボックスからの受信を待つ

115

rcv̲tmb［5］

タスク付属メイルボックスからの受信を待つ

121

rel̲blk［3］

固定長メモリブロックを返却する

143

rel̲wai［5］

タスクの待ち状態を強制解除する

78

ret̲int［#1］

割込みハンドラから復帰する

129

ret̲rst［5］

割込処理復帰とタスクリスタートを行う

133

ret̲tmr［#4］

タイマハンドラから復帰する

158

ret̲wup［3］

割込処理復帰とタスク起床を行う

130

rot̲rdq［3］

タスクのレディキューを回転する

76

rsm̲tsk［3］

強制待ち状態のタスクを再開する

86

sem̲sts［4］

セマフォ状態を参照する

111

set̲flg［3A］

1ワードイベントフラグをセットする

94

set̲flg［3B］

1ビットイベントフラグをセットする

100

set̲tim［2］

システムクロックを設定する

147

［#3］

511
sig̲sem［1］

セマフォに対する信号操作（V命令）106

slp̲tsk［1］

タスクを待ち状態へ移行する

88

snd̲msg［2］

メイルボックスへ送信する

112

snd̲tmb［5］

タスク付属メイルボックスへ送信する

119

sta̲tsk［2］

タスクを起動する71

sus̲tsk［3］

タスクを強制待ち状態へ移行する

84

ter̲tsk［3］

他タスクを強制的に異常終了させる

73

tmb̲sts［5］

タスク付属メイルボックスの状態を参照する

123

tsk̲sts［3］

タスクの状態を見る

81

wai̲flg［3A］

1ワードイベントフラグを待つ96

wai̲flg［3B］

1ビットイベントフラグを待つ（クリア無）102

wai̲sem［1］

セマフォに対する待ち操作（P命令）109

wai̲tsk［3］

タスクを一定時間待ち状態に移行する

88

wup̲tsk［1］

待ち状態のタスクを起床する

90

ITRON2システムコール索引513

この索引は、本書で説明されるITRON2システムコールのアルファベット順索引である。

abo̲tsk

自タスクを異常終了させる

200

acp̲por

ポートに対するランデブの受け付け

372

act̲cyc

周期起動ハンドラの活性制御を行なう

420

alh̲sts

アラームハンドラの状態を参照する

426

blk̲sts

共有メモリブロックの状態参照

329

cal̲por

ポートに対するランデブの呼び出し

368

can̲cyc

タスクに出された周期起床要求を解除する

336

can̲wup

タスクの起床要求を無効にする

230

chg̲ims

割込みマスクを変更する

272

chg̲pri

タスク優先度を変更する

207

clr̲ems

例外処理マスククリア

307

clr̲flg

イベントフラグをクリアする

235

cre̲flg

イベントフラグを生成する

232

cre̲lmp

ローカルメモリプールの生成395cre̲mbf

メッセージバッファを生成する

355

cre̲mbx

メイルボックスを生成する

254

cre̲mpl

メモリプールの生成318

cre̲por

ランデブ用のポートを生成する

365

cre̲sem

セマフォを生成する

243

cre̲tsk

タスクを生成する

191

cyh̲sts

周期起動ハンドラの状態を参照する

422

def̲alm

アラームハンドラを定義する

423

def̲cex

タスク用CPU例外ハンドラの定義

298

def̲cyc

周期起動ハンドラを定義する

417

def̲ext

タスク用終了ハンドラの定義

298

def̲fex

タスク用強制例外ハンドラ

389

def̲int

割込みハンドラを定義する

268

514
def̲sex

タスク用システムコール例外ハンドラの定義

298

def̲svc

拡張SVCハンドラを定義する

338

del̲flg

イベントフラグを削除する

234

del̲lmp

ローカルメモリプールを削除する

398

del̲mbf

メッセージバッファを削除する

358

del̲mbx

メイルボックスを削除する

256

del̲mpl

メモリプールを削除する

321

del̲por

ランデブ用のポートを削除する

367

del̲sem

セマフォを削除する

247

del̲tsk

タスクを削除する

195

dly̲tsk

タスクの遅延を行う

333

end̲exc

例外ハンドラの終了

304

exd̲tsk

自タスクを正常終了後、削除する

198

ext̲tsk

自タスクを正常終了する

196

flg̲sts

イベントフラグ状態を参照する

241

frsm̲tsk

強制待ち状態のタスクを強制再開する

226

fwd̲por

ポートに対するランデブの回送

377

get̲blk

共有メモリブロックを獲得する

322

get̲lbl

ローカルメモリブロックを獲得する

399

get̲tid

自タスクのIDを得る

212

get̲tim

システムクロックの値を読み出す

332

get̲ver

ITRONのバージョン番号を得る

345

hdr̲sts

ハンドラ実行環境を参照する

216

idef̲cex

タスク独立部用CPU例外ハンドラの定義

312

idef̲ext

タスク独立部用終了ハンドラの定義

312

idef̲sex

タスク独立部用システムコール例外ハンドラの定義

312

lbl̲sts

ローカルメモリブロックの状態参照

404

lmp̲sts

ローカルメモリプールの状態を参照する

402

mbf̲sts

メッセージバッファ状態を参照する

363

mbx̲sts

メイルボックス状態を参照する

262

515
mpl̲sts

メモリプールの状態を参照する

326

por̲sts

ポート状態を参照する

384

psw̲sts

プロセッサ状態語を参照する

352

ras̲fex

他タスクに対する強制例外の発生

392

ras̲ter

他タスクに対して終了要求を出す

204

rcv̲mbf

メッセージバッファから受信する

361

rcv̲msg

メイルボックスから受信する

260

rdv̲sts

ランデブ状態を参照する

386

rel̲blk

共有メモリブロックを返却する

325

rel̲lbl

ローカルメモリブロックを返却する

401

rel̲wai

タスクの待ち状態を強制解除する

210

ret̲exc

例外ハンドラから復帰

302

ret̲int

割込みハンドラから復帰する

271

ret̲svc

拡張SVCハンドラから復帰する

341

ret̲tmrタイマハンドラから復帰する

427

rot̲rdq

タスクのレディキューを回転する

208

rpl̲por

ポートに対するランデブの返答

382

rsm̲tsk

強制待ち状態のタスクを再開する

226

sdef̲cex

拡張SVC用CPU例外ハンドラの定義

431

sdef̲ext

拡張SVC用終了ハンドラの定義

431

sdef̲sex

拡張SVC用システムコール例外ハンドラの定義

431

sem̲sts

セマフォ状態を参照する

252

set̲ems

例外処理マスクセット

310

set̲flg

イベントフラグをセットする

235

set̲tim

システムクロックを設定する

331

sig̲sem

セマフォに対する信号操作（V命令）248

slp̲tsk

タスクを待ち状態へ移行する

227

snd̲mbf

メッセージバッファへ送信する

359

snd̲msg

メイルボックスへ送信する

257

sta̲tsk

タスクを起動する

194516
sus̲tsk

タスクを強制待ち状態へ移行する

223

ter̲tsk

他タスクを強制的に異常終了させる

204

tsk̲sts

タスクの状態を見る

213

uget̲blk

共有メモリブロックを獲得する（メモリ更新有）412

uget̲lbl

ローカルメモリブロックを獲得する（メモリ更新有）412

urcv̲msg

メイルボックスから受信する（メモリ更新有）410

urel̲blk

共有メモリブロックを返却する（メモリ更新有）414urel̲lbl

ローカルメモリブロックを返却する（メモリ更新有）414

usig̲sem

セマフォに対する信号操作（メモリ更新有）406

usnd̲msg

メイルボックスへ送信する（メモリ更新有）409

uwai̲sem

セマフォに対する待ち操作（メモリ更新有）

407

wai̲flg

イベントフラグを待つ

237

wai̲sem

セマフォに対する待ち操作（P命令）250

wai̲tsk

タスクを一定時間待ち状態に移行する

227

wup̲tsk

待ち状態のタスクを起床する

229

ITRON・μITRON標準ハンドブック
1990年 12月 15日 初版 1 刷発行
監
発

行

修

坂村 健

所

パーソナルメディア株式会社
東京都品川区平塚1-7-7 MYビル

電 話

東京 (03) 5702-0502

振 替

東京 4- 105703

印刷／製本

〒142

倉敷印刷

Printed in Japan
定価はカバーに記載© 1990 TRON ASSOCIATION

ISBN4-89362-079-7 C3055