【次世代言語】D言語でOSを作ろう【Monaの移植?】

【次世代言語】D言語� ..

39:デフォルトの名無しさん
05/10/10 17:09:54
>>1はD言語の糞GC仕様を知ってて言ってるのかねえ

40:デフォルトの名無しさん
05/10/10 20:53:14
さっそく真似されとるな
URLﾘﾝｸ(wiki.monaos.org)

41:デフォルトの名無しさん
05/10/11 01:21:58
>>16
いっその事CPUに(ぇ
>>29
マイクロカーネルのMachやL4をベースに作成したいなと思ってます。
マイクロカーネルにするかモノリシックカーネルにするかは未定。
D言語の為のD言語によるOSを目指しD言語を対応する部分はC言語で書く。(メモリ管理とシステムコール、GC)
ただMonaの方が日本語の文章が多いのでMonaのコアをCに書き換えて使うのもいいかなとも思ってます。
>>35
リングってなんですか?
>>39
GCの仕様と問題点はある程度理解してるつもりです。
が、理想としてはOS側でGCの機能を持たせてしまえば無問題かと。(コンパイラの変更、GCの移植からしなくてはならないので面倒ですが)
ただ実装時にユーザーモードのメモリ領域とカーネルモードのメモリ領域とが問題になりそう。
システムコールを使いまくらなきゃいけなくなる気ガス。
#メモリー関係/システムコールを一から学んでる状態なので変な事言ってるかもしれない。
URLﾘﾝｸ(tkralia.hp.infoseek.co.jp)
URLﾘﾝｸ(tkralia.hp.infoseek.co.jp)
URLﾘﾝｸ(mona.sourceforge.jp)
>>38
作れるめどが立つまで名無しでいまつ。
>>40
向こうはMonaで動くアプリ/ライブラリだから微妙に違うかも…ってあんまりちがくも無いか。
俺の理想としてはアセンブラ->C->Dでは無くアセンブラ(メモリ管理とシステムコールとGCのみC言語で書く)->Dを目指したいです。

42:デフォルトの名無しさん
05/10/11 03:11:38
Dにそこまで入り込むだけの価値なんてあるか？

43:デフォルトの名無しさん
05/10/11 03:24:48

そこにDがあるから。

44:デフォルトの名無しさん
05/10/11 06:13:43
C#のOS -> CooS
D のOS -> DooS?

45:デフォルトの名無しさん
05/10/11 09:11:40
>>44
>>36

46:デフォルトの名無しさん
05/10/11 22:21:59
>>41
D言語のためにC++を排除してC言語に固執する意味が分からん。
extern "C"にしておけばC++がC言語に比べて障害になることはない。
マングリング規則が違うからC++とD言語でクラスを混ぜることはできないが
それを言ったらC言語にはクラス自体がないから悩まないだけだろ。

47:デフォルトの名無しさん
05/10/11 23:27:03
>>41

メモリ管理とシステムコールとGCとか言っている時点でOSが必要でしょ。
ベースOSをMonaにしたら URLﾘﾝｸ(wiki.monaos.org) でやってることと
全くかわらないでしょ。まずはサーバーとアプリを全部D言語にしてから
カーネル周りのD言語化を考えたら？

あとわざわざCにする理由がわからん。だったらMonaじゃなくAntOSとか他のOS使ったら？

48:デフォルトの名無しさん
05/10/11 23:43:18
>>46
C言語で作成するのは、GCだとかのランタイム機能だけだろ。
あとは、すべてＤ言語で書くのだろう。

他言語で作成する必要があるGCだとかは、オブジェクト指向的な作りに出来ないだろう。
それなら、わざわざハマリどころの多いＣ++で、
苦労して作成する必要性はどこにもない。

49:デフォルトの名無しさん
05/10/11 23:44:09
自動的にガベコレを埋め込むDの仕様からして
OSになることはできないんじゃないのかい？

50:デフォルトの名無しさん
05/10/11 23:46:35
DのガベージコレクタってDで書いあるんじゃないけ

51:デフォルトの名無しさん
05/10/11 23:54:40
Ｄ言語とアセンブリ言語だけで全部記述出来るじゃん。

52:デフォルトの名無しさん
05/10/11 23:57:08
>>48
> C言語で作成するのは、GCだとかのランタイム機能だけだろ。
↓のことを指しているかと。
>>41 MonaのコアをCに書き換えて使うのもいいかな

> 他言語で作成する必要があるGCだとかは、オブジェクト指向的な作りに出来ないだろう。
Monaでgcjのために用意されたGCはC++で書かれている。

>>49
アセンブリに埋め込まれるわけではない。
メモリ確保時に呼ばれる関数から適宜GCに振り分けてるだけ。
その関数をどう実装するかが肝。
面倒ならGCをやめてdeleteを書かせることすら可能。
D言語の優位性はGCだけではないから
GCがないとD言語の意味がないとまでは思わない。
もちろんユーザーランドではなくカーネル限定なので誤解なきよう。

53:デフォルトの名無しさん
05/10/12 11:36:57
>>50
正解

>>51
だと思う

54:デフォルトの名無しさん
05/10/12 12:39:48
GD

55:デフォルトの名無しさん
05/10/13 22:43:43
1はとにかく手を動して、blogでも書いて経過を晒せ。
Monaの方はどんどん進んでるぞ。
URLﾘﾝｸ(wiki.monaos.org)

56:デフォルトの名無しさん
05/10/14 23:14:39
1はOSとか言う前にDは一通り使いこなせてるのか？
glExcessの移植程度のことはできるんだろうな？

57:デフォルトの名無しさん
05/10/15 15:24:48
ま　た　ネ　タ　か　！　！

58:デフォルトの名無しさん
05/10/15 16:19:21
個人的にはLISPかSchemeで今風のOS作ってみて欲しい。

59:デフォルトの名無しさん
05/10/17 02:20:17
>>41
リングじゃ無くて特権レベル0～3だな
簡単にいうとx86は68000系のようにユーザーモード/カーネルモードの切替が2段階じゃなくて、特権レベル0～3までの4段階持てる

60:デフォルトの名無しさん
05/10/17 08:12:49
その特権レベルの事をリングって言うんだよボケ

61:デフォルトの名無しさん
05/10/17 19:31:34
ああ、あれか、経産婦が避妊に使うやつか。

62:デフォルトの名無しさん
05/10/18 20:58:24
>>3
心配しなくてもC++でも使えないから
cc1plus: warning: command line option "-ffreestanding" is valid for C/ObjC but not for C++

63:1
05/10/26 18:03:01
取り合えずage

64:デフォルトの名無しさん
05/10/26 20:49:15
sageてるがな

65:デフォルトの名無しさん
05/12/11 10:56:18
まったく進まんけどなんか期待

66:デフォルトの名無しさん
05/12/31 21:22:07
保守

67:デフォルトの名無しさん
06/01/02 18:28:49
D ver.0.100!!!

68:デフォルトの名無しさん
06/01/02 21:39:21
全部Ｄで作ってこそ意味があるのでは？

69:デフォルトの名無しさん
06/01/07 12:26:24
保守

70:デフォルトの名無しさん
06/01/15 03:02:35
保守

71:デフォルトの名無しさん
06/01/15 13:00:19
age

72:デフォルトの名無しさん
06/01/15 17:00:32
発想が逆だ。言語はOSというソフトの仕様を満たすための手段だ。
始めに言語ありきで話を進めたら言語に縛られた貧相なものしか出来ないぞ。
まずOSの仕様を考えて、それを作るために言語を新たに作るぐらいで
なければいかんだろう。C言語だってそれで出来たんだしな。

73:デフォルトの名無しさん
06/01/15 17:54:45
そう、C言語はUNIXを作るために生まれたんだ！
C++やJavaがいくら攻勢を見ようとも、未だに元祖Cが使われている理由がまさにこれ。

74:デフォルトの名無しさん
06/01/15 19:53:57
これから作る新機能満載なOSにはそれを使えば簡単に書けるというような新たな言語が必要だ。
従来の殻を破るには根本から変えるしかない。第二の Linux や Windows を作りたいなら
それでもいいが、そんな車輪の発明は誰も欲しがらないだろう。もっと根底から考え直さねば
駄目だ。

75:デフォルトの名無しさん
06/01/15 20:20:50
JavaはJavaVMを作るために作られた訳だが

76:デフォルトの名無しさん
06/01/15 21:53:33
　　　　　　　　　　　　_,､-‐‐'ｰ- ､,_ヽ_
　　　　　　　　　　／ ,､ -‐ ''"´;:　;　ヽ
　　　　　　　　　 / ／ ,､‐''"´´　　;: ;;`ヽ
　　　　　　　　 /　(／　 ,､-‐''"´´　_,　,丶　　　　　　　　　そおおおんあわけねええだろぉ？
　　　　　　　　 i　 (ゝ／,　, ､ｰ''"､´ 　 _ヽ
　　　　　　　　 |　 /'''_ｰ-<___, -'´ lｰ''"ノヽ.　　, へ､ _
　　　　　　　　　､　'l { ｀ヽ;ｰ-､-,ｰ‐,r''1　; ;ヽ<''ﾍ　　ヽー---‐'''"""""
　　　　　　　　　 r､ iヽ　　ヽ'　｀'　　　.|､　　,. |　 |
　　　　　　　　　{λヽ.ヽ　　　　　　 ,,ｿヽ-' t' __ﾉ　　　,______
　　　　　　　　　＼ゝ､iヽｰ '`ー'''`1´　　　　 ~ヽ､､､／~　　　￣￣,~"＝
　　　､‐'''''ヽ　　　｀'ﾍ.',ヽ　　 , ､　{　　　　　　　　　　　　　　,､- '´　　　
　　/　　　　＼　　　ヾヽ⌒ヽヽ {　　　　　　　, ‐､_　　／　　　　　　　
.　 |　　　　　　゛‐-ｰ'.,!＼＼__　｀ヽ.　,､　　／　　　｀'´　　　　　　　　,
　　､　　　　　　　　/ / |　＼＼゛､ｰ'>' ﾉrｰ' ´　　　　| ,　　　　　　　／
　　r;　　　　　　　/ /　 |＼,_＼｀""´r''| ト､　　　　　| |　　　　　／
　　ｉ　　　　　　　 /　　|　　フ丶､___ノヽ.　　　　　　|/　/　　／
　　ｒヽ＼　　　　 (　　 | 　 ,ﾍ　　　| |　ヽ＼　　　　 ∥/　／

77:デフォルトの名無しさん
06/01/21 00:36:42
非チューリングマシンで動くOSきぼう

78:デフォルトの名無しさん
06/01/22 16:58:25
このスレって、なにか成果があがることを期待していいんですか？

79:デフォルトの名無しさん
06/01/22 21:24:24
D言語は当分完成しないみたいだからFreePascalで作って

80:デフォルトの名無しさん
06/01/24 09:08:55
>>79
GCCにPASCALなかったっけ? あれじゃ駄目?

81:デフォルトの名無しさん
06/01/28 20:12:04
やっぱりDだったのか。。。

82:デフォルトの名無しさん
06/02/15 15:56:11
保守

83:デフォルトの名無しさん
06/02/21 23:45:08
何故わざわざＤ言語なんだ？ｗｗｗｗｗ

84:デフォルトの名無しさん
06/04/09 14:46:13
保守

85:デフォルトの名無しさん
06/04/12 00:10:33
既存OSをD言語で作り変えることは、D言語の魅力/問題を洗い出すという目的において良い課題であると思うけどね。

86:デフォルトの名無しさん
06/04/12 02:55:24
OSってどのレイヤーを指してるのかと思ったらカーネル作ろうっての？
マイクロカーネルなだけで遅いのにしかもD言語。
ライブラリ整備するほうが先でしょ

87:デフォルトの名無しさん
06/04/12 12:32:20
ていうかDが1.0になるのが先ｗ

88:デフォルトの名無しさん
06/04/27 23:31:49
>>1はどうした？
Dの悲惨な現状を知って（僕は知らないけど）にげたか？

89:デフォルトの名無しさん
06/07/18 00:40:55
age

90:デフォルトの名無しさん
06/10/02 23:09:35
hage

91:デフォルトの名無しさん
06/10/03 00:38:09
CP/M ++ → DQ/N

DQN-OS

92:デフォルトの名無しさん
06/10/03 05:03:10
すげー

93:デフォルトの名無しさん
06/10/04 02:55:51
D言語は、1.0がリリースされるよりも早くMSが買い取るかも。
MS-D コンパイラってね。
手厚いMS印のサポートが期待できる。

94:デフォルトの名無しさん
06/10/04 03:26:18
DotNETになるだけだろ

95:デフォルトの名無しさん
06/10/13 01:36:30
IronD on .NET

96:デフォルトの名無しさん
06/10/14 21:28:29
いきなりスケールのでかいスレタイでつね

97:FD
06/10/21 16:18:40
Ｄ言語でＯＳ作成ですか？面白い課題だと思います。
クラスを使用しなければ、Ｃ言語を少し柔軟にした言語使用なので、極端難しくないです。
参考するなら、Ｃ言語で書かれたＯＳソースを、Ｄ言語のプリプロセッサ機能を削除したソースへ置き換えることからはじめるのですかね？

組み込みＯＳでは基本的にＣ＋＋特有な機能を使用しないのが一般的です。
コメントだけＣ＋＋で中身Ｃ言語と言うものをよく見かけましたが・・・

98:デフォルトの名無しさん
06/10/21 17:20:41
あれじゃね？
C言語で書かれたソースをD言語に変換するツール作成すれば一発じゃね？

99:デフォルトの名無しさん
06/10/21 20:00:57
>>97
> 組み込みＯＳでは基本的にＣ＋＋特有な機能を使用しない
組み込みだとサイズ/速度のオーバヘッドがデカいからじゃないかなあ。

100:FD
06/10/21 20:45:20
>>99さん
それもありますが、ｎｅｗなどメモリのどこに配置されるか分からないので、メモリの制限された世界では使いにくいのです。
ＯＳカーネルになれば、メモリ管理はレガシーな方法とった方が安全だからです。
ただし、しっかりとメモリ管理された環境下であればＣ＋＋特有の機能は作る側に利点があると思います。
「しっかりとメモリ管理された環境」ですからカーネルの基本的な領域には適用しにくいです。
例えばＣ＋＋で記述されたというL4Ka-Pistachioのソースを参照すると、
ＡＰＩの領域（外向きの顔）はＣ＋＋ポイですが、内部制御はＣ＋＋と言うよりＣ言語です。
Ｃ＋＋の仕様自体にＣ言語仕様を含んでいるから当然なんでしょうけど・・・

>>98さん
のいわれている通り非常に近い仕様ですから、可能だと思います。

カーネルでも基本的なところを製作後は、言語仕様に関係なく開発できるのがベストだと思います。
Ｄ言語が優れているところはＣ言語より柔軟であると言うところ、プリプロセッサ機能を搭載していたら、そのままＤ言語に移行できてしまいます。

なお、Ｄ言語でもいいですけど、日本でカーネルを再勉強できる機会は少ないです。
ＯＳを作ると言う企画は面白いと思います。
まずは、簡単な部分から作らないといけませんね。
私も個人的に勉強したい領域です。

101:デフォルトの名無しさん
06/10/24 01:34:37
>>100
>メモリ管理
Cよりは柔軟な罠。newはオーバーロード出来るもの。
コンパイラと人間で責任もって書けばいいだけなんだけどな。

ところで、このスレの元ネタでもあるMonaは知ってる？
元々はム板にあったんだけど、嵐に粘着されてOS板やsiberiaへ亡命しちゃった。
URLﾘﾝｸ(wiki.monaos.org)
ｽﾚﾘﾝｸ(os板)
ｽﾚﾘﾝｸ(siberia板)

102:デフォルトの名無しさん
07/01/09 06:23:10
がんばれ

103:デフォルトの名無しさん
07/01/11 12:13:59
>>101
組込みはメモリの動的管理自体をやらないやつらが多い。
あらかじめ最大値を決めてそのサイズ分確保してる。

104:デフォルトの名無しさん
07/01/12 00:46:07
組み込みの場合、何よりも「落ちないことが保障できる」ことが重要だからな。

105:デフォルトの名無しさん
07/04/30 11:25:28
さらに言うと

「落ちても速やかに復帰して動き続ける」

だよな

106:デフォルトの名無しさん
07/06/29 16:04:05
つーか組み込みは、やる事決まってるからだろ

107:デフォルトの名無しさん
07/07/11 23:37:40
MoNaじゃなくてBSDをDで再実装なら協力する。

108:デフォルトの名無しさん
07/07/11 23:47:03
>>101
ガベコレの問題が有って、今のガベコレ言語は、

帆にゃらら言語のアプリ→OSへのメモリ要求
帆にゃらら言語のアプリ→OSからもらったメモリをゴミ扱いにする
帆にゃらら言語のアプリのガベコレ→さっきゴミにしたメモリを再利用可能ににする

ってな流れだけど、DでOSを書くと言うことはこのOSに頼んでる部分を書く必要が有って、
でも、DでOS書く訳で。と言うループに陥らないために

OSのメモリ管理＝D言語のメモリ管理という部分を設計してしまう必要が有るわけ。
手を抜こうと思えば、抜けるけども。

109:デフォルトの名無しさん
07/08/26 07:07:10
/

110:デフォルトの名無しさん
07/08/26 08:06:04
これって実は言語とかは全然関係なくて、
GC用ヒープがシステムメモリとして何百メガか確保されるだけでは？
ただ、これだとアルゴリズムがコンカレントGCしか選択できないな。

111:デフォルトの名無しさん
07/09/06 22:17:18
age

112:デフォルトの名無しさん
07/09/11 22:09:02
今のGCって論理アドレス空間で整頓してるんだよね？
カーネルだと物理アドレス空間を触ることになると思うんだけど、
そっちだとより効率的にメモリを整頓できたりするの？

113:デフォルトの名無しさん
07/09/16 15:24:08
むしろ、このマルチコア時代には、１CPUを丸々メモリ管理に割り当ててもいいんじゃないかと思ってる。

114:デフォルトの名無しさん
07/09/18 00:36:29
>>113
それだとキャッシュ効率が悪過ぎる

115:デフォルトの名無しさん
07/09/23 12:49:14
>>62
初めて来たけどこれObjC組み込めるのか？
期待age

116:デフォルトの名無しさん
07/09/23 12:50:31
sageてしまったorz

117:デフォルトの名無しさん
07/12/05 21:40:57
保守

118:デフォルトの名無しさん
07/12/05 22:05:50
そういや任天堂がC++のOS作ってたね。ライセンスは知らんが成果も発表してた気が。
任天堂なら作れるかも

119:デフォルトの名無しさん
07/12/13 09:36:12
C++のOSって既にあった気がするんだが

120:デフォルトの名無しさん
07/12/13 09:56:32
まさか Mona とか

121:デフォルトの名無しさん
07/12/13 09:59:43
実装は知らんがインターフェースがC++だったのはBeOS

122:デフォルトの名無しさん
07/12/13 15:55:27
Nintendo esだろ

123:119
08/01/07 14:54:13
>121
ああそれそれ。あくまでインターフェイスの話なのか、あれ。

ところで D で TRON ってどうよ、とかいう無茶振りをしてみるテスツ

124:デフォルトの名無しさん
08/01/07 20:34:20
今更使い道はないんじゃない？
TRONの需用自体がITRONくらいで、そこにGCはヘビーかと。

125:デフォルトの名無しさん
08/01/07 21:39:57
携帯でも Java なんだから gc がヘビーってこともない機器もあるかも

126:デフォルトの名無しさん
08/01/07 22:19:55
そこであえて超漢字を

127:デフォルトの名無しさん
08/01/09 03:30:00
携帯の Java は PC みたいに軽くないので、昔のBasicみたいにクラス作らないでかく

128:デフォルトの名無しさん
08/01/09 21:18:23
Basicを引きあいに出さなくてもＣでいいんじゃね？

129:デフォルトの名無しさん
08/03/08 10:53:23
>>125
そうでもない。
最近の携帯は、かなり軽いよ。

今、携帯Java（MIDP2.0）上でJavaベースのOS作ってるよ。
うまく行けば、このOSの上にJava2SE実装して、パソコン用のソフトも使えるようにしたいな。

130:デフォルトの名無しさん
08/03/08 13:36:06
URLﾘﾝｸ(www.geocities.jp)

131:デフォルトの名無しさん
08/04/15 13:15:53
結局OS作れませんでしたスレか

132:デフォルトの名無しさん
08/12/06 21:15:42
URLﾘﾝｸ(extjs.com) [extjs.com] こういうのは？

133:デフォルトの名無しさん
09/01/20 01:22:36
ｽﾚﾘﾝｸ(cg板:116番)

134:デフォルトの名無しさん
09/07/21 17:53:46
D言語ってガーベージコレクションもってるよね。
これって、どう動くかと言えば

　＜＝＝＝＝メモリ＝＝＝＞　　　　　　＜＝＝＝＝メモリ＝＝＝＞
　アプリケーション1+ガベコレコード　アプリケーション2+ガベコレコード
　　　　　　↑↓
　　　　　　OS
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
　　　　　　　　　　　実メモリー
というイメージになることが多いと思うんだけど、
（最近だとこの辺はもうすごく手が入っててイメージです状態だろうけど
アプリからリニアにアドレスが見えるわけだし、ガベコレはそのリニアアドレス
を操作してるんだからこうだよね）

でも、これを

　＜＝＝＝＝メモリ＝＝＝＞　＜＝＝＝＝メモリ＝＝＝＞
　アプリケーション1　　　　　　アプリケーション2
　　　　　　　　　　　　↑↓
　　　　　　OS+カーネルが各アプリのガベコレを制御
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
　　　　　　　　　　　実メモリー
ということになれば、マルチスレッド、マルチコア、マルチキャッシュの
cpuでのパフォーマンス的にも色々と行けるような気がするのね。
もうね、まったく新しいosというレベル。
目指すならここを目指すべきだと思う。

135:デフォルトの名無しさん
09/07/24 20:19:35
D言語の中の人の主張はそれだけどね。
何で俺が言語にＧＣを実装しなきゃいけないんだって人。

136:デフォルトの名無しさん
09/08/01 22:01:04
D用のGUI・画像・ファイル処理系のライブラリが充実されたら手を出してやる

137:デフォルトの名無しさん
09/08/01 23:22:16
C用のGUI・画像・ファイル処理系のライブラリが充実してる

138:デフォルトの名無しさん
09/08/10 12:49:13
age

139:デフォルトの名無しさん
09/08/11 12:41:47
プロセスを作成したらヒープを作成して、
システムコールを呼んだら、ヒープ内にメモリブロックを確保したり解放したりして、
プロセスが終わったら、ヒープを解放する。

140:デフォルトの名無しさん
09/08/11 13:48:50
それから動的にメモリを確保するときにシステムコールを呼ぶように、D言語自体を書き換えすることが必要。

141:デフォルトの名無しさん
09/08/11 14:11:54
>>140
お前D言語のこと何も知らずに書いてるだろ
言語自体なんか書き換えなくてもPhobosの書き換えで済む

142:デフォルトの名無しさん
09/08/11 20:35:06
>>140
メモリ確保ごとにシステムコールってどんなネタだよ

143:デフォルトの名無しさん
09/08/27 18:55:58
Schemeってガーベージコレクションもってるよね。
これって、どう動くかと言えば

　＜＝＝＝＝メモリ＝＝＝＞　　　　　　＜＝＝＝＝メモリ＝＝＝＞
　アプリケーション1+ガベコレコード　アプリケーション2+ガベコレコード
　　　　　　↑↓
　　　　　　OS
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
　　　　　　　　　　　実メモリー
というイメージになることが多いと思うんだけど、
（最近だとこの辺はもうすごく手が入っててイメージです状態だろうけど
アプリからリニアにアドレスが見えるわけだし、ガベコレはそのリニアアドレス
を操作してるんだからこうだよね）

でも、これを

　＜＝＝＝＝メモリ＝＝＝＞　＜＝＝＝＝メモリ＝＝＝＞
　アプリケーション1　　　　　　アプリケーション2
　　　　　　　　　　　　↑↓
　　　　　　OS+カーネルが各アプリのガベコレを制御
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
　　　　　　　　　　　実メモリー
ということになれば、マルチスレッド、マルチコア、マルチキャッシュの
cpuでのパフォーマンス的にも色々と行けるような気がするのね。
もうね、まったく新しいosというレベル。
目指すならここを目指すべきだと思う。