GUIGUI01​/memo08

ぐいぐい01に関するメモ-08

• (by K, 2008.11.16)
• メモのうち重要な部分をそのうちまとめてまともなページを作る

(19) 「ぐいぐい01」ではなにかにつけて4bitを単位に設計されていることについて

• （これはOSC-do-2008でのセミナーの内容の一部を切り出したもの。若干の付け足しもある。）
  
  
  
  
• これを4bitじゃなくて8bitにすれば、OSやefg01内部はもっと簡潔にできたのではないか？という指摘は全面的に正しい。そのほうが実行も速いのではないかと言われると確かにそう*かもしれない*。速さを追求することこそOSASKの本分なのではないかという指摘も完全に正しい。

• しかしまず指摘しておきたいのは、IA-32においてもっとも効率よく（つまり最も速く）アクセスできるのは、間違いなく32bit固定長である（＝8bit単位の可変長ではない）。そしてまさにそれで設計されているのが「ぐいぐい00」である。そして一方で、IA-32であることをひとまず完全に無視し、そして既存のメジャーなCPUの仕様も全部無視して、純粋に二進数の性質だけからもっとも効率の高そうなフォーマットを検討した結果が（つまり実際の利用状況を前提にそれらを最小長でエンコードできそうなのは）、4bit単位の可変長である（というのが僕の結論）。
• 僕は従来、アプリやデータのサイズ縮小は圧縮に任せて、アプリは扱いやすい32bit数値を好きなだけ使えばいいと主張してきた。それが結局はアプリの構造を単純化し、それによって圧縮後のサイズはかえって小さく、さらに拡張性と高速性まで手に入れられるとした。これは大体の傾向においては全面的にその通りである。
• しかし一方で、僕はKHBIOSの設計を通じてCPUの仕様にとらわれずにAPIなどを設計する経験をした（厳密にはOSがKHBIOSを呼び出すためのインタフェースなので、APIではなくOSIというべきかもしれないが）。そもそもどんなCPUで実行されるか分からない以上は、32bitが効率いいなどと事前に決めることはできない。しかも将来への拡張性を担保するためにはパラメータを可変長にすることも避けられない。そうして結局「ぐいぐい01」で採用したのと非常によく似たフォーマットなった（というか「ぐいぐい01」はそのフォーマットをAPIに適用したものに過ぎないので類似性は当然といえる）。
• そうしてできてみるとこれが実によくできており、圧縮しなくてもかなり小さい上に、圧縮すれば更に小さくなることが分かった。少なくとももともと32bit前提で書いて圧縮したものよりもさらに小さいことは確実だった（その差はそんなには大きくはないが、しかし確かにより小さくなることは確実）。
• またこのエンコード方法では、可変長エンコードを常に強要しているわけではなく、固定長モードも内部に持っており、これを使えばモード切替のための数バイトが犠牲になるほかは、従来の32bit固定と全く同様に使うこともできる。だから何か回避しがたい問題があれば、このモード切替を必須にしてしまえばいいわけだ（このAPIは32bit固定モードでないと機能しません、とか）。そうすればフォーマットは一切変更することなく（＝互換性を維持したまま）ふさわしい仕様にすることもできる。この固定モードのおかげで、APIのパラメータを適当にPUSHしてEBX=ESPにしてAPIを呼び出すという従来の手法ももちろん使える。
• ということで、とりあえずこれを前提にAPIを設計してみたくてたまらなくなり、そしてできたのが「ぐいぐい01」というわけである。
• 4bitを基本単位にすることで、ローダやAPIのパラメータ解釈ルーチンが複雑になったのは間違いなく、それは明らかにデメリットである。しかしAPIパケットやアプリそのもののサイズは小さくなったのでキャッシュヒット率は改善している。またファイルサイズがより小さくなることはディスクキャッシュの効率を高め、キャッシュヒット率に貢献するだろう。さらに将来のOSASKに搭載されるであろう「展開キャッシュ」（よく利用されるファイルについては、tekの展開時間すら惜しいかもしれないので、展開後のものをメモリ上にキャッシュとして保持）も、展開後のサイズが小さくなることでキャッシュ利用効率が上がるだろう。そういうトータルで考えれば、たとえ4bitを基本単位としていても、むしろ32bit固定長より速いかもしれない。というか試してみないと分からない。だからとにかく作ることにした。
• なお今後32bitではないCPUのOSを作ることになったとしても、僕はとりあえずこの「ぐいぐい01」とよく似た仕様のものにするつもりでいる。CPUのbit数からして違うのに、APIがほとんど変わらないなんて、いかにも設計がよくできている気がするではないか（笑）。ただこれについてはAPIに互換性があったところでバイナリ非互換であることは変わりなく、せいぜいアプリのソースレベルで互換性が維持しやすいかどうかという程度のメリットしかないが。ほとんど設計者の自己満足でしかない。

• 以上の話は32bit固定にしなかった理由であって、8bit可変長との比較ではない。4bit可変長と8bit可変長は、効率では大きな差があるわけではないが（しかし小さくはない差がある）、しかしデコードプログラムの簡単さでは全然違う。それはひとえにIA-32では8bit整数列を扱いやすくするための命令群が比較的豊富にあるのに、4bit整数列を扱いやすくするための命令群がほとんどないためである。というかIA-32に限らず、4bit整数を意識したCPUアーキテクチャは現状ではほぼ皆無だろう。
• これに対する僕の言い分としては、二点ある。まずKHBIOSのようなCPUを超えて汎用性を追及しようという立場に立てば、現状のCPUの設計に落ち度があるのを理由にして、KHBIOSの仕様まで落ち度があるものにしていいのか。だって単純に二進数の性質からいってもっとも効率がよさそうなのは4bit単位なのだ。それをサポートできていないのはCPUの命令セットにそういう命令が入っていないだけの理由だ。将来のCPUには入るかもしれない（というかキャッシュヒット率が重要になってきた昨今の状況を考えると入れるべきだ）。そもそもアドレスが8bit単位でしか付いていないってのは非常に不自然で、IA-32なら32bit単位か、もしくは1bit単位にするべきだったと思う（まあ1bit単位にすると全メモリ空間が512MBしかないという寒い状況になってしまうわけだが）。8080から引きずっている互換性のために8bit単位なのだろう。それ以外の必然性は何もない。KHBIOSは幸いにもまだ配慮すべき互換性の対象がない（旧バージョンのKHBIOSがあれば話は別かもしれなかった）。だから一番よいと思われるものを採用することをためらうと将来に禍根を残すと思う。
• そしてもう一つの言い分は、仕様として4bit単位を採用しても、実装として8bit単位のみを扱うということにすることは十分に可能である（最初から8bit単位にしているものと比べれば当然効率は落ちるが）。しかし逆はできない。つまり8bit単位で仕様を決めてしまったら、4bit単位の実装を後から作りたいと思っても互換性を維持した形ではできない。だから、どちらが「仕様として」拡張性が高いかといえば、4bit単位に決まっている。拡張性はもちろん高いほうがいい。仮に8bit単位でしか当面は運用しないとしても、将来4bitが扱いやすくなったときのための拡張性のためなら、十分に我慢できると僕は考えた。

こめんと欄