(toppers-users 357) Re: Toppers CPU ロック状態について

[Shigemitu Takata]

こんにちは
高田＠京都ソフトウェアリサーチです。

  詳しい説明ありがとうございます。

> あくまでも
>  ・CPUロック状態  = カーネルが管理している割込み/例外ハンドラ/タスクへの
>                     ディスパッチ禁止
>  ・割込み禁止状態 = CPUが管理している割込み/例外要求の受付拒否
> であり、両者は独立だということです。

  はい、私もこのように解釈しております。

> しかし、ここで「割込み禁止 = CPUロック状態」としてしまうと、
> この割り込みハンドラ実行中は常にCPUロック状態だということになってしまい、
> ほとんどのAPIが実行できません。
> また、前の項目の「ハンドラ起動時はCPUロック解除状態であるべき」に反します。
>  #V850依存部のテストのときにこの現象を体験しました

  そうですね。まさしく上記の問題がおこるので再度確認させていただきました。
 
> ここまで書いていて気づいたのですが、「割込み禁止 = CPUロック状態」という
> 実装で一番厄介なケースが割込みハンドラ内のソフトウェア例外要求です。
>  ：
>  ：
>  ：
> 上記のようなケースの場合、TRAPでハンドラを起動する前に現在
> CPUロック状態であるかどうかを判定し、CPUロック状態であれば
> 要求をペンディングするような仕組みを設けるか、
> これらの例外をカーネルの管理外とするなどの対策法がありそうです。
> 
> 利用頻度によると思いますが、個人的にはサポート外とするのが妥当だと思います。
>  #関数呼び出しやタスク例外ではなく、
>  #TRAPで起動しようとする意図がちょっと思いつきません

  思いつくところでは、デバッカ上で動作するアプリケーションでしょうか。
デバッカは、デバックしているアプリケーションで指定した breakpoint に 
trap(break) 命令を埋め込んで例外を発生させ、デバッカに処理を引き渡します
から。 
#デバッカはカーネルから独立して動くべきものですから、このケースには当て
#はまらないですね。


  以上、ありがとうございます。
/*
Shigemitu Takata <takata ＠ kyoto-sr.co.jp>
*/