さらに小さなフロントエンドコードを目指して
はじめに
- これは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ビット形式に割り振って・・・みたいなことがやりたい。
こめんと欄
- Do you know each other? http://thisav.fun/ thisav.com The Rangers arenât deep enough to bench players left and right, with Rick Nash (concussion) and Carl Hagelin (shoulder) sidelined. But Vigneault still has cause to demote his struggling forwards. Zuccarello (17:23), Pyatt (15:22) and Pouliot (13:49) rank third, seventh and eighth, respectively, among Rangers forwards in minutes played. But they have combined for no points and a minus-11 through five games. -- Irea 2019-06-29 (土) 20:30:05
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
