memo0009
のバックアップ(No.14)
[
トップ
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
バックアップ一覧
差分
を表示
現在との差分
を表示
ソース
を表示
memo0009
へ行く。
1 (2014-06-02 (月) 15:58:46)
2 (2014-06-02 (月) 18:27:07)
3 (2014-06-03 (火) 17:31:17)
4 (2014-06-05 (木) 07:08:39)
5 (2014-06-05 (木) 11:21:19)
6 (2014-06-05 (木) 18:23:40)
7 (2014-06-06 (金) 11:00:45)
8 (2014-06-06 (金) 14:25:21)
9 (2014-06-06 (金) 14:25:21)
10 (2014-06-06 (金) 23:34:14)
11 (2014-06-06 (金) 23:34:14)
12 (2014-06-07 (土) 07:32:53)
13 (2014-06-07 (土) 18:32:35)
14 (2014-06-09 (月) 16:54:15)
15 (2014-06-10 (火) 17:50:32)
16 (2014-06-10 (火) 17:50:32)
17 (2014-06-14 (土) 09:56:00)
18 (2014-06-18 (水) 19:05:00)
19 (2014-06-20 (金) 20:41:41)
20 (2014-06-23 (月) 17:46:50)
21 (2014-06-23 (月) 21:31:56)
22 (2014-06-24 (火) 18:50:46)
23 (2014-06-25 (水) 11:07:22)
24 (2014-06-25 (水) 17:33:22)
25 (2014-06-26 (木) 17:55:29)
26 (2014-06-27 (金) 18:03:52)
27 (2014-06-30 (月) 20:52:38)
28 (2014-07-02 (水) 18:35:39)
29 (2014-07-03 (木) 18:34:33)
30 (2014-07-04 (金) 18:15:28)
31 (2014-07-08 (火) 18:31:22)
32 (2014-07-14 (月) 16:33:47)
33 (2014-07-17 (木) 11:24:23)
34 (2014-07-18 (金) 06:30:39)
35 (2014-07-22 (火) 09:03:43)
36 (2014-07-23 (水) 16:12:57)
37 (2014-07-24 (木) 17:01:29)
38 (2014-07-29 (火) 10:58:51)
39 (2014-07-31 (木) 18:33:36)
40 (2014-08-08 (金) 23:44:13)
41 (2014-08-24 (日) 07:11:25)
42 (2014-08-24 (日) 07:11:25)
43 (2014-08-27 (水) 12:43:38)
44 (2014-08-27 (水) 22:33:56)
45 (2014-08-28 (木) 11:45:10)
46 (2014-08-28 (木) 11:45:10)
47 (2016-07-18 (月) 19:49:22)
48 (2016-07-19 (火) 07:08:59)
49 (2016-07-19 (火) 13:42:40)
50 (2016-07-20 (水) 19:24:22)
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-07 (土) 07:32:52
どういたしまして。 --
K
2014-06-07 (土) 18:32:34
コメント
お名前
NameLink