【次世代言語】D言語でOSを作ろう【Monaの移植?】
95 ：デフォルトの名無しさん：2006/10/13(金) 01:36:30
IronD on .NET
96 ：デフォルトの名無しさん：2006/10/14(土) 21:28:29
いきなりスケールのでかいスレタイでつね
97 ：FD：2006/10/21(土) 16:18:40
Ｄ言語でＯＳ作成ですか？面白い課題だと思います。
クラスを使用しなければ、Ｃ言語を少し柔軟にした言語使用なので、極端難しくないです。
参考するなら、Ｃ言語で書かれたＯＳソースを、Ｄ言語のプリプロセッサ機能を削除したソースへ置き換えることからはじめるのですかね？
組み込みＯＳでは基本的にＣ＋＋特有な機能を使用しないのが一般的です。
コメントだけＣ＋＋で中身Ｃ言語と言うものをよく見かけましたが・・・
クラスを使用しなければ、Ｃ言語を少し柔軟にした言語使用なので、極端難しくないです。
参考するなら、Ｃ言語で書かれたＯＳソースを、Ｄ言語のプリプロセッサ機能を削除したソースへ置き換えることからはじめるのですかね？
組み込みＯＳでは基本的にＣ＋＋特有な機能を使用しないのが一般的です。
コメントだけＣ＋＋で中身Ｃ言語と言うものをよく見かけましたが・・・
98 ：デフォルトの名無しさん：2006/10/21(土) 17:20:41
あれじゃね？
C言語で書かれたソースをD言語に変換するツール作成すれば一発じゃね？
C言語で書かれたソースをD言語に変換するツール作成すれば一発じゃね？
99 ：デフォルトの名無しさん：2006/10/21(土) 20:00:57
100 ：FD：2006/10/21(土) 20:45:20
>>99さん
それもありますが、ｎｅｗなどメモリのどこに配置されるか分からないので、メモリの制限された世界では使いにくいのです。
ＯＳカーネルになれば、メモリ管理はレガシーな方法とった方が安全だからです。
ただし、しっかりとメモリ管理された環境下であればＣ＋＋特有の機能は作る側に利点があると思います。
「しっかりとメモリ管理された環境」ですからカーネルの基本的な領域には適用しにくいです。
例えばＣ＋＋で記述されたというL4Ka-Pistachioのソースを参照すると、
ＡＰＩの領域（外向きの顔）はＣ＋＋ポイですが、内部制御はＣ＋＋と言うよりＣ言語です。
Ｃ＋＋の仕様自体にＣ言語仕様を含んでいるから当然なんでしょうけど・・・
>>98さん
のいわれている通り非常に近い仕様ですから、可能だと思います。
カーネルでも基本的なところを製作後は、言語仕様に関係なく開発できるのがベストだと思います。
Ｄ言語が優れているところはＣ言語より柔軟であると言うところ、プリプロセッサ機能を搭載していたら、そのままＤ言語に移行できてしまいます。
なお、Ｄ言語でもいいですけど、日本でカーネルを再勉強できる機会は少ないです。
ＯＳを作ると言う企画は面白いと思います。
まずは、簡単な部分から作らないといけませんね。
私も個人的に勉強したい領域です。
それもありますが、ｎｅｗなどメモリのどこに配置されるか分からないので、メモリの制限された世界では使いにくいのです。
ＯＳカーネルになれば、メモリ管理はレガシーな方法とった方が安全だからです。
ただし、しっかりとメモリ管理された環境下であればＣ＋＋特有の機能は作る側に利点があると思います。
「しっかりとメモリ管理された環境」ですからカーネルの基本的な領域には適用しにくいです。
例えばＣ＋＋で記述されたというL4Ka-Pistachioのソースを参照すると、
ＡＰＩの領域（外向きの顔）はＣ＋＋ポイですが、内部制御はＣ＋＋と言うよりＣ言語です。
Ｃ＋＋の仕様自体にＣ言語仕様を含んでいるから当然なんでしょうけど・・・
>>98さん
のいわれている通り非常に近い仕様ですから、可能だと思います。
カーネルでも基本的なところを製作後は、言語仕様に関係なく開発できるのがベストだと思います。
Ｄ言語が優れているところはＣ言語より柔軟であると言うところ、プリプロセッサ機能を搭載していたら、そのままＤ言語に移行できてしまいます。
なお、Ｄ言語でもいいですけど、日本でカーネルを再勉強できる機会は少ないです。
ＯＳを作ると言う企画は面白いと思います。
まずは、簡単な部分から作らないといけませんね。
私も個人的に勉強したい領域です。
101 ：デフォルトの名無しさん：2006/10/24(火) 01:34:37
>>100
>メモリ管理
Cよりは柔軟な罠。newはオーバーロード出来るもの。
コンパイラと人間で責任もって書けばいいだけなんだけどな。
ところで、このスレの元ネタでもあるMonaは知ってる？
元々はム板にあったんだけど、嵐に粘着されてOS板やsiberiaへ亡命しちゃった。
http://wiki.monaos.org/pukiwiki.php?FrontPage
http://pc8.2ch.net/test/read.cgi/os/1138681234/
http://etc3.2ch.net/test/read.cgi/siberia/1136088527/
>メモリ管理
Cよりは柔軟な罠。newはオーバーロード出来るもの。
コンパイラと人間で責任もって書けばいいだけなんだけどな。
ところで、このスレの元ネタでもあるMonaは知ってる？
元々はム板にあったんだけど、嵐に粘着されてOS板やsiberiaへ亡命しちゃった。
http://wiki.monaos.org/pukiwiki.php?FrontPage
http://pc8.2ch.net/test/read.cgi/os/1138681234/
http://etc3.2ch.net/test/read.cgi/siberia/1136088527/
102 ：デフォルトの名無しさん：2007/01/09(火) 06:23:10
がんばれ
103 ：デフォルトの名無しさん：2007/01/11(木) 12:13:59
104 ：デフォルトの名無しさん：2007/01/12(金) 00:46:07
組み込みの場合、何よりも「落ちないことが保障できる」ことが重要だからな。
105 ：デフォルトの名無しさん：2007/04/30(月) 11:25:28
さらに言うと
「落ちても速やかに復帰して動き続ける」
だよな
「落ちても速やかに復帰して動き続ける」
だよな
106 ：デフォルトの名無しさん：2007/06/29(金) 16:04:05
つーか組み込みは、やる事決まってるからだろ
107 ：デフォルトの名無しさん：2007/07/11(水) 23:37:40
MoNaじゃなくてBSDをDで再実装なら協力する。
108 ：デフォルトの名無しさん：2007/07/11(水) 23:47:03
>>101
ガベコレの問題が有って、今のガベコレ言語は、
帆にゃらら言語のアプリ→OSへのメモリ要求
帆にゃらら言語のアプリ→OSからもらったメモリをゴミ扱いにする
帆にゃらら言語のアプリのガベコレ→さっきゴミにしたメモリを再利用可能ににする
ってな流れだけど、DでOSを書くと言うことはこのOSに頼んでる部分を書く必要が有って、
でも、DでOS書く訳で。と言うループに陥らないために
OSのメモリ管理＝D言語のメモリ管理という部分を設計してしまう必要が有るわけ。
手を抜こうと思えば、抜けるけども。
ガベコレの問題が有って、今のガベコレ言語は、
帆にゃらら言語のアプリ→OSへのメモリ要求
帆にゃらら言語のアプリ→OSからもらったメモリをゴミ扱いにする
帆にゃらら言語のアプリのガベコレ→さっきゴミにしたメモリを再利用可能ににする
ってな流れだけど、DでOSを書くと言うことはこのOSに頼んでる部分を書く必要が有って、
でも、DでOS書く訳で。と言うループに陥らないために
OSのメモリ管理＝D言語のメモリ管理という部分を設計してしまう必要が有るわけ。
手を抜こうと思えば、抜けるけども。
109 ：デフォルトの名無しさん：2007/08/26(日) 07:07:10
/
110 ：デフォルトの名無しさん：2007/08/26(日) 08:06:04
これって実は言語とかは全然関係なくて、
GC用ヒープがシステムメモリとして何百メガか確保されるだけでは？
ただ、これだとアルゴリズムがコンカレントGCしか選択できないな。
GC用ヒープがシステムメモリとして何百メガか確保されるだけでは？
ただ、これだとアルゴリズムがコンカレントGCしか選択できないな。
111 ：デフォルトの名無しさん：2007/09/06(木) 22:17:18
age
112 ：デフォルトの名無しさん：2007/09/11(火) 22:09:02
今のGCって論理アドレス空間で整頓してるんだよね？
カーネルだと物理アドレス空間を触ることになると思うんだけど、
そっちだとより効率的にメモリを整頓できたりするの？
カーネルだと物理アドレス空間を触ることになると思うんだけど、
そっちだとより効率的にメモリを整頓できたりするの？
113 ：デフォルトの名無しさん：2007/09/16(日) 15:24:08
むしろ、このマルチコア時代には、１CPUを丸々メモリ管理に割り当ててもいいんじゃないかと思ってる。
114 ：デフォルトの名無しさん：2007/09/18(火) 00:36:29
>>113
それだとキャッシュ効率が悪過ぎる
それだとキャッシュ効率が悪過ぎる
115 ：デフォルトの名無しさん：2007/09/23(日) 12:49:14
116 ：デフォルトの名無しさん：2007/09/23(日) 12:50:31
sageてしまったorz
117 ：デフォルトの名無しさん：2007/12/05(水) 21:40:57
保守
118 ：デフォルトの名無しさん：2007/12/05(水) 22:05:50
そういや任天堂がC++のOS作ってたね。ライセンスは知らんが成果も発表してた気が。
任天堂なら作れるかも
任天堂なら作れるかも
119 ：デフォルトの名無しさん：2007/12/13(木) 09:36:12
C++のOSって既にあった気がするんだが
120 ：デフォルトの名無しさん：2007/12/13(木) 09:56:32
まさか Mona とか
121 ：デフォルトの名無しさん：2007/12/13(木) 09:59:43
実装は知らんがインターフェースがC++だったのはBeOS
122 ：デフォルトの名無しさん：2007/12/13(木) 15:55:27
Nintendo esだろ
>121
ああそれそれ。あくまでインターフェイスの話なのか、あれ。
ところで D で TRON ってどうよ、とかいう無茶振りをしてみるテスツ
ああそれそれ。あくまでインターフェイスの話なのか、あれ。
ところで D で TRON ってどうよ、とかいう無茶振りをしてみるテスツ
124 ：デフォルトの名無しさん：2008/01/07(月) 20:34:20
今更使い道はないんじゃない？
TRONの需用自体がITRONくらいで、そこにGCはヘビーかと。
TRONの需用自体がITRONくらいで、そこにGCはヘビーかと。
125 ：デフォルトの名無しさん：2008/01/07(月) 21:39:57
携帯でも Java なんだから gc がヘビーってこともない機器もあるかも
126 ：デフォルトの名無しさん：2008/01/07(月) 22:19:55
そこであえて超漢字を
127 ：デフォルトの名無しさん：2008/01/09(水) 03:30:00
携帯の Java は PC みたいに軽くないので、昔のBasicみたいにクラス作らないでかく
128 ：デフォルトの名無しさん：2008/01/09(水) 21:18:23
Basicを引きあいに出さなくてもＣでいいんじゃね？
129 ：デフォルトの名無しさん：2008/03/08(土) 10:53:23
>>125
そうでもない。
最近の携帯は、かなり軽いよ。
今、携帯Java（MIDP2.0）上でJavaベースのOS作ってるよ。
うまく行けば、このOSの上にJava2SE実装して、パソコン用のソフトも使えるようにしたいな。
そうでもない。
最近の携帯は、かなり軽いよ。
今、携帯Java（MIDP2.0）上でJavaベースのOS作ってるよ。
うまく行けば、このOSの上にJava2SE実装して、パソコン用のソフトも使えるようにしたいな。
130 ：デフォルトの名無しさん：2008/03/08(土) 13:36:06
131 ：デフォルトの名無しさん：2008/04/15(火) 13:15:53
結局OS作れませんでしたスレか
132 ：デフォルトの名無しさん：2008/12/06(土) 21:15:42
http://extjs.com/deploy/dev/examples/desktop/desktop.html [extjs.com] こういうのは？
133 ：デフォルトの名無しさん：2009/01/20(火) 01:22:36
134 ：デフォルトの名無しさん：2009/07/21(火) 17:53:46
D言語ってガーベージコレクションもってるよね。
これって、どう動くかと言えば
＜＝＝＝＝メモリ＝＝＝＞ ＜＝＝＝＝メモリ＝＝＝＞
アプリケーション1+ガベコレコード アプリケーション2+ガベコレコード
↑↓
OS
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
実メモリー
というイメージになることが多いと思うんだけど、
（最近だとこの辺はもうすごく手が入っててイメージです状態だろうけど
アプリからリニアにアドレスが見えるわけだし、ガベコレはそのリニアアドレス
を操作してるんだからこうだよね）
でも、これを
＜＝＝＝＝メモリ＝＝＝＞ ＜＝＝＝＝メモリ＝＝＝＞
アプリケーション1 アプリケーション2
↑↓
OS+カーネルが各アプリのガベコレを制御
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
実メモリー
ということになれば、マルチスレッド、マルチコア、マルチキャッシュの
cpuでのパフォーマンス的にも色々と行けるような気がするのね。
もうね、まったく新しいosというレベル。
目指すならここを目指すべきだと思う。
これって、どう動くかと言えば
＜＝＝＝＝メモリ＝＝＝＞ ＜＝＝＝＝メモリ＝＝＝＞
アプリケーション1+ガベコレコード アプリケーション2+ガベコレコード
↑↓
OS
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
実メモリー
というイメージになることが多いと思うんだけど、
（最近だとこの辺はもうすごく手が入っててイメージです状態だろうけど
アプリからリニアにアドレスが見えるわけだし、ガベコレはそのリニアアドレス
を操作してるんだからこうだよね）
でも、これを
＜＝＝＝＝メモリ＝＝＝＞ ＜＝＝＝＝メモリ＝＝＝＞
アプリケーション1 アプリケーション2
↑↓
OS+カーネルが各アプリのガベコレを制御
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
実メモリー
ということになれば、マルチスレッド、マルチコア、マルチキャッシュの
cpuでのパフォーマンス的にも色々と行けるような気がするのね。
もうね、まったく新しいosというレベル。
目指すならここを目指すべきだと思う。
135 ：デフォルトの名無しさん：2009/07/24(金) 20:19:35
D言語の中の人の主張はそれだけどね。
何で俺が言語にＧＣを実装しなきゃいけないんだって人。
何で俺が言語にＧＣを実装しなきゃいけないんだって人。
136 ：デフォルトの名無しさん：2009/08/01(土) 22:01:04
D用のGUI・画像・ファイル処理系のライブラリが充実されたら手を出してやる
137 ：デフォルトの名無しさん：2009/08/01(土) 23:22:16
C用のGUI・画像・ファイル処理系のライブラリが充実してる
138 ：デフォルトの名無しさん：2009/08/10(月) 12:49:13
age
139 ：デフォルトの名無しさん：2009/08/11(火) 12:41:47
プロセスを作成したらヒープを作成して、
システムコールを呼んだら、ヒープ内にメモリブロックを確保したり解放したりして、
プロセスが終わったら、ヒープを解放する。
システムコールを呼んだら、ヒープ内にメモリブロックを確保したり解放したりして、
プロセスが終わったら、ヒープを解放する。
140 ：デフォルトの名無しさん：2009/08/11(火) 13:48:50
それから動的にメモリを確保するときにシステムコールを呼ぶように、D言語自体を書き換えすることが必要。
141 ：デフォルトの名無しさん：2009/08/11(火) 14:11:54
142 ：デフォルトの名無しさん：2009/08/11(火) 20:35:06
>>140
メモリ確保ごとにシステムコールってどんなネタだよ
メモリ確保ごとにシステムコールってどんなネタだよ
143 ：デフォルトの名無しさん：2009/08/27(木) 18:55:58
Schemeってガーベージコレクションもってるよね。
これって、どう動くかと言えば
＜＝＝＝＝メモリ＝＝＝＞ ＜＝＝＝＝メモリ＝＝＝＞
アプリケーション1+ガベコレコード アプリケーション2+ガベコレコード
↑↓
OS
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
実メモリー
というイメージになることが多いと思うんだけど、
（最近だとこの辺はもうすごく手が入っててイメージです状態だろうけど
アプリからリニアにアドレスが見えるわけだし、ガベコレはそのリニアアドレス
を操作してるんだからこうだよね）
でも、これを
＜＝＝＝＝メモリ＝＝＝＞ ＜＝＝＝＝メモリ＝＝＝＞
アプリケーション1 アプリケーション2
↑↓
OS+カーネルが各アプリのガベコレを制御
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
実メモリー
ということになれば、マルチスレッド、マルチコア、マルチキャッシュの
cpuでのパフォーマンス的にも色々と行けるような気がするのね。
もうね、まったく新しいosというレベル。
目指すならここを目指すべきだと思う。
これって、どう動くかと言えば
＜＝＝＝＝メモリ＝＝＝＞ ＜＝＝＝＝メモリ＝＝＝＞
アプリケーション1+ガベコレコード アプリケーション2+ガベコレコード
↑↓
OS
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
実メモリー
というイメージになることが多いと思うんだけど、
（最近だとこの辺はもうすごく手が入っててイメージです状態だろうけど
アプリからリニアにアドレスが見えるわけだし、ガベコレはそのリニアアドレス
を操作してるんだからこうだよね）
でも、これを
＜＝＝＝＝メモリ＝＝＝＞ ＜＝＝＝＝メモリ＝＝＝＞
アプリケーション1 アプリケーション2
↑↓
OS+カーネルが各アプリのガベコレを制御
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
実メモリー
ということになれば、マルチスレッド、マルチコア、マルチキャッシュの
cpuでのパフォーマンス的にも色々と行けるような気がするのね。
もうね、まったく新しいosというレベル。
目指すならここを目指すべきだと思う。
144 ：デフォルトの名無しさん：
GikoOS