さらに小さなフロントエンドコードを目指して
はじめに
- これはrev3の構想のためのメモです。
- 現時点での切り分け。
- rev1: JITC型でとにかく作ってみたバージョン
- rev2: rev1での経験を踏まえて今度はインタプリタ型でフロントエンドコードを改良。
- rev3: さらにフロントエンドコードを改良。でもまだレンジコーダには手を出さない。予定。
- rev4: ついに究極のレンジコーダ利用のフロントエンドコード。もはや読めない。
このページで何をやりたいのか
- OSECPU-VMのアプリのフロントエンドコードの中には、様々な整数の定数が現れるが、rev2ではこれらをhh4の改造版でエンコードしている。かなりいいところまで行っていると思うけど、しかしまだ完全ではない気がする。場当たり的な感じがする。
- それをもっと系統的に整理したい。
分かっていること
- 絶対値の小さな数値は頻出する。
- 負の数は-1を除けばめったに表れない。
- 2のベキ数を短くエンコードできると有利。
- 10のベキ数も短くエンコードできると有利。
- 四則演算ができるとさらに良い。
- レジスタ参照も含める必要がある。
- ビット列を見ると、1か0のどちらかが多い。均等に配分されることは珍しい。
案1
- 4ビット形式(7通り)：
-1, 0, 1, 2, 3, 4, rep0
- 8ビット形式(64通り)：
- 0および正の数(16)：0～15
- リピートレジスタ(8)：rep0～7
- 通常レジスタ(8)：R00～0F
- 負の数(8)：-1～-8
- 2のベキ数(8)：16,32,64,128,256,512,2^n(n=10～),16^n(n=3～)
- 2^nのnについて： 4ビット形式の特例： 10,11,13,14,15,17,pre-mul
- 演算(6):ビット反転,積,和,差,xのy乗(x=3～,y=2～),10^(n=3～)
- 未定(2):
- 12ビット形式(512通り)：
- 0および正の数(384)：0～383
- 通常レジスタ(64):R00～3F
- 負の数(32)：-1～-32
- 未定(32)
- 16ビット形式：
- 0および正の数(3584)：0～3583
- 未定(512)
- 24ビット形式以降では、0および正の数しかない。
- 考察：
- 8ビット形式で、リピートレジスタを半減させてしまったのは良い判断だっただろうか？
- でもぶっちゃけ、rep8以降の出現率はかなり低そうだから、まあいいんじゃないかな？
- 典型的な数のエンコード例：
- 1024は12ビット、65536も12ビット
- 100は12ビット、1000や1万も12ビット。1億まで12ビット。
- 4億は(10^)(pre-mul)(8)(4)で8+4+4+4=20ビット。rev2と同点。
- 192は普通に12ビット。
- 384は普通に16ビット。
案2
- pre-mulは利用頻度が高そうなのでデフォルトで適用する。これで4ビット減らせる。
- pre-mulがデフォルトではない2のベキを未定に入れる。
案3
- いや、ちょっとまて。こんなことがやりたかったわけじゃない。これじゃあrev2と大差ない（やり方的には）。
- 数値ごとに利用頻度的なものをうまく定義して、それで上位64個を8ビット形式に割り振って、上位512個を12ビット形式に割り振って・・・みたいなことがやりたい。
こめんと欄
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
