# HG changeset patch # User anatofuz # Date 1612861673 -32400 # Node ID d60edd5f3a049dad4754f038c35adb205128e8ca # Parent 942cf5235a845a10975c66a14b38b3f7b8b25bac add msg diff -r 942cf5235a84 -r d60edd5f3a04 other/naltoma.md --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/other/naltoma.md Tue Feb 09 18:07:53 2021 +0900 @@ -0,0 +1,47 @@ +# GearsOSのメタ計算 + +- 参考文献参照位置がたまにおかしい。 + - p.10, 「〜表現されていた。[15]」みたいなやつ。句点の前に。 + - p.17のようにソースコード参照位置もおかしいことがある。 +- タイトルがとても抽象的。過去の蓄積はどうなっていて、修論としてはどこをやった？メタ計算の鳥瞰図が欲しい。 +- 「メタ計算」を(1)リソース管理という目的そのもの、(2)リソース管理のためのコード、(3)実際の動作、の3種類の意味を文脈で使い分けていたりする？ + +## 1章 OSとアプリケーションの信頼性 +- p.2 + - OSを巨大な状態遷移マシンと考えると、特定の状態の繊維まで範囲を絞ることができるとは？ + - 有限時間で検証できる保証は？ + - プログラムの整合性とは？ + - 「自由にメタレベルの計算で証明したい」という文脈における「自由」とは？ + - 検証用とそうでないノーマルレベルの実装をコード上で切り替えること無く、「各レベルを切り離す」とは？ + - 図2.2のこと？ +- p.3 + - CbCでノーマルレベルとメタレベルの分離により信頼性を得るというのは分かるが、ここでいう拡張性を得るというのは「信頼性が高い拡張しやすい」ぐらいの意味？ +- 解消したい問題点メモ + - メタ計算の自動生成の未実装=>4章？ + - Interfaceの実装（Implementの型定義ファイル）の未実装=>5章？ + - メタ計算に関するAPI考察、トランスコンパイラ=>6章？ + +## 2章 CbC +- ソースコード2.1: goto exit(0)？ +- ソースコード2.5: cbccodesにCodeGearへのアドレス、cbc_retはCodeGear。これはcbccodesに継続し、それが終わったらCodeGearへ継続するという意味？ + - 仮にcbcodesで指すCodeGearに別CodeGearへの継続が書かれていた場合にはどうなる？ + +## 3章 GearsOS +- p.18, Contextに格納されているCodeGearの配列から要素を特定するための添字は、各CodeGearに割り振られた番号を利用するとあるが、この番号は単純に参照する都度インクリメントされる？queueのような動作？もしくは何かのタイミングでガーベジコレクション的な動作はある？ +- 3.8.6, Stack.stack->Stack.stack問題は何が問題？ +- 3.11 pure CbCへの変換について。元の拡張CbCに誤りがある場合、Perlスクリプトによる変換時点で問題になると思うがどのように扱う？ + - どういう問題に対してチェックしていて、ユーザへはどう通知する？ + +## 4章 新GearsOS + +## 5章 Interface改良 +- 5.3, 「Imple内部で持つ値はDataGearではなく、DataGearに含まれる値である」ということは強制できないか？する必要はないのか？（したという話？） +- かなり改良点が多いが、これに伴う後方互換性は？ + - GearsOSはともかく個別プログラムも一通り手動修正が必要？ + +## 6章 トランスパイラによるメタ計算 + +## 7章 +- 1ファイルに1つの型定義という制限はどこの問題？改善の見込みはある？ + +