gg02​/p0002 :: OSASK計画

第三世代OSASKに関するメモ群 ^[1]

• (by K^[2], 2011.12.30)

(2) OSASK計画再定義 ^[3]

• 1995年、PCの世界にWindows95が出て、そして結果的にTOWNS系やPC9801系やX68000系はシェアを落として行き、ついには新機種が開発されなくなってしまった。それらの競争に負けたPCたちは、本当に全力を出し切った上で負けたのだろうか。私にはとてもそうは思えない。本当はもっといろいろなことが出来たはずなのに、私も含めた当時のプログラマの腕が悪かったために、能力を出し切れないまま、競争上の敗者になってしまった。
• 私はTOWNSが好きだ。今でも好きだ。しかし自分が今からがんばっていろいろなソフトを作ったとしても、今さらTOWNSが復活するとは思っていない。でも私は1995年に存在したPCたちを意識してソフトウェアを作り続ける。墓標に花をそえているだけかもしれない。しかしそれは私にとって、TOWNSというハードウェアを開発した人々への感謝の表現でもある。
• にもかかわらず、OSASK計画はTOWNS用のソフトウェアを作るというわけではない。それだと本当に動かせるユーザがいなくなってしまう。そうではなくて、TOWNSへ移植可能な、TOWNSでもそこそこ快適に使えるような、そういうレベルのソフトウェアを作っていく。最新のハードウェアにあわせて、MMX、SSE、64bit、マルチコア、メモリ8GB以上、などに迎合し、それらのスペックがなければ本質的に動作しないようなソフトウェアは私は作りたくない（仕事では作るかもしれないけど、趣味のOSASK計画ブランドでは作らないということ）。手抜きで少々メモリを浪費するとかは十分にありうるが、移植の際に気をつければ問題ないレベルにとどめる。・・・もちろん、最新ハードウェアを完全に否定しているわけではなく、それらの機能があればそれはそれで高速に動作する、というものは作るだろう。しかしそれらがなければ動作しないようなものは作らない。
• どうせ最新機能を使わないと出来ないようなソフトウェアは誰かが作ってくれる。そういうソフトを作りたがる人はいくらでもいるから。私は何年も何十年も前に作られていなければいけなかったのに作られてこなかったものを、好んで作るといっているだけである。忘れ物を拾い集めるのだ。・・・私のやることは時事に左右されない。陳腐化もしない。真に必要なもののうち、過去の技術で十分に実現可能なものを選んで作るだけだからだ（まあ作る前から陳腐化しているともいえるが・・・笑）。
• 私が示したいのは、1995年のハードウェアのままでもソフトウェアががんばればこの程度のことはどのPCでも十分にできたんだ、どうして早く作ってやらなかったのだろう、私たちは本当に反省しなければいけない、ということだ。これを今後の当面のOSASK計画の指針とする。

(3) hh4 ^[4]

• hh4はgh4の後継とでもいうべきもので、総ビット16bit形式までは互換性がある。
  • 参考： GUIGUI01​/man0004^[5]
• 主な違いをまとめると次のようになる。
  • 20bit形式以降がかなり単純化された。
  • パディング用コードが"7"から"F"に変更された。
    • "7"は長bit形式用の拡張プリフィクスになった。
  • 長い総bit長でのエンコード効率が改善された（パディングをあまり使わなくてよくなった）。仕様上の長さの上限もなくなった。
    • （例）252bit : 制御ビットは12bit(gh4は40bit)
  • 負の整数のエンコード方式が規定された。
  • 浮動小数点のエンコード方式も規定予定。
  • 構造を表現するためのフォーマットも用意された。
    • 似たようなものはgh4でも利用されてはいた。今回はこれを整理しなおして、さまざまな用途で使えるように調整した。
    • 参考：GUIGUI01​/man0003^[6]
    • 平たく言えば、XMLのOSASK版だと思ってほしい。
