ページへ戻る

− Links

 印刷 

GUIGUI01​/memo01 のバックアップソース(No.1) :: OSASK計画

osaskwiki:GUIGUI01/memo01 のバックアップソース(No.1)

  Next »[4]
* ぐいぐい01に関するメモ-01
-(by [[K]], 2008.04.25)
-メモのうち重要な部分をそのうちまとめてまともなページを作る
*** (5) KHBIOSとの関係
-何かにつけて「ぐいぐい01」はKHBIOSの影響で改良に成功とか言っている気がするので、少し詳しく説明しておく。他の人から見たら、「ぐいぐい01」がKHBIOSの影響を受けているのはちっとも自明ではない気がするので。
-「ぐいぐい00」では、第一にIA-32にとって最良のAPIとは何かから出発して設計していた。まあこれで本当にIA-32にとって最良の設計に到達できていれば何も問題はなかったのだが、実際はそうではなかった(今になって思えば)。
-KHBIOSを作るにあたり、KHBIOSはIA-32のみならず、どんなCPUにとっても合理的な設計でありたいと強く思った。これはKHBIOSが一つのディスクでAT/TOWNS/PC98のどれでも起動できるような仕様にしたいと思ったのに関連して、PowerPCのMacやそのほかのアーキテクチャのコンピュータも意識し始めて、それで特定のCPUのみならず、過去現在未来のアーキテクチャまで含めてベストを目指そうと、より深いレベルから設計を考えた。
-そうして目が肥えてくると、「ぐいぐい00」を見たときに、なんとまあ今までいい加減なレベルで満足していたんだと思うくらいに問題点が出てきた。それで、KHBIOSの設計を反映させてAPIを作り直したのである。
*** (6) APIの基本構造
-「ぐいぐい00」では基本のデータ型は32bitの整数であった。これに対し「ぐいぐい01」の基本のデータ型はない。ただよく出てくるデータ型というのはある、それは4bit整数である。もちろんすべての数値を4bitで表せるなんて事はめったにないので、4bitで表せない数値は2倍長の8bitや3倍長の12bit、もちろんそれより長い16、20、24、28・・・といくらでも伸ばせる。多倍長の場合、エンディアンはビッグである。インテルでおなじみのリトルではない。これらは何ヶ月(というか1年以上?)どうするのが一番いいのかを考えた末の[[K]]なりの結論である。
-4bitで数値を表すといっても、0~15の符号なし整数が扱えると思いきやそうではない。実際は4bitでは0~7までしか表現できない。というのは、最上位ビットがヘッダで、「これは4bit形式ですよ」ということを示しているからである。8bit形式の場合は3bitがヘッダ、12bitも16bit形式も3bitがヘッダ、20bit形式では6bitもヘッダに食われる。
-かつては多倍長形式といえばs7sのような「継続ビット系」の設計をよく使っていたが、これはあまりよくないと今では思っている。というのは数値をデコードする際にエンコード長を早く抽出できたほうがデコードはやりやすいわけで(たとえばFPGAなどでデコードすることを考えている)、それならエンコード長を得るためのデータは一箇所にまとまっているほうが有利だからである。
-(つづく)

* こめんと欄
#comment

  Next »[4]