ページへ戻る

− Links

 印刷 

GUIGUI01​/memo08 のバックアップ差分(No.2) :: OSASK計画

osaskwiki:GUIGUI01/memo08 のバックアップ差分(No.2)

« Prev[4]  Next »[5]
1: 2008-11-16 (日) 06:48:16 ソース[6] 2: 2008-11-16 (日) 06:48:16 ソース[7]
Line 2: Line 2:
-(by [[K]], 2008.11.16) -(by [[K]], 2008.11.16)
-メモのうち重要な部分をそのうちまとめてまともなページを作る -メモのうち重要な部分をそのうちまとめてまともなページを作る
-*** (19) ぐいぐい01ではなにかにつけて4bitを単位に設計されていることについて +*** (19) 「ぐいぐい01」ではなにかにつけて4bitを単位に設計されていることについて 
--(これはOSC-do-2008でのセミナーの内容の一部を切り出したもの)+-(これは[[OSC-do-2008>OSC_2008/Hokkaido]]でのセミナーの内容の一部を切り出したもの。若干の付け足しもある。) 
 +
 +~
-これを4bitじゃなくて8bitにすれば、OSやefg01内部はもっと簡潔にできたのではないか?という指摘は全面的に正しい。そのほうが実行も速いのではないかと言われると確かにそう*かもしれない*。速さを追求することこそOSASKの本分なのではないかという指摘も完全に正しい。 -これを4bitじゃなくて8bitにすれば、OSやefg01内部はもっと簡潔にできたのではないか?という指摘は全面的に正しい。そのほうが実行も速いのではないかと言われると確かにそう*かもしれない*。速さを追求することこそOSASKの本分なのではないかという指摘も完全に正しい。
---- ----
--しかしまず指摘しておきたいのは、IA-32においてもっとも効率よく(つまり最も速く)アクセスできるのは、間違いなく32bit固定長である。8bit単位の可変長ではない。そしてまさにそれで設計されているのが「ぐいぐい00」である。そして一方で、IA-32であることをひとまず完全に無視し、そして既存のメジャーなCPUの仕様も全部無視して、純粋に二進数の性質だけからもっとも効率の高そうなフォーマットを検討した結果が(つまり実際の利用状況を前提にそれらを最小長でエンコードできそうなのは)、4bit単位の可変長である(というのが僕の結論)。+-しかしまず指摘しておきたいのは、IA-32においてもっとも効率よく(つまり最も速く)アクセスできるのは、間違いなく32bit固定長である(=8bit単位の可変長ではない)。そしてまさにそれで設計されているのが「ぐいぐい00」である。そして一方で、IA-32であることをひとまず完全に無視し、そして既存のメジャーなCPUの仕様も全部無視して、純粋に二進数の性質だけからもっとも効率の高そうなフォーマットを検討した結果が(つまり実際の利用状況を前提にそれらを最小長でエンコードできそうなのは)、4bit単位の可変長である(というのが僕の結論)。
-僕は従来、アプリやデータのサイズ縮小は圧縮に任せて、アプリは扱いやすい32bit数値を好きなだけ使えばいいと主張してきた。それが結局はアプリの構造を単純化し、それによって圧縮後のサイズはかえって小さく、さらに拡張性と高速性まで手に入れられるとした。これは大体の傾向においては全面的にその通りである。 -僕は従来、アプリやデータのサイズ縮小は圧縮に任せて、アプリは扱いやすい32bit数値を好きなだけ使えばいいと主張してきた。それが結局はアプリの構造を単純化し、それによって圧縮後のサイズはかえって小さく、さらに拡張性と高速性まで手に入れられるとした。これは大体の傾向においては全面的にその通りである。
-しかし一方で、僕はKHBIOSの設計を通じてCPUの仕様にとらわれずにAPIなどを設計する経験をした(厳密にはOSがKHBIOSを呼び出すためのインタフェースなので、APIではなくOSIというべきかもしれないが)。そもそもどんなCPUで実行されるか分からない以上は、32bitが効率いいなどと事前に決めることはできない。しかも将来への拡張性を担保するためにはパラメータを可変長にすることも避けられない。そうして結局「ぐいぐい01」で採用したのと非常によく似たフォーマットなった(というか「ぐいぐい01」はそのフォーマットをAPIに適用したものに過ぎないので類似性は当然といえる)。 -しかし一方で、僕はKHBIOSの設計を通じてCPUの仕様にとらわれずにAPIなどを設計する経験をした(厳密にはOSがKHBIOSを呼び出すためのインタフェースなので、APIではなくOSIというべきかもしれないが)。そもそもどんなCPUで実行されるか分からない以上は、32bitが効率いいなどと事前に決めることはできない。しかも将来への拡張性を担保するためにはパラメータを可変長にすることも避けられない。そうして結局「ぐいぐい01」で採用したのと非常によく似たフォーマットなった(というか「ぐいぐい01」はそのフォーマットをAPIに適用したものに過ぎないので類似性は当然といえる)。
Line 18: Line 20:
-これに対する僕の言い分としては、二点ある。まずKHBIOSのようなCPUを超えて汎用性を追及しようという立場に立てば、現状のCPUの設計に落ち度があるのを理由にして、KHBIOSの仕様まで落ち度があるものにしていいのか。だって単純に二進数の性質からいってもっとも効率がよさそうなのは4bit単位なのだ。それをサポートできていないのはCPUの命令セットにそういう命令が入っていないだけの理由だ。将来のCPUには入るかもしれない(というかキャッシュヒット率が重要になってきた昨今の状況を考えると入れるべきだ)。そもそもアドレスが8bit単位でしか付いていないってのは非常に不自然で、IA-32なら32bit単位か、もしくは1bit単位にするべきだったと思う(まあ1bit単位にすると全メモリ空間が512MBしかないという寒い状況になってしまうわけだが)。8080から引きずっている互換性のために8bit単位なのだろう。それ以外の必然性は何もない。KHBIOSは幸いにもまだ配慮すべき互換性の対象がない(旧バージョンのKHBIOSがあれば話は別かもしれなかった)。だから一番よいと思われるものを採用することをためらうと将来に禍根を残すと思う。 -これに対する僕の言い分としては、二点ある。まず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が扱いやすくなったときのための拡張性のためなら、十分に我慢できると僕は考えた。 -そしてもう一つの言い分は、仕様として4bit単位を採用しても、実装として8bit単位のみを扱うということにすることは十分に可能である(最初から8bit単位にしているものと比べれば当然効率は落ちるが)。しかし逆はできない。つまり8bit単位で仕様を決めてしまったら、4bit単位の実装を後から作りたいと思っても互換性を維持した形ではできない。だから、どちらが「仕様として」拡張性が高いかといえば、4bit単位に決まっている。拡張性はもちろん高いほうがいい。仮に8bit単位でしか当面は運用しないとしても、将来4bitが扱いやすくなったときのための拡張性のためなら、十分に我慢できると僕は考えた。
-* こめんと欄 
-#comment 
- 
- 
* こめんと欄 * こめんと欄
#comment #comment
« Prev[4]  Next »[5]