H8/SH gcc vs 純正コンパイラ

H8/SH系でプログラミングする際に使うCコンパイラについて熱く語り合おう

純正コンパイラやgcc、(gcc developper liteも含む)
またYellowなどのサードパーティも含め
活発な意見をお願いします。

関連スレ
H8,SH系マイコン限定スレ 3チップ目
http://science6.2ch.net/test/read.cgi/denki/1176990598/

gcc糞だろ

>>2
糞な理由をちゃんと書かないやつが糞なんじゃないかな。

書かなきゃ糞ぶりを理解できないやつこそ糞

>>3
確かに、
お客さんに「開発環境はｇｃｃです。（何故かちょっと半笑い）」と言う機会は
お客さんに「開発環境はルネサス純正です。(ムダに声大きい）」と言う機会より
ずーと少ないのは事実なのだが。

>>ID:apwyPKFK

自分自身にアンカー入れて騙りでもしてえのかヴぉけ

>>6
アンカーとかフックとか良く入れるけどね。OK、OK

"良く"いれるんかい
国語ぐらい勉強しらさせ賤民

まだこの落語スレ生きてたのか.........

インテル純正コンパイラの最適化性能が良いのは常識だが
インテルファンがgccを目の敵にしてヒステリックに反応するのは見たことない。
ルネサス厨のgccに対するヒステリックな反応は何ゆえ？

ID:KZ0Behu9　みたいな凶は別として
オレは現実に性能が劣るものを
絶対的に良いと言って薦める人間も信用できないが。

良いの内容は局面によって違うから
ルネサス純正でもgccでも、いいとこ取りして使いこなせば良いだけで
他人に強要する奴は精神異常の兆候あるんじゃねえか。

>>10
逆にGCC厨がインテルコンパイラを目の敵にする、
ってのも見たことないような・・・・

ルネサス純正（評価版）とGCCのどちらも
無償で使えてしまって、色々な意味で「狭い」ところで
競合を起こしているのに対して、
インテルコンパイラのほうは価格が価格だけに
図らずも棲み分けが出来てしまってるってことかな。

>>12
それが正解っぽいなー。

タダで使えるコンパイラに厨がたかる
　　→厨密度が上がる
　　→厨同士が言い争う
という図式か。

ユーザーの立場からすると、
ルネサスコンパイラはいつ公開止められたりライセンス変更されたりするか判らないのでｇｃｃには生き残っていて貰いたいし個人ではｇｃｃを使うことに抵抗はないが
でもお仕事で使うにはｇｃｃベースはドキュメントサポートが無いから仕様が不明確でツライんだよね。結局ソース嫁の世界だから
そういう仕様がハッキリしてないものを仕事に持ち込むにはgcc厨（ただの口だけ厨じゃなくてちゃんと能力のある厨）が会社にいてくれないと危険で使えないな。

>>14
>ただの口だけ厨じゃなくてちゃんと能力のある厨

それ、厨じゃなくてウィザードだろうが(w
・・・って、最近ウィザード言わないよな。

ウィザードも人間的には厨なことあるしな。

>インテルコンパイラのほうは価格が価格だけに


ハァ？インテルコンパイラもVisual Studio 2005もロハでんがな

お前の糞分析、糞の役にもたたず

インテルのコンパイラっていくらだっけ？
けっこうしたような気がするんだけど

インテリCは高すぎて検討対象にも入らなかったな
個人では無償のLSI-C86試食版とか使ってた
仕事ではLatticeC,TurboC,後にMS-Cとかが対象だった気がする。

商用のコンパイラとしては安いと思うが、Standardで$449
http://www.intel.com/cd/software/products/asmo-na/eng/download/locations/index.htm
あと只ってのはLinux版でNonCommercialな物。

>>10
コンパイラ作ってる部所が、
「なんか成果上がってんの。 こういうの給料泥棒ってんじゃないの。」
見たいに責められてるとか？
俺はどっちでもいい派なんだが、純正擁護派の必死すぎる意見ると、
穿った見方をしてしまう。

>>20
非商用版のところ見てみた。glibcやgccが必要なんだな。
これってｇｃｃ＋αだなんてことオチないのかなあ。

>>21
どうだろ。メーカーとしては遅延スロットの仕様が変わった製品出す度に
コンパイラをいじってくれる部署は必要だろう。

一番の解決法はｇｃｃがルネ純正の性能を抜いてくれる事なのだろうが
このスレのgcc派はそういう方向を向いてない気がするのが悲しい。

>>23
性能？

gccを好む人は最適化性能による数割の速度差でソフトの成否が
左右されるようなシビアな使い方をしてまでH8/SHにこだわりたくない
ってのもあるんじゃないかな。
Z80の時代ならともかく今ではCPU内蔵の高機能なIF機能を使いこなす
ことの方がソフトの実行速度にこだわるよりずっと効率的なことの方が多い。
以前は内蔵Flashと豊富な内蔵周辺機能でH8/SHが抜きんでていたので
普及したんだが今はH8/SHよりも使いやすいCPUもたくさん出てきたしね。

最適化性能よりもCPU選択自由度を取るというスタンスもありじゃないかと。

>>25
それってソフト屋の下っ端の言い分に聞こえる。
製品計画立てる立場にいればそういう論理では動けないでしょ。

チップの価格動向から過去の開発資産からの継承から
生涯生産までの部品入手の手当の想定まで考えないとダメだよ。

日本国内で開発するという枠の中で他にベターな選択ができる？

>>25
周辺回路の使い勝手を優先するならｇｃｃ使うの煩わしいよ。
公開されてるCソースをコピペして使えるのがGPLとｇｃｃの醍醐味でしょ。

>>27
とはいえHEW並の統合環境があればgccを使う機会が増えるだろうし
gccがルネサスCに並べばソースツリー管理のツールが多いgccを喜んで使うけどな。

>>28
つ http://www.apnet.co.jp/techinfo/kpit-gcc/kpit_inst1.html

>>26
現実を知ってるつもりの営業やさん？　それとも．．
最近の日本メーカー態度急変にさんざ振り回されて痛い思いをした
製品計画を立てる立場の人間ですよ。

＞チップの価格動向
H8/SHにこだわることこそ姿勢を疑われるでしょ？

＞過去の開発資産
確かにそれを言う人は多い、しかしそれこそ慣れた環境で仕事をしたい
下っ端ソフト屋のせりふ。
組み込みで新規開発案件にバイナリレベルで過去の開発資産に
こだわらなければならない例は少ないし
組み込みとしては突出して複雑な携帯のソフトでさえハード性能優先で
ARM系に鞍替えした例がたくさんあるのをご存じない？

＞日本国内で開発するという枠の中で他にベターな選択ができる？
確かにかつては「国産だから供給不安がない」という伝説があった。
その伝説が幻想に過ぎなかったことを思い知らされたのが何年前の
ことか知ってるの？

コストを意識した価格動向という言葉と日本国内で開発する枠などと
いう矛盾した単語を平気で並べるあたり、開発経験のない純正ツール
関係の営業にしか思えないんだけど。
それとも自動車メーカーかなんかの開発部門で自分とこで使っている
限定されたCPUの例が業界標準だと錯覚している人？

>>29
KPIT Cummins GCC　を使ってデバッグしたことないだろ。このボケ。

>最近の日本メーカー態度急変にさんざ振り回されて痛い思いをした製品計画を立てる立場の人間ですよ。

海外メーカーはずっとそうだった。君が井の中の蛙で知らなかっただけやろ。
日本メーカーはディスコン猶予あって事前通知くれるだけマシ。

それに日本メーカーだと契約して生産計画出しとけば数量確保もしてくれるよ。
君のとこスポットでしか注文出してないだろ。
必要なだけしか買いたくないんだから必要なとき手に入らない場合も許容しないと。
つまり君の言ってる事は自分の環境限定の世界で文句言ってるだけだと思うがな。

>組み込みとしては突出して複雑な携帯のソフトでさえハード性能優先で
>ARM系に鞍替えした例がたくさんあるのをご存じない？

論理のすり替えご苦労さん。

確かに海外携帯はCDMA系以外はARMが強いけど、それは君が選択したわけではないだろ。
君がARMでやったとしたらそれは下請けで初めからARMでやることになってたからだと思うが。
全然関係ない話だよねえ。

国内携帯の上位機種だとSH-Mobileの機能モジュール構成から計画立てたりするんじゃない？

>31
何か話が支離滅裂になって行ってるし、だいたいどういう立場の人かも
察しがついたのでこれを最後に相手にしない、失礼。

＞それに日本メーカーだと契約して生産計画出しとけば数量確保もしてくれるよ。
＞君のとこスポットでしか注文出してないだろ。
確かにそう、ルネサスは面倒見の悪い方じゃない、数百個のロットからでも
予定がはっきりしていれば数量確保はしてくれる。
完成品を決まったロットで延々と作っていけば利益が出るという
おいしいビジネスがあればそれだけで文句はないが世の中そんなに甘くない。
新規採用で試作が済みいざ見積もりを取ったら供給がタイトで半年後に
なりますなどということがあるCPUを気軽に採用できますか？
あらかじめ入手性を検討しようとすれば、発注しなければ納期回答は
出来ないとふざけた回答をよこす。
H8シリーズは無駄にシリーズ展開を拡げすぎていると思う。

もし常に最優先で回して貰える大メーカーの人だったとしたら、
そういう立場の人間は別格なんだからgccだ純正ツールだと言う
議論に口を出す資格がないという自覚を持ったらどう？
もひとつ、ルネサスの営業がすっ飛んでくるのはメーカーの力で担当者の
実力じゃないんだよ。大メーカーの下っ端に限って変な勘違いをしてる奴が多い。

それはそうとSH-Mobileはこけるのかと思ったら今のところ健闘している
みたいだな、目論見どおりのシェアを獲得できるかどうかは疑わしいが
ルネサスがその路線で持ちこたえられればいいと思ってる、
なんだかんだ言ってもH8/SHシリーズには随分お世話になったからね。

>>32
よく判らんが
どっちとも自分の言いたいこと言ってて相手の話聞いてないことはよく判った。

それはこのスレが機能しているという証左だから
悪いことではないかと。

>>32
自分から会話を拒否した側が負けたように見えるのは普遍的な真理？
内幕知りたいなあ。もっとバトルしてくれればいいのにｗ。

おまえも参加しろ
傍観者なら 黙ってろ

>>35
負けは認める、で>>30に向かって言ってるんじゃないが

GCCだとGDBを使うことになるんだがGDBは環境によって
最初は動かないことが多いし確かに使いにくい。
>>KPIT Cummins GCC　を使ってデバッグしたことないだろ。このボケ。
などとデバッガが使えないといきなりきれる人はGCCを使わないが吉

KPIT＋HEWの利点はプロジェクト管理が楽になることだけ。
じゃ、なんでGCCを使うのかというと例えば、
H8で内蔵フラッシュ書き込み関数をRAMに割り当てる必要があるが、
純正だとソース単位でしかセクションを分けられないのに対し
GCCでは関数単位でセクションを割り当てられる。
リンカスクリプトやインラインアセンブラの記述はややこしいが
汎用性だけでなく柔軟性の高いのがGCCの魅力。
Windowsでもデバイスドライバの開発になるとデバッガは使えず
debug用printf文を埋め込んでデバッグするように
組込みの制御プログラムでも判りにくいバグは割込のタイミングなどによる
ダイナミックな状況でしか発生しないので同様にdebugprintで対応することになる。

自分が新人を育てる場合はエキスパートになって貰うのが目標なので
最初は面倒でもGCCを使わせるが、>>30のような反応を見ると
好きでプログラムをやっているんでなければ純正コンパイラを使う方が
幸せになれるだろうなと思う。

debugprintってようはシリアルなんかに文字列を吐き出させることだろ？
デバッガの存在を知らなかった頃はそうやってデバッグしてたけど
スマートじゃないだろ。

そこでLEDチカチカですよ。

>>38
スマートじゃないが、デバイスドライバでも組込制御プログラミングでも
それが標準的なデバッグ方法。
プログラムを走らせたままメモリの状態をチェックできる高機能デバッガも
あるけどオシロのプローブと一緒でハードウェア的な影響で別の異常を
引き起こしたり、装着や設定が実に面倒だったりする。

それに慣れてくるとデバッガでトレースして見つけられるレベルのバグは
ソースを見ると大体見当がつくようになってくる。
そんなわけで出来る人はprintfを活用したり自作のデバッグ用ツールを
使ったりしていたりする。
いつまでもデバッガを頼らないとデバッグも出来ない人で優秀なプログラマは
見たことがない。

>>39
タイミングをオシロで見たりするけど案外LEDチカチカだけでデバッグ出来ることも多い。

>>38
勿論デバッガを使った方が効率的な場合はデバッガ使用推奨ですよ。
それにアセンブラリストまで見ればいい勉強になるしね。

http://www5b.biglobe.ne.jp/~ajiji/index.html

いのら進化論！！
箱庭げーむやろう！

>>40
プログラマになりたての頃、当時はDOSのプログラムを組んでたんだが、
printfで文字列吐き出させてると正常に動作するが、それをコメントアウトすると
動作しなくなるという問題に悩まされたことがある。
多分スタックがらみのバグだったと思うんだが、それ以来、printfしないとどうしようもない場合を除いて
俺はデバッガを使うようにしている。

たまにしか発生しない不具合で、日がな一日、プローブぶら下げたり、エミュレータつなげたりできない時は
シリアルで文字列吐き出させてるけどな
それはやむをえないからやってるだけで、好き好んでやってるわけではない。

SHくらいになるとICEと連携してないデバッガって辛いだろう。
ましてprintf埋め込みしてソースがその度変わっちゃうと
進捗管理っていうかソースツリー管理でものすごいことになりそう。

>>44
設計センスがないと自爆するのは当然だよ。

>>45
設計センスというほど高度な問題じゃないが。

純正コンパイラ、pragmaで関数単位にセクション変えられるぞ。
あまり純正コンパイラ使い込んでないな。
SH純正コンパイラのオプチマイザは凄いぞ。
debug用にprintfなんか入れた日にゃ、それでタイミング崩れるだろ。
大昔のデバッグ方法ですな。

>>46
デバッグ中にパニックする人って、設計が悪いからのような気がするけど．．．

>>48
は？
デバッグ中にパニックってお前しか言ってないんだが、何勝手なシチュエーション作ってるんだ？

>>49
パニクってるの？

せっかく２CHにしては技術的トピックを中心に話が進んでいるのに荒れるともったいないからマジレスすると。

>>47
その通り、最近のはよく知らない。教えてくれてありがとう。

繰り返すがデバッガを使った方が効率的だと思えばデバッガを使った方がいい。
ただし、いつまでもデバッガだけを頼っていてはエキスパートにはなれないと言ってるだけ。
まずコードの流れでタイミングを取るという概念が古い。
Z80の時代には各命令の実行速度を積算してタイミングを取るのが主流だったが
SHを始め最近のCPUでは予測分岐やパイプラインで命令単位の実行時間を積算しても
正確な時間を算出できないしタイマやDMAなどの豊富なハードウェア機能が使えるので
ループで時間待ちをするなどCPUパワーをわざわざ殺すような使い方はあまりしない。
タイマ割込やイベント割込待ちでタイミングを取りながら待ち時間を有効に使う方法が主流。

それからprintfを入れることによるタイミングの影響やスタック＆ヒープの消費は
当然頭に入っているレベルの人がエキスパート。
最初はスタックの問題でトラブル解決に時間がかかってもそれは良い勉強だけど
だからと言ってデバッガ万歳という考えに凝り固まればエキスパートへの階段を
自ら外しているように思える。

例えばシリアル通信プロトコルのデバッグやLANのドライバで通信が混み合った
時に発生するエラーなどはデバッガのステップ実行では捕まえられないし、
リアルタイムでメモリ内容を観察できるハードウェアエミュレータをつないで
長時間画面とにらめっこしているよりは、printfやデバッグ用メモリブロックへの
書き込みでログを取ってそれを解析するのが効率的。

>>51
あのう
>例えばシリアル通信プロトコルのデバッグやLANのドライバで通信が混み合った時に発生するエラーなどはデバッガのステップ実行では捕まえられないし

って、printfデバッグとすごく親和性悪いでしょ。
ICEでイベント引っ掛けてスナプ使ってスタックフレームダンプするほうが良くないですか？

>printfを入れることによるタイミングの影響やスタック＆ヒープの消費は当然頭に入っているレベルの人がエキスパート。

printfはスタック消費しないのかい？レジスタ使わないのかい？I/O使わないのかい？

犯罪捜査じゃないけど現場はなるべく原型のまま保存が基本でしょう。
printfを入れたりすると現場が足跡だらけになってしまって余計犯人が判りにくくなる。
エキスパートというよりワザと難しい事件にして喜んでる名探偵な感じを受けるのだが。

LEDチカチカ、これ最強。

＞って、printfデバッグとすごく親和性悪いでしょ。
＞ICEでイベント引っ掛けてスナプ使ってスタックフレームダンプするほうが良くないですか？
親和性が悪いっていうのがprintfの影響が大きすぎるという意味なら
アプリケーションによって正しくもあり間違ってもいる。
>>52さんはメモリもCPUパワーも目一杯使うアプリケーションのことしか
思い浮かばない業界の人かもしれないね。

Windowsのデバイスドライバなんてうっかりするとdebugprint文を外すのを
忘れてしまうくらいのもんだしH8はともかくSHクラスのアプリケーションだと
CPUパワーもRAM容量もprintf埋め込んでも十分間に合う場合が多い。

まずデバッグ用出力を余裕で持てるメモリとCPU性能があることが前提だが、
例えばルーターのパケットが時々化けるバグを解決するとき、
何かあるたびにプログラムの流れを止めてスタックダンプなどやるよりは
デバッグ用出力で怪しいデータを長時間ログしてあとから解析する方が
はるかに効率的だしスマート。
例えばロボットがたまに予測しない動きをする時にもいちいち止めるより
ログを取って解析する方が効率的だし、途中で止めたりしたらそれこそ復帰がたいへん。

プログラムを止めて解析できるシーケンスレベルのバグが全てと思っている段階をクリアして
もう少し頭をつかわないと解決できないバグまで解決できる人をエキスパートと言ってる。

＞printfはスタック消費しないのかい？レジスタ使わないのかい？I/O使わないのかい？
そんな視野の狭い突っ込みを入れてると却って馬鹿にされるよ、
せっかくある程度の技量はあるように思えるのに。

>>53
割込関数内の処理が間に合っているかを確認するときなども
＞ICEでイベント引っ掛けてスナプ使ってスタックフレームダンプするほうが良くないですか？
この手法は使えないし 正直LEDチカチカが最強だったりする。

>>54
にいちゃんもういいよ。乙カレー。

>>55

>通信が混み合った時に発生するエラー
が
>割込関数内の処理が間に合っているかを確認する
に置き換えられてますが

君の中ではこの２つの発生条件が等価なんだねえｗ。

もういいじゃねぇか
printf使いたい奴は使えばいい
要は手っ取り早くデバッグした奴の勝ちだ

ま、俺はデバッガも使えない低能とは仕事しないがな

>>58
低能の俺は、ICEって、ローダーみたいな使い方しかしたことないけど．．．

それはE10AみたいなJTAGデバッガ。リアルタイムでデバッグするのはE6000とかだと思う。
ソフトウェア開発のデバッグの話とハードウェアデバッグの話が一度に噴出してて
両者ともちゃんと区別してない模様。

>区別してない模様
切り分けできる奴がここに書くわけないだろ。

>>61
おまえモナー

ったくお前らそろいもそろって大マヌケか？

>>18
>>19

Intel CはWin版もLinux版もロハだと言ってんのにお前らバカか
何も知らんあほが糞コメントを延々書きこむな文盲が

>>20
なぁ、お前英語読めんか池沼
WinXP上でちゃーんとロハのネイティブコンパイラが起動してますが何か?
今の俺のバージョンは W_CC_P_10.0.025でちゃーんと使えてる。
非商用、非サポートベースで使う限り、LinuxもWin版もロハだ。
Win版Intel C/C++は普通はVisual Studioと環境統合して使う。
調べもせず糞情報を書き込むな。
あ、アホ故調べてもわからんかったんだなｹﾞﾗｹﾞﾗｹﾞﾗ
インテル製のチップ載ったPC使ってて本家本元のロハのコンパイラすら使ったことないって？
それでよくエンジニアやってるな？そんなオツムのレベルだから純正ルネサスコンパイラがあるのに
gccをありがたがるハメになるのさ。マヌケが。

>>23
>一番の解決法はｇｃｃがルネ純正の性能を抜いてくれる事なのだろうが

今のコンパイラ技術と共に開発されてるCPUが、gccに負けたら大恥だろうが。
戯言も休み休み言え池沼


バカ者ども晒し上げ

>>63
なんかgcc厨の自作自演っぽい感じがｗ。

リンクくらいのせないとアホと思われて終わりだろ。
>>20はちゃんとリンク載せてるから信頼度高いしな。

結局、>>13が言うところの
「タダで使えるコンパイラに厨がたかる」
が、ますます信憑性を増したわけだ。

厨というレベルではないかもな
自分だけの意見でいちいちageるとこも自己主張の塊っぽくて肝いな。
まあこういう奴は体力ないから
言わせるだけ言わせればそのうち落ちてくな。

>>64
アホはテメエだ。
わざわざアホに耳寄り情報を教えてやってるのに、
なんでそこまで手とり足とり、面倒みにゃならんのだ。
嫌なら使うな。テメエが使おうが使うまいが俺には関係ない。甘えるな。
ただ、アホにはアホとちゃんと罵倒だけはしてやるからありがたく思えアホ
マルチコアオートアサインの無料純正コンパイラが誰でも使える状況なのに
それすら理解できず指くわえて見てるだけか？　ア　ホ
まお前のようなアホは英語のドキュメント読めるはずもないしどうせ使えないだろうけどよ。
アホは技術に首突っ込むなってこった。死ねアホ

>>67
いやオレはIntelコンパイラ別にいらんですし

今ごろインテルコンパイラの話題を蒸し返す自意識過剰バカが
全然信用できないしかな〜りキモくて
いちいちageるのが粘着っぽくてウザいだけでｗ。

アホに付き合ってたらオレまでウザ臭が漂い始めたのでまたな。

乙>>69

>>68

ｹﾞﾗｹﾞﾗ
背の届かないブドウは酸っぱいって？
持ってても豚に真珠、猫に小判、お前にコンパイラだもんなぁ


>>69
>>70
アホどもで傷なめあってうれしいか？ボケナス

アホ晒しあげ

一気に寂れたな・・・

>>72
最初から判ってる結論によくこれだけ持ったもんだ。

14Vだ

次は14Vで再利用？

わからないことがあれば、まずゴーグル先生(ry

ゴーグルつけてスキーでもすんのか？

ゴーグルだって、ハハハハ、アホじゃん。

ヤッホーで検索すりゃいいんだよ。

ヤフーの方はヤッホーと読んでも全くおかしくない。
お前 >>78 人を愚弄しながら自分のアホ晒してること気づけバカ

>>70 じゃなかった >>78な

いつ、イソテルがルネサスのH8/SH用コンパイラをリリースしたの？
どこで売ってるのかな〜？ゴーグル先生に訊いてみるか？

>>81
アホは死んだ方がいいぜ

お、再利用され始めた？

>>82
残念ながらアホじゃなくて、アスホールなんだが？

アホは無くても困らないが、アスホールがないとうんこできないぞ。

>>ALL
このスレッド内で質問しても，レスってちゃんと返ってくる？

なんかこう，表にまとめりゃいいじゃん．なんでウンコの投げ合いするの？

>>86
ルネサス環境の質問にgcc厨が出てこなきゃ大丈夫じゃない？
それとKPIT環境についての質問にルネ厨が出てこなきゃ。

まず質問をしてみることだ。

今 H8 3052Fを使っていて GCCを使っているのですが
Ｃ++もコンパイル出来ますかね?

GCCはＣだけでしょうか?

>>88
H8用のC++をビルドすればいいんだよ。

>>89さん

それはgccですよね?

>>90
俺の読解力じゃ君の質問に答えられないようだ。

gccデベロッパーを使っているのですが
Ｃ++を書くには 具体的には何が必要なんですかね?

今はH8 3052Fを使用していて gccデベロッパーで Ｃでプログラムを書いています
コンパイルは 秋月の H8 write turboを使用しています
Ｃ++で書くには 具体的には何が必要でしょうか?

文章がへたくそですみませんm(_ _)m

>>92
H8のg++でコンパイルすればいいんじゃないの？
質問がC++の文法がわからんように読めるんだけど．．．

g++ってのがあるんですか

ありがとうございます。

ほんとすいません分かりにくい文章でm(_ _)m

純正コンパイラ買えないのでGCCマンセーでつ

HEWの方が性能がでるってのは分かるがなぁ...
-Weffc++が便利だからgccを手放せない。

>>95
趣味なら純正買わずにgccマンセーで桶だろうね
仕事でなら純正コンパイラもあるけどgccをあえて使う人じゃなきゃダメだけど。

GDLのバージョンの違いで割り込み関係の挙動がおかしくなるのはやめてくれ、たまらん。

今、大学の卒業研究でロボット制御やってるんですけど、
去年まではH8/３０５２を使用してたんですけど、今年はH8/３０６９
を使用することになりそうなんですが、
３０５２と３０６９ではプログラムは一緒でいいのでしょうか？？

周辺機能が違うかも？ソースは流用できるよ、たぶん、腕があれば．．．

足し算引き算程度なら同じソースコードで動くだろうけど、
ペリフェラルが色々違うからほとんどの場合無理では？

H8/3052のプログラム書いた人が後輩のためを思い、ルネサスのアプリノートとか参考にして
ペリフェラル依存をヘッダファイル参照でデバイス切り替えられるようにしてくれてればＯＫ

って卒研プログラムでは無理っぽいかなｗ。

3052と3069のハード的な違いを書き出すところから始めりゃいいんじゃないかな？

とりあえずタイマの内部構成が違うな。確か、タイマ割り込み周辺の
ベクタも違ったと思う。

ポート数が違う
ポートの抜けbitもちがう
兼用ポートも違う
日立のヘッダファイルがちがう。ということは構造体の名前も違う
割り込みベクタも違う

全く別のマイコンです。

修正する点は、
・IOヘッダファイル入れ替え
・IOポートの再割り当てを考える
・マイコン内部のハードウェア(機能モジュール)を使っている所を
　　全部書き換える
　　　　・タイマー
　　　　・SCI
　　　　・IOポート

関数名と外部インターフェースを統一した上で、それらをCPUに依存
しない共通のヘッダ(TMR.h,SIO.h)に記述して、それらの関数の実装は
CPU毎に、タイマ(30xxTMR.c)やシリアル(30xxSIO.c)等、機能単位で
ソースを作成して、それらをコンパイルして作成されたobjモジュールを
CPU別にライブラリファイル化(3069.lib,3052.lib等)しておいく。

機種依存するヘッダ(3069IO.hや3052IO.h)は、個別のソース(3069TMR.c,
3052TMR.c)でのみ参照する。

上位のプログラムでは、CPUに依存しない共通のヘッダ(TMR.h,SIO.h)のみ
をインクルードして、リンク時にターゲットのCPUに応じてライブラリ
を指定する。

こういったやり方が一番スマートだと思うが？

当然ならが、追加された異なる機能部分(シリアルのクロック同期等)を
使わず、共通する機能(非同期通信)部分のみだけなら、ソースコード
は共通にできる。

話の流れをブッタギル様でスマンが。

1年ほど前にGCCを改造して、H8用に、ERn以外にもレジスタ割り当て
できるように試みた。16ビット値をEn, 8ビット値をRnH にも割り振って
ビットシフトの結果などをEn, RnH などから取り出せるようにしてみた。

しかし、局所的にはおもしろいコード吐くようになったけど、
大局的に見ると、global register allocation を専用に書き直さない限り
レジスタ割り当てが満足に程遠いありさまとなってしまった。

…という研究の続きをやったら喜ぶヤツいる?
改造方針がかなり外道だったので、本流にとりこんでもらう勇気ナシ。

論文に仕上げるくらいの勢いで続きを頼む

>>108
ひさしぶりにレスがw

ルネサスコンパイラ使ったことがないのであえて訊くが
ルネサスのは柔軟なレジスタ割り当てしてくれるの?

喜ぶヤツがひとりでもいるなら暇を見つけて研究再開するが
学士様すら持ってない俺が論文書くと思うか????!!!!!!

家のloox u50にGDL入れようと思ってGDLFull2.0.1.3r6
実行したらyour PC is not support 8.3filenameとか出てきて
インスコできないんだけど同じような症状のやつとかいない？
XP SP2だからＤＯＳ形式ぐらい対応してんだろと思うんだが・・

>>109
引数の割り当てがこれでもかって感じで最適化するのが売りだったような？

>>111
逆に、他の処理系が引数を合わせるのがメンドくさいってことか。
さいきんH8いじってないなあ…

>>110
ファイルシステム自体をNTFSではなくDOSに変えなきゃだめかもね。

ファイルシステムがDOSってなんやねん？
DOS == Disk Operating System
FATのことでも言いたいんか？

FATのなかでも、FAT16にして桶ってことじゃないか？

rteの直後にレジスタをポップする命令があるんですけど

良いことじゃないかね

>>116
SH3/4ならべつにいいんじゃね。

SH2でそれやってハマったのがいたが。

SH3/SH4でもバンクのレジスタだとはまるような気が？

KPIT GNU tools のを使ってみているんだが、これってgccってことでいいんでっしゃろか？

ところで gcc 4.4 ってすごいってね。
ループの順番まで変えてくれるって。

（株）髭男爵のギャグ　-　「ン」　設計　の
　
柚木正章は、宮�ｱ勤みたいなオタク、

まあ、大人だろう？！

>>120
IDEがルネサスでコンパイラはgcc
挙動はGDLつかっとるんと同じだとおもうわ

KPITのgccは微妙に手が入ってたりすることがあったような。

KPITのヴァージョンはv0901でGDLのほうがv0803だったかの
ぶっちゃけどうちがうのかわからん

>>123-125
だいたい把握
�d

ということは、宣言通りにＲＡＭが並んでくれないのは、gccの仕様なのかな…

しかし静かなスレだな、ここ

>127
じゃあ俺が


安くイエローのリモートデバッカ買っちゃったぜ。これでSHも触れるってモンさ。
……ってイエローのコンパイラ(YCSH)必要なのかよ…orz
な俺が通りますよ。まだ入れてないんだけどこれってCソースデバックも無理なんだよなぁ…多分。

微妙な開封品だしちょっとお安くオクで流して、あとは手持ちのロジアナでちまちまやろうかな。
SHやH8は詳しくないんだけど、この会社ってシェアはやっぱりしょぼい？
オクに流しても売れそうにないのが寂しい。

そして誰ものってこない…

GDLってlibiconvがリンクされてないのね

gdl 使ってみました。Hewで作ったコードの一部を読み込ませてコンパイルしたんですが、
・複数ファイルに分けて書いたソースはダメみたい→全部１ファイルにすればOK？
・ベクタ部はどうやって書く？
・割り込み処理関数はどうやって書く？
・割禁、内部I/Oレジスタのアクセスの書き方はどう書けばいい？
先輩達、よろしくお願いします。

あ、書き忘れた。石はH8S/2000シリーズですが、コンパイルオプションは
標準設定にあったH8/3064を使いました。

＞複数ファイルに分けて書いたソースはダメみたい
何がどう駄目なんだかな？

他はgccのマニュアルでも眺めりゃいいもんじゃねーの？

歯車押すと開いてるファイルだけでリンクまで行っちゃうんです。

付いてくるフォルダの雛形見て、.DEFや.xファイルいじってlinkまで行くようになりました。
void rxrdy0(void) __attribute__ (( interrupt_handler ));
void rxrdy0(void) {/* SCI0受信　int.　*/
　　r0ring[c0r_wpt++] = SCI0.RDR;　　　　// ringバッファに格納
　　SCI0.SSR.BIT.RDRF = 0;　　　　　　　// 割り込み要因 ﾘｾｯﾄ
}　という関数を書いてみたのですが、-SでASMコード見るとこの関数が出てない。なんで？

追加パスに同じフォルダが無限に記述されてたのが原因みたいでした。

今度は、includeしたヘッダファイル（自分で書いた奴）の最後で
error: stray '\32' in program　って出るのどういう意味でしょう？

いま話題のはやぶさに積んでるのがSH-3なんだってな

>>136は、ファイルの終わりにEOFの1Aｈが付いてると出るのでした。
エディタをバイナリモードにして削除できました。

BSET／BCLR　を、LD mask ST 型式でなく BSET @変数 型式で出させるようにしたい
のですが、マニュアルのどの辺読んだらいいのかHINTください。#defineのとこに
それっぽいのが見つからない・・・

libがフルセットで付いてくるのをなんとかできませんか？
malloc/freeなんて機能使わないのが判っているのに・・・

ここはgldのサポートセンタじゃないからなぁ

似たような体験した人居ないのかな・・・　どうにかMOTまでたどりつきました。
めんどうだけど面白かった。　タダなんだから自分で考えろが基本なんですよね。
でもスレチではないでしょう。

どう見ても過疎スレで，しかもサポセンでもなく使っている人は限りなく
少ないだろうということが明白になっている環境の独り言のようなことを
わざわざageてまで書かれてもね。

少ないんですか。何千人も居るかとおもってた・・・
会社で開発する場合はやっぱりフリーだと心配だからメーカー品使うんですか？

心配…？

とりあえず、人命を預かるかもしれない大量生産アイテムが、コンパイラやデバッガの不具合で
チェックを通り抜けた後に問題が発生して、賠償問題になったときなんかを想像するとどうか。

そんなこと言っていたらLinuxを入れたルータやネットワーク機器なんて心配で出荷できないだろうな。
万が一鉄道や航空会社、病院や保安会社に納入されたら困るもんな。

まぁ，超零細で試作の一品物をとりあえずでっち上げるという程度なら
ともかくとして，普通に仕事でやるなら，デバイスメーカが推奨する環境
を使うだろうね。
何か不可解なことがおきて相談するにしても，「推奨環境でやってみて
ください」で終わりになってしまうしな。

>>145
あぁ，だから必ずマニュアルに書いておくだろ。「生命維持装置には使うな」
みたいなことを。（デバイスのマニュアルにも書いてあるんじゃね？）

そういえば、ＪＲの表示装置作ってる会社、未だにｃは信用ならないっつってASMでの開発
押しつけてきましたね。　ｃで出したASMコード納品したけど。

>>146 じゃあ、医療機器や、街頭のAEDなんかみんなASM・・・じゃなくて推奨環境か。
鉄道や航空機のソフトはどんな作り方してるんだろ？エイダ限定とか

推奨環境だからってバグが消えるわけじゃないしなぁ。
それより開発効率の点で（妙なトラブルに巻き込まれないためにもサポートのある環境という意味で)、
推奨環境でやるだけだと思うけど。
どうせ機材やソフトを含めて開発費は回収できるでしょ。そういう金額で受けてるでしょ。

>>147
以前鉄道会社の改札機が死んだときのドキュメンタリではC言語でしたね。
ダイアグラムや信号制御はどうなってるのかわかりませんけど。

>>147
特注になるし，検証試験工数も相当かかるね
コンパイラ使うにしてもバージョンは固定されて，同じソース食わせたら
まったく同じオブジェクトが出ないと駄目っていうのは基本中の基本。
漏れも昔はうるさいところ相手にしていて，いろいろ意地悪試験をしていて，
メモリデバイスのバグ（あるタイミングでアクセスするとデータが化ける）
とか，コプロがらみのバグとか見つけたりしたなぁ。
（メーカさんに認めさせるまでしばらくかかったけど）
今は商売替えしたからそういう世界とは無縁だけど，やっぱり今でも
細かいところまで追い込んでいくといろいろな問題は出てくるんだろうな。

トリッキーなコードではまるより
マイコンの周辺機能がある条件で奇妙な動作する方がやっかいだよな

>>147
表示装置程度でCを使わなくては作れないって、よっぽど…

よっぽど何なの？　作るほうとしては楽なほうがいいのはあたりまえで、
わざわざ手間のかかる製造方法を指定してくるのはいかがなものか、
と言いたかったんだが。

企業としては、工数というか見積を安く出さないといかんしねえ。
取引先がアセンブラ信者だとどうしようもないか。

言語知らずに、マイコンは万能のはずだ！コレもアレも出来るハズだ！っていう注文されるのも困るが。

>>152
初心者が書くCコードほど怪しいものは無いからね。
作るのが楽とはいってもそれはコーディングだけの話で、製造まで考えれば大差ない。
逆にコスト高になる事も多い。
まあ、プログラマ不足を解消する為、簡単に養成出来るのがC等の高級言語だったから致し方無いけどね。

3664のプログラムをgcc使って作った初心者だけど、
3664.hが無いから3694.hとして使ってたら、シリアル通信はクロックの差のせいか、
ボーレイトは3664用にしないと通信できなかった。
gccは手軽でいいんだけどね。

n88Basicのようなコンパイラがあれば一番なんだけど。

シリアル通信のSCI3_OUT_DATA命令が動いてない気がする。
3664.hのファイル見つけたけど、最新版に使えないよ〜
見比べて書き換えるしかないか・・・

SCI3_OUT_DATAって、defineされてるだけでしょ

よくわからないから、サンプルをコピペして、3694.hにして
通信速度だけ直接レジスタに書き込んで3664用のボーレイトに変えたんだけど、
サンプルが作動してない。
ほかにも違う所があるのかも。

最新版用の3664.hは、どこかにないかな？

うちが持ってる3664.hは、　タイムスタンプが2003/08/05 06:11:16で、
51,505バイト。　　これより新しいのがあるかな？

自前で書いたら、それが最新

158だけど、自分の手持ちも159と同じ。最新版には使えない様な・・・
インストール方法があるのかもしれないが。
自前で書くには何ヶ月かかるかわからない。

もう一度、3694.hで、ボーレイト設定を3664用にしたら、サンプルのSCI3_OUT_DATAが機能してた。
前回はなにか間違えてたみたい。

自前にトライしてみようかな。

構造体と共用体がわかってるなら
ハードウェアマニュアルとにらめっこしながらで
1週間もあれば、出きるでしょ。
3694.hを参考にしながら、SCI部分だけでもやってみたら

ふと…
マイコン毎の定義ファイルの存在を知らず、ハードウェアマニュアル片手にポート定義やビットテーブルを
イチから組んできた俺はマイノリティというか愚かなのだろうかという気がしてきた

道具に使われてるよりはましなんじゃないの

>>162 は、GCCの3694fフォルダにあるsci3.cとかを使おうとしているのかな。

俺も>>164と同じく、sci3.cに相当するコードを全部自前で書いてる。
何十回も使い回したからインターフェースも暗記してるし、sci3.cより効率もいい。

でも162のアプローチも間違いではないとおもう。SCI3のポートアドレスと、
SMRのクロックセレクトを3664の石ではどうなるか確認すれば動くと思うよ。

166を書いた後でsci3.cを読んでみた。割と素直に書かれているじゃない。
俺の自前はバッファをドライバ側に抱え込むこととバッファサイズを２のｎ乗に
限ることで、ring読み書きの際割り算が起きないようにしたり工夫してるけど、
思想的には殆ど一緒だった。

シリアル程度なら、「まともなヤツ」が「普通に作れば」そんなに変わらない

162だけど、
3694.hの下記の部分の右側だけ書き換えたら動くと思ってる

/*--------------------------------------------------------------*/
/* シリアル通信関数(FIFOバッファ付) */
/*--------------------------------------------------------------*/
typedef enum { // ボーレート設定リスト
br4800 = 129,
br9600 = 64,
br19200 = 32,
br31250 = 19,
br38400 = 15,
br57600 = 10

IIC接続も違いがあるらしいが、今は使わないから後回し。
他も違いがあるのかどうか知らない。ハードウェアマニュアルのページが多くて。

タイマー周期は3664のサンプルプログラムなら大丈夫だろうし。

Ｃは入門書のポインターで止まってて、その後ろに構造体とかあったような・・・。
sci3.cなんて無視してた。3694.hだけ見てた。

ジャンク工業用ミシン買って、振動の少ない回転数で使おうと、
ＤＣモーターの親戚のようなＡＣモーターの回転数制御のためとマイコン買った。
裁縫はお休み状態。

kpitの中の人のgccに入れようとしてるパッチって今ひとつなんだよね
追加パッチじゃなくて、bugfixのパッチあげりゃあいいのに

三三三三三三三三三三三三三三三三三三三三三三三三三三三三三
三三三三三l =====（（（（）=== l´.l三三三三三三三三三三三三三三
三三三三三||.l三三三|| ＼ 三 l　|三三三三三三三三三三三三三
三三三三三||.l三三三||三 ＼　l　|三三三三三三三三三三三三
￣￣￣￣￣||,l.-‐＝テ||＝ ‐ - l　|￣￣￣￣
　 　 　 　 　 l　‐- ､- ＝＝-ｖ‐‐.　l
　 　 　 　 　 |　　　　　 　　　　　 彡|　　　　　　　　 　　　　　　(？
　 　 　 　 　 | ああああああああ彡|　　 　　　　　　
　 　 　 　 　 |　　　　井戸　　 　 彡| 　 　Λ　Λ
　　　　　 　"´　‐- ､- 　　　-　‐‐."｀　 （　　 　）＜

>>164
鳩山には遠く及びませんが、立派な情弱です。胸を張って生きてください。

kpitの中の人のパッチ、また、お断りされちゃったね

kwsk
kpit版のコンパイラ本体の改良点が知りたい。
ソースたぐりよせてdiffれカスはナシの方向で。

何をkwskかわからんけど
shの割り込みの終了処理のコードの問題は直ってたような

longが64bitな環境で、
h8300をターゲットにする時はbinutilsにパッチあてないと
関連ライブラリをコンパイルする時にwarningがでる

shの割り込みの終了処理のコードの問題解決に変なpatch採用しちゃったね。
ttp://gcc.gnu.org/ml/gcc-patches/2001-06/msg01351.html
の
! (ior
! (ne (symbol_ref "TARGET_SH3") (const_int 0))
! (eq_attr "hit_stack" "no"))))) (nil) (nil)])
ここの論理演算がおかしいだけなのに

