C18でのインラインアセンブラについて

Question

C18でインラインアセンブラができるのは知っているのですが、処理速度はどの程度速くなるのでしょうか？

足し算1回だけやPICのポートへの出力をアセンブリで書くと１サイクルでも処理を短縮できますか？

アセンブリ言語は全く知らない素人ですが教えてください

Answer 1

なるでしょう，とはお答えできますが，定量的にどのくらい早くなりますか？と聞かれると分かりません．
Cコンパイラがマシンコードに書き直すコードよりも簡潔に書けばそのステート分だけ早くなります．

安全性が同じですか？って聞かれると多分違うでしょうね．

足し算１回と行っても，それが１バイトなのか２バイトなのか，符号付きなのかそうでないのか，桁落ち，桁あふれしたらどうするのか，というのをアセンブリならばすべて配慮しなくてはなりません．
C言語ならばその辺をおおよそ処理系としてまとめてありますので…

たとえばPICのポートのアドレスをインクリしながらアクセスしようとする場合，ライブラリからの操作であれば，その引数の妥当性も配慮してあるかもしれません．

アセンブリコードならばそこも配慮する必要があります．

が，このポートの値を読む！このポートに値を書き込む！というだけならばライブラリを通すよりも早い，とこんな具合です．

PICじゃないですが，Arduinoなんかはライブラリ経由すると１８～２０ステートかかるのでマイコンのクロックに追従したフリップフロップなんか夢のまた夢ですが，アセンブリコードだと１サイクルステートでアクセスできるのでそちらを使う，なんて高速化手段は用います．

安全性と高速性のバランスをどのへんで取るか，と言ったところでしょうかね？
（液晶パネルにprintfで数値を表示するような場合，アセンブリで高速化しよう！なんてすれば多分血反吐吐く羽目になりますけど…）

Answer 2

アセンブラで、最適化したコードを書く能力のある人間がコードを書けば、
確かに、Cコンパイラの出力する結果よりも早く動くコードが書けると思います。
また、下手をすると、コンパイラの出力より遅いコードになる事もあります。

また、「必要？」という疑問があります。

自分は、長い間仕事で、コードを書いていますが、最近では「速度」の為に、
アセンブラを使う事は、ありません。
後で、他の人がメンテナンスする事が困難になるからです。

また、スピードを求める場合、局部の1クロックよりも、アルゴリズム全体を
改良した方が、効果が大きいからです。

最近、自分がアセンブラを使うのは、RAMのチェック処理で、RAMを一切使わない
で処理を書く必要がある場合とか、ROMの全領域チェックを行うプログラム自身が
そのROMに書かれているので、自分自身をRAMに引っ越しして、ROMのチェックを
行い、その後ROMのコードを書き戻す処理を作る場合などです。

ただ、アセンブラを勉強事自体は、良いと思います。
コンピュータがどうやって動いているかをより深く知ることができると思いますよ。

Comments

[fujimon7111]

能力のある人間がコードを書けば＞＞
確かにそうですね何個か書いて計ってみたいと思います（勉強として）

Answer 3

C18でインラインアセンブラができるのは知っているのですが、
処理速度はどの程度速くなるのでしょうか？
足し算1回だけやPICのポートへの出力をアセンブリで書くと
１サイクルでも処理を短縮できますか？

と、問う前に、
cコンパイラの、
単純な演算ルーチンコードでの、
最適化有り、最適化無しでの、アセンブリソースと
インラインコードでの、アセンブリソースを見比べてみてください。
但し、その結果は、局所的な物であって、全体としての数字ではありません。
cの処理系によっては、処理系のアセンブリ出力を見ながら、
コードの内容を変更するなどの処置で、実行コード量が変化する事もあります。
c&ライブラリを使う場合と、主としてアセンブラを使う場合の、
分岐点的な物はありますが、場合によります。
ざっくりであれば、実行コードが、64K / 128K を超える辺りからは、cが有利です。
ROM 容量8k 未満の場合は、アセンブラの使用を検討した方が、良い場合が多いです。
MCUを使う場合、フラッシュ製品だけではなく、
まず、仕様と、MCUのROM容量を考慮します。（忘れがちなのが、将来拡張があるかないか）
私の場合は、
ライブラリ含めて、MCUのROMに収まり、時間要因、物理的要因に支障が無いのであれば、
ｃや、開発ツールがサポートしているプラットフォームで、行います。
割込み等の部分で、時間要因等が発生した場合は、その部分のみ、アセンブラの使用を検討します。
ライブラリが過大であれば、ライブラリをカスタマイズして、ダイエットします。
それでも、ダメだなぁという場合は、アセンブラでその部分を書いてしまったり、
ライブラリを差し替えたり、最終手段として、MCUの変更を考えます。
現在では、PIC でも、プロトタイプ系のツールが使える場合もあるので、
試作機→製品確認機→製品機 などの手順での場合に、
プロトタイプ系を使ったりもします。
試作機：プロトタイプ系でロジックや、機能を確認
確認機：コスト含め、c / assembler / プロタイプ系 どうするか決めたり