【C】Poneytail(仮称)OSスレッド01【未踏】
もう日曜か…orz
>>443,444
結局のところ、個々の技術的には、大した新規性は無いのは間違いないです。
仮想マシン、メモリモデル、中間言語、リフレクション、コード検証…。
OSアーキテクチャはどうしてもCPUに縛られますから、本質的な多様さはありませんし。
それをふまえて、CooSの特徴(というよりはCLIのすごさ)ってのは、それらを動作可能な形で実際にまとめ上げた、の一点に尽きると思います。
で、たぶんこれが本当のCooSの特徴なんですが、これって説明しにくいんですよね。
「どんなOS?」っていう問いに答えるには、思想的なものではなく、技術的なものがあった方が答えやすい。
だから書いてあるのがメモリモデルやらなんやら、というわけです。
>CLIの場合は、一応言語独立なのだけれど、分類上は汎用OSというよりは、Smalltalk環境やLISPマシンの方向に近いのではないかと。
SmalltalkやLISPマシンについてはあまりよく知らないのですが、近いといえば近いし、遠いと言えば遠い、、、かな。
SmalltalkマシンとかはSmalltalkありきですよね。CLIは普及した言語ありきだった。
Smalltalkは未来予想図としては良かったんだけど、"次の一歩"としてはCLIの方がいい。
だから、究極の環境としてはMMUは無くなって当たり前に見えるけれど、現実にはMMUが存在していて、
じゃあ現実にこれからMMUを無くすためにどうすればいいかってことになると、CLIとCooSってことにならないかな・・・。
#思いつくまま書いてるので分かりにくいかもしれない
>新規性も将来性もないような書き方されているけど、モチベーションは維持できてますか?
最近忙しくて触ってないけど、たぶんそのうち「開発させろー」とか言い始めるので大丈夫ですよ〜。 > 動作可能な形で実際にまとめ上げた
同意。だからこそ今の技術解説だと曲解されないかなという気が。
ちなみに、技術よりも思想の差異を示したほうが記事にしてもらいやすい。マスコミ対策の瑣末なテクニック。
あんまり思想に傾きすぎるのも、TRON界隈みたいな状態を呼びそうだけど…バランスバランス。
> CLIは普及した言語ありき
必ずしも同意できない。VB.NETなんて、もとのVBに対してかなり大きな変更を強いたし。
(CLIが強いた制約とは別に「このどさくさに紛れて」と言語設計者が考えたものも、あるいはあるかもしれないけれど)
まあそれぞれの言語に対して工数最小の移行パスを用意できた。そのバランス感覚は大したものだ、とは思う。 > CLIは普及した言語ありき
これはどちらかと言うと、Windowsアプリがかけるっていうのが大きいんじゃないの?
VS見たいなIDEで、アプリを書く環境がある。 単一アドレスのOSは研究レベルなら結構ある。
ttp://www.cs.washington.edu/homes/levy/opal/
ttp://www.cse.unsw.edu.au/~disy/Mungi/
など。
coosの特徴は「CLIのネイティブ実装」に尽きるような気がする。
なので将来のことはわからないけれど、今はCLIをもっと
前面に押し出すべきだと思う。 > 単一アドレスのOSは研究レベルなら結構ある。
ざっと読んだけど、やっぱしIPC絡みなのね。誰でも一度は考えそうだよな。
相変わらず調べてないけど、Embeddedの切り口でもきっと研究例はあると思うんだよね。
メモリの仮想化しちゃうとヤワなデバッガでは対応できなくなるケースがあるから。
> 今はCLIをもっと
言語Cの環境区分に倣って、フリースタンディングCLI環境と呼んでみたりとか?
まあ確かにそういう訴求の仕方が正しいと思う。 >452
>coosの特徴は「CLIのネイティブ実装」に尽きるような気がする
???? 意味分からん。CLI 実装はネイティブなんて必要条件でしょ
下記のページを参考に独自性を見つけるってはどう?
Microsoft シェアード ソース CLI 実装
http://www.microsoft.com/japan/msdn/net/sscli/mssharsourcecli.asp >>454
それ見ちゃうとNDAにひっかかるだろ。 >454
ネイティブってのは下位のレイヤーを必要としないという意味にとってください。
> Windowsアプリがかけるっていうのが
書けない。CLR相当まで拡張すれば話は別だけど。
IDEの大部分を流用できるというのは確かにメリットだね。
"大部分"と書いたのは、ウイザードがCLRにべったりのコードを吐く可能性があるから。
そういえば去年も9月の中旬に未踏申請したあと非常に忙しかった気がする。。。
>>452
そうですね。実際には、CLIっていう現実解を選んだことが大きいと思います。
ただ、CLIを前面に押し出したとしても、普通の人はそれで何が起こるか分からないのではないかなあ。
んで、まずアーキテクチャ的な説明か、セキュリティみたいなエンドユーザ側からの説明が必要になって、
そのあとにようやくCLIを選んだことの意味っていうふうになるんじゃないかなぁ。
ま、とりあえず、サイトのドキュメントが未整備なのは良くありませんね。。。
>>457
CLI規格はCLRも含むので、一応ドットネット向けなら動かせるはずです。
絶対動かせないのはP/Invokeとかで明らかに依存してるやつ。
あとCLRがライブラリという意味なら、たしかにSystem.Windowsの移植はしてないので足りないですね。 > 絶対動かせないのはP/Invokeとかで明らかに依存してるやつ。
VBから流れてきた人々は、Declare使うよね、ふつう。
.NET向けなら動くっていうのはわかるんだけど、Windowsアプリが
書けるっていうのは、ちょっと言いすぎじゃないかな。 うーん、そもそも"Windows"アプリでは言葉の定義としてOS依存なわけですから、
エミュレーションをしないCooSでは動かないですね。 なんか、理解はできないけどすごく読み応えのあるスレですね。
そんな中、こんなことを聞くのは気が引けるのですが、
このCooSは.NET FrameworkのVM(のような感じ?)として使えますか?現段階ではなくても
たとえばQemu上のCooSの中に.NET Frameworkでできたアプリケーションを動かしたいと思っています。
.NET Framework製アプリ専用のお砂場みたいな・・・
たぶん今日あたりプレスリリースかな。
おかげさまで「スーパークリエータ」らしいです。
感想とかはリリースを待ってからで。
とりあえずもう晒されるのは勘弁してほしいなぁ。
>>461
さすがにムリぽw
>>462
それは可能だと思います。もちろんOS+.NETなのですぐに実現できるわけではないですが…。 >>463
おめ。名前だけで特にメリットが無いのがあれだが。
暇なので展示を見に行くかのう。
>>463
レスどうもです。
やはり.NETのアプリケーションを動かせる段階というのは
その他OSの基本的な機能が実装されてからになるのでしょうか?
.NET Frameworkのアプリを動かすだけなら
現時点ではqemuに別のWindowsOSを入れてそこに.NET Frameworkランタイムを入れて
.NET Framework製アプリケーションを動かしたほうが現実的でしょうか? > とりあえずもう晒されるのは勘弁してほしいなぁ。
引きこもるか、晒されるか、どちらかしか道は無い。
未踏採択者は定期的に近況報告を求められるので、
引きこもるほうが難しい。
資料作ってない〜。ひー。
>>464
ありがd。
スーパーも恥ずかしいし、クリ"エータ"も恥ずかしいです…。
展示は特にしない予定なんだけど、ダメ?
ここ一ヶ月は何も進んでないしなあ。忙しすぎ。
>>465
CooSでは.NETが基本レイヤなので、むしろ「基本的な機能」が.NET関係だと言えます。
実用的な解であれば、おっしゃるとおりWindowsか、強いていえばLinux+Monoだと思います。
>>466
また色々言われたらめんどーって思ってます。。。
つーかスーパー(ry)になっちゃったからもう未踏応募できない〜。かなしー。 まだほとんど出来てないのに、スーパークリエータで応募出来ないのか。
どういう制度だよ。 人材発掘が目的だとすればスーパーなひとの再採用は不要だと思いますが、
スーパークリエータのがノンスーパーよりも権利を制限されるってのはどう考えても謎ですね。 スーパーになった奴は、希望すれば自動で継続とかにすればいいのに。 未踏の後は次世代があります、って話じゃないの?
確か去年か一昨年、そういう例あったよね。
次世代で目処がつければマッチングファンドとか。
って、釣られておいてなんですが、そろそろ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
たまに進めてるんですが、やっぱり毎日数時間みたいなのは無理ですね。。。