osecpu_0002

OSECPUに関するメモ（番外版） #2

• (by K, 2013.05.28)

機能密度追及に関するメモ

• (0) このメモをOSECPUのサイトに書かない最大の理由は、OSECPU-wikiが機能密度の話題でいっぱいになるのが少々申し訳ないため。

• (1) ver.0.40をリリースしてから思いついたこと。
  • まず、charsは現在9バイトだが、実はこれは8.5バイトで書く方法もある。つまりもう少しで8バイト化が可能だ。どうにかならないだろうかと考えること1時間弱。実はcharsの9バイト目は00なのだ。それなら実行ファイルを解釈する際には、00を数個付与してから解釈するようにしたらどうだろうか。実はそのようにしても他の実行ファイルには何の影響もない。というか内部では数バージョン前からそうしている（番兵にしている）。よし採用。

• 次にhelloだけど、実はこれも15.5バイトで書ける。そしてOSASK文字列という7bitエンコードと8bitエンコードの中間みたいなものはやめて、純粋な7bitエンコードに切り替えることができれば、これも15.0バイト化が可能なはずだ。よしこれもやってみるか。

• (2) なんか僕の場合、いきなり最高の設計には到達できなくて、まず自分の持っているアイデアを全部入れたものを作ってみて、それをしばらく使っているとやっと改良案が出てくる。・・・ということは、出し惜しみなく作るしかない。

• (3) charsをちょっと考えてみる。現在8バイトだけど、単純に考えれば、0x20という開始値と0x7fという終了値は必要で、まあこれがそれぞれ1バイトだとしよう。そして2バイトのシグネチャがある。そうするとそれだけで4バイトは必要で、制御のために使っているのは4バイトだということになる。なるほど。

• (4) アセンブラ短歌という遊びがある。31バイトでプログラムを書くのだが、さらに制約があってそれは57577のところで命令を区切らなければいけない。またがってはいけないのだ。非常に文化的で有意義な遊びである（笑）。ちなみにシグネチャやヘッダは31バイト内に含めなくてよい。
  • http://kozos.jp/documents/ の

    第２回APASEC+第２期サイボウズ・ラボユース合同勉強会(2013/03/29)

  • のところによい資料がある
  • このアセンブラ短歌にOSECPUで挑戦したらどうなるのかということを少し考えてみた。すると、3+5+3+5+6=22バイトじゃないかなということになった。OSECPU以外のCPUではせいぜい13バイト程度だったことを思えば、これは圧倒的に強い。575であるアセンブラ川柳でさえ3+5+4=12バイトまでいけるので、もはやハンデとして川柳にしてやらなければいけないかなと思うレベルだ。
  • また7bitエンコードモードにすればメッセージの難読化も同時に実現できるので「アセンブラかるた」の実現も容易だと思う。
  • 余談ではあるが、アセンブラ短歌は本当は機械語短歌だよなあ、と思った。

• (5) putConstStringのメモ：
  • 510(len)(UINT8): lenは符号なしhh4
    • (1...6 → +2), (7...63 → +2.5), (64...511 → +3)
    • OSASK文字列を使えば、8文字を9.5バイトで出力できる。以降8文字ごとに-1バイト。
  • 513(UINT8)(00):
    • (1... → +2.5)
    • 末尾: (1... → +1.5)
    • OSASK文字列を使えば、8文字を9.5バイトで出力できる。以降8文字ごとに-1バイト。
  • 515x(UINT7): xはlen-4で、0～F
    • (4...7 → +1.5), (8...11 → +1), (12...15 → +0.5)
  • 516(UINT7)(00)
    • (1...2 → +2.5), (3...6 → +2), (7...10 → +1.5), (11...14 → +1)
    • 末尾: