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

更に小さくするために

(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）のサポートももういれてしまう。サイズとは無関係。

[2013.08.29] #0011 for構文はデフォルトでstep1、それを変更するのならプリフィクスで、でいいのではないか？そのほうが単純だし融通がききそう。あと開始値と終了値の両方が定数であれば終了値に開始値を加える。

[2013.08.29] #0012 拡張符号付整数で、-16からをレジスタに割り当てるのは改善の余地がある。-4くらいからでいいのではないか？それくらいマイナスの定数は使わない。

[2013.08.29] #0013 PLIMMでP3F以外を指定したときはopt=0のものは除外できるのだから、そうしたほうがよい。そのほうが値が小さくなる。データラベルを優先するべきという気もする。それならコードラベルのときは0dプリフィクスをつけさせようか。

↑

(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 60c20c5f 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
#0011: → rev2
#0012: → rev2
#0013: → rev2

↑

こめんと欄

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

コメント	お名前	NameLink