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

次世代言語、インラインアセンブラも仕様レベルでサポートしているD言語でOSを作ろうというスレ。
D言語は文字列がnull終端でないのでその部分はC言語と互換性がありません。
またC++とは一切互換性がないので他のライブラリのクラスを使ったアプリを作るのは非常に面倒です。
なのでOSから作ってしまおうというプロジェクト。(単にgtkをD言語に移植すればいいだけというのは置いといて)
ちなみに折れはブートローダーの作り方も分かりませんのでOSを作ろうの過去ログを見てる所

■関連サイト
MONAソースコード解析
http://tkralia.hp.infoseek.co.jp/mona/
Yamami-Open
http://f38.aaa.livedoor.jp/~yamami/pukiwiki/pukiwiki.php?Yamami-Open

■関連スレ
【char[] str】 D言語 Part7 【str ~= "nullpo"】
http://pc8.2ch.net/test/read.cgi/tech/1122912733/
OSを作ろうpart12
http://pc8.2ch.net/test/read.cgi/os/1108836476/
OSを作ろうpart14　Mona専用
http://pc8.2ch.net/test/read.cgi/os/1127467365/

>>2
華麗に 2get

Bochs
http://bochs.sourceforge.net/
Higepos(Monaの古いコード?)
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/higepos/higepos/src/

リンカオプション
http://pc3.2ch.net/tech/kako/1024/10244/1024411711.html
678〜
>ld -Ttext 0x100000 --oformat binary -o
>ld -o xxx -Ttext 0x0 -e main xxxx.o

コンパイラオプション
http://pc3.2ch.net/tech/kako/1027/10270/1027080631.html
>gcc -c -ffreestanding -Wall kernel.c
>strip --output-target=binary kernel.o
D言語に-ffreestanding相当の物はあるのか?
まぁ無くてもC言語でD言語のD_main辺りを呼ぶブリッジを作成すれば出来そう。

D自体微妙なのに。

微妙なの？

リンカの順序について
http://pc3.2ch.net/tech/kako/1027/10270/1027080631.html
100辺り〜
>リンカスクリプトで、コードセグメントを先頭に持っていく

C++のnew/deleteについて
http://pc3.2ch.net/tech/kako/1027/10270/1027080631.html
157〜
D言語の場合…メモリ管理部分がどうなるんだろう…?
メモリ管理部分を先に実装し後はクラス/GCを使っていきたいけどDコンパイラがどの程度依存してるのかその辺が分からない。

>>4-5
微妙ではないけどC言語との互換性の面からあまり使われていない。
C#やJAVAのネイティブ版って感じ。

Phobosをどこで動かすんだろう

ふむぅ…
アセンブラなりCなりC++なりで書かれたマイクロカーネルなOSをベースにサブシステムをD言語で作るというのが現実的っぽい。(ってよりも個人的にそれで満足だけど)
どのマイクロカーネルを元にするのがいいか、その場合のDコンパイラやPhobosをどのぐらいごにょる必要があるかを考えた方がいいのかな。

そういや、最近触ってなかったんだけど、D言語って仕様は安定したの？
（まだ正式版（１．０）もリリースされていないみたいだけどさ）

普及してないだけか。

所詮ｼｪｱｳｪｱ厨のｵﾅﾆｰ言語ですから

マイクロカーネルで有名な物はMachとL4があると。
L4をベースにして見たいけどまだ検討中。

VB6しかやったことないけど、おれも協力するよ！

>>13
D言語とcygwinが使えるなら大歓迎さ！

サービスをユーザーモードで走らせるかカーネルモードで走らせるか
ユーザーモードだとスピードが落ちるらしい。
カーネルモードはメモリ保護機構がないため危険。
だけどD言語だったらサービス自体もカーネルモードで大丈夫な気がする。(変な事しなければいいんだし…)
後はソースを見てどこからとっかかる and 調べるかだな…

OSがGCを実装してアプリはメモリ使いまくりがDの理想らしいじゃん
OSがGCサポートしてればDはいらん

