(toppers-users 474) Re: TOPPERS/JSP の実装で教えてください。

[Tatsuhiko Matsukawa]

高田さん、再びコメントありがとうございます。

> ただ、itron.h ですべてのコンパイラのバリエーションを吸収するのは、読み
> やすさを損なうと考えており、コンパイラ (ないしは開発環境) 依存のヘッダ
> ファイルを分離する方向で考えています。
>
> ご提案の __int32 を long と定義する方法も考えられますが、long が 32ビッ
> トという保証もないので、程度問題である気がしています。
おっしゃるとおりだと思います。(いまどきの64bitマイコンでは
intもlongも64bitなんですかね。)
中途半端に#ifdefで切り替えるよりは、ファイルを分けて
しまったほうが、可読性も保守性もよくなると思われます。

> おそらく、タイムイベントの処理のあたりが一番重いと思います。
貴重な情報、ありがとうございます。
(どこの割り込み禁止が一番長いか、これから調べようと
していたところでしたので、参考にさせていただきます。)

> ご指摘の点は、カーネル設計上の大きな分岐点でして、割込み応答性が
     ： 中略
> い標準化」の考え方を採っている理由です)。
ご意見ありがとうございます。検討してみます。
(遅延実行するサービスコールのキューイング等、
かなり大変そうですね。)

TIPPERS/JSPを含むITRONに限らず、全てのRTOSで、その
内部のクリチカルセクションの実装で割り込み禁止区間が
必要となるのは、程度の差こそあれ、しかたがないことだと
思います。
先の書き込みで、「別の方法を考えてみます」と書いたのは、
あっさり、割り込みハンドラを２種類に分けてしまおうかという
方法です。
割り込みハンドラごとにCPUロック状態で、割り込みを受け付
ける/受け付けないを、ユーザーが指定できるようにし、高い
応答性を必要とする割り込みハンドラはCPUロックでも割り込
めるようにする方法です。当然このハンドラからはITRONサー
ビスコールは(ユーザーの責任において)使用させず、必要な
クリチカルセクションの実装もユーザー独自に行う必要が
あります。
(ソフト的にも実装できそうですが、ハード的に実装したほ
うが効率がよさそうなので)これについては、盆休み明け、
Xstormy16コアのハードウェア担当者と相談してみます。
(私も盆休みに入りますので、次にメールを読むのは20日
ごろになります。)

************************
松川竜彦
KFC00725 ＠ nifty.ne.jp
************************