memo0009 のバックアップソース(No.32)

* Kの開発メモ #0009
-(by [[K]], 2014.06.02)
-ここは川合の開発の進捗などをレポートするところです。

** 2014.06.02 Mon
-とりあえずbballはできるようになったー。
-フロントエンドコードは、新規設計しなければいけない部分もあって気合を入れなければいけないので、結構たいへん。でもやるしかない。
** 2014.06.03 Tue
-新フロントエンドコードなら、charsが7バイトで書けそう（rev1では8バイトだった）。app0100のグラデーションも15バイトで書けそう（rev1では17バイトだった）。
--我ながら、かなり攻めている。
--(2014.06.06追記)でもやっぱりcharsは8バイトに戻りました（7.5バイト）。
** 2014.06.05 Thu
-OSECPU-VMとは？
--それは限界への挑戦。
--それは究極への追求。
--それは自分との戦い。
-OSECPU-VMは、第三世代OSASK構想として、かなり以前から8割くらいが[[K]]の頭の中で完成していた。
--bitに関する設計も2012年より前に済んでいた。構造体に関する設計もほぼできていた。
--2013年のセキュリティキャンプのおかげで、それを形にすることができた（構造体は間に合わなかったけれど）。
--2014年のセキュリティキャンプでは作り直しをすることができた。短期間でできたのは仕様を検討する必要がほどんどなかったため。
--やっぱり設計って大事だなと改めて思った。
-app0100のフロントエンドコード
 05 E2 59 0B B0 61 BB 62 BB 45 23 00 BB
--13バイトでグラデーションが描ける！（参考：rev1では17バイト）
-app0101のフロントエンドコード
 05 E2 54 06 66 00 55 01 E1 2C 0C AA C5 A0
--14バイトで日本の国旗が描ける！（参考：rev1では17バイト）
-明日の夜にはosecpu110dをリリース予定。
** 2014.06.06 Fri
-アプリケーションサイズが重視される時代は来るだろうか。10年後か20年後か。そしてそのときにOSECPU-VMは注目されるだろう。そしてこの分野も徹底的に研究されると思うけど、しかしOSECPU-VMよりもよいものを作るのは相当に難しいに違いない。改善の余地はもはや5%も残っていなかった、とか。そしてそのときに日本がこの分野において圧倒的に進んでいたことが判明する。・・・そしてそれまでにかかわった学生たちも高く評価されるようになる。
-そもそも、アプリケーションをバイトコードにしてJITコンパイラで実行して、そこで互換性とセキュリティを担保しようというOS設計の方向性は、もはやそれほど珍しくはない。そこに「サイズの追及」という、トレードオフではない要素を持ち込んだのがOSECPU-VMである。
-ハードウェア技術は年々進歩している。それを否定する人はいないだろう。しかしソフトウェア技術は進歩しているのか。OSやアプリは年々大きくなっているようだけど、機能はそれ以上に増えているのか。それとも密度はどんどん落ちているのか。仮に密度が落ちているのだとしたら、それは果たして進歩と言えるのか。もしかしたら進歩したのはハードウェアだけで、ソフトウェアはそのハードウェアの進歩で「進歩しているかのように」見えているだけなのではないか？
--仮に10年前のPCに10年前のOSを使った場合と、同じ10年前のPCに現在のOSを使った場合とで、少しでも速くなったと感じられるだろうか？速さがダメならインストールサイズでもいい。HDDの空きは増えるのか？それもダメなのだとしたら、じゃあいったい何がよくなったというのか。
--（まあ少なくともセキュリティホールは減ったとは思うけど。）
-OSASK計画では、そんなまやかしはない。第一世代OSASK → efg01（第二世代OSASK） → OSECPU-VM（第三世代OSASK）と進歩していく中で、同じ内容のアプリケーションはバージョンが上がるごとに小さくなっている。互換性も改善している。ハードウェアの進歩に頼っていない（ハードウェアに小さく書ける支援機能がついたわけじゃない）。
--世代が大きく変わった時に劇的な進歩があるのはもちろんだけど、同世代内でも、細かいバージョンが上がるたびに改良されている。
-OSECPU-VMの本質とは何か？
--考えてみたら、OSECPU-VMのソースコードにはあまり価値がない気がする。むしろ仕様のほうが本質だと思う。
--こういうアーキテクチャを想定して、こういう命令セットでやりましょう。ここでダウンロードできるのは「実装例」です。・・・っていう説明が一番僕の考えに近い。
--だからソースが気に入らなくても、まったくOKなのです！仕様が同じなら何通りの実装があってもかまわないのです。むしろ歓迎です。
--仕様が気に入らなかったら・・・ごめんなさい！代案を提案していただければ検討させていただきます！！
~

