トップページ⇒tech
144コメント42KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2005/10/09(日) 03:00:38
次世代言語、インラインアセンブラも仕様レベルでサポートしている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/
0002デフォルトの名無しさん2005/10/09(日) 03:06:14
>>2
華麗に 2get
0003デフォルトの名無しさん2005/10/09(日) 03:35:34
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辺りを呼ぶブリッジを作成すれば出来そう。
0004デフォルトの名無しさん2005/10/09(日) 03:39:38
D自体微妙なのに。
0005デフォルトの名無しさん2005/10/09(日) 03:57:44
微妙なの？
0006デフォルトの名無しさん2005/10/09(日) 04:07:00
リンカの順序について
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のネイティブ版って感じ。
0007デフォルトの名無しさん2005/10/09(日) 04:11:01
Phobosをどこで動かすんだろう
0008デフォルトの名無しさん2005/10/09(日) 04:20:53
ふむぅ…
アセンブラなりCなりC++なりで書かれたマイクロカーネルなOSをベースにサブシステムをD言語で作るというのが現実的っぽい。(ってよりも個人的にそれで満足だけど)
どのマイクロカーネルを元にするのがいいか、その場合のDコンパイラやPhobosをどのぐらいごにょる必要があるかを考えた方がいいのかな。
0009デフォルトの名無しさん2005/10/09(日) 04:22:46
そういや、最近触ってなかったんだけど、D言語って仕様は安定したの？
（まだ正式版（１．０）もリリースされていないみたいだけどさ）
0010デフォルトの名無しさん2005/10/09(日) 04:24:44
普及してないだけか。
0011デフォルトの名無しさん2005/10/09(日) 04:36:38
所詮ｼｪｱｳｪｱ厨のｵﾅﾆｰ言語ですから
0012デフォルトの名無しさん2005/10/09(日) 04:50:38
マイクロカーネルで有名な物はMachとL4があると。
L4をベースにして見たいけどまだ検討中。
0013デフォルトの名無しさん2005/10/09(日) 05:00:17
VB6しかやったことないけど、おれも協力するよ！
0014デフォルトの名無しさん2005/10/09(日) 05:02:50
>>13
D言語とcygwinが使えるなら大歓迎さ！
0015デフォルトの名無しさん2005/10/09(日) 05:17:50
サービスをユーザーモードで走らせるかカーネルモードで走らせるか
ユーザーモードだとスピードが落ちるらしい。
カーネルモードはメモリ保護機構がないため危険。
だけどD言語だったらサービス自体もカーネルモードで大丈夫な気がする。(変な事しなければいいんだし…)
後はソースを見てどこからとっかかる and 調べるかだな…
0016デフォルトの名無しさん2005/10/09(日) 08:27:29
OSがGCを実装してアプリはメモリ使いまくりがDの理想らしいじゃん
OSがGCサポートしてればDはいらん
0017132005/10/09(日) 10:23:51
>>14
VBしかできねーっていってんだろ。なめてんのか、あぁ？
0018デフォルトの名無しさん2005/10/09(日) 11:20:45
VBでOS？
0019デフォルトの名無しさん2005/10/09(日) 12:31:09
VBでVBのコンパイラを書いて、VBで出来たカーネルコードを(ry
0020132005/10/09(日) 12:36:43
>>19
うっせーばーか
ウシャシャシャシャシャ
0021デフォルトの名無しさん2005/10/09(日) 14:26:27
とりあえず何を作るの？
0022デフォルトの名無しさん2005/10/09(日) 14:44:40
100 REM BASIC ﾃﾞ OS
110 PRINT "KawaisOS Ver.-1 (´・ω・)"
120 INPUT "C> "; A$
130 PRINT "コマンドまたはファイル名が違います."
140 GOTO 120
0023デフォルトの名無しさん2005/10/09(日) 15:40:20
>>21
1.GCを動くようにする
2.D言語で下位互換性無視してクラスでいろいろ実装

ってかマイクロカーネルを使ってモノリシックカーネルを作ればGCも簡単に動くであろう…と思うんだけど
後、プログラムが動く上で必要なGCは一つだけなんだから(ry
取り合えず暇な時にマイクロカーネルのソースを読もうと思います。
0024デフォルトの名無しさん2005/10/09(日) 17:25:14
ひげぽんは最初JavaでOSを作ろうとしたみたいだよ。
今頃になってJavaをネイティブコンパイルしてMonaを書き換える動きが出てきたけど
ひげぽんは興味がないみたいだね。
0025デフォルトの名無しさん2005/10/09(日) 17:26:33
>>11
それはひげぽんが師匠と仰ぐ屋根裏のことか？
0026デフォルトの名無しさん2005/10/09(日) 17:44:12
>>19
絵空事前提で書いてるみたいだけどやろうと思えばできることだから。
ttp://nienie.com/~masapico/doc_MakeExe.html
0027デフォルトの名無しさん2005/10/09(日) 20:37:45
最終的に機械語なりアセンブリ言語なりを吐くことさえできれば、
何のプログラミング言語でも*理論上*は可能。
0028デフォルトの名無しさん2005/10/09(日) 21:17:48
作成する本人に言語処理系を作成する能力があれば、普通にどんな言語でも出来るだろ。
HSP、なでしこ、その他何でもＯＫだろ。
0029デフォルトの名無しさん2005/10/09(日) 21:30:59
MonaOSを移植するの？
それとも、完全オリジナルのOSを造るの？
0030デフォルトの名無しさん2005/10/09(日) 22:24:51
>>27
ダウト
0031デフォルトの名無しさん2005/10/09(日) 23:00:10
言い方が悪かったな。
極論すればファイル入出力と文字列処理ができる言語であれば良い。
0032デフォルトの名無しさん2005/10/10(月) 03:04:31
D言語いいんだけど、>>9が言うように正式版が無いってのが不安。
処理系の変化にどこまで追従するのか。
GCとスレッド周りの扱いさえ決めれば問題無く使えると思うよ。
0033デフォルトの名無しさん2005/10/10(月) 12:41:28
俺が新しい言語Φを作ろうと思っているんだが誰か乗らないか？
0034デフォルトの名無しさん2005/10/10(月) 12:59:08
>>33
まんこ？
0035デフォルトの名無しさん2005/10/10(月) 13:10:32
>>15
ここでいっその事x86アーキテクチャ全開でリング１〜リング４を使い切るというのはどうだ？
0036デフォルトの名無しさん2005/10/10(月) 13:23:53
Dで作ったOS
　↓
D+OS
　↓
DOS
0037デフォルトの名無しさん2005/10/10(月) 14:37:39
どうせならマルチCPUを使い切る言語きぼんぬ
0038デフォルトの名無しさん2005/10/10(月) 15:18:22
とりあえず>>1はトリップつけて、サイトを立ち上げてくらはい。
0039デフォルトの名無しさん2005/10/10(月) 17:09:54
>>1はD言語の糞GC仕様を知ってて言ってるのかねえ
0040デフォルトの名無しさん2005/10/10(月) 20:53:14
さっそく真似されとるな
ttp://wiki.monaos.org/index.php?gdc
0041デフォルトの名無しさん2005/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の移植からしなくてはならないので面倒ですが)
ただ実装時にユーザーモードのメモリ領域とカーネルモードのメモリ領域とが問題になりそう。
システムコールを使いまくらなきゃいけなくなる気ガス。
#メモリー関係/システムコールを一から学んでる状態なので変な事言ってるかもしれない。
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を目指したいです。
0042デフォルトの名無しさん2005/10/11(火) 03:11:38
Dにそこまで入り込むだけの価値なんてあるか？
0043デフォルトの名無しさん2005/10/11(火) 03:24:48

そこにDがあるから。
0044デフォルトの名無しさん2005/10/11(火) 06:13:43
C#のOS -> CooS
D のOS -> DooS?
0045デフォルトの名無しさん2005/10/11(火) 09:11:40
>>44
>>36
0046デフォルトの名無しさん2005/10/11(火) 22:21:59
>>41
D言語のためにC++を排除してC言語に固執する意味が分からん。
extern "C"にしておけばC++がC言語に比べて障害になることはない。
マングリング規則が違うからC++とD言語でクラスを混ぜることはできないが
それを言ったらC言語にはクラス自体がないから悩まないだけだろ。
0047デフォルトの名無しさん2005/10/11(火) 23:27:03
>>41

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

あとわざわざCにする理由がわからん。だったらMonaじゃなくAntOSとか他のOS使ったら？
0048デフォルトの名無しさん2005/10/11(火) 23:43:18
>>46
C言語で作成するのは、GCだとかのランタイム機能だけだろ。
あとは、すべてＤ言語で書くのだろう。

他言語で作成する必要があるGCだとかは、オブジェクト指向的な作りに出来ないだろう。
それなら、わざわざハマリどころの多いＣ++で、
苦労して作成する必要性はどこにもない。
0049デフォルトの名無しさん2005/10/11(火) 23:44:09
自動的にガベコレを埋め込むDの仕様からして
OSになることはできないんじゃないのかい？
0050デフォルトの名無しさん2005/10/11(火) 23:46:35
DのガベージコレクタってDで書いあるんじゃないけ
0051デフォルトの名無しさん2005/10/11(火) 23:54:40
Ｄ言語とアセンブリ言語だけで全部記述出来るじゃん。
0052デフォルトの名無しさん2005/10/11(火) 23:57:08
>>48
> C言語で作成するのは、GCだとかのランタイム機能だけだろ。
↓のことを指しているかと。
>>41 MonaのコアをCに書き換えて使うのもいいかな

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

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

>>51
だと思う
0054デフォルトの名無しさん2005/10/12(水) 12:39:48
GD
0055デフォルトの名無しさん2005/10/13(木) 22:43:43
1はとにかく手を動して、blogでも書いて経過を晒せ。
Monaの方はどんどん進んでるぞ。
ttp://wiki.monaos.org/index.php?gdc
0056デフォルトの名無しさん2005/10/14(金) 23:14:39
1はOSとか言う前にDは一通り使いこなせてるのか？
glExcessの移植程度のことはできるんだろうな？
0057デフォルトの名無しさん2005/10/15(土) 15:24:48
ま　た　ネ　タ　か　！　！
0058デフォルトの名無しさん2005/10/15(土) 16:19:21
個人的にはLISPかSchemeで今風のOS作ってみて欲しい。
0059デフォルトの名無しさん2005/10/17(月) 02:20:17
>>41
リングじゃ無くて特権レベル0〜3だな
簡単にいうとx86は68000系のようにユーザーモード/カーネルモードの切替が2段階じゃなくて、特権レベル0〜3までの4段階持てる
0060デフォルトの名無しさん2005/10/17(月) 08:12:49
その特権レベルの事をリングって言うんだよボケ
0061デフォルトの名無しさん2005/10/17(月) 19:31:34
ああ、あれか、経産婦が避妊に使うやつか。
0062デフォルトの名無しさん2005/10/18(火) 20:58:24
>>3
心配しなくてもC++でも使えないから
cc1plus: warning: command line option "-ffreestanding" is valid for C/ObjC but not for C++
006312005/10/26(水) 18:03:01
取り合えずage
0064デフォルトの名無しさん2005/10/26(水) 20:49:15
sageてるがな
0065デフォルトの名無しさん2005/12/11(日) 10:56:18
まったく進まんけどなんか期待
0066デフォルトの名無しさん2005/12/31(土) 21:22:07
保守
0067デフォルトの名無しさん2006/01/02(月) 18:28:49
D ver.0.100!!!
0068デフォルトの名無しさん2006/01/02(月) 21:39:21
全部Ｄで作ってこそ意味があるのでは？
0069デフォルトの名無しさん2006/01/07(土) 12:26:24
保守
0070デフォルトの名無しさん2006/01/15(日) 03:02:35
保守
0071デフォルトの名無しさん2006/01/15(日) 13:00:19
age
0072デフォルトの名無しさん2006/01/15(日) 17:00:32
発想が逆だ。言語はOSというソフトの仕様を満たすための手段だ。
始めに言語ありきで話を進めたら言語に縛られた貧相なものしか出来ないぞ。
まずOSの仕様を考えて、それを作るために言語を新たに作るぐらいで
なければいかんだろう。C言語だってそれで出来たんだしな。
0073デフォルトの名無しさん2006/01/15(日) 17:54:45
そう、C言語はUNIXを作るために生まれたんだ！
C++やJavaがいくら攻勢を見ようとも、未だに元祖Cが使われている理由がまさにこれ。
0074デフォルトの名無しさん2006/01/15(日) 19:53:57
これから作る新機能満載なOSにはそれを使えば簡単に書けるというような新たな言語が必要だ。
従来の殻を破るには根本から変えるしかない。第二の Linux や Windows を作りたいなら
それでもいいが、そんな車輪の発明は誰も欲しがらないだろう。もっと根底から考え直さねば
駄目だ。
0075デフォルトの名無しさん2006/01/15(日) 20:20:50
JavaはJavaVMを作るために作られた訳だが
0076デフォルトの名無しさん2006/01/15(日) 21:53:33
　　　　　　　　　　　　_,､-‐‐'ｰ- ､,_ヽ_
　　　　　　　　　　 ／ ,､ -‐ ''"´;:　;　ヽ
　　　　　　　　　 / ／ ,､‐''"´´　　;: ;;`ヽ
　　　　　　　　 /　(／　 ,､-‐''"´´　_,　,丶　　　　　　　　　 そおおおんあわけねええだろぉ？
　　　　　　　　 i　 (ゝ ／,　, ､ｰ''"､´ 　 _ヽ
　　　　　　　　 |　 /'''_ｰ-<___, -'´ lｰ''"ノ ヽ.　　, へ､ _
　　　　　　　　　､　'l { ｀ヽ;ｰ-､-,ｰ‐,r''1　; ;ヽ<''ﾍ　　ヽー---‐'''"""""
　　　　　　　　　 r､ iヽ　　ヽ'　｀'　　　.|､　　,. |　 |
　　　　　　　　　{λヽ.ヽ　　　　　　 ,,ｿ ヽ-' t' __ﾉ　　　,______
　　　　　　　　　＼ゝ､iヽｰ '`ー'''`1´　　　　 ~ヽ､､､／~　　　￣￣,~"＝
　　　､‐'''''ヽ　　　 ｀'ﾍ.',ヽ　　 , ､　{　　　　　　　　　　　　　　,､- '´　　　
　　/　　　　 ＼　　　 ヾ ヽ⌒ヽ ヽ {　　　　　　　, ‐､_　　 ／　　　　　　　
.　 |　　　　 　　 ゛‐-ｰ'.,!＼＼__　 ｀ヽ.　,､　　 ／　　　｀'´　　　　　　　　,
　　､　　　　　　　　/ / |　＼ ＼゛､ｰ'>' ﾉrｰ' ´　　　　| ,　　　　　　　／
　　r;　　　　　　　/ /　 |＼,_＼ ｀""´r''| ト､ 　　　　　| |　　　　　／
　　 ｉ　　　　　　　 /　　|　 　フ 丶､___ノヽ.　　　　　　|/　/　　／
　　ｒヽ＼　　 　　 (　　 | 　 ,ﾍ　　　| |　ヽ ＼　　　　 ‖/　／
0077デフォルトの名無しさん2006/01/21(土) 00:36:42
非チューリングマシンで動くOSきぼう
0078デフォルトの名無しさん2006/01/22(日) 16:58:25
このスレって、なにか成果があがることを期待していいんですか？
0079デフォルトの名無しさん2006/01/22(日) 21:24:24
D言語は当分完成しないみたいだからFreePascalで作って
0080デフォルトの名無しさん2006/01/24(火) 09:08:55
>>79
GCCにPASCALなかったっけ? あれじゃ駄目?
0081デフォルトの名無しさん2006/01/28(土) 20:12:04
やっぱりDだったのか。。。
0082デフォルトの名無しさん2006/02/15(水) 15:56:11
保守
0083デフォルトの名無しさん2006/02/21(火) 23:45:08
何故わざわざＤ言語なんだ？ｗｗｗｗｗ
0084デフォルトの名無しさん2006/04/09(日) 14:46:13
保守
0085デフォルトの名無しさん2006/04/12(水) 00:10:33
既存OSをD言語で作り変えることは、D言語の魅力/問題を洗い出すという目的において良い課題であると思うけどね。
0086デフォルトの名無しさん2006/04/12(水) 02:55:24
OSってどのレイヤーを指してるのかと思ったらカーネル作ろうっての？
マイクロカーネルなだけで遅いのにしかもD言語。
ライブラリ整備するほうが先でしょ
0087デフォルトの名無しさん2006/04/12(水) 12:32:20
ていうかDが1.0になるのが先ｗ
0088デフォルトの名無しさん2006/04/27(木) 23:31:49
>>1はどうした？
Dの悲惨な現状を知って（僕は知らないけど）にげたか？
0089デフォルトの名無しさん2006/07/18(火) 00:40:55
age
0090デフォルトの名無しさん2006/10/02(月) 23:09:35
hage
0091デフォルトの名無しさん2006/10/03(火) 00:38:09
CP/M ++ → DQ/N

DQN-OS
0092デフォルトの名無しさん2006/10/03(火) 05:03:10
すげー
0093デフォルトの名無しさん2006/10/04(水) 02:55:51
D言語は、1.0がリリースされるよりも早くMSが買い取るかも。
MS-D コンパイラってね。
手厚いMS印のサポートが期待できる。
0094デフォルトの名無しさん2006/10/04(水) 03:26:18
DotNETになるだけだろ
0095デフォルトの名無しさん2006/10/13(金) 01:36:30
IronD on .NET
0096デフォルトの名無しさん2006/10/14(土) 21:28:29
いきなりスケールのでかいスレタイでつね
0097FD2006/10/21(土) 16:18:40
Ｄ言語でＯＳ作成ですか？面白い課題だと思います。
クラスを使用しなければ、Ｃ言語を少し柔軟にした言語使用なので、極端難しくないです。
参考するなら、Ｃ言語で書かれたＯＳソースを、Ｄ言語のプリプロセッサ機能を削除したソースへ置き換えることからはじめるのですかね？

組み込みＯＳでは基本的にＣ＋＋特有な機能を使用しないのが一般的です。
コメントだけＣ＋＋で中身Ｃ言語と言うものをよく見かけましたが・・・
0098デフォルトの名無しさん2006/10/21(土) 17:20:41
あれじゃね？
C言語で書かれたソースをD言語に変換するツール作成すれば一発じゃね？
0099デフォルトの名無しさん2006/10/21(土) 20:00:57
>>97
> 組み込みＯＳでは基本的にＣ＋＋特有な機能を使用しない
組み込みだとサイズ/速度のオーバヘッドがデカいからじゃないかなあ。
0100FD2006/10/21(土) 20:45:20
>>99さん
それもありますが、ｎｅｗなどメモリのどこに配置されるか分からないので、メモリの制限された世界では使いにくいのです。
ＯＳカーネルになれば、メモリ管理はレガシーな方法とった方が安全だからです。
ただし、しっかりとメモリ管理された環境下であればＣ＋＋特有の機能は作る側に利点があると思います。
「しっかりとメモリ管理された環境」ですからカーネルの基本的な領域には適用しにくいです。
例えばＣ＋＋で記述されたというL4Ka-Pistachioのソースを参照すると、
ＡＰＩの領域（外向きの顔）はＣ＋＋ポイですが、内部制御はＣ＋＋と言うよりＣ言語です。
Ｃ＋＋の仕様自体にＣ言語仕様を含んでいるから当然なんでしょうけど・・・

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

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

なお、Ｄ言語でもいいですけど、日本でカーネルを再勉強できる機会は少ないです。
ＯＳを作ると言う企画は面白いと思います。
まずは、簡単な部分から作らないといけませんね。
私も個人的に勉強したい領域です。
0101デフォルトの名無しさん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/
0102デフォルトの名無しさん2007/01/09(火) 06:23:10
がんばれ
0103デフォルトの名無しさん2007/01/11(木) 12:13:59
>>101
組込みはメモリの動的管理自体をやらないやつらが多い。
あらかじめ最大値を決めてそのサイズ分確保してる。
0104デフォルトの名無しさん2007/01/12(金) 00:46:07
組み込みの場合、何よりも「落ちないことが保障できる」ことが重要だからな。
0105デフォルトの名無しさん2007/04/30(月) 11:25:28
さらに言うと

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

だよな
0106デフォルトの名無しさん2007/06/29(金) 16:04:05
つーか組み込みは、やる事決まってるからだろ
0107デフォルトの名無しさん2007/07/11(水) 23:37:40
MoNaじゃなくてBSDをDで再実装なら協力する。
0108デフォルトの名無しさん2007/07/11(水) 23:47:03
>>101
ガベコレの問題が有って、今のガベコレ言語は、

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

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

OSのメモリ管理＝D言語のメモリ管理という部分を設計してしまう必要が有るわけ。
手を抜こうと思えば、抜けるけども。
0109デフォルトの名無しさん2007/08/26(日) 07:07:10
/
0110デフォルトの名無しさん2007/08/26(日) 08:06:04
これって実は言語とかは全然関係なくて、
GC用ヒープがシステムメモリとして何百メガか確保されるだけでは？
ただ、これだとアルゴリズムがコンカレントGCしか選択できないな。
0111デフォルトの名無しさん2007/09/06(木) 22:17:18
age
0112デフォルトの名無しさん2007/09/11(火) 22:09:02
今のGCって論理アドレス空間で整頓してるんだよね？
カーネルだと物理アドレス空間を触ることになると思うんだけど、
そっちだとより効率的にメモリを整頓できたりするの？
0113デフォルトの名無しさん2007/09/16(日) 15:24:08
むしろ、このマルチコア時代には、１CPUを丸々メモリ管理に割り当ててもいいんじゃないかと思ってる。
0114デフォルトの名無しさん2007/09/18(火) 00:36:29
>>113
それだとキャッシュ効率が悪過ぎる
0115デフォルトの名無しさん2007/09/23(日) 12:49:14
>>62
初めて来たけどこれObjC組み込めるのか？
期待age
0116デフォルトの名無しさん2007/09/23(日) 12:50:31
sageてしまったorz
0117デフォルトの名無しさん2007/12/05(水) 21:40:57
保守
0118デフォルトの名無しさん2007/12/05(水) 22:05:50
そういや任天堂がC++のOS作ってたね。ライセンスは知らんが成果も発表してた気が。
任天堂なら作れるかも
0119デフォルトの名無しさん2007/12/13(木) 09:36:12
C++のOSって既にあった気がするんだが
0120デフォルトの名無しさん2007/12/13(木) 09:56:32
まさか Mona とか
0121デフォルトの名無しさん2007/12/13(木) 09:59:43
実装は知らんがインターフェースがC++だったのはBeOS
0122デフォルトの名無しさん2007/12/13(木) 15:55:27
Nintendo esだろ
01231192008/01/07(月) 14:54:13
>121
ああそれそれ。あくまでインターフェイスの話なのか、あれ。



ところで D で TRON ってどうよ、とかいう無茶振りをしてみるテスツ
0124デフォルトの名無しさん2008/01/07(月) 20:34:20
今更使い道はないんじゃない？
TRONの需用自体がITRONくらいで、そこにGCはヘビーかと。
0125デフォルトの名無しさん2008/01/07(月) 21:39:57
携帯でも Java なんだから gc がヘビーってこともない機器もあるかも
0126デフォルトの名無しさん2008/01/07(月) 22:19:55
そこであえて超漢字を
0127デフォルトの名無しさん2008/01/09(水) 03:30:00
携帯の Java は PC みたいに軽くないので、昔のBasicみたいにクラス作らないでかく
0128デフォルトの名無しさん2008/01/09(水) 21:18:23
Basicを引きあいに出さなくてもＣでいいんじゃね？
0129デフォルトの名無しさん2008/03/08(土) 10:53:23
>>125
そうでもない。
最近の携帯は、かなり軽いよ。

今、携帯Java（MIDP2.0）上でJavaベースのOS作ってるよ。
うまく行けば、このOSの上にJava2SE実装して、パソコン用のソフトも使えるようにしたいな。
0130デフォルトの名無しさん2008/03/08(土) 13:36:06
http://www.geocities.jp/tor_park/Dlang/byte.html
0131デフォルトの名無しさん2008/04/15(火) 13:15:53
結局OS作れませんでしたスレか
0132デフォルトの名無しさん2008/12/06(土) 21:15:42
http://extjs.com/deploy/dev/examples/desktop/desktop.html [extjs.com] こういうのは？
0133デフォルトの名無しさん2009/01/20(火) 01:22:36
http://pc11.2ch.net/test/read.cgi/cg/1046440380/116
0134デフォルトの名無しさん2009/07/21(火) 17:53:46
D言語ってガーベージコレクションもってるよね。
これって、どう動くかと言えば

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

でも、これを

　＜＝＝＝＝メモリ＝＝＝＞　＜＝＝＝＝メモリ＝＝＝＞
　アプリケーション1　　　　　　アプリケーション2
　　　　　　　　　　　　↑↓
　　　　　　OS+カーネルが各アプリのガベコレを制御
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
　　　　　　　　　　　実メモリー
ということになれば、マルチスレッド、マルチコア、マルチキャッシュの
cpuでのパフォーマンス的にも色々と行けるような気がするのね。
もうね、まったく新しいosというレベル。
目指すならここを目指すべきだと思う。
0135デフォルトの名無しさん2009/07/24(金) 20:19:35
D言語の中の人の主張はそれだけどね。
何で俺が言語にＧＣを実装しなきゃいけないんだって人。
0136デフォルトの名無しさん2009/08/01(土) 22:01:04
D用のGUI・画像・ファイル処理系のライブラリが充実されたら手を出してやる
0137デフォルトの名無しさん2009/08/01(土) 23:22:16
C用のGUI・画像・ファイル処理系のライブラリが充実してる
0138デフォルトの名無しさん2009/08/10(月) 12:49:13
age
0139デフォルトの名無しさん2009/08/11(火) 12:41:47
プロセスを作成したらヒープを作成して、
システムコールを呼んだら、ヒープ内にメモリブロックを確保したり解放したりして、
プロセスが終わったら、ヒープを解放する。
0140デフォルトの名無しさん2009/08/11(火) 13:48:50
それから動的にメモリを確保するときにシステムコールを呼ぶように、D言語自体を書き換えすることが必要。
0141デフォルトの名無しさん2009/08/11(火) 14:11:54
>>140
お前D言語のこと何も知らずに書いてるだろ
言語自体なんか書き換えなくてもPhobosの書き換えで済む
0142デフォルトの名無しさん2009/08/11(火) 20:35:06
>>140
メモリ確保ごとにシステムコールってどんなネタだよ
0143デフォルトの名無しさん2009/08/27(木) 18:55:58
Schemeってガーベージコレクションもってるよね。
これって、どう動くかと言えば

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

でも、これを

　＜＝＝＝＝メモリ＝＝＝＞　＜＝＝＝＝メモリ＝＝＝＞
　アプリケーション1　　　　　　アプリケーション2
　　　　　　　　　　　　↑↓
　　　　　　OS+カーネルが各アプリのガベコレを制御
＜■■■■■■■■■■■■■■■■■■■■■■■■■■■＞
　　　　　　　　　　　実メモリー
ということになれば、マルチスレッド、マルチコア、マルチキャッシュの
cpuでのパフォーマンス的にも色々と行けるような気がするのね。
もうね、まったく新しいosというレベル。
目指すならここを目指すべきだと思う。
0144デフォルトの名無しさん2010/02/15(月) 06:12:15
GikoOS
■ このスレッドは過去ログ倉庫に格納されています