コンピュータは実に面白いもので、人間と同じように 言葉を使って命令を与えなければなりません。 やりたい作業内容を、 一つ一つ丁寧にコンピュータに説明してあげるのです。
その命令のしかたが悪いと、 これがなかなか言うことを聞いてくれません。
人間に指示を出すときも、 簡潔でわかりやすい説明の方が、いっぱい仕事してくれるし作業効率も上がります。 わかりにくくて話の内容に無駄が多かったら、 効率よい作業なんてできません。
プログラムの善し悪しは、 「コンピュータへの命令の仕方、 作業内容の説明の仕方が うまいのか下手なのか」 で決まります。
一般のアプリケーションソフト、ユーザーオペレーション、 高級言語で書いたプログラム、 これらは最終的に「そのコンピュータが話す言語」に 翻訳されることになります。
コンピュータが話す言語は CPU によって違います。 コンピュータが話す言葉の語彙は、環境や文化、つまり OS によって違います。
アセンブリ言語は、CPUが直接話す「機械語」にかなり近い言語です。 CPU 毎に文法も単語も異なります。 その代わり CPU が理解できる言葉をすべて直接表記することができます。
もしこれを自由自在に使いこなせれば、 きっと微妙なニュアンスまで完璧に伝わるに違いない。
でも CPU 毎に違う言語を全部覚えるのは大変です。
海外旅行に行くたびに毎回現地の言語をマスターしていたら・・ 確かにマスターできたら便利なんだけど、 中途半端に覚えたたどたどしい言葉で話すよりも、 ちゃんと通訳してもらった方がやっぱり確実に伝わります。
実際の開発でよく使われるのが「C言語」です。 「C++」もよく使われています。
これらはいわば、どこでも使える 共通言語 です。 「C言語」を翻訳するソフトウエア 「コンパイラ」は、どの CPU にも大抵 標準で揃っているからです。
答え：「いいえ。ほとんど全部 C言語で書いています。」
もしアセンブラで開発を行うならば、 SH3 CPU の動作の仕組みまできちんと理解しておく必要があります。
命令の配置や演算の順番、つまり パイプラインの流れまで考慮しながらプログラムコードを置いていきます。 SH シリーズは命令が 16bit 固定長なので、 一回のメモリアクセスで2命令をフェッチできます。 SH4 と違って 2way スーパースカラではありませんが、 命令フェッチのタイミングとメモリアクセスは、 基本的に 2命令単位で考えます。
そこまで考えてコードを並べてどれだけ速度アップに効果があるのかといえば・・ 実はほとんど無いんです。 そもそも一般的に、 アプリケーションソフトの 動作上のボトルネックは、 ぜんぜん別のところにあるものです。
コンパイラの翻訳が悪いから性能が上がらない、 直接アセンブラで書いた方がすごく速くなるんだ、 なんてことは、実はそんなにあるものではないんです。
GA 3D Engine でアセンブラを使っているのは「SH3 に FPU が乗ってないから」です。
FPU は浮動小数演算を実行するためのユニットです。 FPU が無いと、CPU は直接実数計算ができません。 計算が必要なときは、代わりのライブラリルーチンを呼び出しています。 これはあまり効率が良くありません。
GA 3D Engine は 3D 計算のために数値演算を多用します。 効率よく実現するために CPU が内蔵している特殊な機能「積和演算器」を使いました。 これは SH3 固有の命令なので、共通言語では表記することができないのです。 ここに、CPU専用の言語アセンブラを使う意義があります。
実際は、描画処理にもアセンブラを使っています。 これ、アセンブラを使っても、 必ずしもかけた労力の分だけ性能があがるわけではありません。
いろいろな記述方法を何通りも試してみて、 実際に速度を計測しながら一番結果の良いものを選択していきます。 アセンブラでプログラムを書くたびに、 このような試行錯誤を繰り返すのです。 何度か手段を試してはみるけれど、結局徒労に終わることも少なくなりません。
答え：「機種にもよりますが、通常の描画APIを使った方が速いこともあります」
世の中そんなに甘くはないようです。 機種にもよりますが、 チューニングされているマシンの描画 API は、決して侮れるものではありません。 アセンブラで書いて、コードの高速化をぎりぎりまで考慮して、 やっと同等に追いつけるかちょっと速くなるか程度です。
例えば MI-110M の描画はもともと遅いので、 アセンブラ効果が大きく働きます。 ところが MI-P1/P2 の API は高速になっていて、 ほとんど専用ルーチンを用意する意味がありませんでした。 がんばってカラー減色ルーチンを効率化して、 なんとかわずかに速い程度です。がんばって作ってもその程度です。 MI-P10 も全く同様でした。
MI-TR1(EX1) の QVGA 転送に至っては、 まだコーディングのノウハウを得ていないためか 標準の描画 API に勝てません。 効率の良いメモリアクセスの方法をもっと研究しなければ、 ZaurusOS の API よりも遅くなってしまうのです。
しっかりした OS が乗ったマシンでは、 一般のアプリケーションが ハードウエアを直接操作することはありません。 各プロセスは完全に保護され、安全な状態で動作します。 競合するハードウエアリソースには、安全なアクセス方法が必ず用意されています。
デバイスドライバを書くなら別ですが、 それでもきちんとした手段と手順を踏んだ上で実行しなければなりません。
実は SZAB のマニュアルにきちんと説明が載っています。 製品版には紙のマニュアルも付いていますし、 お試し版でも C:\GREEN\more.pdf というオンラインマニュアルが用意されています。
インラインアセンブラの使い方から 引数の呼び出し規約、破壊非破壊レジスタの説明まで書いてあります。 C言語関数と比較しながら アセンブラプログラミングの詳しい説明も載ってるので、 直接アセンブラのソースコード *.s を書くことも可能です。
これで説明が足りないと感じるなら、 無理してアセンブラを使う必要はぜんぜん無いと思います。
アセンブラを使っても、 かけた労力に見合うメリットが、必ずしも得られるとは限らないからです。 使い方を調べる労力が惜しいならば、 アセンブラにかける労力の方を惜しむべきでしょう。
Q:「なんでアセンブラソースをライブラリ化する方法を公開しなかったんですか?」
*.o さえできてしまえば、ライブラリ化の方法は C言語のソースと全く一緒です。 アセンブラだからといって特別なことは何もないので、 特に難しいところはないはずです。
ライブラリ化の方法は上記の pdf マニュアルに載ってますし、 それよりももっと具体的な解説が SZAB サポートページにあがっています。
アセンブラを使って C言語の関数を丸ごと書く場合は、そのシンボル名を 関数名として export する必要があります。 他のアセンブラ経験があれば、すぐわかる ところ だと思います。 このへん の記事にも関数丸ごと アセンブラでコードを載せてますので、参考になるでしょう。
アセンブラ化してコードのわずかな違いで速度を稼ぐよりは、 見通しの良い C言語のまま、 アルゴリズムを改良した方が何十倍も効果があります。
積和演算や 64bit乗算など、極一部の CPU 専用命令を使う場合のみ アセンブラを使ってください。 それ以外に使うメリットはほとんどありません。 解は確かにあるけれど、そこにたどり着くまでの労力の方が惜しいのです。
| [メニューに戻る] | [ZAURUS総合] | [DirectX] | [Ko-Window] | [Win32] | [WinCE] | [携帯電話] | [その他] |
| フルパワー全開 | Hyperでんち |