page0065 のバックアップ(No.10)

更に小さくするために

(by K, 2013.08.23)

↑

(1) メモ

[2013.08.23] #0000 inkeyでEnter, ESC, カーソルキー, Tab, Spaceなどを1,2,3,4,5,...で拾えたら有利そうだ。どれをどれに割り当てるかは検討が必要だけど。

[2013.08.23] #0001 8色カラーモードのほかに、64色、512色、4096色、32K色モードがあればいいのでは？（フルカラー、8、512、32Kの4択でいいかなー）

[2013.08.23] #0002 8色カラーモードでは、-1を7と同一視する。白の使用頻度は高いのに7に割り当てるのは不利だから。

[2013.08.24] #0003 フロントエンドコードにおいて、LIMMとCPは統合されるべきなのでは？ PLIMMとPCPも。いやPLIMMはマイナスも結構使うから、統合しないほうがいいかもしれない。あと絶対JMPもほしい（関数call用）。PCPを絶対call用にしてはどうか？

[2013.08.24] #0004 ADDの使用頻度が相当なものなので、どうにかならないだろうか。

[2013.08.24] #0005 OR 0, OR -1, XOR 0, AND 0, AND -1, ADD 0, SUB 0, MUL 0, MUL 1, DIV 1, DIV -1, DIV 0, MOD 0, MOD 1, MOD -1, SHL 0, SHL -1, SAR 0, SAR -1 これらは基本的に出現しないから、何か有用な別の意味を与えられないだろうか？

[2013.08.24] #0006 op:13はsbxにする必要がなくなったので、incにするのはどうか？で17をdecとか？・・・うーん、微妙な気がする。incやdecの利用頻度はどうなのだろうか？

[2013.08.24] #0007 むしろマルチプルエクスチェンジのほうが夢がある気がする。エクスチェンジではなく代入方向があったほうがいいかな。これで13と17を使うとか。・・・うーん。

[2013.08.27] #0008 リピートレジスタを導入する。2本くらいが適当だろう。直近の2つのdestレジスタを非常に短い形式で参照できる。

[2013.08.28] #0009 第三世代OSASKで導入予定のRxxに対する精度指定をもう入れてしまう。そうすればバイトコードの互換性がさらにとりやすくなる。しかしOSECPUでは値は無視してしまってよい。サイズとは無関係。

[2013.08.28] #0010 第三世代OSASKで導入予定の可変長バックエンド（hh4）のサポートももういれてしまう。サイズとは無関係。

↑

(2) 詳細検討

#0000: うまい方法を思いついた。結局よく使うのはカーソルだけだから、-1,0,+1をR32とR33に入れて返そうと思う。つまり非標準の戻り値。これなら互換性も崩れない。

#0001: 従来との互換性を保ったまま実現できる。
- 512では、8階調になる。255を掛けて7で割る。
- 32Kでは、32階調になる。255を掛けて31で割る。

#0002: 従来との互換性を保ったまま実現できる。

#0003: LIMMで-16以下の数字を扱ってなければ、互換性を維持したまま統合できる。
- CPよりも短くなるのは、srcがR06-R0Fの場合かな。後は同じにしかならない。ただこれにより17が空く。
- PCPについては0x40以降をabsoluteモードにすればいいので、互換性を維持したまま拡張できる。
- 関数呼び出しは複数回行われると期待していいので、常にabsoluteで問題ない。
#0005: ADD -1, SUB -1, MUL 2, MUL 4, DIV 2, DIV 4, MOD 2, MOD 4もその気になれば除外できる。
- これらをレジスタ演算に割り当てるという手はある。もしくはもっと遠い定数に割り当てることもできる。どっちが有用か？
- レジスタ演算の場合： OR:R01まで、XOR:R00まで、AND:R01まで、ADD:R01まで、SUB:R01まで、MUL:R03まで、DIV:R04まで、MOD:R04まで、SHL:R01まで、SAR:R01まで。
- 定数拡張の場合： OR:7まで、XOR:6まで、AND:-2,6まで、・・・いやちがうな。
  - ORはビット操作を想定するべき？1,2,4,8,16,64,256。XORは値の反転を想定すべき？-1,1,2,3,4,5,6。ANDは抽出を想定するべき？1,3,7,15,31,63,255。
  - ADDとSUBは1,2,3,4,5,6,7。MULは-1,3,5,6,7,9,10。DIVとMODは3,5,6,7,9,10,11。XORは値を交互にすることを想定。
  - PADDも0はいらないので、XORと同様のテーブルかも。
- 定数拡張が筋よさそうだ。あとは互換性を維持して変換テーブルを並べ替えればいい。
- とここまで検討しておきながら、まだレジスタ演算にするべきかもと迷っている。
  - この決定を下すにはもっとたくさんアプリを書いて、材料を集める必要がありそうだな・・・。
#0008: src側の場合、4bit形式での指定と、12bit形式での指定（べき数のリザーブエリアの末尾）がある。dest側の場合、0と1がリピートで、R00以降は2以降になる。R3CとR3Dは12bit形式に追い出す。Pxxも同様。4bit形式はRR0、PR0のみでいい。RR1、PR1は12bit形式のみでOK。
- LIMMや関数の引数などでは、4bit形式はこうなる： -1,0,1,2,3,4,RR0
  - charsは0を補わなくてもよくなるわけだ。 05e2 60c20c7f 5146

↑

(3) 実装計画

#0000: ver.0.74で実装予定。
#0001: ver.0.74で実装予定。
#0002: ver.0.74で実装予定。
#0003: ver.0.74で実装予定。
#0005: 検討中。→ rev2
#0008: → rev2
#0009: → rev2
#0010: → rev2

↑

こめんと欄

思いついたことがあれば、どんどん教えてください！ -- K 2013-08-23 (金) 19:51:08

コメント	お名前	NameLink