GNURX用のCCRXmachine.hとCCRXmachine.cというソースがe2 studioフォルダにありました(内容は概ね名前から予想される通りのものでした)

こんにちは。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.h



e2 studioインストールフォルダ\internal\projectgen\rx\Generate\CCRXConversion\inc\CCRXmachine.c



Parents
  • こんにちは。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.pdf
    xchg()関数の備考に以下の記述あり(私が紫枠で囲った部分)

    生成されるXCHG命令は、data2が指す位置のメモリオペランドを持ちます。



    RXファミリ ユーザーズマニュアル ソフトウェア編
    www.renesas.com/ja-jp/doc/products/mpumcu/doc/rx_family/r01us0032jj0120_rxsm.pdf
    XCHG命令の説明に以下の記述あり(私が赤枠で囲った部分)(紫枠で囲った部分は先程のxchg()関数の紫枠と対応)

    実装により、排他制御に使える場合があります。詳細については、各製品のハードウェアマニュアルを参照してください。



    実は、xchg()関数の2つの引数のdata1とdata2に関しては、どちらがXCHG命令のメモリオペランドでどちらがレジスタオペランドなのかを把握しないと、xchg()関数でセマフォのロックを正しく行うことが出来ません。逆に言えば、xchg()関数が、単にデータ交換を行うことしか意図されていない関数なら、引数とオペランドの対応関係はマニュアルに記載する必要は無いのです。つまり、それが記載されているということから、xchg()関数は、ただ単にデータ交換を行うことだけを意図されている関数では無い、ということが分かるのです。

Reply
  • こんにちは。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.pdf
    xchg()関数の備考に以下の記述あり(私が紫枠で囲った部分)

    生成されるXCHG命令は、data2が指す位置のメモリオペランドを持ちます。



    RXファミリ ユーザーズマニュアル ソフトウェア編
    www.renesas.com/ja-jp/doc/products/mpumcu/doc/rx_family/r01us0032jj0120_rxsm.pdf
    XCHG命令の説明に以下の記述あり(私が赤枠で囲った部分)(紫枠で囲った部分は先程のxchg()関数の紫枠と対応)

    実装により、排他制御に使える場合があります。詳細については、各製品のハードウェアマニュアルを参照してください。



    実は、xchg()関数の2つの引数のdata1とdata2に関しては、どちらがXCHG命令のメモリオペランドでどちらがレジスタオペランドなのかを把握しないと、xchg()関数でセマフォのロックを正しく行うことが出来ません。逆に言えば、xchg()関数が、単にデータ交換を行うことしか意図されていない関数なら、引数とオペランドの対応関係はマニュアルに記載する必要は無いのです。つまり、それが記載されているということから、xchg()関数は、ただ単にデータ交換を行うことだけを意図されている関数では無い、ということが分かるのです。

Children
  • NoMaYさん、fujitaさん

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

    本件、なんらか見解だすように関係者に依頼しました。進展ありましたら、書き込みます。
    私としてはfujitaさんのコードを暫定として適用するのが今の対策としてよいと思いました。
    ご協力に感謝いたします。

    以上です
  • NoMaYさん
    ほやです。
    > xchg()関数でセマフォのロックを正しく行うことが出来ません。
    まあまあ、
    XCHG命令として吐かないと「そういう目的には」使えない、って話は皆さん解っているとは思いますよ。

    ・GCCで実装されていないのだから体裁だけでもあるだけマシ
    ・体裁だけあっても紛らわしいだけ
    どちらと見るかは何に使おうとしているかに寄るのかと。
  • fujitaさん、NoMaYさん
    検証による証明、ご指摘、ありがとうございます。
    お手数をおかけしました。

    本来のテーマから若干のずれは把握してましたが、
    一時変数を使用せず、変数の整数データを交換をするだけ。
    の意図でした。すみません。