【次世代言語】D言語� ..
2:デフォルトの名無しさん
05/10/09 03:06:14
>>2
華麗に 2get
3:デフォルトの名無しさん
05/10/09 03:35:34
Bochs
URLﾘﾝｸ(bochs.sourceforge.net)
Higepos(Monaの古いコード?)
URLﾘﾝｸ(cvs.sourceforge.jp)
リンカオプション
URLﾘﾝｸ(pc3.2ch.net)
678～
>ld -Ttext 0x100000 --oformat binary -o
>ld -o xxx -Ttext 0x0 -e main xxxx.o
コンパイラオプション
URLﾘﾝｸ(pc3.2ch.net)
>gcc -c -ffreestanding -Wall kernel.c
>strip --output-target=binary kernel.o
D言語に-ffreestanding相当の物はあるのか?
まぁ無くてもC言語でD言語のD_main辺りを呼ぶブリッジを作成すれば出来そう。
4:デフォルトの名無しさん
05/10/09 03:39:38
D自体微妙なのに。
5:デフォルトの名無しさん
05/10/09 03:57:44
微妙なの？
6:デフォルトの名無しさん
05/10/09 04:07:00
リンカの順序について
URLﾘﾝｸ(pc3.2ch.net)
100辺り～
>リンカスクリプトで、コードセグメントを先頭に持っていく
C++のnew/deleteについて
URLﾘﾝｸ(pc3.2ch.net)
157～
D言語の場合…メモリ管理部分がどうなるんだろう…?
メモリ管理部分を先に実装し後はクラス/GCを使っていきたいけどDコンパイラがどの程度依存してるのかその辺が分からない。
>>4-5
微妙ではないけどC言語との互換性の面からあまり使われていない。
C#やJAVAのネイティブ版って感じ。
7:デフォルトの名無しさん
05/10/09 04:11:01
Phobosをどこで動かすんだろう
8:デフォルトの名無しさん
05/10/09 04:20:53
ふむぅ…
アセンブラなりCなりC++なりで書かれたマイクロカーネルなOSをベースにサブシステムをD言語で作るというのが現実的っぽい。(ってよりも個人的にそれで満足だけど)
どのマイクロカーネルを元にするのがいいか、その場合のDコンパイラやPhobosをどのぐらいごにょる必要があるかを考えた方がいいのかな。
9:デフォルトの名無しさん
05/10/09 04:22:46
そういや、最近触ってなかったんだけど、D言語って仕様は安定したの？
（まだ正式版（１．０）もリリースされていないみたいだけどさ）
10:デフォルトの名無しさん
05/10/09 04:24:44
普及してないだけか。
11:デフォルトの名無しさん
05/10/09 04:36:38
所詮ｼｪｱｳｪｱ厨のｵﾅﾆｰ言語ですから
12:デフォルトの名無しさん
05/10/09 04:50:38
マイクロカーネルで有名な物はMachとL4があると。
L4をベースにして見たいけどまだ検討中。
13:デフォルトの名無しさん
05/10/09 05:00:17
VB6しかやったことないけど、おれも協力するよ！
14:デフォルトの名無しさん
05/10/09 05:02:50
>>13
D言語とcygwinが使えるなら大歓迎さ！
15:デフォルトの名無しさん
05/10/09 05:17:50
サービスをユーザーモードで走らせるかカーネルモードで走らせるか
ユーザーモードだとスピードが落ちるらしい。
カーネルモードはメモリ保護機構がないため危険。
だけどD言語だったらサービス自体もカーネルモードで大丈夫な気がする。(変な事しなければいいんだし…)
後はソースを見てどこからとっかかる and 調べるかだな…
16:デフォルトの名無しさん
05/10/09 08:27:29
OSがGCを実装してアプリはメモリ使いまくりがDの理想らしいじゃん
OSがGCサポートしてればDはいらん
17:13
05/10/09 10:23:51
>>14
VBしかできねーっていってんだろ。なめてんのか、あぁ？
18:デフォルトの名無しさん
05/10/09 11:20:45
VBでOS？
19:デフォルトの名無しさん
05/10/09 12:31:09
VBでVBのコンパイラを書いて、VBで出来たカーネルコードを(ry
20:13
05/10/09 12:36:43
>>19
うっせーばーか
ウシャシャシャシャシャ
21:デフォルトの名無しさん
05/10/09 14:26:27
とりあえず何を作るの？
22:デフォルトの名無しさん
05/10/09 14:44:40
100 REM BASIC ﾃﾞ OS
110 PRINT "KawaisOS Ver.-1 (´・ω・)"
120 INPUT "C> "; A$
130 PRINT "コマンドまたはファイル名が違います."
140 GOTO 120
23:デフォルトの名無しさん
05/10/09 15:40:20
>>21
1.GCを動くようにする
2.D言語で下位互換性無視してクラスでいろいろ実装
ってかマイクロカーネルを使ってモノリシックカーネルを作ればGCも簡単に動くであろう…と思うんだけど
後、プログラムが動く上で必要なGCは一つだけなんだから(ry
取り合えず暇な時にマイクロカーネルのソースを読もうと思います。
24:デフォルトの名無しさん
05/10/09 17:25:14
ひげぽんは最初JavaでOSを作ろうとしたみたいだよ。
今頃になってJavaをネイティブコンパイルしてMonaを書き換える動きが出てきたけど
ひげぽんは興味がないみたいだね。
25:デフォルトの名無しさん
05/10/09 17:26:33
>>11
それはひげぽんが師匠と仰ぐ屋根裏のことか？
26:デフォルトの名無しさん
05/10/09 17:44:12
>>19
絵空事前提で書いてるみたいだけどやろうと思えばできることだから。
URLﾘﾝｸ(nienie.com)
27:デフォルトの名無しさん
05/10/09 20:37:45
最終的に機械語なりアセンブリ言語なりを吐くことさえできれば、
何のプログラミング言語でも*理論上*は可能。
28:デフォルトの名無しさん
05/10/09 21:17:48
作成する本人に言語処理系を作成する能力があれば、普通にどんな言語でも出来るだろ。
HSP、なでしこ、その他何でもＯＫだろ。
29:デフォルトの名無しさん
05/10/09 21:30:59
MonaOSを移植するの？
それとも、完全オリジナルのOSを造るの？
30:デフォルトの名無しさん
05/10/09 22:24:51
>>27
ダウト
31:デフォルトの名無しさん
05/10/09 23:00:10
言い方が悪かったな。
極論すればファイル入出力と文字列処理ができる言語であれば良い。
32:デフォルトの名無しさん
05/10/10 03:04:31
D言語いいんだけど、>>9が言うように正式版が無いってのが不安。
処理系の変化にどこまで追従するのか。
GCとスレッド周りの扱いさえ決めれば問題無く使えると思うよ。
33:デフォルトの名無しさん
05/10/10 12:41:28
俺が新しい言語Φを作ろうと思っているんだが誰か乗らないか？
34:デフォルトの名無しさん
05/10/10 12:59:08
>>33
まんこ？
35:デフォルトの名無しさん
05/10/10 13:10:32
>>15
ここでいっその事x86アーキテクチャ全開でリング１～リング４を使い切るというのはどうだ？
36:デフォルトの名無しさん
05/10/10 13:23:53
Dで作ったOS
↓
D+OS
↓
DOS
37:デフォルトの名無しさん
05/10/10 14:37:39
どうせならマルチCPUを使い切る言語きぼんぬ
38:デフォルトの名無しさん
05/10/10 15:18:22
とりあえず>>1はトリップつけて、サイトを立ち上げてくらはい。
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というレベル。
目指すならここを目指すべきだと思う。
最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5385日前に更新/31 KB
担当:undef