あのパッチじゃ、このコードもダメになるじゃないかな
rts
mov.l @r15+,r14

H8S用にコンパイルしています。main()冒頭のER4,5,6をpushする命令を
出させない方法ありませんか？

age忘れました。すいません

naked

void main () __attribute__ ((noreturn));

ありがとうございます！　>>182の方法でできました。
void main(void) {　　　　　　// 電源ONでここに来る
　　extern char stack[];　　// startupで隠している情報
　　asm (" mov.l #_stack,sp"); // LINK制御文により00FFC000になる。
　　DI; // 割り込み禁止
　　HardwareSetup();　　　// Hardware Setup(含ROM,RAM init)
こうすると、h8crt0.sというASMのstartupコードを追放できます＝Hewのentryと同様に。
ROM→RAMcopyと、RAMクリヤはHardwareSetup()中で任意のタイミングでできます。

__attribute__ ((noreturn))
void
main()
{
extern char stack[];
asm (" mov.l %0,sp"::"i"(&stack));
for(;;);
}

そのほうがスマートな書き方ですね。%0と後ろのどれが対応するとか、"i"の意味とか
その辺はどこの章を読めばいいですか？

ttp://www.sra.co.jp/wingnut/gcc/gcc-j.html#Extended Asm
ttp://www.sra.co.jp/wingnut/gcc/gcc-j.html#Constraints

>>139
ar 使えば？

>>187 それはIARのコンパイラのことですか？ それなら小さいlibでのビルドは
成功しています。

>>186 ありがとうございます。なんか抽象的でよく解りませんが、
使用例をちょっとずついじりながら使ってみようとおもいます。

今 -O1 レベルの最適化でコンパイルしていますが、関数の順序が入れ替わる
ファイルとそうでないのがあるのですね。これはどういう基準で起きるのでしょう？

>関数の順序が入れ替わる　これはどういう基準で起きるのでしょう？
とりあえず、gccのバージョンによって違うとしか

h8300.mdを読むとインラインアセンブラの使い方がわかるかも
mdファイルを読むのは大変だけどね

ありがとうございます。

binutils2.20向けのrx-elfのパッチが出てるね

んなもんsnapshot使えばいいやん。
とか思わなくもない。

>>164
>>172
この前、Hewのアップデートをかけて新しいCPUのI/O定義ファイルを
手に入れたんだが、以前使っていたCPUと定義ルールが違っていて、
プログラムソースを修正するハメになった。
自分で書いてれば、こんな目には遭わないだろうね。

ttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=42102
mdに書いてある+Qの＋ってのが悪いみたいだね

しまった、オリジナルは+mだった

>>178
試してみたけど、案の定、改悪しちゃったね。

kpitの中の人はsh2aのmovuを使えるようにするパッチとかはつくらないんだろうか？

>>196
bsetは修正されたけど、bnotとbclrは忘れてるっぽい

sh2aのmovmlとmovmuを使うようにgccを改造してみた。
すっきりした汗のソースを吐くようになったよ。

shのgccだとdt使うpeepholeが悪さして、変なコードを吐くことがある。
peephole2で回避できるみたいだけど...

kpitの中の人はsh2aのmovmlの追加で迷走してるみたいだね。
あのmdの追加じゃ、変な汗のソースを吐くことがあるような。

添削ついでに、新しいpatchが出たけど、
r7固定にしたんじゃ、sh2aのmovmlの効果があんまりないような。

kpitの中の人はあきらめたのかな？
sh2aのmovmlを使うようにするとこんな汗吐くようになるんだけどね。

mov.l r7,@-r15
mov.l .L3,r7
mov.l @r7,r7
mov.l r15,@-r7
mov r7,r15
movml.l r6,@-r15
movmu.l r14,@-r15
sts.l mach,@-r15
mov.l .L4,r0
sts.l macl,@-r15
jsr @r0
mov r15,r14