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

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.05 Thu

OSECPU-VMとは？
- それは限界への挑戦。
- それは究極への追求。
- それは自分との戦い。
OSECPU-VMは、第三世代OSASK構想として、かなり以前から8割くらいがKの頭の中で完成していた。
- bitに関する設計も2012年より前に済んでいた。構造体に関する設計もほぼできていた。
- 2013年のセキュリティキャンプのおかげで、それを形にすることができた（構造体は間に合わなかったけれど）。
- 2014年のセキュリティキャンプでは作り直しをすることができた。短期間でできたのは仕様を検討する必要がほどんどなかったため。
- やっぱり設計って大事だなと改めて思った。
app0100のフロントエンドコード
```
05 E2 59 0B B0 61 0B B6 20 BB 45 23 94 0B B0
```
- 15バイトでグラデーションが描ける！
app0101のフロントエンドコード
```
05 E2 54 06 66 00 55 01 E1 2C 0C AA C5 A0
```
- 14バイトで日本の国旗が描ける！
明日の夜には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）と進歩していく中で、同じ内容のアプリケーションはバージョンが上がるごとに小さくなっている。互換性も改善している。ハードウェアの進歩に頼っていない（ハードウェアに小さく書ける支援機能がついたわけじゃない）。
- 世代が大きく変わった時に劇的な進歩があるのはもちろんだけど、同世代内でも、細かいバージョンが上がるたびに改良されている。

↑

こめんと欄

コメント	お名前	NameLink