XC8のバージョンアップ（Ver 1.12）に落とし穴が・・・
2012-12-24
MPLABXとXC8がそれぞれバージョンアップしていました。HP上の表示修正が間に合っていないようですが、今日時点でMPLABXがVer 1.60、XC8がVer 1.12になっていたため、早速ダウンロード。
MPLABX（Ver 1.60）は特に問題なくインストール完了。リリースノートを見ると、前バージョンのデバイス関連の不具合修正など、それなりの盛り込みがあったようですが、特に不具合なく動いている模様。
一方、XC8（Ver 1.12）にも結構な修正が施されたようでそれ自体は歓迎なんですが、なんとアセンブルリストにコメントとして入るはずの「元のC言語」が妙なサブタイトルに変わっており、全然役に立ちません・・・。そのサブタイトルの内容も「ライトモードを使ってるよ」という何の意味もなさないものであり、リストとして大変解り辛くなってしまいました。
試行錯誤の挙げ句、元のバージョン（Ver 1.11）に戻してあります。多分バグなんでしょうが、ひょっとして「無償版」はこうなっちゃうの
・・・という一抹の不安が無きにしも非ず
ソフトの改版には非常に神経質な職場に居るため、もし自分らがこんなに目立つ不具合を出したらそれこそ大変な目に遭うわけですが、流石に他社製の「無償版」には文句も言えません
後続のバージョンでの改善を期待したいと思います。
ちなみに、吐き出されたニーモニックには特に異常は無さそうで、逆アセンブルされたアセンブルコードも大丈夫そうです。
MPLABX（Ver 1.60）は特に問題なくインストール完了。リリースノートを見ると、前バージョンのデバイス関連の不具合修正など、それなりの盛り込みがあったようですが、特に不具合なく動いている模様。
一方、XC8（Ver 1.12）にも結構な修正が施されたようでそれ自体は歓迎なんですが、なんとアセンブルリストにコメントとして入るはずの「元のC言語」が妙なサブタイトルに変わっており、全然役に立ちません・・・。そのサブタイトルの内容も「ライトモードを使ってるよ」という何の意味もなさないものであり、リストとして大変解り辛くなってしまいました。
試行錯誤の挙げ句、元のバージョン（Ver 1.11）に戻してあります。多分バグなんでしょうが、ひょっとして「無償版」はこうなっちゃうの
・・・という一抹の不安が無きにしも非ずソフトの改版には非常に神経質な職場に居るため、もし自分らがこんなに目立つ不具合を出したらそれこそ大変な目に遭うわけですが、流石に他社製の「無償版」には文句も言えません
後続のバージョンでの改善を期待したいと思います。ちなみに、吐き出されたニーモニックには特に異常は無さそうで、逆アセンブルされたアセンブルコードも大丈夫そうです。
関数呼び出しの様子
2012-12-24
今日も朝から懲りずに周波数カウンタに温度計を突っ込んで放っておき、時々眺めていました。結局、昨晩と同じような温度差（8～9℃程度カウンタ内部温度の方が高い）だということが判ったんで、次なる改良案へ・・・と思ったのですが、どうしてもPIC12Fシリーズが欲しくなり、次の秋葉行き（実は、25日に寄り道できそう）までお預けにしました（この辺りは、別のカテゴに譲ります）。
さて、もう一つ同時並行的に進めているAD9834を使ったSG試作の方・・・禁断のC言語に手を出したばかりにその展開形（コンパイル後のニーモニックの様子）が気になり、プログラミング部分で停滞していますが、今日は関数呼び出し部分がどんな風になるのかを探ってみました。なお、パラメータについては8ビットPICでは最も使われるであろう「unsigned char型」についてのみの調査です。
まず、パラメータが「unsigned char」×1つのタイプでは、呼び出し側のニーモニック・・・というか、コンパイル結果を逆アセンブラすると以下のようになっています（以下、unsigned char ⇒ uchar）。
Wレジスタにパラメータをそのまま入れて直ぐに呼び出す形ですから、全く無駄がありません。一方、呼ばれる側はというと、以下のようになります。
呼ばれる側・・・つまり関数の方では、Wレジスタで受け渡されたパラメータを「lcd_cmd@out」という変数に直ぐに代入していることが判ります。以降、この関数内では、パラメータが「lcd_cmd@out」に入っているという前提で処理されます。
本当は、折角Wレジスタに入っている値をそのまま使って処理することもできるわけですが、後の処理で何度もこのパラメータを参照する場合には、結果的にどこかに置いて記憶しておかなければなりませんから、この展開形は特に問題ないでしょう。
ところで、実際の処理の組み立てでは、上記のようなパラメータが1つしかない関数もさることながら、複数パラメータのものも多く見受けます。2つのパラメータを受け渡してみましょう。
先頭のパラメータ「mode」は、Wレジスタで渡されますが、「out」の方は「?_lcd_cmd」という別の変数に置かれて渡されます。こうなると、相変わらず「余計な2ステップ」（上の囲みの矢印部分）が出てきてしまいますから、あまりパラメータを考え無しに多くすると冗長になりそうです。即ち、XC8を使う限り、関数の王道としては「unsigned char×1」が良さそうです。
単機能の関数にパラメータを1つだけ渡す・・・所詮8ビットですから、まぁこんなもんでしょう。
さて、もう一つ同時並行的に進めているAD9834を使ったSG試作の方・・・禁断のC言語に手を出したばかりにその展開形（コンパイル後のニーモニックの様子）が気になり、プログラミング部分で停滞していますが、今日は関数呼び出し部分がどんな風になるのかを探ってみました。なお、パラメータについては8ビットPICでは最も使われるであろう「unsigned char型」についてのみの調査です。
まず、パラメータが「unsigned char」×1つのタイプでは、呼び出し側のニーモニック・・・というか、コンパイル結果を逆アセンブラすると以下のようになっています（以下、unsigned char ⇒ uchar）。
| 関数 static void lcd_cmd(uchar out)の呼び出し ;lcd.c: 52: lcd_cmd(0b00000110); movlw (06h) fcall _lcd_cmd |
Wレジスタにパラメータをそのまま入れて直ぐに呼び出す形ですから、全く無駄がありません。一方、呼ばれる側はというと、以下のようになります。
| 関数 static void lcd_cmd(uchar out)の先頭 _lcd_cmd: movwf (lcd_cmd@out) |
呼ばれる側・・・つまり関数の方では、Wレジスタで受け渡されたパラメータを「lcd_cmd@out」という変数に直ぐに代入していることが判ります。以降、この関数内では、パラメータが「lcd_cmd@out」に入っているという前提で処理されます。
本当は、折角Wレジスタに入っている値をそのまま使って処理することもできるわけですが、後の処理で何度もこのパラメータを参照する場合には、結果的にどこかに置いて記憶しておかなければなりませんから、この展開形は特に問題ないでしょう。
ところで、実際の処理の組み立てでは、上記のようなパラメータが1つしかない関数もさることながら、複数パラメータのものも多く見受けます。2つのパラメータを受け渡してみましょう。
| 関数 static void lcd_cmd(uchar mode, uchar out)の呼び出し ;lcd.c: 52: lcd_cmd(1,0b00000110); movlw (06h) movwf (??_lcd_init+0)+0 ← movf (??_lcd_init+0)+0,w ← movwf (?_lcd_cmd) movlw (01h) fcall _lcd_cmd |
先頭のパラメータ「mode」は、Wレジスタで渡されますが、「out」の方は「?_lcd_cmd」という別の変数に置かれて渡されます。こうなると、相変わらず「余計な2ステップ」（上の囲みの矢印部分）が出てきてしまいますから、あまりパラメータを考え無しに多くすると冗長になりそうです。即ち、XC8を使う限り、関数の王道としては「unsigned char×1」が良さそうです。
単機能の関数にパラメータを1つだけ渡す・・・所詮8ビットですから、まぁこんなもんでしょう。
にほんブログ村