こんにちは。NoMaYです。e2 studio v6.3.0がリリースされていたので、インストールして幾つかプロジェクトを作成して、いつものようにe2 studioのインストールフォルダを眺めていたら、CCRXmachine.hとCCRXmachine.cというファイルがあることに気付きました。中を見てみると、概ねファイル名から予想される通りのソースファイルでした。(今までのe2 studioのインストールフォルダを見直してみたところ、以前からあったことが分かりましたが、今まで気付きませんでした。) ただ、一部コメントアウトされているものがあったり、以前に別スレッド『GUNRX用プロジェクトのスマートコンフィグレータのBSPを見ていて気付いた変な移植コード』で話題にしたことと同じ元のコードの意図を理解していない書き換えがあったり、ちょっと惜しいような気もしました。e2 studioインストールフォルダ\internal\projectgen\rx\Generate\CCRXConversion\inc\CCRXmachine.he2 studioインストールフォルダ\internal\projectgen\rx\Generate\CCRXConversion\inc\CCRXmachine.c
こんにちは。NoMaYです。fujitaさん、xchg()のGNURXでの実装例は、別スレッド『Amazon FreeRTOSだそうです。ルネサスさんのRXは参加しないのかな?』でCC-RX用プロジェクトをGNURX用プロジェクトへ移植する際に参考にさせて頂こうと思います。有難う御座います。ほやさん、LEONさん、お二人のリプライの文面から察するに、別スレッド『GUNRX用プロジェクトのスマートコンフィグレータのBSPを見ていて気付いた変な移植コード』でのCC-RXによるr_bspモジュールをGNURXによるr_bspモジュールへ移植したプログラマ殿や、本スレッドでのCC-RXのxchg()関数をGNURXによるxchg()関数へ移植したプログラマ殿と、同じ勘違いをされている状態なのだと思われます。その別スレッドに私が書いた文面と一部重複するのですが、この関数は、ただ単にデータ交換を行うだけの関数では無く、RXマイコンのXCHG命令でセマフォのロックを行う操作をプログラマがアセンブラ記述しなくても行えるようにすることも意図されている関数なのです。その意図が分かるのは『CC-RXコンパイラ ユーザーズマニュアル 』と『RXファミリ ユーザーズマニュアル ソフトウェア編』の以下の画面コピーにある記述からです。CC-RXコンパイラ ユーザーズマニュアル www.renesas.com/ja-jp/doc/products/tool/doc/011/r20ut3248jj0105-ccrx.pdfxchg()関数の備考に以下の記述あり(私が紫枠で囲った部分)「生成されるXCHG命令は、data2が指す位置のメモリオペランドを持ちます。」RXファミリ ユーザーズマニュアル ソフトウェア編www.renesas.com/ja-jp/doc/products/mpumcu/doc/rx_family/r01us0032jj0120_rxsm.pdfXCHG命令の説明に以下の記述あり(私が赤枠で囲った部分)(紫枠で囲った部分は先程のxchg()関数の紫枠と対応)「実装により、排他制御に使える場合があります。詳細については、各製品のハードウェアマニュアルを参照してください。」実は、xchg()関数の2つの引数のdata1とdata2に関しては、どちらがXCHG命令のメモリオペランドでどちらがレジスタオペランドなのかを把握しないと、xchg()関数でセマフォのロックを正しく行うことが出来ません。逆に言えば、xchg()関数が、単にデータ交換を行うことしか意図されていない関数なら、引数とオペランドの対応関係はマニュアルに記載する必要は無いのです。つまり、それが記載されているということから、xchg()関数は、ただ単にデータ交換を行うことだけを意図されている関数では無い、ということが分かるのです。