>>14
VBしかできねーっていってんだろ。なめてんのか、あぁ？

VBでOS？

VBでVBのコンパイラを書いて、VBで出来たカーネルコードを(ry

>>19
うっせーばーか
ウシャシャシャシャシャ

とりあえず何を作るの？

100 REM BASIC ﾃﾞ OS
110 PRINT "KawaisOS Ver.-1 (´・ω・)"
120 INPUT "C> "; A$
130 PRINT "コマンドまたはファイル名が違います."
140 GOTO 120

>>21
1.GCを動くようにする
2.D言語で下位互換性無視してクラスでいろいろ実装

ってかマイクロカーネルを使ってモノリシックカーネルを作ればGCも簡単に動くであろう…と思うんだけど
後、プログラムが動く上で必要なGCは一つだけなんだから(ry
取り合えず暇な時にマイクロカーネルのソースを読もうと思います。

ひげぽんは最初JavaでOSを作ろうとしたみたいだよ。
今頃になってJavaをネイティブコンパイルしてMonaを書き換える動きが出てきたけど
ひげぽんは興味がないみたいだね。

>>11
それはひげぽんが師匠と仰ぐ屋根裏のことか？

>>19
絵空事前提で書いてるみたいだけどやろうと思えばできることだから。
ttp://nienie.com/~masapico/doc_MakeExe.html

最終的に機械語なりアセンブリ言語なりを吐くことさえできれば、
何のプログラミング言語でも*理論上*は可能。

作成する本人に言語処理系を作成する能力があれば、普通にどんな言語でも出来るだろ。
HSP、なでしこ、その他何でもＯＫだろ。

MonaOSを移植するの？
それとも、完全オリジナルのOSを造るの？

>>27
ダウト

言い方が悪かったな。
極論すればファイル入出力と文字列処理ができる言語であれば良い。

D言語いいんだけど、>>9が言うように正式版が無いってのが不安。
処理系の変化にどこまで追従するのか。
GCとスレッド周りの扱いさえ決めれば問題無く使えると思うよ。

俺が新しい言語Φを作ろうと思っているんだが誰か乗らないか？

>>33
まんこ？

>>15
ここでいっその事x86アーキテクチャ全開でリング１〜リング４を使い切るというのはどうだ？

Dで作ったOS
　↓
D+OS
　↓
DOS

どうせならマルチCPUを使い切る言語きぼんぬ

とりあえず>>1はトリップつけて、サイトを立ち上げてくらはい。

>>1はD言語の糞GC仕様を知ってて言ってるのかねえ

さっそく真似されとるな
ttp://wiki.monaos.org/index.php?gdc

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

Dにそこまで入り込むだけの価値なんてあるか？

そこにDがあるから。

C#のOS -> CooS
D のOS -> DooS?

>>44
>>36

>>41
D言語のためにC++を排除してC言語に固執する意味が分からん。
extern "C"にしておけばC++がC言語に比べて障害になることはない。
マングリング規則が違うからC++とD言語でクラスを混ぜることはできないが
それを言ったらC言語にはクラス自体がないから悩まないだけだろ。

>>41

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

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

>>46
C言語で作成するのは、GCだとかのランタイム機能だけだろ。
あとは、すべてＤ言語で書くのだろう。

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

自動的にガベコレを埋め込むDの仕様からして
OSになることはできないんじゃないのかい？

DのガベージコレクタってDで書いあるんじゃないけ

Ｄ言語とアセンブリ言語だけで全部記述出来るじゃん。

>>48
> C言語で作成するのは、GCだとかのランタイム機能だけだろ。
↓のことを指しているかと。
>>41 MonaのコアをCに書き換えて使うのもいいかな

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

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

>>50
正解

>>51
だと思う

GD

1はとにかく手を動して、blogでも書いて経過を晒せ。
Monaの方はどんどん進んでるぞ。
ttp://wiki.monaos.org/index.php?gdc

1はOSとか言う前にDは一通り使いこなせてるのか？
glExcessの移植程度のことはできるんだろうな？

ま　た　ネ　タ　か　！　！

個人的にはLISPかSchemeで今風のOS作ってみて欲しい。

>>41
リングじゃ無くて特権レベル0〜3だな
簡単にいうとx86は68000系のようにユーザーモード/カーネルモードの切替が2段階じゃなくて、特権レベル0〜3までの4段階持てる

その特権レベルの事をリングって言うんだよボケ

ああ、あれか、経産婦が避妊に使うやつか。

>>3
心配しなくてもC++でも使えないから
cc1plus: warning: command line option "-ffreestanding" is valid for C/ObjC but not for C++

取り合えずage

sageてるがな

まったく進まんけどなんか期待

保守

D ver.0.100!!!

全部Ｄで作ってこそ意味があるのでは？

保守

保守

age

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

そう、C言語はUNIXを作るために生まれたんだ！
C++やJavaがいくら攻勢を見ようとも、未だに元祖Cが使われている理由がまさにこれ。

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

JavaはJavaVMを作るために作られた訳だが

　　　　　　　　　　　　_,､-‐‐'ｰ- ､,_ヽ_
　　　　　　　　　　 ／ ,､ -‐ ''"´;:　;　ヽ
　　　　　　　　　 / ／ ,､‐''"´´　　;: ;;`ヽ
　　　　　　　　 /　(／　 ,､-‐''"´´　_,　,丶　　　　　　　　　 そおおおんあわけねええだろぉ？
　　　　　　　　 i　 (ゝ ／,　, ､ｰ''"､´ 　 _ヽ
　　　　　　　　 |　 /'''_ｰ-<___, -'´ lｰ''"ノ ヽ.　　, へ､ _
　　　　　　　　　､　'l { ｀ヽ;ｰ-､-,ｰ‐,r''1　; ;ヽ<''ﾍ　　ヽー---‐'''"""""
　　　　　　　　　 r､ iヽ　　ヽ'　｀'　　　.|､　　,. |　 |
　　　　　　　　　{λヽ.ヽ　　　　　　 ,,ｿ ヽ-' t' __ﾉ　　　,______
　　　　　　　　　＼ゝ､iヽｰ '`ー'''`1´　　　　 ~ヽ､､､／~　　　￣￣,~"＝
　　　､‐'''''ヽ　　　 ｀'ﾍ.',ヽ　　 , ､　{　　　　　　　　　　　　　　,､- '´　　　
　　/　　　　 ＼　　　 ヾ ヽ⌒ヽ ヽ {　　　　　　　, ‐､_　　 ／　　　　　　　
.　 |　　　　 　　 ゛‐-ｰ'.,!＼＼__　 ｀ヽ.　,､　　 ／　　　｀'´　　　　　　　　,
　　､　　　　　　　　/ / |　＼ ＼゛､ｰ'>' ﾉrｰ' ´　　　　| ,　　　　　　　／
　　r;　　　　　　　/ /　 |＼,_＼ ｀""´r''| ト､ 　　　　　| |　　　　　／
　　 ｉ　　　　　　　 /　　|　 　フ 丶､___ノヽ.　　　　　　|/　/　　／
　　ｒヽ＼　　 　　 (　　 | 　 ,ﾍ　　　| |　ヽ ＼　　　　 ‖/　／

非チューリングマシンで動くOSきぼう

このスレって、なにか成果があがることを期待していいんですか？

D言語は当分完成しないみたいだからFreePascalで作って

>>79
GCCにPASCALなかったっけ? あれじゃ駄目?

やっぱりDだったのか。。。

保守

何故わざわざＤ言語なんだ？ｗｗｗｗｗ

保守

既存OSをD言語で作り変えることは、D言語の魅力/問題を洗い出すという目的において良い課題であると思うけどね。

OSってどのレイヤーを指してるのかと思ったらカーネル作ろうっての？
マイクロカーネルなだけで遅いのにしかもD言語。
ライブラリ整備するほうが先でしょ

ていうかDが1.0になるのが先ｗ

>>1はどうした？
Dの悲惨な現状を知って（僕は知らないけど）にげたか？

age

hage

CP/M ++ → DQ/N

DQN-OS

すげー

D言語は、1.0がリリースされるよりも早くMSが買い取るかも。
MS-D コンパイラってね。
手厚いMS印のサポートが期待できる。

DotNETになるだけだろ

IronD on .NET

いきなりスケールのでかいスレタイでつね

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

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

あれじゃね？
C言語で書かれたソースをD言語に変換するツール作成すれば一発じゃね？

>>97
> 組み込みＯＳでは基本的にＣ＋＋特有な機能を使用しない
組み込みだとサイズ/速度のオーバヘッドがデカいからじゃないかなあ。

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

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

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

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

>>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/

がんばれ

>>101
組込みはメモリの動的管理自体をやらないやつらが多い。
あらかじめ最大値を決めてそのサイズ分確保してる。

組み込みの場合、何よりも「落ちないことが保障できる」ことが重要だからな。

さらに言うと

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

だよな

つーか組み込みは、やる事決まってるからだろ

MoNaじゃなくてBSDをDで再実装なら協力する。

>>101
ガベコレの問題が有って、今のガベコレ言語は、

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

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

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

/

これって実は言語とかは全然関係なくて、
GC用ヒープがシステムメモリとして何百メガか確保されるだけでは？
ただ、これだとアルゴリズムがコンカレントGCしか選択できないな。

age

今のGCって論理アドレス空間で整頓してるんだよね？
カーネルだと物理アドレス空間を触ることになると思うんだけど、
そっちだとより効率的にメモリを整頓できたりするの？

むしろ、このマルチコア時代には、１CPUを丸々メモリ管理に割り当ててもいいんじゃないかと思ってる。

>>113
それだとキャッシュ効率が悪過ぎる

>>62
初めて来たけどこれObjC組み込めるのか？
期待age

sageてしまったorz

保守

そういや任天堂がC++のOS作ってたね。ライセンスは知らんが成果も発表してた気が。
任天堂なら作れるかも

C++のOSって既にあった気がするんだが

まさか Mona とか

実装は知らんがインターフェースがC++だったのはBeOS

Nintendo esだろ

>121
ああそれそれ。あくまでインターフェイスの話なのか、あれ。



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

今更使い道はないんじゃない？
TRONの需用自体がITRONくらいで、そこにGCはヘビーかと。

携帯でも Java なんだから gc がヘビーってこともない機器もあるかも

そこであえて超漢字を

携帯の Java は PC みたいに軽くないので、昔のBasicみたいにクラス作らないでかく

Basicを引きあいに出さなくてもＣでいいんじゃね？

>>125
そうでもない。
最近の携帯は、かなり軽いよ。

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

http://www.geocities.jp/tor_park/Dlang/byte.html

結局OS作れませんでしたスレか

http://extjs.com/deploy/dev/examples/desktop/desktop.html [extjs.com] こういうのは？

http://pc11.2ch.net/test/read.cgi/cg/1046440380/116

D言語ってガーベージコレクションもってるよね。
これって、どう動くかと言えば

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

でも、これを

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

D言語の中の人の主張はそれだけどね。
何で俺が言語にＧＣを実装しなきゃいけないんだって人。

D用のGUI・画像・ファイル処理系のライブラリが充実されたら手を出してやる

C用のGUI・画像・ファイル処理系のライブラリが充実してる

age

プロセスを作成したらヒープを作成して、
システムコールを呼んだら、ヒープ内にメモリブロックを確保したり解放したりして、
プロセスが終わったら、ヒープを解放する。

それから動的にメモリを確保するときにシステムコールを呼ぶように、D言語自体を書き換えすることが必要。

>>140
お前D言語のこと何も知らずに書いてるだろ
言語自体なんか書き換えなくてもPhobosの書き換えで済む

>>140
メモリ確保ごとにシステムコールってどんなネタだよ

Schemeってガーベージコレクションもってるよね。
これって、どう動くかと言えば

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

でも、これを

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

GikoOS