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

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ではどこまで小さくなるのか？！

↑

2014.07.17 Thu

for構文におけるcontinueの仕様を変更しました。osecpu122dからは、C言語と同じ挙動になります。
```
for (i = 0; i != 4; i++) {
    if (j == i) continue;
    k += i;
}
```
この書き方をした場合、continueによって i++; が実行され i != 4 が判定されて、ループの続行or終了が決まります。
一方で、この書き方のせいで、従来は有効だった書き方がうまくいかなくなります。
```
do {
    いろいろ
    if (j == i) continue;
}
```
この書き方をしても繰り返してくれないのです。なぜならdoの実体はfor(;0;)なので、判定の時に偽になってしまい、ループ終了になるからです。
ということでcontinue0;という命令も作りました。これは旧バージョンのcontinueと同じ挙動をします。つまりcontinue0;は無条件のループ先頭へのgotoと同じです。

↑

2014.07.18 Fri

OSASKコミュニティの人におしえてもらったこのプレゼンがすごい！感動。
- “スクールガールストライカーズの内製クライアントエンジン”
- http://www.jp.square-enix.com/info/images/image_technical_seminar2014_06/pdf/SQEX_DevCon_sugimoto.pdf

プログラムを小さくすることがこんなに役立つという話。
シンプルなアルゴリズムが最強という話。なんでも複雑にすればいいわけじゃない。

僕の言いたいことを僕よりもはるかにうまく言ってくれている。
- ちなみに杉本浩二さんは僕と同じ1975年生まれだった！

出典： https://twitter.com/Akkiesoft/status/489784761166987264

↑

2014.07.22 Tue

x86のコードのうち、immやdispの部分だけをhh4化して、それに伴ってimm8とimm32の命令コードを統合してしまうと、どのくらいの機能密度になるんだろうか。この方法ならJccは全部0fを使わずに書ける。
なんかこれだけでOSECPU-VMの機能密度に結構近づけるんじゃないかという気がしてきた。せいぜい2倍程度で済むようになるとか。・・・まあでもAPI呼び出しに差がありすぎるかなあ。そこはefg01方式で追いつかせるしかなさそうだなあ。

↑

2014.07.23 Wed

ニュース速報です。bballは63バイトで書けるようになりました。グラデーションも9バイトになっています。
まさかここまでできるとは思っていませんでした。rev2化でいろいろやっているうちに、無駄なところが見つけやすくなって、ついにここまで来てしまいました。

↑

2014.07.24 Thu

app0103(bball)について、ちょっと考えてみる。
- rev1のころは71バイトだった。rev2で63バイトになった。これだけ見ると、11.3%の改善かなと思う。
- しかし実際はそんな生易しいものではない。bballにはシグネチャ2バイトと座標データ32バイトがある。これはプログラムロジックとは関係がない。だから34を差し引いて比較してみると、37→29ということになって、なんと21.6%もの改善ということになる。
- rev1だってとんでもなく機能密度は高かった。その「乾いたぞうきん」を絞っているわけだけど、そう考えると我ながらすごいなー。

↑

2014.07.29 Tue

またページが荒らされている・・・。じゃあとりあえず凍結してみますね。
凍結解除の必要があるページがあったら、impressionsとかで教えてください。

↑

2014.07.31 Thu

今夜osecpu124dをリリース予定です。

↑

2014.08.08 Fri

オセロはrev2では476バイトになりました（rev1では505バイトでした）。
インベーダゲームがかなり小さくなったので期待したのですが、そもそも相当にがんばっていたようで、少ししか減りませんでした。でも、500バイト未満になったのはうれしいです。

↑

2014.08.24 Sun

最近は、OSEPCU-VM向けの言語を作りやすくするために、バイトコード体系を整理したり、そのためのコンバータを作ったりしています。
- 作成中のコンバータは、内部に多数のマイクロフィルターがあって、それを組み合わせることで目的のコンバータを作るようになっています。それぞれのマイクロフィルターは、一度にメモリを確保して一括変換するのではなく、必要に応じてちょろちょろと作っていく方式なので、メモリ消費量が少ないです。
- こうすることで一時的に何十倍にもサイズが増えてしまうような中間フォーマットを採用することも容易になって、中間フォーマットが単純化されて、応用しやすくなっています。
- 最初からこうすればよかったんだと感じています。
会社のイベントの懇親会で、アセンブラとかCとかもできるけれど、それでもLispを絶賛している人と話をすることができて、そういえばyaoさんもLispが好きだったし、少し勉強しようと思って、通勤中に読むために本を数冊注文してみました。
- もしかしたらプログラムを小さくするためのヒントもあるかもしれないと思っています（Lispはソースコードが短くなる傾向があるんじゃないかと勝手に思っている）。

↑

2014.08.27 Wed

やっとコンバータがいい感じでまとまってきた。今夜のリリースを予定。
- しまった、まだ出来上がっていなかった！

↑

2014.08.28 Thu

gh4 vs ih4

	gh4	ih4a	gh4a	ih4b
4bit	3bit	3bit	3bit	3bit
8bit	6bit	6bit	6bit	6bit
12bit	9bit	9bit	9bit	8bit
16bit	12bit	12bit	12bit	12bit
20bit	12bit	12bit	12bit	16bit
24bit	16bit	19bit	16bit	18bit
28bit	20bit	19bit	20bit	22bit
32bit	24bit	26bit	24bit	26bit
36bit	24bit	26bit	28bit	26bit
40bit	28bit	33bit	32bit	30bit
44bit	32bit	33bit	36bit	34bit
48bit	36bit	40bit	40bit	38bit
52bit	40bit	40bit	40bit	42bit
56bit	44bit	40bit	44bit	46bit
60bit	48bit	40bit	48bit	50bit
64bit	52bit	55bit	52bit	54bit

結局、gh4aがいい気がする・・・まあでも現状のままでもいいかな。

ih4a
- 0(3)
- 10(6)
- 110(9)
- 1110(12):ここまで3ずつ
- 1111_0(19)
- 1111_10(26)
- 1111_110(33)
- 1111_1110(40):ここまで7ずつ
- 1111_1111_0(55)
- 1111_1111_10(70)
- 1111_1111_110(85)
- 1111_1111_1110(100):ここまで15ずつ
- 1111_1111_1111_0(131)

gh4a
- 0(3)
- 10(6)
- 110(9)
- 1110(12)
- 0111_0000(16)
- 0111_0001(20)
- 0111_0010(24)
- 0111_0011(28)
- 0111_0100(32)
- 0111_0101(36)
- 0111_0110(40)
- 0111_1000_0111(44)
- 0111_1000_1000(48)
- 0111_1000_1001(52)
- 0111_1000_1010(56)
- 0111_1000_1011(60)
- 0111_1000_1100(64)
補助符号a
- 1:1
- 2:01
- 3:0001
- 4:0010
- 5:0011
- 6:000001
- 7:000010
- 8:000011
- 9:0000000001
- a:0000000010
補助符号aをつかってih4b
04:1(3)
08:01(6)
12:0001(8)
16:0010(12)
20:0011(16)
24:000001(18)
28:000010(22)
32:000011(26)
36:(pad4)000011(26)
40:0000000001(30)
44:0000000010(34)

↑

こめんと欄

ありがとうです。 -- けめっぽ 2014-06-07 (土) 07:32:52
どういたしまして。 -- K 2014-06-07 (土) 18:32:34

コメント	お名前	NameLink