最近、Atom IDE(まだC/C++サポートは無い模様)とかVisual Studio Code(C/C++サポートのプレビュー版は有る模様)とか、新しい開発環境が出て来ていますね。ルネサスCS+と連携させる方法を探してみたいですね。Google検索: Atom IDE site:マイナビニュースwww.google.co.jp/search?q=Atom+IDE+site%3Anews.mynavi.jpGoogle検索: Visual Studio Code site:マイナビニュースwww.google.co.jp/search?q=Visual+Studio+Code+site%3Anews.mynavi.jp[リンク]C/C++ for VS Code (Preview)code.visualstudio.com/docs/languages/cpp[案(当面)]・ ビルドはCS+のコマンドラインモードを使用する・ ビルドエラーメッセージパーサはVisual Studio Codeのソースを改造する・ もちろんCS+のコマンドラインモードでビルドした.absファイルはCS+のGUIモードでデバッグ可能・ e² studio同梱のrenesas_cc_converter.exeでCC-RXやCC-RLの.absファイルをGDBで読める.xファイルに変換可能・ e² studio同梱のe2-server-gdb.exeでGDBとE1/E2Lite等を接続可能・ Visual Studio CodeはGDBと接続可能(任意のGDBと接続可能かは分からないが少なくともARM GDBとは接続可能な模様)[案(将来)]・ Visual Studio CodeをルネサスCS+と接続出来れば、、、(出来ればGDBを介さずに、、、)・ Visual Studio CodeをルネサスCS+のmtpjファイル内のソース情報が読めるように改造出来れば、、、
こんばんは、尭です。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 Rulzjapan.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#endiftypedef 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との相性が良くなって、結果、槍玉に挙げられることも無かったのかなぁ、と思ったりしたのでした、、、
こんにちは、尭です。>バス幅固定の外バス接続メモリの場合、__evenaccessがピッタリではないかと思っています。>今時は無いかも知れませんが、バス幅さえ守ってくれれば、最適化は行って欲しい、何て場合です。今は無いのかも知れませんが、小生が現役時代は結構あったものですから。。。 1アクセスに付き1回セットアップするタイプのメモリであればアクセスのサイクル数を節約できそうですが、単にメモリとして使うならvolatile修飾子を付ける状況は限られるでしょうし、その場合はコンパイラによる最適化を期待出来るのではないでしょうか。 またRXユーザーズマニュアルのSDRAMコントローラの所を確認してみたところ、>16.3.9 SDRAM アクセスモードレジスタ (SDAMOD)>BE ビット ( 連続アクセス許可ビット )>SDRAM 空間の連続アクセスの許可または禁止を設定します。>注 . EXDMAC 以外のバスマスタから SDRAM 領域へアクセスする場合、連続アクセス許可に設定することは禁止>しており、設定された場合の動作は保証していません。 広帯域を活かしたければEXDMACを使ってバースト転送してくださいという方針のようです。>ただ、GCCのネームバリューのお陰で、最初から or 早期に、それらがケアされるようになっている、ということなのですね。 VSCodeのC/C++インテリセンスはgcc以外にMSVC、Clangに対してもローカライズされているようなのでこれらの拡張言語仕様は問題なく処理されるはずです。拡張言語仕様に絡む問題はVSCodeだけでなく例えばソースコード解析ツールのSourcetrailも__evenaccess修飾子を認識できません。VSCodeと同様にマクロを定義すれば解消しますが・・・ 後方互換性を考えるとそう簡単に変更出来ないのは判りますが、最近はIoT関連などで組み込み界隈の作法をよく知っているとは限らない人が開発を行うケースも少なからずあるようですし、一般的なCコンパイラから外れる独自仕様はあまり好ましくないのではと思います。自分はコーディングをVSCodeに移しつつありますが当面の目標は・アセンブラファイル用のシンタックスハイライトを用意する・ビルド出来るようにする・設定が面倒なレジスタ群をVSCodeからGUIでエディット出来るようにする・VSCodeからデバッグできるようする・VSCodeのデバッグコンソールを使えるようにする(CS+のPythonにも関連する物はなさそうなので方策不明)あたりでしょうか。何処まで実現できるか判りませんが。＃それとも最近はお仕着せのライブラリやデバイスドライバを使用するのが主流になってきていますし、レジスタ関連まで解析できなくても問題はあまりないとか・・・？
こんにちは、エビスクラウンです。
「一般的なＣコンパイラ」とは何なのかに疑問が残ります。
業界標準の拡張言語仕様がどこかで公になっていれば納得できますが。。。それがVSCodeのC/C++インテリセンスがローカライズしている拡張言語仕様ってことなんですかね。
こんばんは、尭です。取り込んでいたら一週間経ってしまいました。VSCodeはEclipseをおさえて最も支持されているコードエディタという話もありますし・MSVC(Microsoft系の主力コンパイラ)・Clang(Apple系およびGoogle系の主力コンパイラ、ARM CompilerやBCC64などもClang派生)・gcc(最近はClangに押され減りつつある？STさんやNXPさんのIDEには標準添付)を3大C/C++コンパイラと言って過言ではないのではないでしょうか。他にもIntelさんやIARさんのなどありますが上記と比べるとマイナー感は否めないように思います。>VSCodeのIntelliSenseは2進定数を認識しますね。gccやClangは独自拡張で2進数リテラルに対応しているおかげでしょうか。