• なぜこんなものを作ったのかということを明確にしておこう。
  • 第三世代OSASKでは、タスクセーブをする。これはつまりファイルにプログラムの状態を出力するというものである。この保存方法はメモリのイメージを単純にバイナリで出力するといったようなものではなく、メモリのどこにどんな構造体があって、その値はかくかくじかじかで・・・のような形式で保存する。なぜならこのような対応関係が明らかではない方法で保存すれば、異なるOS、異なるCPUでのタスクロードに対応できないからである。
  • このような用途では、一般にはテキスト形式での保存が行われることが多い。しかしこれは非常に冗長である。また10進数で記録するのなら、進数変換もしなければいけない。これは除算を必要とするので、結構重い。・・・この冗長性は何のために行われるのか。
    • テキストだと将来何ビットにでも拡張できる（拡張性）。
    • テキストだと人間に分かりやすいのでデバッグしやすい。
    • バイナリだとエンディアンの問題とかも悩ましい。
  • しかしそもそもデータの保存や読み込みはコンピュータが書いてコンピュータが読むものである。人間がその内容を直接確認することなどめったにない。現在の状況は、日本人同士が会話するときになぜか英語を使っているような状況といえる。日本語で会話すればいいではないか。なぜ効率のよくない言語を経由しなければいけないのか。・・・それは結局、誰も使いやすいフォーマットを決めてこなかったからである。テキスト並みの無限の拡張性とテキスト並みの構造記述力を兼ね備えたバイナリベースのフォーマットを整備しなかったからである。それどころかテキストベースのXMLまで作ってしまった。こんなものは文字列比較を何度もやらなければいけない上に、禁止文字などがあってそれはエスケープしなければいけないなど、本当にコンピュータにとっては不便極まりないものである。
  • まず私は整数の数値の単純かつ効率のよいエンコードを考えた。これは絶対値の小さい数値は少ないビット数でエンコードできるし、またわざと固定長でエンコードすることも許す。・・・そしてこれを利用して多様な構造を表現できるフォーマットを作った。タグには英語名はつけられないが番号をつけることは出来る（番号ゆえに比較は非常に容易である）。またストリングテーブルを用意して、どのタグ番号がどのタグ名に対応するのか決めておけば、事実上XML並みの表現力もある。
  • これらはバイナリであって、人間には分かりやすくない。しかしこれらのフォーマットは単純かつ応用が利くので、汎用のviewerやeditorや対テキストコンバータを用意することは容易である。したがって、人間が読み書きしたいときはそういうツールを利用すれば何の問題もない。
  • まとめ：私たちプログラマは長い間テキスト形式に匹敵する汎用性と拡張性を持ったバイナリベースのフォーマットを考えてこなかった。そのせいでコンピュータは不必要な非効率を強いられてきた。実に情けない。hh4はこの問題を解決するためのフォーマットである。
• 符号なし整数のフォーマット：

  総bit長	フォーマット（2進数）	xのbit数	表現可能な最大値（10進）	同最大値（16進）	俗称
  4	0xxx	3	(註)6	(註)6	0型
  8	10xx_xxxx	6	63	3F	8型
  12	110x_xxxx_xxxx	9	511	1FF	C型
  16	1110_xxxx....xxxx	12	4095	FFF	E型
  20	1111_1110_xxxx....xxxx	12	4095	FFF	FE型
  24	0111_0100_xxxx....xxxx	16	65535	FFFF	7-4型
  28	0111_0101_xxxx....xxxx	20	1048575	FFFFF	7-5型
  32	0111_0110_xxxx....xxxx	24	(省略)	FFFFFF	7-6型
  64	0111_1000_1101_xxxx....xxxx	52	(省略)	(省略)	7-D型
  128	0111_1001_1101_xxxx....xxxx	116	(省略)	(省略)	7-1D型
  256	0111_1011_1101_xxxx....xxxx	244	(省略)	(省略)	7-3D型
  512	0111_1100_0111_1100_xxxx....xxxx	496	(省略)	(省略)	7-7C型

  • 先頭に7があると拡張モードになり、 データ部のビット数/4 が符号なし整数のhh4で記述される。
  • 拡張モードでのビット数指定部分のhh4がさらに拡張モードであってもよい（どれだけ入れ子になっていてもいい）。
  • 先頭のFはpadding用で意味がない。Fは連続でいくつ並べてもよい。