最近Atom IDEとかVisual Studio Codeとか新しい開発環境が出て来てますね(Renesas CSplusと連携させる方法を探したいですね)

こんにちは。NoMaYです。

来年は(来年こそは)何かやってみたいです、、、

＞ 最近、Atom IDE(まだC/C++サポートは無い模様)とかVisual Studio Code(C/C++サポートのプレビュー版は有る模様)とか、新しい開発環境が出て来ていますね。ルネサスCS+と連携させる方法を探してみたいですね。

こんにちは。NoMaYです。

Visual Studio Codeのブラウザ版だそうです、、、

Webブラウザで開発できる、インストール不要のWeb版VSCode登場
2021/10/25 11:11 著者：後藤大地
news.mynavi.jp/article/20211025-2168756/

[関連リンク]

エンジニアに愛されているエディタ、第1位は？
2021/08/07 21:07 著者：後藤大地
news.mynavi.jp/article/20210807-1939915/
　

こんにちは。NoMaYです。

e2 studio 2021-10に同梱されているrx-elf-gdb.exeとe2-server-gdb.exeをコマンドラインから起動して接続してみました。苦戦しましたが何とか出来るようになりましたので、週末にVSCodeをインストールしてみます、、、

RX Simulator環境でコマンドラインからプロジェクトを実行する
japan.renesasrulz.com/cafe_rene/f/forum5/7608/rx-simulator/40123#40123

こんばんは、尭です。

WebベースのコードエディタですがVSCodeをフォークしたEclipse Theiaなるものもあります。
https://theia-ide.org/

　VSCodeでC/C++のソースコードを編集するときは大抵Microsof  C/C++ Extensionのお世話になると思いますが、Renesas純正環境のRX用ソースコードを開くと「__evenaccess」修飾子の影響によりI/Oレジスタ関連でインテリセンスが機能しない現象が起きます。
　プリプロセッサの定義の所に「__evenaccess=」と追加すれば該当の修飾子は無視されて期待通りに機能しますが・・・過去にも議論があったようにこの修飾子が存在する意味はあまりないですよね。

尭さん、エビスクラウンです。

過去の議論は拝見していませんが、ルネ純正のCC-RXには必要な修飾子です。例えば、

unsigned short a;

    a %= 256;

などと記述すると、CC-RXは16ビットではリードせず、下位の８ビットだけをゼロ拡張でリードし、16ビットでライトします。勿論、aのように単なるメモリならば、それでも良いのですが、周辺機能のようにアクセスサイズが16ビット固定のような場合、このままだと正しく動作しないことになります。

通常はvolatileの型修飾子で対策するのですが、CC-RXは違っており、volatileを付けても結果は変わりません。

その対策が__evenaccessです。これを付けると、変数のサイズを守り、16ビットでリード・ライトを行うようになります。つまり、CC-RXはアクセスサイズの厳守はvolatileではなく、__evenaccessで対策する仕様となっています。

最適化が絡みますので、処理系毎に仕様が違うのは仕方がないと思うのですが、如何でしょうか？

こんにちは。尭です。

自分はその議論に参加していたわけではないのですがこのスレッドですね
CC-RXでvolatile指定有り__evenaccess指定無しのobjectへのaccess sizeが保証されないのは言語規格上妥当なのかな？ - 102: ＲＸ - Forum - かふぇルネ - Renesas Rulz
japan.renesasrulz.com/.../cc-rx-volatile-__evenaccess-object-access-size
上記スレッドで指摘されていますがvolatile修飾子が__evenaccess修飾子を内包すれば済む話に思います。

尭さん、エビスクラウンです。

はい。済む話だと私も思いますが、別に分かれていても私は良いのは？と思っています。

と言うのも、周辺機能に的を絞れば確かにそうですが、バス幅固定の外バス接続メモリの場合、__evenaccessがピッタリではないかと思っています。

今時は無いかも知れませんが、バス幅さえ守ってくれれば、最適化は行って欲しい、何て場合です。今は無いのかも知れませんが、小生が現役時代は結構あったものですから。。。

こんにちは。NoMaYです。

そのスレッドを投稿していた時の最後では、ビッグエンディアン設定時の#pragma bit_order left 又は rightが関係するのかも？と書いて以後は他のことに気を取られてケアしていませんでしたけれど、今でもこの#pragmaの件は気にはなっています。例えば、RX65NのGNURXプロジェクトのiodefine.hは以下のようになっていますけれど、このビッグエンディアンとリトルエンディアンの切り替え機構(同じものでなくても相当するもので良くて)をCC-RXのiodefine.hに持たせないと、volatileが言語仕様に従うようになっても(厳密には例えばvolatileの16ビット内蔵周辺レジスタを8ビットづつ2回に分けて操作しても言語仕様には反しないという点はありますが)、iodefine.hから__evenaccessを無くすことが出来ないかも知れないと今のところ思っています。(すみません、3年放置していて、今だに検証していません。)

[追記] ん？私は間違えたかな？図とか描いてちゃんと考えないと私では駄目かも(単に年のせいかも？)、、、[ここまで追記]

