hamayan です。 勿論元ネタは別のスレッドなのですが、タイトル見て興味の無い人が判る様に別ス レッドにしてみました。多分この辺でこのメールを閉じている人が八割位・・・。 元ネタでは、machine.hを使う事はお勧めできない、色々悩むくらいなら、アセン ブラで記述した方が良いのでは！。と言う趣旨の発言をしていました。 ちょっと言葉足らずなので補足すると、コンパイラに秋月のコンパイラを使ってい る状況で、machine.hはルネサスのコンパイラに依存すると思われるので、これを インクルードすると、問題が有るかもしれないし、どうなるか判らない！という事 です。 じゃあmachine.hは何の為に有るのか？ 別にルネサスの人が洒落で作ったのではなく、ルネサス純正コンパイラを使ってい るなら、使うだけの理由は十分に有ります。 元ネタのスレッドにも書いた様に、machine.hはCPUに依存する処理をＣ言語で記述 する為に存在するのであって、このヘッダーファイルが有効なのは、勿論ルネサス のコンパイラを使用した時のみです。 ではどんな利点が有るのでしょうか。 その良い例が set_imask_ccr(0); ですね。何度か登場しています。 この関数は関数に見えますが、実はルネサスのコンパイラに掛かると、インライン 展開されて、割り込みマスクレジスタを0にクリアするコードを埋め込みます。 インラインアセンブルで行われているのと同じ事を、もっと使い易い形で提供してい るのです。 下が埋め込まれたコードです。 ANDC.B #127,CCR 別スレッドのアセンブラ関数をＣからコールする方法は、とても原始的ですが、普遍 的で、まずマスターしたい方法です。 が、わざわざ開発環境にHEWを選んだのなら、最速のコードを出力して欲しいですよね。 埋め込み関数は実際に関数コールをしない為、最速です。 しかも、インラインアセンブルに比べて遥かに可読性、生産性が高い！ そもそも生産効率を高くしたいから、多少の実行効率が落ちてもアセンブラよりＣ言 語を選んでいるので、その辺の兼ね合いは、まあ使う人が選んで下さい。 さてこれは全く個人的な考えなのですが、汎用OS上のプログラムとは異なり、組み込 みマイコンでの優先すべき事は、移植性より、可読性だと思います。 移植性の問題はコンパイラを使う前に、マニュアルをよく読めば解決できる問題ばか りです。エンディアンとか、ビットフィールドの並びなんて、コンパイラのスイッチ 一つで解決できたりしかねません。 しかし、可読性の悪いプログラムが内包するバグは、発見し難く、コンパイラのスイ ッチ一つで直ったりもしません。 勿論、移植性を軽視しているのではありません。実際GCCでもHEWでも動くプログラム を作っていたりもしますから。 machine.hで提供される埋め込み関数は、思いっきり移植性を無視していますが、可 読性は高くなる事が判ったと思います。 ANDC.B #127,CCR よりは、 set_imask_ccr(0); の方が何をやっているのか判り易いという事です。 Ｃ言語良いですよね。関数名の文字制限なんて256文字とかだったりして、もう関数名 に、一体この関数は何をする関数で、入力は何で、出力は何ですよー！ってのを記述 できるじゃあないですか。もう8文字位で暗号の様なラベルにしなくてもいい！ なるべくＣ言語で書けるなら、書こうよ！を拡張させて来たのが、今のルネサスのコ ンパイラとも言えます。 ただし！コンパイラのマニュアルは良く読むか、セミナーに参加して、講師の方に聞 いて下さいね。 同様にビットフィールドも、私は、『有る物は使え！』派なのです。 ビットフィールドも、とても可読性を良くしてくれます。 例えば、 ITU.TSTR.BIT.STR0 = 1; /*俺はITU0だけスタートさせたいんだー*/ と言う記述と、 ITU.TSTR.BYTE &= 0xfe; /*俺はITU0だけスタートさせたいんだー*/ では、勿論ビットフィールドを使った方が理解し易いですよね。 そもそも、ITU0とITU1は別の目的のタイマーとして使われる事が多いと思いますが、 ITU0だけ見た時は、ITU1のビットはまるで関係無いのに、それを意識して、書き換え ない様に"&="に続く数値を考慮する必要が有ります。 ここに気付かないバグを内包し易くなります。 しかも、この二つのコードをルネサスのコンパイラが出力すると、どっちも同じコード を吐きます。どっちもビット操作命令に置き換わります。 ところで今月号のトラ技の何処かの記事に、ビットフィールドは移植性が無い！とか、 実行が遅くなる！とか、否定的な記事が掲載されていましたが、 移植性が無い！のは事実です。実際、H8の内蔵タイマーのレジスタをいじったプログラ ムをARMに持って行っても、動く事は全く期待できません。 実行が遅くなる！のはルネサスに限れば、ビットフィールドを使っても、使わなくても 同じコードが生成されるので、嘘と言う事になります。 BSET命令と、AND等の演算命令を比較すると、実行ステートでBSET命令の方が遅いのです が、最近のルネサスのコンパイラは、前後の文脈まで考慮してコードを吐くので、下手 をすると、BSETを使った方が実行が早くなる事が有ります。 そもそもトラ技の記事は、どのコンパイラの、どのバージョンの話なのでしょう？ この様な都市伝説みたいな話に惑わされずに、アセンブル出力させたりして、実際に自 分で確かめてみる事が大切ではないでしょうか。 え！、秋月のコンパイラなのでアセンブル出力できない！ 大丈夫です。そんな貴方の為に、幾つかのデバックモニタを作って用意してあります。 http://hamayan.ddo.jp/~hamayan/so-net/download.html からどうぞ。 ------------------------------------------------------------ )^o^()^o^()^o^()^o^()^o^()^o^()^o^()^o^()^o^()^o^()^o^()^o^( ☆☆☆☆☆☆☆☆☆☆☆☆designed by hamayan☆☆☆☆☆☆☆☆☆ from はまやん アドレスは webmaster@xxxxxxxxxxxxxxxx URL http://hamayan.ddo.jp/~hamayan/so-net/ The Embeded Protocol Engine Navajoデモ中！続行中！！ http://hamayan.ddo.jp:8080/ ★★★★★★★★★end of message and thank you★★★★★★★
