R8C/34C　Cコンパイラ　割り込み応答時間

1サイクル単位の非常に細かな実行時間を気にしているように思えます。C言語は使わずにアセンブラでコンテキストの退避などを自分で作成する必要があるのでは？割り算掛け算もシフト命令などで可能かも？高級言語使用と非常に細かな実行時間の考慮は矛盾しているように感じます。私はR8Cを使ったことがありますが、命令セットを勉強したことが有りません。akasuimonさんの応用では本当にR8Cで良いのでしょうか？例えば、データ転送命令もマイコン毎でそれなりの差がでます。TIなどは直行型ニーモニックと称してすべての領域で一発で転送ができることをウリにしてます。マイコンそのもの選択を再検討する必要もありそうに感じます。ポータビリティーや検証のしやすさ、最近の高度な応用などからちょっと高くても高性能マイコンと高給言語の選択がお得な気がします。

割り込み応答時間を短くしたいということは割込処理にかかる時間を短くしたいということだと解釈します。
で、処理の内容がどういうものなのか分かりませんが根本的に割り込みルーチンは極力シンプルにまとめるしかないと思います。
コンパイラにとって最大サイクル数を保証するなんてことはループがあったら何回回るか分からないし関数コールがあったらその関数の処理時間は分からないので無理でしょ。
よって割込処理は
　長いコードを書かない\,ループは極力させない
　関数呼び出しはなるべく避ける
でしょう。コンパイラの最適化は最後の調整くらいに考えるべきです。
それでも無理ならMCUをもっと高速のものにするしかないと思います。

マイコンの選定はプロジェクトで決定事項のものとして…

実際に割り込み処理を軽くするためにはポーリングを活用するなりの工夫が必要でしょう。取りこぼしたときのことも検討しておいてください。


以下余談。

サイクル数の制限、と書かれていますが割り込み内で処理すべき内容は「単純」かつ「変更のない」ものなのでしょうか？追加項目が発生した時に破たんしなければいいのですが。。。

そして、コンパイラには「ループ回数分コード展開する」オプションはありましたが、関数ごとの実行サイクル数を制限するようなオプションは探せませんでした。

他の皆さんも心配されているように、割り込み処理時間を保証はかなりシビアな問題です。確実な時間内実行を保証したいのであれば、マイコンの選定を覆す覚悟も必要でしょう。

私が問題にしているのは、ハードウェア割り込みで割り込み発生から割り込みサービスルーチンが実行されるまでの時間（遅れ）です。
R8CはCISCなので、実行中の命令により遅れが変動しますが、この変動をなるべく少なくしたいため、コンパイラが出力する命令をサイクル数が少ない命令に限定したいわけです。
命令のサイクル数は1から30まで変動する可能性が有り、現在CPUのクロックを4.6MHzで動作させているので、遅れは0.22usから6.5usまで変動する可能性があります。
クロックを上げれば変動を小さくすることができますが、消費電流などを考慮するとなるべく4.6MHzのまま行きたいところです。
特に条件ブランチやDIV命令が遅いので、これだけでも抑止できればありがたいですね。

>DIV命令が遅いので、これだけでも抑止できればありがたいですね。

　先日の「ルネサス　エンジニア　フォーラム　２０１２」の
Ｄ－ＲＳ４（鹿取祐二さん）で説明していました。

　資料がWebサイトに公開されているのですが、パスワードが設定されています。

　そこには以下のように書かれています。

DIV命令は3～22サイクル、DIVU命令は2～20サイクル、FDIV命令は16～18サイクルです。
その間は割り込みを受け付けることができません。
「除算、剰余算をDIV\,DIVU\,FDIV命令で生成する」オプションはサイクル数の長い命令を抑止します。
ただし、ランタイムライブラリを使った結果となりますから、全体の実行速度は低下します。
割り込みの応答速度を重視するシステムでは重要なオプションとなります。