RXv3コアのレジスタ一括退避機能の使い方(Register Bank Save Function Usage)を調べてみるスレッド

こんにちは。NoMaYです。

RXv3コア搭載の120MH動作のRXマイコンも、RX66T以降、RX671、RX66N、RX660と品種が増えてきましたが、RXv3コアのセールスポイントの1つであるレジスタ一括退避機能の使い方が今ひとつピンと来ません。そこで、いつものように、ちょっと好奇心からスレッドを立ててみました。(注: RX66Tは、160MHz動作、レジスタ一括退避機能未搭載、です。) いつものように、ぼちぼちと続きます。

ホワイトペーパー
卓越したMCU性能と電力効率を実現するRXv3コア
2019年10月
www.renesas.com/jp/ja/document/whp/introducing-rxv3-core-superior-performance-excellent-power-efficiency#page=6

割り込み応答時間の改善

モータ制御システムなどは、高速な割り込み処理によるリアルタイム性能が必要となってきます。

RXv3コアには、割り込み処理時にレジスタを高速退避/復帰するために、オプション機能として、レジスタ退避バンクと呼ばれる専用メモリを実装しています。図6に示すように、レジスタ退避バンクを使用することで割り込み応答時間を短縮でき、割り込み処理全体の時間を短縮することができます。 割り込み処理ルーチンの中で、SAVE命令を使用すると汎用レジスタとアキュムレータを1クロックで専用メモリに保存できます。RSTR命令は、保存されたレジスタを3~6cycleで復元します。レジスタ退避バンクは専用メモリを複数面持っており、多重割り込みにも対応することが可能です。

図6.割り込み応答時間の改善

レジスタ退避バンクは、割り込みハンドラだけでなく、RTOSコンテキスト切り替えにも使用できます。 RTOSコンテキスト切り替え時間は、レジスタバンク保存機能により最大20%高速化します。


Parents Reply Children
  • NoMaYさん

    シェルティです、こんにちは。

    情報展開ありがとうございます。FreeRTOSとAzure RTOSのコンテキストスイッチのところにこの命令を埋め込んでみて本当に性能が改善できるかどうかを試してみようかと考えています。うまくいけば本家にプルリクエスト出します。

    FreeRTOS:https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/1e0843929477c8f2e2679b70d18341ee312a5fce/portable/Renesas/RX700v3_DPFPU/port.c

    Azure RTOS:https://github.com/azure-rtos/threadx/blob/master/ports/rxv3/ccrx/src/tx_thread_context_save.src

    以上です

  • シェルティさん、こんにちは。NoMaYです。

    私としてはRTOSカーネルの内部では以下の理由で使わない方が良いのではないのかなぁ?、と思っていたりします。(性能の改善に繋がらないのではないのかなぁ?、と思っていたりします。このスレッドでRTOSに関して何かしらの数値的な話にまでは辿り着けないとは思いますけれども。)

    (1) RTOSのタスクのコンテキスト切り替え処理の全体は、ホワイトペーパーにてレジスタ一括退避機能で短縮出来るとされるクロック数に対し、遥かに長い時間が掛かっていると思われ、時間の短縮分が、相対的に、ソースが煩雑になるデメリットを超えられるか微妙な気がする。(煩雑さというのは主観的なので数値化してクロック数と比較するということも難しかったりして、頭が痛いです。) (言い換えると、ホワイトペーパーの%を私は信じていません。)

    (2) 実は、実際の製品では、レジスタ一括退避先バンクは16バンクとなっていて、言い換えると、レジスタ一括退避機能をRTOSのタスクのコンテキスト切り替えに使う場合、最大16タスクまでしか使えないことになります。タスクはサブルーチンでは無いのでやみくもに増やすものでも無いとは思いますけれども、ひとそれぞれですが多数タスクを生成することを好む人もそれなりにいらっしゃるような気がする。

    (3) FreeRTOS(やNORTi)では、OS管理外の高優先度割り込みが使えるようになっていますが、そちらでレジスタ一括退避機能が使えるよう開放しておいた方が利便性が良いような気がする。このスレッドでも、(高優先度割り込みとしてでは無いのですけれども、普通にそれと対等な通常の)割り込みに関して、どの程度のクロック数のメリットがあるかについては、きっと、調べてみるだろう、と思います。(もっとも、多大なメリットがある、との結論に至るかどうかは、調べた結果次第、なのではありますけれども。)

    (4) というか、ラウンドロビンのコンテキスト切り替え処理は1msecとか10msecとかのオーダーの頻度でしかないことですので、もともと数十クロック短縮されたところで大勢に影響は無く、他方で、OS管理下の通常優先度割り込みではカーネルの内部のクリティカルセクションでの割り込み禁止時には割り込みが保留されますので、割り込み→待ち状態のタスクの起動(正しいRTOS表現で無いかも)という流れにおいて、そもそもの割り込みが保留される可能性がある以上、この流れにおいての「割り込み応答性の向上」というか「タスクのコンテキスト切り替え処理の時間の短縮」をどうこう言っても実利的では無いような気がします。

    [補足]

    (3') FreeRTOS(やNORTi)ではOS管理外の高優先度割り込みが使えるようになっている、とは言っても、RXスマートコンフィグレータというかFIT/CGで割り込み処理先頭での多重割り込み許可を設定出来ませんので、そこを小細工する方法が思い浮かばないと、レジスタ一括退避機能で数十クロックの割り込み応答性の向上が可能だと言っても実利的では無いような気がします。(ですので小細工を考えないと、、、)

  • こんにちは。NoMaYです。

    すみません、前の投稿の(1)で「RTOSのタスクのコンテキスト切り替え処理の全体」という書き方をしましたが単に「RTOSのタスク切り替え処理の全体」とした方が、私の推測/予想していることが伝わりやすかったかも知れません。