-メモ： [[page0065]]の#0013以外は全部盛り込んだと思う。
~

-ここまでの成果：
--osecpu110d→[[page0074]]

** 2014.06.07 Sat
-kemecoさんへ：
--float -> int の型変換はCNVFI（0x43）という命令を使います。

** 2014.06.09 Mon
-フロントエンドコードの設計がかなり大変です。しかもこれを生成するためのappackもおそらく近日中に作らなきゃいけないわけで、それも大変そうです。
-kemecoさんによると、Raspberry PiでOSECPU-VMのrev2が動作したそうです。これはうれしいニュースですね！

** 2014.06.10 Tue
-[[page0065]]の#0013のアイデアを取り込み中。
--なんとかできた。bballは68バイトになった。すごいところまできたもんだ。
-明日は型推論を書こう。

** 2014.06.14 Sat
-フロントエンドコードのデコーダがPLIMM命令やLMEM命令に対応しました。
--osecpu111d→[[page0074]]

** 2014.06.18 Wed
-僕が今後数年をかけてやるべきこと。
--OSECPU-VMの仕様を完成させて、その仕様だけで既存のどのプログラムも記述できることを実証する。できればどれもすさまじくコンパクトになることも実証する。
---つまりむやみに大きくて複雑なVMなんかこの世に無くてもいいのだということ（あってもいいけど）。
--コミュニティの規模を拡大して、開発をスピードアップする。
--もちろん、かかわってくれた人たちに十分な名声が得られるようにする。
-僕が数十年かけてやるべきこと。
--将来に天才的な誰かが現れて、OSECPU-VMよりもさらにシンプルでコンパクトでセキュアなVMを考案し、「OSECPU-VMも、その中心的開発者の[[K]]も、あんなのはぜんぜんダメだ。もう引退させるべきだ」と発言する、そんな未来を実現すること。
-・・・僕のこの夢に共感してくれたら、是非、力を貸してください！

