ページへ戻る

− Links

 印刷 

GUIGUI01​/memo08 の変更点 :: OSASK計画

osaskwiki:GUIGUI01/memo08 の変更点

« Prev[3]  
3: 2009-11-17 (火) 12:08:34 ソース[4] 現: 2024-01-08 (月) 12:58:42 k-tan[5] ソース[6]
Line 1: Line 1:
-* ぐいぐい01に関するメモ-08+TITLE:x 
 +* ぐいぐい01に関するメモ-08 [#w2536575]
-(by [[K]], 2008.11.16) -(by [[K]], 2008.11.16)
-メモのうち重要な部分をそのうちまとめてまともなページを作る -メモのうち重要な部分をそのうちまとめてまともなページを作る
-*** (19) 「ぐいぐい01」ではなにかにつけて4bitを単位に設計されていることについて+*** (19) 「ぐいぐい01」ではなにかにつけて4bitを単位に設計されていることについて [#sd29e408]
-(これは[[OSC-do-2008>OSC_2008/Hokkaido]]でのセミナーの内容の一部を切り出したもの。若干の付け足しもある。) -(これは[[OSC-do-2008>OSC_2008/Hokkaido]]でのセミナーの内容の一部を切り出したもの。若干の付け足しもある。)
~ ~
Line 20: Line 21:
-これに対する僕の言い分としては、二点ある。まず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が扱いやすくなったときのための拡張性のためなら、十分に我慢できると僕は考えた。
-* こめんと欄+* こめんと欄 [#k3653b8e]
#comment #comment
« Prev[3]