2: 2008-11-16 (日) 06:48:16  |
3: 2009-11-17 (火) 12:08:34 |
| | -なお今後32bitではないCPUのOSを作ることになったとしても、僕はとりあえずこの「ぐいぐい01」とよく似た仕様のものにするつもりでいる。CPUのbit数からして違うのに、APIがほとんど変わらないなんて、いかにも設計がよくできている気がするではないか（笑）。ただこれについてはAPIに互換性があったところでバイナリ非互換であることは変わりなく、せいぜいアプリのソースレベルで互換性が維持しやすいかどうかという程度のメリットしかないが。ほとんど設計者の自己満足でしかない。 | | -なお今後32bitではないCPUのOSを作ることになったとしても、僕はとりあえずこの「ぐいぐい01」とよく似た仕様のものにするつもりでいる。CPUのbit数からして違うのに、APIがほとんど変わらないなんて、いかにも設計がよくできている気がするではないか（笑）。ただこれについてはAPIに互換性があったところでバイナリ非互換であることは変わりなく、せいぜいアプリのソースレベルで互換性が維持しやすいかどうかという程度のメリットしかないが。ほとんど設計者の自己満足でしかない。 |
| | ---- | | ---- |
| - | -以上の話は32bit固定にしなかった理由であって、8bit可変長との比較ではない。4bit可変長と8bit可変長は、効率では大きな差があるわけではないが、しかしデコードプログラムの簡単さでは全然違う。それはひとえにIA-32では8bit整数列を扱いやすくするための命令群が比較的豊富にあるのに、4bit整数列を扱いやすくするための命令群がほとんどないためである。というかIA-32に限らず、4bit整数を意識したCPUアーキテクチャは現状ではほぼ皆無だろう。 | + | -以上の話は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があれば話は別かもしれなかった）。だから一番よいと思われるものを採用することをためらうと将来に禍根を残すと思う。 | | -これに対する僕の言い分としては、二点ある。まず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 |
