page0046 のバックアップ(No.2)

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
page0046 へ行く。
- 1 (2013-06-27 (木) 16:46:25)
- 2 (2013-06-27 (木) 17:20:13)
- 3 (2013-06-27 (木) 20:30:05)
- 4 (2013-06-27 (木) 20:30:05)
- 5 (2013-07-07 (日) 05:38:07)

OSECPUサイズ最適化テクニック集

(by K, 2013.06.27)

↑

(1) テクニック

(1) PADD+LMEM ではなく PALMEMを使う。
- これで1つにつき3～4バイト改善する
(2) PADD+SMEM ではなく PASMEMを使う。
- これで1つにつき3～4バイト改善する
(3) グラフィックスの色指定で0xffffffを指定するのなら、modeに4を加えて色指定を7にする。
- これで1つにつき3～4バイト改善する
- ほかの典型色も同様（黒は何もしなくても0なのでそのままでいいと思う）
(4) for (i = 12; i < 34; i++) などは、条件式を i != 34 に変更する。
- これで1つにつき3～4バイト改善する
(5) mainルーチンの後に beginFunc(...); が来ているのなら、 jnukApi_exit(0); は省略可能。
- これで6～8バイト改善する
(6) junkApi_sleep(0, -1); を記述したのなら、それ以降に処理が進むことを一切配慮する必要はない。
- 改善量はもとのプログラム次第
(7) キー入力がなければ特に何もすることがないsleepの場合、modeを2にすることができる（通常はゼロ）。
- これをすれば、直後のinkeyで-1が返ってくることを想定しなくてよい
- これで3バイト程度改善する
(8) レジスタを使う場合、R00～R07、P01～P07を積極的に使う。
- R08以降、P08以降は一度出るたびに0.5バイトずつプログラムが長くなる
(9) もしPxxが変化してもかまわないのなら、LMEM0の代わりにLMEM0PPを使う
- これで1つにつき0.5バイト改善する
- これはにわかには信じがたいだろうが、PPつきのほうが利用頻度が高いと分かっていて、それで短い形式を割り振ってあるため
(10) 同様にSMEM0の代わりにSMEM0PPを使う
- これで1つにつき0.5バイト改善する
(11) API呼び出しの際に引数が計算式になっていないかチェックする
- レジスタを含まない定数式なら問題はない
(12) inkeyの処理で、4132,4133,4134,4135と比較する処理が出てくると思うが、いったんレジスタから4132を引いてしまって、それで0,1,2,3と比較するという技が使える

(13) 似たような処理はできるだけまとめる
- これはすごく効果があるので、R08以降を使うことになったとしてもためらわずにやってみる価値あり
- 同じようなものが2度、3度とでているのなら、そしてその違いがわずかなら、その違う部分をレジスタにして、そのレジスタに適切な値をセットできないかを検討する

↑

(2) 数値定数を表現するのに要するバイト数の表

 -3 ～  +3 : 0.5バイト
-15 ～ +31 : 1.0バイト
   ～ +256 : 1.5バイト (255の間違いではない)
  ～ +2047 : 2.0バイト
 ～ +32767 : 3.0バイト (2.5バイトの間違いではない)
～ +524287 : 3.5バイト
（以下略）