** 2014.06.20 Fri
-手伝ってほしいこと：
--VMをいろんな環境に移植してください！
---ソースを使わずに仕様書から作るというのでもOK。
---セキュリティチェックが省略されていてもいいです。
---現在インタプリタ版を作っていますが、その次はコンパイラ版を作ります（来年？）。それができたらそれもいろんな環境向けに移植してほしいです。
--rev2のバックエンドコードが出力できる高級言語がほしいです。
---それともASKAだけでいいのかなあ・・・。
-rev3について：
--今年はrev2を作ったので、来年はrev3を作ると思われるかもしれませんが、その予定はありません。rev2で当初予定していた仕様を全部入れているので、もう大規模な作り直しは不要なはずなのです（つまりバイトコードの互換性は維持できる）。
--ということで、もう安心してください。
** 2014.06.23 Mon
-セキュリティキャンプの事前学習が始まりました。さっそく指導を始めています。学生たちが退屈しないように、OSECPU-VMの完成度も上げていかなければっ！！
-今夜、osecpu112dをリリース予定です。
--→[[page0074]]
** 2014.06.24 Tue
-今日も着々と開発が進んでいます。たぶん明日の夕方にはosecpu113dをリリースできると思います。
-権限によらないセキュリティを実現するための、もっともシンプルな方法を検討中です。うまくいきそうです。
** 2014.06.25 Wed
-今日気づいたこと： OSECPU-VMのフロントエンドコードでは、1バイトで記述できる命令が結構少ない！
--x86ならPUSH/POP/XCHG/INC/DEC/LEAVE/RET/ストリング命令/CLC/STC/CLD/STD/CLI/STI/HLT...などなどたくさんある。
--じゃあOSECPU-VMではどうだろう： NOP(0)、ラベル命令（1）、短距離のJMP（3-x）、Enter（3c）、Leave（3d）...だぶんこれだけ。
--短い命令が少ない分だけ、長い命令が全体として短くなっているのだと思う。
-osecpu113dはちょっとバグが見つかったので、木曜日に延期します。
** 2014.06.26 Thu
-osecpu113dは今夜リリース予定です。→[[page0074]]
-今後の予定：
--osecpu114d: talloc/tfreeをサポート
--osecpu115d: malloc/mfreeをサポート
--osecpu116d: appackを整備しはじめる
-7月中旬ごろには、rev2でも世界最高の機能密度アプリを簡単に作れるようになる予定です。
** 2014.06.27 Fri
-OSECPU-VMに簡易デバッガを付けました。ステップ実行や、ブレークポイント設定もできます。なかなか快適です。
--行番号（DR0）によるブレークポイントのほかに、Rxxの値によるブレークポイントも設定できます。
--ウォッチしたいレジスタを設定すると、そのレジスタについてはpコマンドを使わなくてもレポートしてくれます。
-デバッガ付けたらVMが20.5KBになった。でも便利なので許す。

** 2014.06.30 Mon
-今夜、osecpu114dをリリース予定です。
--デバッガ追加
--talloc, tfree, malloc, mfreeの実装（テストはまだしてないけど）
--vm-miniの追加
--→[[page0074]]

-vm-miniについて：
--これは標準VMから、セキュリティチェックとフロントエンドコードのデコーダーと簡易デバッガを取り除いた物です。これでもVMとしては十分だと思っています。bit[]のチェックもありません。それでも、バグのないアプリならちゃんと動作します。
--フロントエンドコードが動かせないという問題はありますが、それもデコーダをASKAで書き直すまでの辛抱です。これができれば、decode.cやtek.cはお払い箱になるので、これらをVMに含める必要はないわけです。
--また、今回のバージョンから標準VMに-bオプションがサポートされて、これを使えばフロントエンドコードをバックエンドコードに簡単に変換できます。
--osecpu.exe（標準VM）は21.0KBですが、osecpu-m.exe（VM-mini）は11.5KBです。つまりこの11.5KBさえ移植できれば、OSECPU-VMアプリを好きな環境で実行できるというわけです。・・・悪くない話ですね！！

** 2014.07.02 Wed
-昨日気づいたこと。rev2はrev1に比べると結構遅い。やっぱりJITコンパイル方式は速かったんだなー。
--ということで、rev2も来年とか再来年にはJITコンパイル版を作りたいなー。

** 2014.07.03 Thu
-な、なんとか、charsが動くところまでは来た・・・。

** 2014.07.04 Fri
-とりあえずprintf的なことはできるようになって、インベーダーゲームもスコア表示が出るようになって、これでインベーダーに関してはrev1と機能的には互換になった。サイズはひどいけど。
-次はappackかなあ。

** 2014.07.08 Tue
-VMのバグを少しでも減らすために、警告をちゃんと表示させて、それに対処するようにしました。これでプロトタイプ宣言のし忘れは気づけそう。
-osecpu118dができました（今夜リリース予定）。→[[page0074]]

** 2014.07.14 Mon
-フロントエンドコードの自動生成のために頑張り中。インベーダはrev2ではどこまで小さくなるのか？！

* こめんと欄
-ありがとうです。 -- ''けめっぽ'' SIZE(10){2014-06-07 (土) 07:32:52}
-どういたしまして。 -- [[K]] SIZE(10){2014-06-07 (土) 18:32:34}

#comment