最近、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がピッタリではないかと思っています。
今時は無いかも知れませんが、バス幅さえ守ってくれれば、最適化は行って欲しい、何て場合です。今は無いのかも知れませんが、小生が現役時代は結構あったものですから。。。
こんにちは、尭です。>バス幅固定の外バス接続メモリの場合、__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進数リテラルに対応しているおかげでしょうか。