memo0009 のバックアップ(No.21)

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-07 (土) 07:32:52
どういたしまして。 -- K 2014-06-07 (土) 18:32:34

コメント	お名前	NameLink