なお、以下の各iodefin.hですが、最近ダウンロードしたHS300xのプロジェクトにあったRX65NのBSPモジュールのもので、ルネサスさんのiodefine.h生成ツールで生成されたもののようです。(IAR社のICCRX向け版はIAR自体が提供している素のものとは異なる筈であり、そもそもIAR社のものはファイル名がiodefine.hでは無いのです。)

RX65NのCC-RXプロジェクトのiodefine.h

#pragma bit_order left
#pragma unpack
...
#define BSC         (*(volatile struct st_bsc     __evenaccess *)0x81300)
...
typedef struct st_bsc {
...
    union {
        unsigned short WORD;
        struct {
            unsigned short ADDR:13;
            unsigned short :3;
        } BIT;
    } BERSR2;
...
} st_bsc_t;
...
#pragma bit_order
#pragma packoption

　
(参) RX65NのGNURXプロジェクトのiodefine.h (注目点は上記のCC-RXの定義は下記のGNURXのビッグエンディアン側です)

#pragma pack(4)
...
#define BSC         (*(volatile struct st_bsc      *)0x81300)
...
typedef struct st_bsc {
...
    union {
        unsigned short WORD;
        struct {
            
#ifdef __RX_LITTLE_ENDIAN__
            unsigned short  : 3;
            unsigned short ADDR : 13;
#else
            unsigned short ADDR : 13;
            unsigned short  : 3;
#endif
        } BIT;
    } BERSR2;
} st_bsc_t;
...
#pragma pack()

　
(参) RX65NのICCRXプロジェクトのiodefine.h

#ifdef __IAR_SYSTEMS_ICC__
#pragma language=save
#pragma language=extended
#ifndef _SYSTEM_BUILD
#pragma system_include
#endif
#endif

#ifdef __IAR_SYSTEMS_ICC__
#define __evenaccess
#else
#define __sfr
#endif
...
#define BSC         (*(volatile struct st_bsc     __sfr __evenaccess *)0x81300)
...
#ifdef __IAR_SYSTEMS_ICC__
#pragma bitfields=reversed
#else
#pragma bit_order left
#endif

#ifndef __IAR_SYSTEMS_ICC__
#pragma unpack
#endif

typedef struct st_bsc {
...
    union {
        unsigned short WORD;
        struct {
            unsigned short ADDR:13;
            unsigned short :3;
        } BIT;
    } BERSR2;
...
} st_bsc_t;
...
#ifdef __IAR_SYSTEMS_ICC__
#pragma bitfields=default
#pragma language=restore
#else
#pragma bit_order
#endif

#ifndef __IAR_SYSTEMS_ICC__
#pragma packoption
#endif

こんにちは。NoMaYです。

ひとつ思い出したのですけど、CC-RXの内蔵周辺I/O定義ファイルではちょっとしたマクロの小技でIntelliSenseが誤動作しないように出来るのですけど、他のコンパイラには何とも手の打ちようがなくてIntelliSenseやCODANが誤動作するのを指を咥えて見ているしかないものもありますね。私が知っているものはIAR社のICCRL78の内蔵周辺I/O定義ファイルですが、以下のようなC言語標準外の拡張文法が使われています。

__sfr __no_init volatile union
{
  unsigned char ADM0;
  __BITS8       ADM0_bit;
  struct
  {
    unsigned char  ADCE:1;
    unsigned char  :6;
    unsigned char  ADCS:1;
  };
} @ 0xFFF30;

構造体__BITS8の定義は以下の通りで特にマズイところは無いのですが、上記で内蔵周辺I/Oレジスタのアドレスを指定するのに使われている「@ アドレス数値」という構文が、もうどうにもこうにもならないのです。(__sfr __no_initはCC-RXと同様のマクロの小技で何とかなるのですけど。)

#ifndef __RL78_BIT_STRUCTURE__
  #define __RL78_BIT_STRUCTURE__
  typedef struct
  {
    unsigned char no0:1;
    unsigned char no1:1;
    unsigned char no2:1;
    unsigned char no3:1;
    unsigned char no4:1;
    unsigned char no5:1;
    unsigned char no6:1;
    unsigned char no7:1;
  } __BITS8;
#endif

こんにちは。NoMaYです。

ひとつ思ったのですが、よくよく考えると、GCCの変数アトリビュートや関数アトリビュートの__attribute__((XXX))もC言語標準外の拡張文法ですね。表面的には関数呼び出しの見掛けに見えますが、でも、変数の宣言/定義や関数の宣言/定義のその場所には関数呼び出しは書けないよね、ということで本来はエラーになる筈ですね。ただ、GCCのネームバリューのお陰で、最初から or 早期に、それらがケアされるようになっている、ということなのですね。

今考えてみたらという話ですけど、CC-RX V1.00が出た時に__evenaccessの他に__attribute__((evenaccess))とも書けるようになって、iodefine.hでは__attribute__((evenaccess))と書く方を採用していたら、IntelliSenseやCODANとの相性が良くなって、結果、槍玉に挙げられることも無かったのかなぁ、と思ったりしたのでした、、、