【C】Poneytail(仮称)OSスレッド01【未踏】
まだほとんど出来てないのに、スーパークリエータで応募出来ないのか。 どういう制度だよ。 人材発掘が目的だとすればスーパーなひとの再採用は不要だと思いますが、 スーパークリエータのがノンスーパーよりも権利を制限されるってのはどう考えても謎ですね。 スーパーになった奴は、希望すれば自動で継続とかにすればいいのに。 未踏の後は次世代があります、って話じゃないの? 確か去年か一昨年、そういう例あったよね。 次世代で目処がつければマッチングファンドとか。 って、釣られておいてなんですが、そろそろCooSの話に戻しませんか? >>467 漏れは飯を食うのが主目的なのでどうでもいいんだけど、 未踏で成果発表できる所はIPAXくらいなので、出れるなら出た方がいいと思う。 >>471 それは法人格が厳しいですな。 未踏のアンケートにそう書いて送ったけど、どうにもならんしなあ。 > それは法人格が厳しいですな。 んなもん印紙税数万円と2週間の時間がありゃできますがな。実質工数は数日だし。半年もすりゃ会社法も改正でさらに作りやすくなるし、むしろ最近の連中は恵まれていると思うぞ。 ま、会社に勤めているとしがらみ障壁がいろいろあって踏ん切りつかないっていうのなら、判らんでもないけどね。 悩んだんだけど、当日はプレゼンもブースも出さないことにしました。 現状で出しても仕方ないし、それならビジネスにできる人に譲った方が良いかなってのが主な理由。 んで、ひさしぶりに次にやることというか。 次はJIT系だと決めてるんだけど、ちょっと前からバグがバグバグ出てきて、このままだと破綻する予感〜と思っていました。 なのでまずはNUnitを導入して、それなりにテスト駆動に移行しながらやっていこうかなと思います。 時間的見通しは難しいけど、未踏で〆切がなくなったので、品質志向(理想志向?)に戻ってもいいかなーと。 今週来週くらいで再開したい。。。 突然ですが、ブートローダをCで書いてみました。 前々からアセンブラは分からん…と思っていたので。 したらサイズが増える増える。2nd loaderが3KB近越え。 やっぱりアセンブラでちまちま書いた方が小さいねえ。 まー見やすいのでこれで行くけど〜。 http://www.coos.jp/src/viewer.aspx?path=coos/bootloader/ ディスク上では bpb.asm + 1stboot.c + 3rdboot.asm + 2ndboot.c という感じで並ぶけど、 実行は bpb -> 1st -> 2nd -> 3rd です。 >>478 Monaみたいに2ndをC#で書かないの? >>478 どういうコードが生成されるか意識して書けば、それなりに小さくできるよ。 いわゆる高級アセンブラな使いかた。 >>479 x86なコードに落とす手間を考えると、それほどメリットないべ。 ネタとしては面白いけど。 授与式でした。レセプションには偉い人来すぎ。 「未踏打ち上げー」みたいなノリを想像してたのでびびりましたよ。 >>479 ぶっちゃけCのが自然だと思います。CooS的ネタにはなるかもしれないけどw >>480 そーなのかなぁ。 確かにCになると富豪的スタイルになっている感は否めない。 それにくわえて、手を抜いた部分をコンパイラが仕上げている感じもある。 ま、CローダはOS勉強する人に役に立つかなあと言うのも目的です。 アセンブラが王道なんだろうけど、やっぱアルゴリズムは理解しにくいので。 JITの応用でPreJIT(AOT)もできることを示す意味があるかと コード書きに夢中になってレセプション行きそびれたorz。 タダ飯食いながら957に粘着しようとおもっていたのだが。 C#やJavaでAOTという選択肢はスジが悪い(速度もメモリ効率も あんまし上がらない)というのは、巷で割と良く言われていること なのでわん。 そうじゃねーぞと言える何かがないと、頑張るだけの意味ないよね。 まあネタだっていうなら、それはそれでありか。 ぶっちゃけOSをネタから引き上げるのが一番難しいから、 意味のあるなしで言えばOS作りほど筋が悪いことはないかと。 誤解を招きそうなので補足。 Coosに水を差すつもりは毛頭ありません。 現実的な意味を取り沙汰するのに違和感を感じただけっす。 技術的探究心は大いに結構、それこそ未踏の精神では。 >>481 未踏は少数派ですからな。漏れの時は2000-2003合同でそれなり関係者がいたが。 昨日はIPAのえらい人に捕まってあんまし食えんかった。しくしく… >>484-485 漏れはブートローダーなんて枝葉な部分に労力を割くのは もったいないと考えとるので、ネタ扱いした訳ですよ。 実験としてはまあおもろいけど、実用性が?だし。 という意味ではCで書くつーのは正しい道だと思いますよ。 ただサイズの問題があるので、そのへん考慮しないとねえということで。 しかし、ブートローダーを枝葉とか言ってるとそっち方面の人に怒られそうな 気がするな。 >>486 ブートローダーに拘ってるわけじゃないですよ。 ブートローダーを何で書こうがOS自体の機能が増えるわけでなし。 >>480 >x86なコードに落とす手間を考えると、それほどメリットないべ。 AOTの確立自体がメリットだと考えています。 原理的にはCooSに限らずx86汎用で使えるわけですし。 (ブートローダーをAOTで書いたら汎用という意味ではないので念のため) AOTよりHotSpotみたいにJITを極めた方が有利というのは、 技術的な難しさと天秤に掛けると絵に描いた餅かと。 >>484 > 意味のあるなしで言えば 現時点でのCooSをOSと呼ぶには、ちょっとした躊躇いが漏れはあるんだけど、どうよ。 現時点のCooSってOSっていうよりもプリミティブな言語マシンに見えるのな。 だからまあOS云々と反論されても?な気分。 せめてポリシーを持った実行コンテキストの管理はしてくれるくらいにならないとと 思う訳で、それを除けて枝葉に走るのはどんなもんかなー、とかとか。 以下 >>486 と同様。 > OS作りほど筋が悪いことはないかと。 はっはっは。そりゃまーそりゃそうだわな。 一応OSとか言われているものに関わっている自分が笑っちゃイカンか。 >>487 > AOTよりHotSpotみたいにJITを極めた方が有利というのは、 > 技術的な難しさと天秤に掛けると絵に描いた餅かと。 んー? Javaでは HotSpot世代までいかなくてもAOTとJITの差は瞭然だった記憶があるんだけど。 静的に決定しないものが結構あるからね、Javaの場合は。C#の場合は何か違うのかな。 >>488 >現時点のCooSってOSっていうよりもプリミティブな言語マシンに見えるのな。 >だからまあOS云々と反論されても?な気分。 自分としてはMSIL処理系として見ていたので、 汎用的に利用価値があるとなると真っ先にAOTが思い浮かんだのです。 >せめてポリシーを持った実行コンテキストの管理はしてくれるくらいにならないとと >思う訳で、それを除けて枝葉に走るのはどんなもんかなー、とかとか。 言語マシンとしてみればAOTは枝葉ですかね。 MSIL処理系としてみればAOTは本命だと思ったのですが。 >んー? Javaでは HotSpot世代までいかなくてもAOTとJITの差は瞭然だった記憶があるんだけど。 >静的に決定しないものが結構あるからね、Javaの場合は。C#の場合は何か違うのかな。 Java特有の動的さというのはC/C++に対しての型付けのことでしょうか? クラスローダの実装が最適化されていないと起動が遅くなったりはするでしょうけど、 実行時の決定的な性能差として影響するというのは聞いたことがなかったです。 HotSpotが実行時に取得する情報というのはプロファイリングなので 型付けの動的さとは全然関係ないしJava特有でも何でもないですね。 何か資料がないと話が発散するだけなので適当に探してみました。 ttp://www.shudo.net/article/Fedora-Core-Expert-200507-GCJ/#performance 商用のAOTコンパイラは蚊帳の外であまり参考にならないかも。 >>489 MINIX3キタね 次はいよいよ大本命HURD1か? >>489 首藤さんの資料ね。 ちょっと古いけど、こっちのほうがCooSスレでは参考になるかも。 http://www.shudo.net/publications/NASDA-200212/ の http://www.shudo.net/publications/NASDA-200212/slide15.png http://www.shudo.net/publications/NASDA-200212/slide16.png 辺り。処理系の詳細は説明はないもののC#のデータが入ってるから。 このプレゼンのときに首藤さんも前置きしてましたけれど、 これLinPackだから、AOTが異様に善戦してますね。 聴講者の大多数がシミュレーション屋さんだったので、 これはこれで数値の取り方として悪くはないけど。 > クラスローダの実装が最適化されていないと起動が遅く 言語やVMの問題っていうよりは、プログラミングスタイルというか。 レイヤの分割で Class.forName() を良く使うので、どんなにコアを AOTで最適化かけても、どうしてもどこかの層がインタプリタ動作に なって律速orzという。クラスローダがオンデマンドコンパイルとか 考えれば考えるほど、JITのほうがいいじゃんという結論に向かって いっちゃうという。泥臭い実運用上の話ですよ。 どこで聞いたのだっけかな? JTRON界隈か、JavaOS界隈か。 Googleに聞いてみたけど、5年以上前の話はさすがにもう残ってないみたい。 MSILではAOTが本命なのかぁ。 >>492 えーとごめんなさい。性能論争は望んでいません。 興味があったのは、CooSのために開発された技術を応用して、 実際に使えるのは何かということだけですので。 MSIL関連のサードパーティー技術で、 自分から見て欲しいと思えるのはAOTだっていう話なので、 AOTが欲しい局面では性能が半分でもAOTが欲しいわけなんですよ。 たとえ実装が不完全で運用に制限があっても ソースを直してでもAOTにしたい案件は多いので。 .NET Frameworkのインスコを客に拒否されたりしたら 今は泣く泣くMFCに戻るしかないって結構ありましたので。 >>494 知らん。隣のオバサン的無責任さで想像すると、こんなことは言えるのかも しれない。 まだJITがこなれていないってことなのかもしれない。 確かJavaからの移植だったはずなので、多次元配列ではなくてジャグ配列を使っているはず。このことでC#の実力を反映できていないのかもしれない。 CLR(CLIもか?)では配列型はCLRが動的に生成するという仕様だったはず。 その辺りに起因して配列操作の性能でCLRはJavaVMよりオーバヘッドが あるのかもしれない。 今評価すると、また違った数値になるだろうね。もう3年も前の資料だから。 ぐは、驚愕の事実を確認。 どうやらVS.NETに「Windows以外禁止条項」はない。 つまりVCのライブラリが含まれていても問題ないってこと。 #EULAのあの一文はなんなんだろう。。。 サポートに聞いたので間違いありません。 二カ所に聞いたけど、最初の人は「お客様のご自由にどうぞ」と言ってた。 次のサポートの人は、「禁止されてはいないが、 そもそもサポート外なので許諾されているとは言えない」らしい。 ということは、あとは実行ファイルに取り込まれているライブラリのコード断片がどう影響するかだけど、 「Windows用アプリを特別視して許諾する」という条項がないからWinアプリと同じだと見なせて、 MSがWinアプリにライブラリ断片を理由に成果物に制限を掛けることはできないだろう。 ということで、 作った基礎ルーチンが無駄に。。。orzorzorz もっと早く聞いておけば良かった…。 これでVC++でも作りやすくなるね。 ttp://channel9.msdn.com/Showpost.aspx?postid=141858 >>501 うぉ。貼り付けさんくすです。 ちと研究活動で忙しいので、見たら感想でも書きますね。 お久しぶりです。 あけましておめでとうございます。 最近はJITコンパイル周りをいろいろやってたんですが、面白くないのに道のりだけは長くて。。。 あとは論文書きと修論書きと、開発そのものはあんまり・・・です。 あとあと、ついでにVS.NET2005への移行を進めていたり。これも大変そうです。 まあ何かあればこちらに書き込もうとは思ってます。 このスレが無事(?)なのも皆様のおかげですし、本年もなにとぞよろしくお願いいたします。 2006年元旦 Kさんがなにやらよさげなものを書かれたときにアレですが、 修士論文がようやくできたので公開することにしました。 http://www.coos.jp/articles/thesis.pdf まぁ絶対評価ではぜんぜん納得できていませんが、 状況とかを振り返れば結構書けた方かなと思います。 #そもそもOSが完成してないのに論文を完成と思うわけがない。 ちと恥ずかしいですが、興味のある方は読んでみてください。 あと、2/16に大阪の学会で発表をします。(トップからリンク有り。) アカデミック縛りがあるのでOS開発という視点では?かもしれませんが こちらもついでに報告しておきます。ただ、学会員じゃないとお金掛かるので C/Pについては言及を避けたいと思います(^^; >>507 修論乙。 一応、うちの研究室もOS風味なので、 行く人がいればどんな話だったか聞いておきたい。 >>509 (論文・修論で開発進まず、)あんまり変わってない上に どうも学術主眼に話をするのは苦手なので、 あんまりクオリティ高くないかも…。 期待しないで来ていただければ嬉しいです。 >>510 各章の扉ページに無意味な絵がある論文は珍しいと思います(笑) 発表終わった 「機械語どうすんだ」って突っ込まれた〜 パワポは戻ったら公開します >>516 ,517 お恥ずかしい限りですが全然進んでません。 就職準備に加えワークショップへの参加で時間全部つぶれてます。 #まだ公開されてないみたいなので名言はしませんが。 もうここ数ヶ月同じネタで発表し続けているので、いい加減開発に戻りたいです…。 近況報告。 3/22-25で北京で開かれるMicrosoft Research AsiaのTheme Workshop 2006というのに出てきます。 30分の持ち時間で研究報告。内容的には前回の研究会からあまり変わってません。 MSRA-TW06: http://research.microsoft.com/asia/ur/workshop06/ でも明後日くらいに出発なのにまだspeakersもpresentationsも"Will provide later!"って…。 予定では24日の午後のはずなんですが。行って何もなかったらどうしよう。 英語とかも超下手なのでもういっぱいいっぱいです。 つか街中で英語すら通じなかったらどうしよう。。。 安心していいよ.北京は空港も町中もろくに英語通じないから. >>520 マジスカorz >>521 MSに発表というよりはMS主催の研究会で発表が正しいです。 ただ、同じ参加者としてMS関係者もたくさんいるので、 そういう意味では「MSに発表」というのもそれほど間違いではないかも。 ついさっき終了。もう骨って感じでした 原稿つきって緊張するもんなんですね。汗だくです。 とりあえずステージでかっっっ! http://www.coos.jp/stage.jpg これは初日のなんですが、今日もステージは一緒。 ただ、観客が少ないのを予想してか席が全部机付きになって、 人も減ってました。(写真のProbert博士はある意味メインゲスト。) とりあえず眠たいけど寝ても仕方ないのでまた戻ろう。 ではまたノシ とりあえずWindows Formsが使えればシェルつくったる 今どの辺ですか?そろそろ使えますか? GUIありの推奨動作環境はどれくらいですか? そろそろ会社生活に慣れてきたので開発再開してるとこです。 C#2.0などで規格が新しくなっているのでそれへの対応をしてます。 #それに対応しないとVS2005とか使えないし。。。 昨年度の後半にしたかったけど、学会やらで後回しにしちゃった分ですね。 Javaを意識した構造に作り替えたところです Javaも考慮することで分離が良くなるかなあ、と。 だいたい出来たのでいまC#で(また)インタープリタ作ってるところ ジェネリクスとかどうなるんだろうなあ、と思っています ただ、FF3がちょっとやばいw メインマシンにドットネット入れたくないからサブマシンにドットネットアプリ専用OSとして入れたいな まあそういう表現も間違ってはいないのですが、 別にvirtualにするわけではないです。 Windows上の.NET VM上の.NETアプリ が COOS上の.NETアプリ と直で動くってこと? 早く使わせろー 途中で投げ出さないでこのペースで行ってくれれば すごくいい感じに >>542 あーWikiは死んでると思います どうもホスティングいまいちだったので解約しました WWWは生きてるはず〜 >>546 たまに進めてるんですが、やっぱり毎日数時間みたいなのは無理ですね。。。 .NETアプリ、入力フォーム部分はWindowsの部品を使っているんだと思ってたけど Windowsなしでも動くんだ。 お久しぶりです。 最近はホント時間取れてないです。申し訳ない。 やっぱり仕事終わったあとは複雑なことは無理ですね。。。 ただずっとこのままなのは寂しいので、社会人二年目からはよく考えたいです。 とりあえず現状報告でした。 勤め人が片手間で開発するのは厳しいですよ、 技術を理解してくれる所に移って、昼間動けるようになるのが理想ですが、 日本だとそういう物好きな会社は少ないので、難しい所ですな。 >>557 真実かは分からないですが、一年目ってスケジューリングしにくくて余計に時間がないっす。 でも非常に近い分野に従事してるし、いまのとこで知見を広げるのも悪くないと思ってます。 >>558 一応CooSで得た経験が役に立ちまくっているので、超間接的に社会に貢献…じゃダメかな〜w 来てないと思いますが。 30日本以来あんましみかけないねえ。 >>559 Linuxカーネル関係ですかね。 この手の経験ってかなり限られた分野でしか役に立たないので、 良い所に就職したなぁと思いますよ。 >>563 英語苦手w >>564-565 ご期待に添えていなくて申し訳ない・・・ 最近はSmalltalkとかSqueakの方針にしたほうが良いのかなあとも思ったり。 なんつーか.NET Frameworkの発展が速すぎて、着いていく限界を感じますね。。。 >>566 MSへ転職して、Singularity ver2 を開発すれば全ては解決 >>568 やー、Singuarityは "Singularity Version 1.0 is complete. We're moving our research forward to the development of Singularity V2.0." らしいですからねえ。こんな研究を着々とやれちゃうのがすごい。 read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる