Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page

CC-RLのコンパイルについて

SFRのビットセット

ADCS = 1U;

コンパイルすると

movw  hl, #0xFF30

set1  [hl].7

となるんですね。

CAは

set1  ADM0.7

としてくれるんですが...

2バイト、1クロックの損だな。うーん。

  • チョコです。

    CC-RLは、出たばかりで、これからよくなっていくと期待しています。

  • In reply to チョコ:

    私も期待しております。

    命令組み合わせハザードによりもう1クロック余計に掛かる筈ですね。

    スミマセン。訂正いたします。

  • In reply to skyblue22:

    CC-RL V1.01を使ってみたら、

    SET1 ADCS (機械語 71 7A 30)

    が展開されました。

    1命令で出ています。

  • In reply to Higetaka:

    私が使用しているのもV1.01なのですが

    オプション設定の違いでしょうか?

  • In reply to skyblue22:

    何だか、謎が潜んでいるようですね。

    ---

    こちらは、以下の方法で確認しました。

    ・RL78/G10を選んで、空のプロジェクトを作成

    ・mainのソースでiodefine.hをinclude

    ・mainにADCS=1を記述

    ・ビルド後、RL78シミュレータにローディングして逆アセンブル結果を確認

    ---

    あと、RL78/G13のサンプルプロジェクトに似たような事をやってみましたが、結果はやはり1命令で展開されていました。

    オプションはデフォルト状態で、特に変更しない状態で確認していました。

    最適化オプションを変更したら何か変わるかと思い、追加で試しましたが、特に変化は見られませんでした。

    ---

    今環境が手元にないので、後程、シンプルな事例のプロジェクトを固めてアップしてみます。

  • In reply to Higetaka:

    1命令で展開されたシンプルな事例をアップしました。

    CS+ for CC V3.01のプロジェクトです。

    Test_G13プロジェクトは、RL78/G13で作成した空プロジェクトにADCS=1の1文を追加したものです。

    DefaultBuild/main.prnは、アセンブルリストです。(以下に抜粋)

    ---

    00000000 15 .SECTION .textf,TEXTF
    00000000 16 _main:
    00000000 17 .STACK _main = 4
    00000000 18 .LINE "C:/Develop/Renesas/CS/RL78/Test_G13/main.c", 18
    00000000 717A30 19 set1 0xFFF30.7 ★ ここがADCS=1
    00000003 D7 20 ret

    ---

    違いが生じるとしたら、デバイス構成ファイルが違うのではないかと考えています。

    こちらでは、1命令以外で生成される状態を再現できていません。

    具体的に指定しているデバイスが何かが気にかかっています。

    Test_G13.zip
  • In reply to Higetaka:

    いろいろ試していただいてありがとうございます。

    G10と伺って「もしや」と思いました。

    こちらでもG13のR5F100GCで試しますと1命令のコードが生成されました。

    2命令で生成されたのはG12のR5F102AAでした。

    同じG12のR5F1026Aも2命令生成するようです。

    G12もG13も主流のS2コアなのでデバイスの違いはないのだろうと考えてしまっていました。

  • In reply to skyblue22:

    スミマセン。G12でも空のプロジェクトにADCS = 1U;を追加しただけの

    ソースをコンパイルすると1命令を生成しました。

    同じプロジェクトでも、2命令を生成するソースと上記の1命令を生成するソースでコンパイル結果が変わってくるので

    ソースの記述内容で結果が変わるのではないかと思われます。

  • In reply to skyblue22:

    なるほど、デバイスではなく記述状態で変化するということですか。実に興味深いですね。

    実は、CC-RLがLLVMを採用しているという事で、歌い文句のように性能の良いコードをはいてくれるのかが気になっています。

    (他にLLVM採用をうたっているARM以外のコンパイラを知らないので)

    ---

    そうなると

    ・コンパイラが何等かのメリットがあって、意図的にレジスタ間接アドレッシングを採用している。

    ・単なるバグ

    の線が考えられますね。

    ---

    可能性として、関数内で同一SFRの複数ビットを操作している時にレジスタ間接アドレッシングにすると、コードサイズがトータルで少なくなるとか、パイプラインの通りが良いとかがあると思います。

    ---

    お手数ですが、2命令生成するサンプルを出していただく事は可能でしょうか?

  • In reply to skyblue22:

    結論としては最適化の影響と思われます。

    2命令を生成するソースは大体次のような構造になっておりまして

        ADCE = 1U;

        (他のコード)

        ADCS = 1U;

        (他のコード)

        ADCS = 1U;

    コンパイルすると、

        set1 0xFF30.0 ;ADCE = 1

        (他のコード)

        set1 0xFF30.7 ;ADCS = 1

        (他のコード)

        set1 0xFF30.7 ;ADCS = 1

    となると想像しておりましたが、

    最適化により、

        movw HL,#0xFF30

        set1 [HL].0

        (他のコード)

        set1 [HL].7

        (他のコード)

        set1 [HL].7

    としたものと思われます。

    ただし、実際のソースでは(他のコード)の部分でHLが破壊されるので

        movw HL,#0xFF30

        movw AX,HL

        set1 [HL].0

        (他のコード)

        movw HL,AX

        set1 [HL].7

        (他のコード)

        movw HL,AX

        set1 [HL].7

        movw HL,#0xFF30

        set1 [HL].0

       (他のコード)

        movw HL,#0xFF30

        set1 [HL].7

        (他のコード)

        movw HL,#0xFF30

        set1 [HL].7

    としてしまうようです。

    Higetakaさんには

    断片的な記述でご迷惑をおかけしまして申し訳ありませんでした。

  • In reply to skyblue22:

    void main(void)

    {

    unsigned short data1;

    ADCE = 1U; //A/D電圧コンパレータ動作許可(消費電流増加)

    ADIF = 0U;

    ADMK = 0U; //A/D変換終了によるHALT解除を許可

    ADS = 0U;    //ANI0

    ADCS = 1U;    //A/D変換開始

    __halt();    //A/D変換終了を待つ

    ADIF = 0U;

    data1 = (ADCR >> 6);

    ADCE = 0U;    //A/D電圧コンパレータ動作停止(消費電流減少)

    ADMK = 1U;    //A/D変換終了によるHALT解除を禁止

    }

    //ご参考までに抜粋して書き込ませていただきます

  • In reply to skyblue22:

    こちらこそ、興味深い情報をありがとうございます。

    これで、#pragma SFRが廃止された理由が納得できました。

    CC-RLはいろいろとやってくれそうな感じですね。

    しかし、最後の事例はちょっと?ですね。

    こういう時は、意図的に1命令を生成させるために、インラインアセンブラを使ったらどうかと考えていたのですが、効果が得られたら報告したいと思います。

  • In reply to Higetaka:

    他にLLVM採用をうたっているARM以外のコンパイラを知らないので

    clang の他では CC-RX がそうですね。 CC-RX については、以前個人的に確認した限りでは他のコンパイラに比べて性能は芳しいものではありませんでした。RL78 では、 同様の比較をした範囲では CC-RL は良い結果を出したので、同じ LLVM 採用といっても一筋縄ではないようです。

  • In reply to fujita nozomu:

    あれ、CC-RXはいつのまにかLLVMになっていたのですね。

    V2からでしょうか?

  • In reply to Higetaka:

    古いドキュメントは見当たらなかったのですが、CC-RX は V1 と V2 は別製品という扱いでライセンスも継承されないという鬼仕様なのでそのタイミングで変わったのではないかと思います。

Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page