1 :
Be名無しさん :
04/02/08 14:00
2ゲットー
monaもついにプログラミング自体の話からOS設計に軸足が移せるようになったのか。 すげえなぁ。 ブートプログラムの作成とかアセンブラの勉強以前から話が始まったからじゃないかな。 OSを作るにはどんなプログラミング作業が必要なのかわかっていなかった。 OSの設計うんぬんよりもまずガチガチのコーディング作業の道筋を知ること自体が主目的だったみたいな。 part2あたりから見るとわかるかも。 #ちなみに俺もOS作ろうとしてたのにひげぽんにあっさり追い抜かれたクチです #secondブートあたりまでは勝ってたのに 。゚・(ノД`)・゚。
お久しぶりです。今年もよろしくお願いいたします。 私に至らない点がある&説明不足であるために皆様に ご迷惑をおかけしているようで申し訳ないです。 年始の計画もかねてまとめてみました。 今後のMonaの開発の流れ(1-2月) 1月 Thread対応によるカーネルの大幅リライト(スレッド・ページング・システムコール・共有ページ等) 2月 ドライバインタフェース設計・試験実装&スレッドユーティリティ実装(Mutexなど・・) 今後のMonaの流れと方針 当分の間、ユーザープログラム・アプリケーションでバリバリ遊べるという環境は用意できません。 理由はカーネルがあまりに貧弱だからです。カーネルの設計・実装に時間を注ぎます。 もちろんユーザープログラム・アプリケーションに関するご提案や、カーネルを改良したなどありましたら 是非お寄せください。 またDOSのようにシングルタスクでもいいから遊べるものをというご意見も理解できるのですが 現状の力量ではMona以外に更にプロジェクトを抱えるのは不可能なのでご理解いただけると助かります。
Mona PJメンバーについて Monaには過去在籍したメンバーも含めて以下のような種類の方々がいます。 1.過去にコードを提供して下さったが現在は本業が忙しいためアドバイザーのような立場の方。 2.やる気があり参加したが、即貢献できないので勉強中の方。 3.Wikiでアドバイスをくれる方 4.2だったがフェードアウト気味の方。 5.カーネルにある機能が実装されればすぐに参加できる人(ひげぽん実装待ちの人) 6.行方不明の方。 2, 4, 6あたりの方々へのフォローが足りなかったのはひげぽんの責任であり。 今後のPJ運営の反省材料として生かしていきたいと思います。 今後どのようなメンバーに参加していただきたいか? カーネルの一部・ドライバを書けるまたは、設計できる。 ハードの仕様に詳しい方。 カーネルの設計にWikiやosdev-jで相談にのっていただける方。 以上、長くなりましたが少しでも誤解がとけてよりよいOSが開発できればと考えています。
MonaをDOSのように遊べるOSにするということについては、 Monaはマイクロカーネルのマルチタスクを目指しており その設計と実装がたのしいということが OS作りの動機の中核となっていますので難しいです。 ※現在Monaはユーザーライブラリ整備に軸足を移しつつあります。
今日(※2003.01.06)は以下の作業を行いました。 Mona開発環境@Linuxの作業 gcc3.2.2のビルド・インストール nasmのビルドインストール monaのビルドができるようになりました。 SDLのインストール qemuのインストール Mona@qemuを実行(Mona Loadingで止まる模様) Thread対応 プロセス追加・プロセススケジュールの実装とテスト プロセススケジュールは実際のタスクスイッチではないので ほぼ実装完了。 明日はスレッドスケジューリングと簡単なスレッドの実行までいければ・・・
ふむ。qemu一応使えたのか。
>>7 ウソダァァァァァァァァァァァァァァァァァァァァァァァィイ!
俺のRHL9ではビルドできないyo.
つーことで、バイナリスナップショットも配布きぼん。
>>8 qemuは暇を見てCVS板(FDC対応済み)のものを試してみようと思います。
>>9 >
http://mona.sourceforge.jp/トップが全然更新されてないのってあまり感じよくないね 。死んでるように思われちゃう
確かにおっしゃる通りですねぇ。最近はリリース毎に更新していたのですが
リリースがなかなか出来ないため滞っています。
これも暇を見て更新いたします。
>>10 > 俺のRHL9ではビルドできないyo.
> つーことで、バイナリスナップショットも配布きぼん。
./configure
make
でいけませんでしたか。
バイナリスナップショットですが現在開発中の物は
カーネルリライト中なので全く動きませんのであまり意味がないかと思います。
ld -n -Ttext 0xA0000000 -e _user_start -static hello.o userlib.o MemoryManager.o -o ../bin/USER.ELF ld: warning: cannot find entry symbol _user_start; defaulting to a0000000 userlib.o(.text+0x1f7): In function `__static_initialization_and_destruction_0': user/userlib.cpp:16: undefined reference to `__dso_handle' userlib.o(.text+0x203):user/userlib.cpp:16: undefined reference to `__cxa_atexit' make: *** [../bin/USER.ELF] エラー 1 RHL9
>>12 gcc --versionした場合のバージョンを教えていただけないでしょうか。
gcc2.9x系ではビルドできないのでそれが原因かもしれません。
>>12 Linuxでgccを使った場合、
エントリポイントについては、_user_startの先頭の_がいらないっぽい。
残りは、Kernelソースのpurevirtual.cppの中から、該当関数を持ってきてリンクすれば、一応、通る。
それが、正しく動くUSER.ELFになっているかは知らないけど。
Win上でCygwinやMingwで出したバイナリとLinux上のgccの吐き出すバイナリをそれぞれobjdumpで表示してみると
違いが見れるよ。
現在(※2004.01.09)の状況は以下の感じです。
スレッド対応が徐々に進み、少しずつ動作するようになって来ました。
現在MemoryManagerのバグ゙をつぶしています。
ttp://wiki.osdev.info/index.php?%5B%5BScreenShot%2FMona%5D%5D スレッドの対応をしていて感じた事ですが以前STLをカーネルに
導入していたことがありました。
そのときはカーネルがあまりに貧弱で(今でもそうですが)
特にメモリの割り当て解放の処理が怪しかったためSTLの
使用をなくなく一時中断することを決意しました。
カーネルを書いているといわゆるコレクション(コンテナ?)
が欲しいと思うところがたくさんあります。
ex)
スレッドのディスパッチキュー
メッセージキュー
共有ページ管理
その部分について今まで以下のような順で アプローチを取ってきました。 1.STLのコンテナ 2.BSD系フリーUNIXのqueue.h系(侵入的データ構造) Interface 2004 2月号Chapter4参照 3.2の改良版で格納対象のオブジェクトをQueueクラスの 継承クラスにする方法(場合によっては多重継承になる) 4.自前テンプレートコレクションクラスHList, BinaryTree, HashMap スレッド対応のついでに3⇒4から移行したのですが 私の感覚からすると実装が少し楽になりました。(実際の処理が早くなるかは別として) 教訓としてカーネルを書くにはいわゆるコレクションライブラリも 整えなければいけないことを痛感しました。 ただし自前コレクションライブラリにはメリット・デメリットがあります。 デメリット 1.信頼性の問題(STLに比べれば信頼性が低い場合もある) 2.速度の問題(実際に計ったわけではありませんが) メリット 動的にメモリを確保している場合、そのポイントと確保量が明確であること STLなどは自分で書いたものでないのでどこでメモリがいくら確保それ解放されるかを 気にしなければいけない場合もあります。(カーネル内で使用するので)
Monaでは1のデメリットに関してはがんばる(笑)、2に関しては今は目をつぶるが 後々すぐに入れ替えれることが出来るように一枚インターフェースをかます方法をとっています。 だらだらと書いてしまいましたが、もしこれからOSを書く方がいれば参考になれば幸いです。
>>16 なぜSTLとAPIコンパチにして後々簡単に入れ替えられるようにしとかないの?
使う機能だけでいいのでクラスと関数の名前を同じにするだけなので別に難しいことではない。
これをやった方が良い理由は2つある。
1つ目は他人が使うときの便宜。
広く知られているものに似ていれば使いやすいのは当然。
2つ目はテストの便。
昔、VC++6.0付属のSTLをバリバリに使いまくってアプリを作ったら、
なぜかメモリリークしまくりでしばらく放置するとスワップが溢れるアプリが出来てしまった。
コードをチェックしてもさっぱり原因が分からなかったんだよ。
ところが同じものをmingwでコンパイルしたらリークしなかった。
どうやらVC++6.0付属のSTLのバグらしい。
そこでSTLportに差し替えてみたところVC++6.0でもリークしなくなった。
つまりUnitTestなどをSTLと独自実装と両方でやることでバグが見付けやすくなる。
これ自体はカーネルと関係ないのでCygwin上だけでも出来ること。
>>18 貴重な資料ありがとうございます。
ローカルに保存して目を通します。
またPITに関してはOSASK Kさんからもアドバイスを頂きました。
この場を借りてお礼を申し上げます。
>>20 なるほど。
STLのヘッダをみて各コンテナの定義等を参照するして
あらたに同名クラス・関数を実装するということですね。
手間でなければやる価値があると思いました。
・頂いたアドバイスを元にタイマの間隔設定関数を作成しました。 ・スレッド化の山場loadProcess(ユーザーモード)が動きました。 ・スレッド作成がユーザーモードからも出来るように一部のAPIを作成しました。 ロック機構のみ作成・セキュリティの問題・スレッド操作インターフェースがされていない など問題は山積みですが以下のようなユーザープログラムUSER.ELFをカーネルから ロードできるようになりました。 簡単なシェルも作成できるかと思います。(都合上ドライバインタフェースの実装が先になりますが) #include <userlib.h> int listener(); int disp(); static char buf[32]; static bool come; int main() { dword id; if (!(id = mthread_create((dword)listener))) { print("mthread create error\n"); exit(-1); } if (mthread_join(id)) { print("mthread join error\n"); exit(-1); } disp(); }
int disp() { for (;;) { if (come) { print(buf); buf[0] = '0'; come = false; } } } int listener() { Message message; for (;;) { if (!_receive(&message)) { buf[0] = '<'; buf[1] = (char)message.arg1; buf[2] = '>'; buf[3] = '\0'; come = true; } } }
>>23 >if (!_receive(&message)) {
だ・か・ら、message.receive()にしろって。
クラスに属さない関数は作るな。
文字列をchar*で扱うな。
メモリ管理部以外でポインタを配列で使うんじゃねーって。
ソース眺めてて気付いたんだけど、これっておかしくない? void ProcessManager::wakeup() { dword tick = getTick(); for (dword i = 0; i < waitList_->size(); i++) { Process* process = waitList_->get(i); if (process->getWakeupTimer() < tick) { dispatchList_->add(process); waitList_->remove(process); } } }
気になるところは大体読んでみた。 取り敢えず言いたいのは「まずは定石を学ぶべき」という事。 ソース奇麗でスジは良いと思うけど、とにかくカーネルの設計・実装におけるセオリーを知らなさ過ぎる。 そのくせマイクロカーネルだとかスレッドだとかいうのは無茶過ぎる。 今からでも遅くないから他のカーネルを勉強してみるのをオススメします。マジで。
>>26 > ソース眺めてて気付いたんだけど、これっておかしくない?
実装ほやほやでテストも満足に出来ていなくて申し訳ないのですが
どこがおかしいでしょうか?
>>27 > そのくせマイクロカーネルだとかスレッドだとかいうのは無茶過ぎる。
> 今からでも遅くないから他のカーネルを勉強してみるのをオススメします。マジで。
貴重なご意見ありがとうございます。
具体的にどのような点で上記強く感じられましたでしょうか?
>>27 セオリー通り作れば確かに変なところで躓いたりしないが、それで面白いか?
他のヤシはどう思うかわからんが、漏れはつまらん。
一般には成功している流行の手法に、基づいているのだから、
一方的にそれを認めないのはいかがなものか?
実際ソースが読みやすいという部分はこれのお陰だしな。
>>28 > どこがおかしいでしょうか?
waitListに入っている全てのプロセスについて起床すべきかどうかを調べて、
起床すべきであればwaitListから削除することを意図したコードだろうけど、
あるプロセスがwaitListから削除されたとき、
waitListでそのプロセスの次に入っていたプロセスはとばされる事に成ると思われ。
> 具体的にどのような点で上記強く感じられましたでしょうか?
例えばシステムコールが割り込み禁止で実行されてころとか。
>>29 セオリーを押さえた上で独自の工夫をするのが面白いと思うんだが。
>>31 上記のページを見た感想ですが、
カーネル内における同期の方法などもっと検討しなければいけないのではないでしょうか。
例えばいまのところ見た感じカーネルはプリエンプト可能のようですが、
カーネル内のデータ構造をどうやって保護するのかとか。
それと、タイマ割り込み以外でもプロセススイッチが起こる方が自然です
(今のところビジーウェイトで同期を取っているようですが)。
割り込みとシステムコールの同期も大きな問題です。
こういうところはカーネルの根幹ですから、
もうすこし検証を重ねる必要があると思います。
そのためにももう少し定石を学んでみるのも良いのでは?とわたしなどは思ってしまうわけです。
現状楽しんでやっているのであれば、とやかく言う事でもないのですが、
定石がわかればもっと楽しくなるかも、という可能性もちょっと考えていただければ幸いです。
>>32 > こういうところはカーネルの根幹ですから、
> もうすこし検証を重ねる必要があると思います
全く持っておっしゃるとおりです。
うすうす気づいていたのですがずばり指摘されて
重大さに気づいた次第です。(特にカーネルデータ構造保護)
> そのためにももう少し定石を学んでみるのも良いのでは?とわたしなどは思ってしまうわけです。
> 現状楽しんでやっているのであれば、とやかく言う事でもないのですが、
> 定石がわかればもっと楽しくなるかも、という可能性もちょっと考えていただければ幸いです。
カーネル(しょぼいですが)を作っているものとして508さんのOS関係の知識・経験が
私よりはるかに勝っていることは頂いたアドバイスの内容からも感じられました。
そういった方からのアドバイスは大変貴重で非常に参考になります。
本当にありがとうございます。
実際問題、定石はどのように学ぶかが最近の悩みどころであったりします。
ここ1年ほどは他のOSのソースをほとんど見ないように心がけていました。
どうしても読んだソースと似たようなものしか書けなくなるからです。
(一度方法を知ってしまうと自分で考えなくなる性格のようです。)
ソースを見ない代わりにAPIドキュメント等を読んで中身の実装は自分で
考えるなどしています。
508さんは定石はどのように学ばれたのでしょうか?
ソースを読む?実際にOSを作る等。
MIT/X採用は偉いけど、こういうときに困るね。
>>33-34 必ずしもソースを見る必要はないです。
OS関連に限ったことではないですが、機能的にどのように変わっているかを把握することがポイントかと。
めったに変わらない部分、すぐに変わる部分。その理由。
チューニングなど、実装的な面だとソースを読む事も必要かもしれませんけどね。
>>35 > 必ずしもソースを見る必要はないです。
ソース以外ではどのような情報源で情報を取得されていらっしゃるのでしょうか?
実際にそのOSを使ってみてプログラマの立場(APIを使うものの立場)からみる。
OSの設計の書籍(ex Solarisインターナル)や、Webで公開されているドキュメントでしょうか。
MINIX本とか。 古いかな…
Webで見つけるなら、論文やプロジェクトの成果報告、公開仕様書など 大学系のものがころがってる。ほとんど英語だけど。 ぐぐるなら、filetype:pdf をつけると、結構みつけやすい。世の中便利になったものだ。
>>37 MINIX本は基礎的なことを学ぶのに役立ちました。
排他とかページングアルゴリズムとか。
>>38 filetype:pdfは知りませんでした。
ありがとうございます。
日本語の研究成果資料なら多少読んだことがあります。
>>33 わたしの場合は、本とソース読みと自作が平行していました。
本やLinuxや*BSDのソースから得られた知識を自作カーネルで試してみたり、
カーネルを自作する過程で出てきた疑問点を本やソースで解消したりといった感じでした。
ソースを見る事によって影響されてしまうのを心配していらっしゃるようですが、
個人的にはそれほど心配する事も無いように思います。
私の習作カーネルの場合、もちろん細かいところで似てしまう事も多々ありましたが、
ソースの雰囲気や具体的なアルゴリズム、全体としてのアーキテクチャ(無謀にもマイクロカーネル風!!)などは、
参考にしたLinuxや*BSDとは似ても似つかないものとなり、
十分独自色が出ていたと思っています。
ま、どうするかは最終的には個人の問題ですけどね。
ひげぽんさんにとって一番良い方法を見つけて、
それで楽しくプログラミングできるのが一番ですから。
>>41 パレットの設定を I/O で叩くのではなくて、プロテクトモードインターフェースを使用したらどうだろうか?
>>42 ありがとうございます。
現在プロテクトモードインターフェース勉強中です。
vbe3.pdfやVBE2.0の資料を斜め読みましたが
コードがないとつらいですねぇ。
>>44 > 相変わらずプロテクトモードインターフェースの資料が見つからないですねぇ。
Linux kernel ソースのdrivers/video/vesafb.c が参考にならんか?
>>45 ありがとうございます。
まだ少ししか読んでみていないですがどうやらそれっぽいですね。
1歩進みました。ありがとうございます。
800 * 600の画面サイズに対応したり、jpegが表示できたりといろいろと 有志の方のコードに大変助かっています。 そろそろユーザー側APIの整備をしなくてはならないと考えています。 割とカーネル側に機能が追加されてきているのに対して ユーザーアプリがそれを使うことが出来ないのは無駄なので。 ただこれはドライバインターフェースにも関わるところなので 設計が難しいですねぇ
ユーザーアプリ環境構築・ドライバインターフェースの検討の第一弾として キーボードドライバのユーザーモードへの追い出しをしています。 キーボードドライバの役割はキーのscancodeを実際のキー情報に分解して キー情報を欲しがっているプロセスにそれを送信するイメージです。 (キー情報を扱うサーバのようなイメージ) 処理事態はカーネルモードでなくても動くものなので追い出しは割りと簡単かと ふんでいましたが。そうでもないようです。。。 以下困ったこと (1)KeyBoardManagerのメンバ変数(キー情報配列) const int []が初期化されて いなかった。本来であれば'a' 'b'などが入るべきなのに全部ゼロだった。 ⇒ elfローダーでelfセクションのmemory上のサイズとファイル上のサイズが 等しくないものはゼロクリアすべきと思っていてその領域をゼロクリア していたのが原因??? (2)keyInfoList_->add(kinfo);時にNULLポインタアクセスを起こす。 ⇒原因調査中。 簡単な「hello world」よりも少し複雑になっただけで潜在的な バグが見えてきました。どうもELFローダー周りが怪しいです。
キーボードドライバのユーザーモードへの追い出しが成功しました。 キーボードサーバの機能をもう少し洗練する必要がありますが ひとまず動きました!! 原因:elfプログラムセクションのmemorySizeとfileSizeが異なる場合に (誤)その領域をmemorySize分ゼロクリアしていた(bssセクション) (正)memorySizeがゼロ以上のときはメモリにロードする
キーボードサーバーはユーザープログラム開発環境でコンパイル・リンクされます。 /src/user/KeyBoardServer.cppがソースファイルになります。 その後makeとすると。 /bin/KEYBDMNG.SVRというELF形式の実行ファイルが作成されます。 こいつを /tools/fat_write.exeで mona.imgに書き込みます。詳細は/src/Makefile参照 こいつをカーネルのどこかから。 loadProcess(".", "KEYBDMNG.SVR", true); 3つ目の引数=trueだとユーザーモードプロセスになります。 として読み込むとサーバーが起動されます。 以下キーボードサーバーのソースを張ります。 長くなりますが現在のMonaでどの程度のプログラムなら 動くかという参考になれば幸いです。
int main() { /* initilize KeyBoardManager */ KeyBoardManager* manager = new KeyBoardManager(); manager->init(); /* initilize destination list */ List<char*>* destList = new HList<char*>(); /* Message loop */ for (;;) { MessageInfo info; /* receive */ if (!Message::receive(&info)) { switch(info.header) { case MSG_KEY_SCANCODE: sendKeyInformation(manager, destList, &info); break; case MSG_KEY_REGIST_TO_SERVER: regist(destList, &info); break; default: /* igonore this message */ break; } } } }
int sendKeyInformation(KeyBoardManager* manager, List<char*>* destList, MessageInfo* info) { MessageInfo message; KeyInfo keyinfo; /* scan code to key information */ byte scancode = info->arg1; manager->setKeyScanCode(scancode); manager->getKeyInfo(&keyinfo); /* create message */ memset(&message, 0, sizeof(MessageInfo)); message.arg1 = keyinfo.keycode; message.arg2 = keyinfo.modifiers; /* send message */ for (int i = destList->size() - 1; i >= 0; i--) { if (Message::send(destList->get(i), &message)) { printf("send error to %s", destList->get(i)); destList->removeAt(i); } } return 0; }
int regist(List<char*>* destList, MessageInfo* info) { char* source = (char*)(info->arg1); printf("message is %s", source); char* target = new char[strlen(source) + 1]; strcpy(target, source); destList->add(target); return 0; } ただこれを書いていて前から気になっていたことが やはりまずいことが分かりました。 sendのあて先はchar*だと全然ダメです。 やはりポートがよいですかね。
>>53 は
プロセス名からpidをlookupするサービスを作って解決しました。
ユーザーモード用に描画の仕組みを用意しました。
APIはC++で用意されていて、cygwinがインストールされていれば
プログラミングが可能です。
今現在下記のようなプログラムが実際にディスクから読み込まれ
動作しています。
Screen screen;
printf("user mode screen (x, y) = (%x, %x)\n", screen.getXResolution(), screen.getYResolution());
printf("you can draw from user mode!! and also use multi thread \n");
word color = Color::bpp24to565(Color::rgb(0x7A, 0x7A, 0xC4));
screen.fillRect16(0, 200, 800, 400, color);
color = Color::bpp24to565(Color::rgb(0x63, 0x63, 0x9F));
for (int x = 0; x < screen.getXResolution(); x++) {
screen.putPixel16(x, 0.5 * x + 300, color);
}
Monaで動作するプログラムを作成するには以下の手順をふみます。 ※サンプルプログラムは(mona_v1.0/src/user/ディレクトリにあります。) (1)C++でプログラムのソースを書きます。必ずuserlib.hというヘッダファイルをincludeしてください。 printf, Screen::putPixel16, fillRect16や。スレッド作成・メッセージsend/receive,string.h系 どんどん増えています。 (2) MakeFileに自分の書いたプログラムを追加してあげます。 user/MakeFile hello.cpp用の記述を真似するとよいでしょう。 (3) makeとするとコンパイル・リンクが行われます。 (4) 成功するとELF形式のファイル(Monaでそのまま実行可能)が作成されます。
簡易シェルを実装しました。 コマンドラインでコマンドを受け付けて FDのFAT12からELF形式のファイルを読み込んで実行することが出来ます。 このシェルからJPEG表示プロセス(ユーザーモード)を実行することに 成功しました。 なおMonaのブート後以下のようにプロセスがカーネルでロードされます。 ブート ビデオモード切替 プロテクトモード移行 キーボードサーバ起動(ユーザーモード):キーボード割込み後の処理・仮想キーコード送信 シェルサーバ起動(ユーザーモード):コマンド受付・プロセス生成 関連ソースは mona_v1.0/src/user/ShellServer.cpp mona_v1.0/src/user/KeyBoardServer.cpp mona_v1.0/src/user/hello.cpp mona_v1.0/src/user/jpegdemo.cpp ユーザーモードではScreenクラスを使用することにより VRAMのアドレスを取得することが出来ます。 またキーボードサーバに自分自身のプロセスを登録することにより キー情報を取得できます。 がんばればゲームが動きそうですね。 (その前にカーネルのバグをつぶさなければなりませんが)
57 :
Be名無しさん :04/02/08 17:13
おめ。 もう「起動するだけ」とは言わせないw ageとこ。
>>57 ありがとうございます。
簡易シェルはBSキーがきかない、プロセスを非同期で起動するので
表示位置がおかしい。
すぐ落ちる(Access Deniedなど)
バグがいっぱいなので徐々に改善していきます。
MONAで遊べば シェルもあるしファイルも読める絵も出せるしJPEGも表示できる。 キー入力も取得できるようだし。 簡単なゲームや、スクリプトエンジンなら動くと思う。
最近進むの早くない? 爆発傾向?
いあ。前からこんなペースだろ。 ユーザ側に実装が踏み込んできただけ。
しかし一時期からここいらの人口は増えんなあ。 monaとかmegの最近の動きから人が増えると面白いんだが。
>>61 そうか。
地味なところの作業が終わって派手さが出てきた感じかな。
もう少ししたら触ってみようかな。
おお、さっそく増えそうだ。
>>63 いや。どうかなぁ。
とりあえず、機能を提供して、ライブラリで上と区切った後に
また下側を直し始めるぽいからなぁ。派手さ、は微妙。
>>65 サンクス
一通りそろってきた感じに思えて遊べそうかな。
派手さはmegの方があるからね。
あまりの荒れようで、このスレもう終わりかと心配してました。 久しぶりに活気が出てきて嬉しい限りです。 ひげぽんガンガレ!
>>67 ありがとうございます。
今日(※2004.02.06)はマウスドライバを書いていました。
マウスの初期化と、マウス割込み、座標の取得らしきものが
出来ました。
ユーザ−モードでのアクセス違反調査中。
なんだここ
マウスサポートということはいよいよGUIかな。 最近進歩がめざましいな。
マウスドライバがほぼ完成しました。 割込みとI/O以外はユーザーモードで処理して ユーザーモードのプロセスがメッセージングによって情報を受けて 座標計算とマウスカーソルの描画(今は■)を行うことが出来ました。 ただ懸念点があってマウス情報の1, 2, 3byte目のうちのどれかが 割込み禁止などで通知が欠けてずれる可能性があるということです。 某ななしさん情報だと1byte目は特定パターンのデータしか来ないので byte & 0xC8 == 0x08というチェックを入れて これを1byte目とすればとのことでした。 他のOSはどうしているんだろう?
マウスデータを取りこぼす程の長時間割り込みを禁止する方が問題ではないかと。
>>72 ご返答ありがとうございます。
おっしゃるとおり長時間割込み禁止するのは問題外です。
Monaでは今のところマウスの割り込みの取りこぼしは一度も発生していません。
システムコール中も基本的には割込み禁止ではないので。
ただ可能性としては取りこぼすことも考えられるので
どのようにチェックをすべきかを悩んでいる状態です。
74 :
Be名無しさん :04/02/08 18:08
サルベージ完了あげ
コピペ大杉。
77 :
Be名無しさん :04/02/08 20:04
皇位継承記念あげ
でMonaとやらはどこから取ってこれるんだ?
>>73 ハードからの割り込みでは割り込み禁止にはせずに、
基本的にドライバのI/O部分ではキューの操作しかせずデータの解釈などは行わない。
マウスの場合はマウスサーバ(gpmdみたいなやつ)がデータを解釈する。
キューが変更されたかどうかは通知する必要があるが、
その部分は割り込みに対するクリティカルセクションではない。
マウスサーバがポインタの描画までする必要はない。
座標を描画サーバ(Xみたいなやつ)に通知するだけ。
描画サーバにマウスサーバの描画オブジェクトを登録しておいて
実際の描画処理を返させても構わない。
これらは全部、取りこぼしがないように非同期に処理するための工夫。
>>81 ありがとうございます。
現在のMonaでは
マウス割込み処理でI/O。生の情報をユーザーモードのサーバーに
送信後終了。
サーバー側でデータの解釈・ついでにカーソル描画をしています。
> 描画サーバにマウスサーバの描画オブジェクトを登録しておいて
> 描画処理を返させても構わない。
描画サーバはそろそろ検討しないといけないですね。
Xとやらがどういう仕組みなのかがよく分かっていないです・・・
> monaApp = new myApplication("HELLO.ELF"); つなぎだろうけどこれはまずいね。 pidを取るための苦肉の策なのは分かるけど。 WindowsではWinMainの引数としてHINSTANCE(pid相当)が渡される。 そういう変態的な特殊起動関数を避けたいという考えものあるだろうけど、 その辺は工夫でどうにでもなるから無問題。 WindowsでもWinMainではなくmainからGUIを起動させるコードを書ける。
>>83 > > monaApp = new myApplication("HELLO.ELF");
> つなぎだろうけどこれはまずいね。
> pidを取るための苦肉の策なのは分かるけど。
そうですね。おっしゃるとおりメッセージループに必要なpidを
取得するための仕組みです。
>WindowsではWinMainの引数としてHINSTANCE(pid相当)が渡される。
おっと。これは知りませんでした。いやあ勉強になります。
mainにargc, argv, envpを渡す計画は立てているのですが
そことの両立が微妙ですね。
やはりWinMain相当関数の引数にセットするのが自然でしょうか?
BeOS・OSASKとかはどうなっているのでしょうね。
>>82 マウスならいいけどLANのパケットとかデータ量が膨大なものを統一的に扱うなら
データを送信までしてしまうモデルはまずい。
ドライバではひたすらキューにだけ溜める。
サーバに対してはキューが変更されたことだけを通知して、
サーバの側でアイドル時にキューを読むようにする。
当然キュー操作はクリティカルセクションだけど、
MutexにWaitForMultipleObject的な機能を追加すると簡単になる。
リエントラントを意識するとデッドロックになりがちで難しいけど、
乗り越えないといけない壁だからね。
>>85 さん
早速、目から鱗です。
> ドライバではひたすらキューにだけ溜める。
> サーバに対してはキューが変更されたことだけを通知して、
> サーバの側でアイドル時にキューを読むようにする。
なるほどこういう方法もあるのですね。
サーバーとドライバの仲立ちにキューが入ると。
キューの仕組み自体はカーネルにあるので
完全なユーザープロセス(サーバー)からキューアクセスできれば
実現できそうですね。
> 当然キュー操作はクリティカルセクションだけど、
> MutexにWaitForMultipleObject的な機能を追加すると簡単になる。
> リエントラントを意識するとデッドロックになりがちで難しいけど、
> 乗り越えないといけない壁だからね。
この辺が難しいですね。キュー操作に時間がかかっては
意味がないですし。
>>84 UNIXのような引数のないgetpid()の実装を考えるしかないでしょう。
> WindowsでもWinMainではなくmainからGUIを起動させるコードを書ける。
というケースでも、GetModuleHandle(NULL)がgetpid()相当の働きをする。
Xの場合はインスタンスはpidで管理されているわけではなく、
XOpenDisplay()として取得したDisplay*で弁別している。
イベント処理も↓のような感じ。
Display* display = XOpenDisplay(NULL);
XEvent e;
XNextEvent(*mDisplay, &e);
つまりXの側で管理しています。
すみません。昔書いた適当なコードから抜粋したので間違っていました。 誤:XNextEvent(*mDisplay, &e); 正:XNextEvent(display, &e);
>>81 いやー禁止するべきでしょう。
PICの操作があるし。プリエンプションといっても限度がありまつ。
>>86 読み書きポインタの管理はアトミック性無くてもなんとかなります。
データの残量はアトミックに管理しないとえらい事になりますが。
>>89 > いやー禁止するべきでしょう。
誤解を招く書き方をしてすみません。
すべての処理で一切禁止しないというように読めてしまいますね。
マウスデータの処理までの一連の流れすべてで、というつもりでした。
>>87 さん
> UNIXのような引数のないgetpid()の実装を考えるしかないでしょう。
早速頂きました。実装します。
気づかなかったです(´ヘ`;)
> > WindowsでもWinMainではなくmainからGUIを起動させるコードを書ける。
> というケースでも、GetModuleHandle(NULL)がgetpid()相当の働きをする。
Windowsであまりプログラムしたことないので知りませんでした。
ありがとうございます。
> XOpenDisplay()として取得したDisplay*で弁別している。
> イベント処理も↓のような感じ。
イメージとしてはpidの場合と一緒ですね。
一意となるキー(ハンドル)基準の操作ということですね。
>>89 さん
> 読み書きポインタの管理はアトミック性無くてもなんとかなります。
> データの残量はアトミックに管理しないとえらい事になりますが。
このへんはご自身の経験からの発言と見受けられますが
どのようにして何とかされたのでしょうか?
カーネル内でsprintfが必要な状況って例えばどんな場合ですか? 文字列クラスは重過ぎるので避けるということであれば、 長さ管理に関してはPASCAL文字列を使った方が良いかもしれません。 [例] "A" C 文字列 "ABC": 41424300 Pascal 文字列 "\pABC": 03414243 同様に文字列以外の配列でも範囲チェックできます。 template <class t> struct Array { int length; t* data; } 安全性確保のため常に長さをつきまとわせるというだけですが、 Cの関数でも配列と長さを引数で渡すケースは多いのでセットにしてしまうわけです。
すみません。 > [例] "A" の"A"は無視してください。
あと補足ですが、
>>92 のArrayはlistやvectorのような可変長のものではなく、
普通のchar[]とかint[]のような固定長のものを念頭に置いています。
可変長である必要がないものまでlistやvectorで扱うとオーバーヘッドが大きいので。
>>92 さん
>カーネル内でsprintfが必要な状況って例えばどんな場合ですか?
あれば便利という感じです。
必須ではないですね。
カーネル内でも簡単な文字列処理をしたいことがあるので。
> 長さ管理に関してはPASCAL文字列を使った方が良いかもしれません。
文字列長と文字列を同じ配列に入れるところがみそでしょうか?
初めてしりました。ありがとうございます。
こういうノウハウはなかなか貴重ですね。
>>95 > カーネル内でも簡単な文字列処理をしたいことがあるので。
そのケースに興味があるわけです。
あと受け流されているArray<>の部分は極めて重要な部分です。
バッファ溢れはどんな一流の人が書いたコードでも根絶できない厄介な問題なので、
すべての配列を
>>92 のArrayのようなもので扱うのはかなり有用な方法です。
コンストラクタや[]を定義して、
int* nums = (int*)malloc(sizeof(int) * 3);
nums[0] = 1;
↓
Array<int> nums(3);
nums[0] = 1;
みたいな感じで。面倒かもしれませんがお勧めしておきます。
listやvectorと違って固定長であるのがミソです。
毎回毎回範囲チェックすると遅くなりそうですが、
#ifdefでDEBUGか否かでチェックする・しないを決めて、
DEBUGが定義されていないときの[]のオーバーロードをinlineにすれば
実質オーバーヘッドはないわけです。
配列溢れでは例外が補足しきれないことが多いので、
なぜか挙動がおかしい……と悩むことが多いのですが、
DEBUGを有効にしたものでチェックすれば一発で見つかるわけです。
以前、アプリですが、CからManaged C++に移植してバグに気付いたことがあります。
> 文字列長と文字列を同じ配列に入れるところがみそでしょうか?
ただ256文字に制限されてしまうので、Array<char>の方が実用的ではありますが。
87さんから頂いたPID取得ロジックを組み込みました。 System::getPID(); 今日はマウスドライバ・サーバーの実装がひと段落しました。 bochsでカーソルが遅いのが気になりますね。 原因として考えられるのは ・send/receiveのオーバーヘッド ・スレッドスケジューリングの問題。 描画に時間がかかりすぎる? タイマ割り込みが実機と違う? マウスサーバは優先順位を高くしないとダメ? ・bochsはそういうもの。 >> 97 >> カーネル内でも簡単な文字列処理をしたいことがあるので。 > そのケースに興味があるわけです。 デバッグ出力とかですね。fault・error時に人間にとって 見やすい情報を出力できればよいです。 > Array<int> nums(3); > nums[0] = 1; > みたいな感じで。面倒かもしれませんがお勧めしておきます。 ふむ。なるほどだいぶイメージがわいてきました。 > #ifdefでDEBUGか否かでチェックする・しないを決めて、 > DEBUGが定義されていないときの[]のオーバーロードをinlineにすれば > 実質オーバーヘッドはないわけです。 うぅ。うまいなぁ。これはすごい。 こういうテクニックはプロの仕事ですねぇ。 すばらしいの一言。 レベル高い。 まねします。。
マジプロジェクトなんだ。びっくり。
MonaApplicationで必ずPIDがいるのなら、プロセスロード時にメンバ変数にセットってのはだめなの?
>97 カーネル内の文字列処理ですが、Monaはまだ初期段階の開発中OSですから、 開発者の環境や、ユーザの環境で実行したときのログ取りに使うというのが 一番の目的になると思います。
>>100 さん
ありがとうございます。
mypid_をメンバ変数として用意しました。
そういえばbochsがマウス初期化のときにaux interfaceテストをすると
死ぬのでコメントアウトしました(感謝某氏)
>>97 さん
確認なのですがPascal 文字列とArrayには関連ないですよね。
Arrayの要点としては
固定長配列のかわりにArrayをつかう。
Arrayの[]演算子で範囲チェックする。
ifdefでリリース時は範囲チェックをはずす。
と理解していますがあっていますでしょうか?
>>98 > 描画に時間がかかりすぎる?
ポインタをただの点にしてしまうことで確認できませんか?
>>98 > デバッグ出力とかですね。fault・error時に人間にとって
> 見やすい情報を出力できればよいです。
なるほど。
>>101 なるほど……って、あれ?ひげさんじゃない??
>>102 > 確認なのですがPascal 文字列とArrayには関連ないですよね。
長さをbyteにしたArray<char>はPASCAL文字列そのもの、という関連性です。
struct pstring
{
byte length;
char* data;
}
※この構造体にPASCAL文字列をmemcpyできます。
長さをbyteにすると256文字制限が出るので、
Array<char>がお勧めということです。
それは文字列に限らないということで話を続けました。
あとArray<char>を徹底するなら、sprintfなどの引数もchar*ではなく、 Array<char>*を引数に取ることでsnprintfと同じになりますが、 sprintf(Array<char>*, const char*, ...); (第一引数はハードコードがほとんどなのでconst char*のまま) それならいっそ継承してクラスにすると良いかもしれません。 class string : Array<char> { public: int sprintf(const char*, ...); } これは単に sprintf(str, "%d", 2); が str.sprintf("%d", 2); と書けるというだけで好みのレベルでどうでもいいかもしれませんが。
あまり関係無いけどWin32のHINSTANCEはプロセス内でしか意味を持たないのでPIDとはちょっと違う Win16の頃はPIDのかわりに使えたが
>>98 > こういうテクニックはプロの仕事ですねぇ。
プロと言えば、newやmallocの後に必ずASSERTでチェックしたりもしますが、
そういうチェックもコンストラクタでやって隠蔽できます。
あと効率上、配列をスタックに作る方が良い場合もあるので、
int __nums[3];
Array<int> nums(&nums_data, 3);
のようなコンストラクタを用意すると良いです。
ただこれだとクラスのインスタンスを作るオーバーヘッドが出てしまうので、
以下のようなマクロを使うと良いかもしれません。
#ifdef DEBUG
#define STACK_ARRAY(type, name, size) type __##name[size]; Array<type> name(&__##name, size);
#else
#define STACK_ARRAY(type, name, size) type name[size];
#endif
int buf[3];
↓
STACK_ARRAY(int, buf, 3);
※こういうときにうっかりbuf[3]とか書くことがたまにあるので。
面倒ですが、それくらいバッファ溢れは用心した方が良いです。
うっとおしくなれば正規表現置換でマクロから戻せるわけですし。
うう、ミスってました。 誤:Array<int> nums(&nums_data, 3); 正:Array<int> nums(&__nums, 3); あと↓の最後のセミコロンはいりませんね。 > STACK_ARRAY(int, buf, 3); 体裁的にセミコロンがあった方が収まりが良ければ マクロの方から末尾のセミコロンを消すと言う手もあります。 好みのレベルでどうでもいいかもしれませんが。
>>106 補足ありがとうございます。Display*も同じです。
ソース本文中に #ifdef DEBUG の嵐は読みずらいと思うな。 マクロでおきかえってのは良いと思う。 malloc とかも良く以下みたいな感じにするし。 #define malloc(p) debug_alloc(__FILE__,__LINE__,p) もちろんデバグコード抜かない方が良い場合は、 チェックコード入れっぱなしにするんだろうけど。
すみません、↓はウソです。 > ※この構造体にPASCAL文字列をmemcpyできます。 memcpyできるのは↓でした。 メモリ効率悪いですが。 struct pstring { byte length; char data[256]; }
>>102 > 固定長配列のかわりにArrayをつかう。
> Arrayの[]演算子で範囲チェックする。
> ifdefでリリース時は範囲チェックをはずす。
はい、そうです。
関数の引数とかもすべてArray<>を前提にしてしまうと(その方が安全)、
STACK_ARRAYのような宣言時のすりかえではきかないので(暗黙にサイズを渡すため)、
#ifdefはArrayクラスのコードの方に書くことを念頭に置いています。
ヒープに確保するのであればオーバーヘッドは大きくないです。
>>110 さんの指摘の__FILEや__LINEを埋め込む方がデバッグしやすいですが、
その場合は配列の宣言もマクロで行ってASSERTに渡すと良いでしょう。
>>92 Array<>って配列をJavaやC#みたいにサイズ込みにするためのもの?
Array<int> a(3); // int[] a = new int[3];
a.length→3
>103さん
点にすると多少早くなります。
>104さん
> 長さをbyteにしたArray<char>はPASCAL文字列そのもの、という関連性です。
理解しました。そういうことですか。
PASCAL文字列よりも固定長配列の扱いの部分に目が行ってしまったのので・・・
>>106 さん
補足ありがとうございます。
> あと効率上、配列をスタックに作る方が良い場合もあるので、
> int __nums[3];
> Array<int> nums(&nums_data, 3);
> のようなコンストラクタを用意すると良いです。
あーなるほど。すばらしいですねぇ。
Arrayの実装のときにそのまま流用いたしますです。
> ただこれだとクラスのインスタンスを作るオーバーヘッドが出てしまうので、
> 以下のようなマクロを使うと良いかもしれません。
うわぁ。頭がパンクしてきました。
ぎりぎりついていってます。
上級テクニック目白押しです。
>>110 > debug_alloc
これはユーザーモードで特に使えそうですね。
まだ不安定なので。
>>112 > はい、そうです。
> 関数の引数とかもすべてArray<>を前提にしてしまうと(その方が安全)、
すばらしいです。Arrayを実装する気です。
ところでArrayにすることでのオーバーヘッドは微々たるものという
イメージなので(範囲チェックを除けば)
おまいら早く寝なさい 明日の仕事に障りますよ
>>113 そうですね。
JavaやC#を知っている人はそう考えた方が分かりやすいかもしれません。
main(int argc, char* argv[])とmain(string[] args)の違いですね。
あ、でもmainはあまり例として良くなかったかも。
文字列クラスを作らないとstring[]はArray<Array<char> >になるから……。
>>116 仕事中です……。
今日は椅子の上で3時間くらい寝れば上出来かな。(泣)
template <class T> class Array { public: Array(dword length) : length_(length), alloc_(true) { array_ = new T[length]; } Array(T* array, dword length) : array_(array), length_(length), alloc_(false) { } virtual ~Array() { if (alloc_) { delete array_; } } public: inline T operator [](dword index) { #ifdef DEBUG_MODE if (index < 0 || index > length_ - 1) { g_console->printf("array index outof range %d\n", index); for(;;); } #endif return array_[index]; } private: T* array_; dword length_; bool alloc_; };
↑でっち上げてみました。 さてどこで使おうかな。
◆Ngzcp/NZpAは、他にも使ってる人間がいるらしいので計算は簡単だと思われ。 つーか、既存のNewOSも知らないんですか。それで勝手にThe New OSを名乗れるんですよね。無知ですか。そうですか。>某
仕方無いから「うにゅうOS」へ改名の方向で。(ぇ
>>121 散々外出の煽りを今更になってわざわざMonaスレでする理由は?
ところでここは結局Monaスレなのか。 そして世の中では今日は休日なのか。 俺ヒキだから(ry
>>119 ハンガリー記法って知ってる?
それはともかくサフィックスは流行らないよ。
もっとも最近はハンガリー記法の反動もあってか
あまりメンバ変数にプレフィックスを付けたりしない。
↓のように記号を使わないのが最近の流行。
private:
int length;
public:
inline int getLength() { return length; }
> delete array_;
これはまずい。delete[]を使わないとダメ。
> ハンガリー記法って知ってる? いや知らないです。。 > それはともかくサフィックスは流行らないよ そうなのですか。メンバ変数とローカル変数を区別するために 付けていたのですが、もうふるいのですね。 > delete array_; > これはまずい。delete[]を使わないとダメ。 うわっ。やってますねぇ。ご指摘ありがとうございます。
>>126 > いや知らないです。。
ハンガリー記法はMicrosoftが昔推奨していた命名規則。
Win32プログラミングすると最初に面食らう。
[例] m_nLength: m_(メンバ), n(整数←iNt)
だけど、今は推奨されていない。
.NETを逆コンパイルするとハンガリー記法と他の記法が混ざってる。
> メンバ変数とローカル変数を区別するため
メンバであることを明示したいときはわざとthis->を付けるのが流行。
return this->length;
これはIDEの補完機能から広まったとも言える表記法。
とりあえずメンバを出したいときにthis->と打てば漢字変換の候補みたいに出てくるので。
ハンガリー記法が廃れたのも補完で型まで出てきて必要性が薄れた面もある。
他国産OSに比べてmonaのメリットって何? 2chで好き勝手に文句言ったり要望垂れ流したりマンセーできることくらい?
>>128 日本語で作者と会話できる。それに尽きる。
OSASKに犬糞崩れの厨房が大挙して押し寄せた理由の1つ。
>>119 Arrayを実際に使う場合、引数でポインタ渡しをすると混乱するので、
(インスタンスを直接扱う型とポインタで扱う型を区別するべき)
operator=を定義してコピーできるようにしておいた方が良いです。
その場合にコピーをどういう挙動にするか考えてみましょう。
JavaやC#で
int[] a = new int[1];
int[] b = a;
b[0] = 3;
としたらa[0]も3になりますよね。
同様に
Array<int> a(1);
Array<int> b = a;
b[0] = 3;
としたらa[0]も3にすることをお勧めします。
中身までコピーするSTLのlistやvectorとは挙動が違いますが、
言語的な仕様としては最近の流行だからです。
(続く)
そうなると重大な問題が発生します。 Array<int> GetArray() { Array<int> ret(3); ret[0] = ret[1] = ret[2] = 0; return ret; } という関数があったとして、 this->array = GetArray(); (↑明示的にthisを使うと流儀に関係なくメンバと分かるのが利点ですね) などとしたらバグります。理由は分かりますよね? この手のバグはその場でアクセス違反が起きないことが多くて厄介です。 バグを減らすつもりがバグを増やしては本末転倒です。 かと言ってGetArray()の中で Array<int> ret(new int[3], 3); などとすると、古いCのライブラリみたいに、 返り値は必ず解放してくださいということになって、 時代遅れの上面倒くさいことになります。 これを避けるためSTLではインスタンスをコピーする仕様だと思われます。 確かにC++的にはスマートですが、オーバーヘッドが大きいです。 もともとカーネルでSTLを避けたのもその辺が一因ですよね? (続く)
さてどうしたものでしょう? もともとJavaやC#の真似をしたということは、 解決策まで真似をするということです。つまりGCです。 STLのlist<int>などではスコープで破棄させて代入ごとにコピーするため GCがなくてもリークしませんがオーバーヘッドがあります。 引数では参照で回避できますが、効率のため参照を考え始めると面倒です。 かと言ってポインタ渡しをするのは使い方に統一性がありません。 オーバーヘッドもリークもなくすにはGCが必要です。 と言ってもGCには実装がたくさんあって、 Mark & Sweepなんかやっていたらオーバーヘッドが大きくなります。 カーネルがGCでストールするのは論外です。 それを考えると現実的なのはReference Countでしょう。 もともとC++ではスタックに作ればスコープで破棄されますし、 Reference Countでも理想的な手動deleteとほとんど同じ効率です。 循環参照のような問題はありますが、 削除したオブジェクトにアクセスすることがないのと引き換えです。 (続く)
簡単なリファレンスカウントの実装。 private: int* refCount; というのを用意します。 alloc_は不要になります。 コンストラクタごとに分類します。 1. Array(int length) this->refCount = new int(); 2. Array(T* array, int length) this->refCount = NULL; 3. Array(Array<T>& src) ← コピーコンストラクタ this->refCount = src.refCount; (*this->refCount)++; ※operator=()も同じ。 (続く)
virtual ~Array() { if (this->refCount == NULL) return; if (*this->refCount == 0) { delete this->refCount; delete [] this->array; } else { (*this->refCount)--; } } ここまで出来れば引数は参照やポインタではなく値渡しでOKです。 void Func(Array<int> arg); 実戦投入する前にテストコードをよーく書いて、 ちゃんと機能しているかを確認してください。 この手のものはWindows上でデバッグできます。 うまくいけば 1. 配列溢れ 2. delete忘れ(メモリリーク) 3. deleteしたオブジェクトへのアクセス(自分でdeleteしないため) の3大バグから解放されます。(やや誇張) 目に見えるほどのオーバーヘッドもないはずです。 配列でないオブジェクト用のものも作ればほとんどJava気分です。 (boostではshared_ptrと配列用のshared_arrayの区別があるのを参照) Javaでカーネルを書くのが当初の夢だったんですよね? 工夫でC++をJavaに近付けているわけです。(パチもんですが……) 以上
>>127 さん
> return this->length;
> これはIDEの補完機能から広まったとも言える表記法
なるほど。メンバ変数が多いとthis->だらけになりそうなのをのぞけば
一番分かりやすいかも知れませんね。
>>128 さん
> 他国産OSに比べてmonaのメリットって何?
現時点では特にメリットはないかと思われます(笑)
>>130 さん
大変有用な書き込みありがとうございました。
勉強不足ゆえ消化中ですが。
しっかりと生かしたいとおもいます
今日はいろいろとバグ修正をしていました。 130さんも書かれている通り例えカーネルのコードであっても 実は部品としてうまく切り出せばWindows上での開発・デバッグが可能です。 その方が断然効率もよく。ある程度汎用性のあるコードを 書く勉強にもなったりします。 さて最近のMonaはユーザーアプリ用にAPIが少しずつそろってきました。 ・FDC直接操作open/read/write/close ・ファイル読み込みFileInputStream ・文字列描画printf ・描画(四角形とか点) Screen::bitblt ・VRAM直接操作 ・仮想VRAMクラス ・スレッドcreate/join Mutex ・汎用メッセージング機構(プロセス間で通信が可能) ・メッセージングを利用してマウス・キーボード入力情報が取得可能 ・プロセス間に共有ページ(メモリウィンドウ)を作成可能 ・新規プロセス生成 ・簡易シェルから自分の作成した実行形式のファイルを実行可能 実はいろいろと簡単なアプリが作れたりするのかなとは思っているのですが なかなか手を付けられないですねぇ。 cygwin/linux のgcc, objcopy, ld等のツールがあれば今すぐ Monaのアプリがかけます。 簡単なサンプル(ゲームなど)を見せられたりしたらよいのでしょうか(多少派手めに) それとも何か有名なものを移植?
そりゃあもちろんRogueCloneを
マインスイーパをキボンヌとか言ってみる
やたら伸びてるなあ。
>>91 文字だけだとうまいこと説明できないので、
リングバッファでぐぐって下さい。
基本的に読む方と書く方には依存関係がないので、
アトミックである必要がないだけです。
当然複数の場所から同時に書き込まれる・読み込まれる場合は
そこの排他制御は必要になります。
ちゃんとソースを見たわけではないけど。 移植とか結構いけるんでないかな。VRAM開放されているのが 大きい。
アプリはC言語で書くのですか?
今のところCかC++を想定してると思われ。 詳しくはWikiを参照の事。 オブジェクト指向のAPIを提供する事と、 C言語ライブラリの整備が行われている途中。
>>89 さん
ありがとうございます。>リングバッファ
>>141 さん
C++言語を想定しています。
C言語でも可能ですがオブジェクト指向APIを
提供して行く予定ですのでC++をお勧めします。
>>142 さん
フォローありがとうございました。
うむ。材料がそろっていても何らかの起爆剤が必要なのですかねぇ。
この時期にMONAでゲームでも作ってレポート書けば神だと思うんだけどな。
strtodとかstrtoulとか。その辺に落ちてるの使ってもイーのに。 University of Californiaのはよく見るけど、あれ元々何からのコードなんだろ。
ライセンスさえ解決すれば、ぱくってきていいと思う。 でも、ライセンスの制限がつくけどライブラリが増えるってのは、 Monaプロジェクト的には、うれしいのかどうかわからない。 このスレ的には、 NICドライバ+TCP/IPプロトコルスタック+2chブラウザをMona上で実現したら神認定 ではないでしょうか。
>>145 UCBのだったら何も無い所から作ってるはずだが。
BSDLか(L)GPLならそこらからさくっともらえるが、
MIT/Xつーのはこういうとき不便やね。
>>144 さん
>>146 さん
どちらも神ですねぇ。
> でも、ライセンスの制限がつくけどライブラリが増えるってのは、
> Monaプロジェクト的には、うれしいのかどうかわからない。
カーネルではなくてユーザー側のライブラリであればあまりライセンスにこだわるつもりはありません。
もちろん議論は必要ですが・・・
あとMona APIの背後にそれらのライブラリが隠れている場合は複雑ですかね。
>>147 さん
是非登録してください。
作者の私が言うのは変な話ですが敷居は割りと低めなので
たくさんの人がチャレンジしてくれるとうれしいです。
今日は某氏からMonaのレスポンスが悪いとの指摘を受けて
チューニングを開始。
当面の課題は3つ
・gcc最適化オプションで動くようにする
- O2まではOK(volatileにすべきところが見つかったりしてよかった)
・FDからの読み込みの高速化
- 詳しい人のサポートがあるとうれしいかも。
・メッセージreceive時にスレッドをブロックするなどのスケジューラ周りの改善。
あと。gccインラインアセンブラのマニュアルを紛失してしまいました。 "p"ってどういう意味かわかる人いたら教えてください。 asm volatile("lidt (%0)\n": :"p"(temp)); 最適化時にこの辺が怪しいので
>>148 タン
> UCBのだったら何も無い所から作ってるはずだが。
いんや、UCBが他からパクってるって意味でなく。
オリが見た事あるのは全部、特定の関数のソースだけをUCBから拝借してる奴で。
元々UCBがライブラリや他のアプリを作る為にそれらの関数を作ったのか、
それともそれらの関数自体を作りたかったのか。
前者だとして元ネタが何なのかを知らないという意味。
アセンブリなんてくっさいもの使わないで全部C++にしようYO
>>150 メモリアドレスらしい。
mとの違いがよくわからん。
-O2で通ればいいんでないかと思ふ。
あとは-fomit-flame-pointer使って、レジスタを有効利用するとか。
>>151 AT&Tのライセンスに縛られないlibcを作るために書き下ろしたはず。
歴史の本を読めばそのへんの話が書いてある。
>>152 では手始めにsetjmp/longjmpをC++だけで書いて見てくれ。
漏れには難しすぎて出来ない。
とか言ってみる。
>>152 さん
> アセンブリなんてくっさいもの使わないで全部C++にしようYO
そうですねぇ。私もアセンブラを極力使わない派です。
使わなければいけないところだけで使います。
>>148 > メモリアドレスらしい。
> mとの違いがよくわからん
ありがとうございます。私もそのような状況です。
mだとコンパイルとおるのですが割込み時に死んでしまうので
lidtがうまく動いてないのかも。
> -O2で通ればいいんでないかと思ふ。
> あとは-fomit-flame-pointer使って、レジスタを有効利用するとか。
とりあえず-O2はとおりました。(カーネル・アプリともに)
FDCドライバの最適化が難しそうですねぇ。
そういえばMonaのユーザーアプリでmain関数にあたるものに
Shellから引数を渡せるようになりました。
アプリ登録お待ちしています!
バイナリ配布汁。
>>148 > BSDLか(L)GPLならそこらからさくっともらえるが、
> MIT/Xつーのはこういうとき不便やね。
BSDLとMIT/Xを混ぜるのは何の問題もない。実質同じだから。
実際、以前FreeBSDのlibcから持ってきたコードがMonaに入ってたことがあった。
GPL系を混ぜても構わないけど作られたバイナリはGPLになってしまう。
それが嫌なら混ぜられない。
神待ち
そういやnewlibってBSDライセンスじゃなかったっけ?
./Jで鳥取砂丘祭りがある。 負けじとMONAネタ投稿したら面白いかも。 それなりにできているわけだし。
/.にはあくまでプレスリリースを出す気持ちでいかないと。過度の期待は禁物
技術的ネタは食いつき悪いので、 おもろくないと思う。
OS板>>/. 結構スラドの記事って引用されるから、まともな形になってからリリースしたほうが。
> 当面の課題は3つ
> ・gcc最適化オプションで動くようにする
> - O2まではOK(volatileにすべきところが見つかったりしてよかった)
-O3も通りました。これからはデフォルトO3でビルドするようにいたします。
インラインアセンブラのエラーの件は某氏のご協力により解決しました。
> ・FDからの読み込みの高速化
> - 詳しい人のサポートがあるとうれしいかも。
未解決です。FDCDriverのソースを眺めているのですが
全く分かりません。たかだか数十`バイトのELFの読み込みに時間がかかりすぎです。
ソースは↓の通りです。どなたか詳しい方の突込みをお待ちしております。
ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/FDCDriver.cpp?rev=1.78&content-type=text/vnd.viewcvs-markup > ・メッセージreceive時にスレッドをブロックするなどのスケジューラ周りの改善
改善しました。
今まではメッセージreceiveを発行したときにメッセージキューがからだった場合
ビジーウェイトしていたのですが、スレッドをブロックするようにしました。
メッセージが到着次第起こされる仕組みです。
これによりCPUが無駄に消費されない&メッセージ受信時に素早く反応できるようになったと思います。
168 :
Be名無しさん :04/02/12 14:33
バイナリキターーーーーーーー
スクリーンショット希望。
ひげー QEMUビルドのその後はどうなった?SDL入れたらうまくいったのかね?
>>167 FDトロイのは1sector毎に読んでるからじゃないの?
毎回シークしてるからじゃね?(´・ω・`)
>>170 qemu@cygwinはあきらめました。
Vine Linux上で環境を以前作りました。
VBE対応版はまだ入れていないです。
>>171 さん
>>鳥取砂丘さん
> FDトロイのは1sector毎に読んでるからじゃないの?
> 毎回シークしてるからじゃね?(´・ω・`)
ありがとうございます。
なるほど。毎回シークしないというのは連続していたら
シーク省略ですかね。
カレントトラックが次の読み込み対象トラックと一緒だったらseek省略 でやってみようかな。
>>166 > 私なんかより全然進んでいらっしゃるようです。
> こちらこそ勉強不足。。。
延々とArrayの話をした本人だもん。
実装を差し上げるよってことなんですが。
Javaみたいで便利とか思えば使い方も分かるかと。
>int MonaMain(List<char*>* pekoe); こういうのこそArrayにすると良い。可変長である必要はない。 ユーザープログラミングではメモリ管理を極力排除できるような構成を意識すべき。 その意味ではSTLやboost的なC++よりManaged C++の方が参考になる。
177 :
Be名無しさん :04/02/12 22:35
きたーーMONA
>>174 前回時のトラックを覚えさせておいて、
前回と同じトラックだったらシークを省略なのでは?
あと、最低限DOSでいうところのFILES相当のディスクキャッシュを
実装してみては?
>>178 ミスった。FILESじゃなくて、BUFFERSね。
>>180 実際にヘッドをシークさせるパルス信号を出すかどうかというのとは
別の話で、ドライバなりがFDCにSEEKコマンドを発行するかどうかと
いう話ね。
物理的にシークしなかったとしても、いちいちSEEKコマンドを発行したら、
次のREADなりWRITEコマンドの発行が次のセクタのID部にヘッドがかかかる
前までに完了しなくて、1回転するのを待つことになりかねないと思うん
だけどね。
#インターバルにセクタ番号を振る物理フォーマットをすれば間に合う
#かな?
>>181 そりゃシーク関係ないとおもわれ。
いくらCPU早くても1セクタ毎にリード出していたら
FDCついてこれなくて一回転待たされるぞ。
そのへんの問題を回避するためにセクタ番号飛び飛びにするつーのは実際あった。
読み方によってはかえって遅くなるという…
>>183 現時点では主に連続読み込みするのはカーネル側っぽいから間に合うかな
と思ったけど、きついかな?
SEEKコマンドの最適化しても遅かったら、マルチセクタ対応にするしか
ないんだろうね。効果的に利用するようにするのは、今のMonaでは簡単
ではないかもしれないけどね(上位層にFDの特性に特化したコードを
入れればそうでもないだろうけど…)。
>>165 さん
失礼いたしました。
熟読させていただきます。
>>176 さん
突っ込まれると思っていました(笑)
すいません。手を抜きました。
カーネルに引数を渡す実装がしたくて
型自体では手を抜きました。
Stringクラスを作ったら改善します。m(__)m
>>178 さん
> 前回時のトラックを覚えさせておいて、
> 前回と同じトラックだったらシークを省略なのでは?
ありがとうございます。実装しましたが
まだ遅いようです。
LBA=1〜10の連続読み込み × 10回で12秒ほどかかります。
50KBに12秒は遅すぎですよね
> ミスった。FILESじゃなくて、BUFFERSね。
ディスクキャッシュですか。
FDCDriverの読み込み速度の改善には
直接はつながらないですよね。
ファイルシステム側のほうがいいですかね。
>>180 さん
> ぐぐったらデータシート見付けたので参考に。
ありがとうございます。
>>183 さん
> SEEKコマンドの最適化しても遅かったら、マルチセクタ対応にするしか
> ないんだろうね。効果的に利用するようにするのは、今のMonaでは簡単
マルチセクタですか。うーむ。OSASKとかはFDアクセスが早いので
その辺のテクニックを使っているのですかね。
アプリ登録所にサンプルとしてオセロを登録しました。 むかしjavaで書いたやつの移植版です。 制限・特徴 ・マウスを用いて人同士の対戦ができます。(コンピュータ対戦部は今回は移植しませんでした。) ・クラスMonaApplicationの実装例です。(Monaではこういうことが出来るよの見本のような感じ) ・GUI部品がないので終了・リセット・UNDO・勝敗表示は出来ません。(機能としてはあるのですが) ・オセロのロジック部と表示部をオブザーバーパターンで分離しているのでC++をサポートしている ほかのOSにも割りと簡単に移植できそう。 ・描画にはダブルバッファを用いて変更箇所のみ描画しなおしているのでちらつきもありません。 今後カーネルコーディングの暇を見て少しずつパワーアップしていく予定です。
2月中はユーザーアプリの作成のサポートと。 サーバー間のメッセージプロトコルを決めるあたりを中心に 作業を進める予定です。 ↑で書き忘れたのですがオセロのソースは日本語でコメントを いっぱい書いたので多少は分かりやすいと思います。 皆様のアプリ登録をお待ちしております。m(__)m
無駄なseekをなくして改良したFDCDriverですがまだ遅いようです。 Mona起動時のBIOS利用のカーネル読み込み時とFD読み込みの音が違うなあ と気づきました。 BIOS利用時は「グッグッ」と読み込みが連続している感じなのですが FDCDriverの方がたまに「グッ」となるだけです。 なんだか「待ち」をしているような感じです。
RDTSC命令を使用してどの部分が遅いか調べてみました。 seek:0x56 ロジックによりコマンド発行せず dma setup:0x29FB read command発行:0x129CC 完了割込み待ち:0x9BB8294 result引き取り:0xE532 stop dma:0x4AD memcpy:0x87B total:0x9BDCAF1 これにより分かったことはreadコマンドを発行後、完了割込みがくるまで が大半の時間であるということです。 readコマンドのパラメータの問題なのでしょうか。 うーん。
つーか、VESAは16bitで十分です。
>>187 >・オセロのロジック部と表示部をオブザーバーパターンで分離しているので
昔pantora(hajimetyan)が/.で公開して弱くて顰蹙だったオセロと同じこと言ってるな。
ひょっとして「ひげぽん=平初」か?と思ったけど年齢が違うね。
ひげぽん: 25 or 26歳
平初: 22歳
Java厨の思考回路は似てるってことか。
>>190 そりゃ、いまどきのCPUならドライブから1sec分のデータを読み込んでくる
のを待っている間が大半になるんじゃないかな?
連続読み込みして、前回の完了割込みから今回のREADコマンド発行まで
の時間が、十分に短いかどうかが問題だと思います。
# ソースをもうちょっとよく読んだら、ちょっときついかもしれない。
# 下請けのプロシージャはインライン展開になっているのかな?
# ローカル変数の配列初期化定義もいくら今どきのCPUでもGAP3通過時間
# との闘いという面では、だいぶ不利かも知れないね。
>>193 必要以上に完了割込み待ちをしているかどうかいう問題もありえるか。
普通の1.44Mドライブの回転速度は、360rpmだったかな?
360rpmだとすると、大雑把には、
(READ待ち時間[s]) = 60/360 / 18
で、9.2592... ms
まぁ、実際にはGAP4などがあるからもうちょっと短いと思うけど…。
>>187 > #include<OthelloBoard.h>
<>はインクルードパスにあるヘッダを指定するのに使う。
ソースのパスと同じ、または相対参照できるものは""を使う。
あと空白を空けといて。
→ #include "OthelloBoard.h"
> monaApp = new myApplication("OTHELLO.ELF");
> dword myPid = Message::lookup("OTHELLO.ELF");
getpid()を実装したんじゃなかったの?
自分自身の名前をハードコードするようなのは良くない。
サーバのようなものだったらハードコードしても実害ないだろうけど、
そういうのはシステムヘッダに定数として書いておくべきだろう。
#define MOUSE_SERVER "MOUSE.SVR"
サービス名がファイル名そのままなのは考え物。
RegisterClass()みたいに文字列で名前を付けられるようにするべき。
あとothello.cppとOthelloBoard.cppの文字コードや改行コードがまちまちなのも気持ち悪い。
犬糞と行き来してるからか?
改行コードは趣味に合わせるとしか言えないが、文字コードは中立でUTF-8が良い。
どうせ文字列クラスと絡んでUnicodeは避けられないんだから。
>>196 >犬糞と行き来してるからか?
eucJPなんか犬糞ですら時代遅れになってる。
Fedoraはja_JP.UTF-8に移行してるぞ。
Kondaraが何年も前にやろうとしてはいたがね。
Solarisだとja_JP.UTF-8はとうの昔にサポートされてる。
Windows 2000からはメモ帳ですらUTF-8をサポートしている。
>>191 さん
> つーか、VESAは16bitで十分です。
現在のMonaは稼動中にビデオモードを変更することは出来ません。
そのため起動時にある優先順位でいくつかのビデオモードがサポート
されているかを調べて行き、最初に見つかったビデオモードに
切り替えるようになっています。
多色が良いという方もいれば16bitで十分という方もいらっしゃって
難しいですね。
稼動中に切り替えることが出来ればこの問題は解決しそうですね。
>>193 さん
> そりゃ、いまどきのCPUならドライブから1sec分のデータを読み込んでくる
>のを待っている間が大半になるんじゃないかな
なるほど。そのまっている時間が実際に何msなのかが問題なのですね。
> 前回の完了割込みから今回のREADコマンド発行まで
>の時間が、十分に短いかどうかが問題だと思います
そういうことですか。なんだか納得しました。
> 360rpmだとすると、大雑把には、
> (READ待ち時間[s]) = 60/360 / 18
そうすると結局。最適化してread間の時間を
短くすればよいってことですよね。
スケジューリングとあわせると複雑になりそうですねぇ。
>>196 さん
ご確認・ご指摘ありがとうございます。
> → #include "OthelloBoard.h"
修正しました。
> monaApp = new myApplication("OTHELLO");
> dword myPid = System::getPID();
> そういうのはシステムヘッダに定数として書いておくべきだろう。
> #define MOUSE_SERVER "MOUSE.SVR"
これはサーバー間のプロトコルが決まり次第ルールを決めたいと思います。
> あとothello.cppとOthelloBoard.cppの文字コードや改行コードがまちまちなのも気持ち悪い。
euc-jp-unixで統一しました。(エディタの都合です)
>>199 >euc-jp-unixで統一しました。(エディタの都合です)
エディタというのがEmacsのことだったら、最近のだと
* Editing -> I18n -> Mule -> utf-translate-cjk-mode
ってやればUTF-8使えるよ。
そんなの出ない古〜いやつを使ってるならMule-UCS必須だけどね。
文字コードの話を避けているようだけど、
避けるためにこそUTF-8を推薦してるんだけどね。
ロカールとか言語ごとの文字コードとか考えたくないでしょ?
今の段階で考える内容じゃないからね。
char*はUTF-8、文字列クラス内部ではUCS-4というのが最も簡単な実装。
SJISとかEUCだとsubstringで漢字を扱うときにDOS時代に逆行しちゃうぞ。
>>200 さん
> エディタというのがEmacsのことだったら、最近のだと
> * Editing -> I18n -> Mule -> utf-translate-cjk-mode
> ってやればUTF-8使えるよ。
set-buffer-file-codingsystemで
utf-8は選択できるのですがc-x sの保存時にエラーになったので
euc-jp-unixにしました。(view cvsの都合もよいかなあと)
> 文字コードの話を避けているようだけど、
> 避けるためにこそUTF-8を推薦してるんだけどね。
すいません。避けているわけではないのですが
まだ何も考えていません。
いつの段階で文字コードのことを考えればよいのか
迷うところです。
>>201 > 保存時にエラーになったので
↓は試しましたか?
>> * Editing -> I18n -> Mule -> utf-translate-cjk-mode
> view cvsの都合もよいかなあと
HTMLのソースで文字コードは指定されていませんよね。
> いつの段階で文字コードのことを考えればよいのか
> 迷うところです。
文字列クラスを作るとき。
new String("漢字")->getLength()
とか
new String("漢字")->substring(1, 1)
がどういう結果になるのが望ましいでしょうか?
ソースが何であれ内部でwcharにしないと自然に扱えませんし、
今から定義するならwchar=UCS-4というのが簡単です。
EUCとかだと変換テーブルとかロカールとか絡んで面倒くさいですよ。
というわけで何も考えなくて済むのはUTF-8。
少なくともEUC-JPはSJISよりはましだけどね。 gccでSJISだと"表\示"みたいなことになっちゃうからね。
gcc って L"日本語" とかやってもだめじゃなかったっけ?
>>204 ダメ。
APIをwchar_t*で扱うようにするのは無謀だから、
全部文字列クラス経由にして隠蔽しないと厳しい。
ソースはchar*で書くにしても文字列クラスのコンストラクタやoperator=とかで
代入時に変換しないとワイドキャラクタは自然に扱えない。
>>205 結局変換するんだったらEUCでもUTF8でも同じなんじゃねーの?
>>206 内部的には固定長文字列が良くて、今選ぶなら UCS4 だろ。
したら UTF-8 で入力するのが楽でない?
という話だと思う。
今作ってる辺りなら ASCII だけで良いと思うけどね。
UCS信者うざいよ UCSとUTFを同一視すんな
>>207 でも既に半角カナでAAしてるからね。
AAをハードコードするとSJISになってしまう。
UTF-8を採用するか否かで勝ち組になるか負け組になるかの瀬戸際だからな。 それは譲れない。
>>209 MS仕様Unicodeみたいに半角カナ用の文字コードを互換領域に
定義してしまえばSJISになってしまうとは限らない。
どうでもいいけど、ロケールって言わないですか? UTF-8を採用しないと、負け組みなのですか。 OSが文字コードに依存しないようにしておけばいいだけじゃないのですか?
>>212 > OSが文字コードに依存しないようにしておけばいいだけじゃないのですか?
文字列を単に表示にしか使用しないのなら別だけど、
ファイルのパス名などカーネルオブジェクトの名前を表現するために
文字を使用すれば通常は文字列操作が必要になるから文字コードに依
存しないようにするのは無理かと。
>>212 >どうでもいいけど、ロケールって言わないですか?
それではシュミレーションなんかと同じ
ロカール
>>213 >ファイルのパス名などカーネルオブジェクト
ファイル操作は全部カーネル外のサーバに押し出したらカーネルとは関係なくなるけどね。
カーネル内部でコード変換とかやったらカーネルが一気に肥大化してしまう。
FATだけ扱うにしてもSJISだからソースをEUCにしたらコード変換が発生してしまう。
そろそろ考えないと、その辺の問題が出てくるよ。
>>211 今のMonaの実装では、という話。
昔のPCみたいにフォントは1バイトに単純にマップしてあるからね。
ともかくFATにしてもAAにしてもソースEUCではコード変換必須。
SJISとEUCの変換は基本的に計算で出来るがIBM拡張領域とかでテーブル必須だし
3バイトEUCとかを実装しないと不可逆変換になってしまう。
UTF-8にしてもFATでコード変換が発生するのは避けられないけどね。
手抜きするなら当面SJISになるけどgccだと"表\示"みたいな問題は覚悟しないといけない。
$ find /path/to/mona_v1.0 -exec qkc -e {} \; OK
>>217 カーネルのコメント全部英語だし。
それに文字コードに依存するような処理はカーネル外に出すべきだからあまり関係ない。
ユーザーアプリとか作るときに影響がある。
WideStudioではMakefileでソースにプリプロセッサかまして避けている。←sjisfix
>カーネルのコメント全部英語だし。 外人に見せるために英語にしてるなら尚更SJIS決め打ちはまずいだろ
モノリシック
物知りっ9
by Canna
>>219 卑下の英語って変だろw
TRISPLANよりマシだが。
VFATも扱うとなると、ロングファイル名はUnicodeで格納されている から、どっちみちコード変換の機能は必要だね。 N:N対応だとコード変換の種類がN*(N-1)通りになるから、 ネイティブともいえる文字コードを1つ決めて、1:N対応になるように すればコード変換の種類がN通りですむという話なのではと思う。 で、そのネイティブ文字コードの地位をめぐる争奪戦が繰り広げられよう としていると。
多数決をとろう。
>>222 MSの特許問題でVFATまずくない?
そうなるとUDFかUFS2かext2辺りが必要になるだろうね。
UDFだとUnicodeだし、UFS2やext2だと特に決まりはないけど
普通はEUC-JPで使ってるだろうから、
マウント時にコードを指定して変換するしかないね。
>>222 ミスった。5行目のN通り→(N-1)*2通り
↓の状況から、ひげぽんは本当に何も考えてなかったんだろうね。 >othello.cppとOthelloBoard.cppの文字コードや改行コードがまちまち 今は他のことがやりたいのに突然畳み掛けられて当惑してるんだろう。 だけど今後ますます「今まで考えたこともなかった」ことがどんどん出てくるし 知らないから後回しにすると修正が面倒になるようなことも多くなる。 OSを作るというのは全方位の知識を総動員しないといけないくらい広いから。 ここをどう乗り切るかで今後が占えるとも言える。 刮 目 し て 待 て ! !
>>202 >> * Editing -> I18n -> Mule -> utf-translate-cjk-mode
Meadow2を使っています。
utf-から始まるコマンドは見つかりませんでした。
私の力不足の可能性濃厚かも。
>> view cvsの都合もよいかなあと
>HTMLのソースで文字コードは指定されていませんよね。
そのむかしview cvs上でchangeLogが文字化けしたので
eucにした記憶があったのですが勘違いかも知れません。
> new String("漢字")->substring(1, 1)
> がどういう結果になるのが望ましいでしょうか?
文字コードに関しては詳しくないですが。
それはユーザーモード側の話と認識しています。
正確にはライブラリですかね?カーネルと関わるところも
あるかもしれませんが、できるだけユーザーモードに
押し戻したい感じです。(Monaのポリシーとして)
文字コード問題ですが。以下のように考えています。 1.カーネルが貧弱なので文字コードを議論する段階ではない。当分ASCIIでよいのでは。 2.ただし将来的にMonaのネイティブ文字コードを考えるのは絶対必要。 3.感触としてはUTF-8かなぁ。 4.ライブラリ等UTF-8のものをどなたか担当していただけるならば大歓迎です。
>>228 頑張ったところ悪いけどピントがズレまくってますよ。
>それはユーザーモード側の話と認識しています。
カーネルの話はしてないよ。もともとオセロの話だったでしょ。
>>229 >2.ただし将来的にMonaのネイティブ文字コードを考えるのは絶対必要。
>3.感触としてはUTF-8かなぁ。
この辺、全然分かってない感じ。
ソースを何で書くのかというのと、内部処理に何を使うかは別問題。
極端な話、前者はコンパイル前にプリプロセッサを通せば
Mona側で何もしなくても解決する問題だから。
内部処理にUTF-8みたいな可変長コードを使うのは最悪。
Unicode 3.1でサロゲートが出てきた現在UTF-16でも同じ問題になる。
固定長ならUCS-4しかない。
> カーネルの話はしてないよ。 それいっちゃ、話の流れ自体がピンとずれまくりじゃない? Mona って今カーネル作ってるところやん。
> >それはユーザーモード側の話と認識しています。 > カーネルの話はしてないよ。もともとオセロの話だったでしょ。 なるほど失礼いたしました。 では。主にユーザーモードでの文字コードの扱いを 決めるということが主題でしょうか。 現在のカーネル作成状況と割ける事件を考えると 文字コード対応したStringやライブラリを用意するよりも カーネルの機能の増強の方が優先されてしまう時期だと思います。 (直近ではドライバインターフェースなど) それを受けて以下のまとめになりました。 > 1.カーネルが貧弱なので文字コードを議論する段階ではない。当分ASCIIでよいのでは。 > 2.ただし将来的にMonaのネイティブ文字コードを考えるのは絶対必要。 > 3.感触としてはUTF-8かなぁ。 > 4.ライブラリ等UTF-8のものをどなたか担当していただけるならば大歓迎です。
>>232 アプリ募集してて、なおかつ、こんなの出来たよ〜って言ったのはひげぽん自身なんだけど
>>234 日本語扱えないとアプリ組むのもメンドイよ。
つー話?
なら、なんとなく分かる気もする。
>>233 >現在のカーネル作成状況と割ける事件を考えると
>文字コード対応したStringやライブラリを用意するよりも
>カーネルの機能の増強の方が優先されてしまう時期だと思います。
>(直近ではドライバインターフェースなど)
それはみんな分かってるんじゃ?
たとえば
>>227 >今は他のことがやりたいのに突然畳み掛けられて当惑してるんだろう
だけどJavaを使っているのにUTF-8とかUCS-4のことを知らないのは
勉強不足と言われても仕方ないよ。
Javaでは内部がUTF-16だしcharはuint16_tだってことは知ってるよね?
コード変換のことを知っておかないとDBとのやり取りで文字化けしたりするし、
そんな人の作ったWebサービスとか怖くて使えない。
煽りじゃなくてマジだよ。
本当に文字コードのことを全然知らないみたいなんで気の毒になって来た。 ググっても小難しい英語の資料とかが多いから簡単に説明しておくか。 もともと各国で別々の文字コードが使われていたけど、 それだと処理を文字コードごとに作りこまないといけなくなるので、 主要な文字コードを単一の文字コードに入れた。これがUnicode。 その際に文字コードは16bitで表現された。つまり65536種類の文字。 1文字2バイトの固定長で表現されるためUCS-2と呼ばれる。 しかし文字単位を16bitにしてしまったため 従来のchar*を使う関数では処理できなくなってしまった。 そのためWin32では同じ関数をA系とW系のペアで提供する羽目になった。 これでは扱いにくいので8bitのcharでUnicodeを扱えるようにしたのがUTF-8。 UCSはコード体系で、UTFは符号化方式を表す。 7bitしか使えないメール用にUTF-7なんてのもある。 つまり本当の体系はUCS-2で、UTF-8は便宜的に作られたもの。 ただしUTF-8は可変長であるため文字列処理には向かない。 文字列処理自体は1文字16bitの固定長配列に変換して行う。 Javaもその考え方に基づいてUCS-2を採用した。
しかしUCS-2は無理矢理世界中の文字を1つのコード表に詰め込んだため 色々と無理が出てきてしまった。 それにビルマ文字などはみ出してしまった文字も残ってしまった。 そのためコードを32bitに拡張して対応することになった。これがUCS-4。 つまりUCS-2は過去のものになってしまった。 しかし既にUCS-2を採用してしまった処理系は多かったので、 サロゲートという拡張方法でUCS-4を16bit可変長に押し込めたのがUTF-16。 UTF-8は理論上31bitまでの拡張に対応できるようになっているので無問題。 ※実際には32bitを使い切るようなことはあり得ないため。 UCS-4登場以降に実装された処理系はUCS-4を採用している。 たとえばglibcがそう。 ただUCS-2からはみ出すような文字は現実的にほとんど使われないので UTF-16と言ってもUCS-2としてしか使われないのが現状ではある。 ともかくUCSがコード体系でUTFが符号化方式なのは最低限理解しないと、 まともにUnicodeについて考えることは不可能ってこと。
うにこーどは合成文字とか面倒臭いんだよなあ。 文字コードの問題は考えれば考えるほど面白くないw interfaceでも文字コードの話してた事無いっけ?
>>239 合成文字だけじゃなくてbidiなんかも超面倒くさい。
同じ文字コードでも結合状態で字体が変わったりする文字もあるし。
だけどSJISとかEUC-JPだとそもそも表現できる可能性自体もないから、
それよりはましってだけで欠点とかそういうことではない。
もっともそんなの今の段階で考えることではまったくない。
8bitのフォントのコードページを16bitにするだけと考えるべき。
それだけならSJISやEUC-JPでも漢字を表示する部分は大差ないので。
>>235 日本語を使わなくたって、文字列をOS側と受け渡しするアプリは作りに
くいね。将来、作り直しを迫られるかも知れないからね。
コンパイルし直すだけですむ場合もあるでしょうけど。
つまりは、UCS-4を主張する人が、 UCS-4<->EUC-jp(or SJIS)の変換コード UCS-4を表示するコード を書けば、採用されるんじゃないの?
>>241 どうせ今のMonAPIは仮だからってことで
その辺の問題をあまり深刻に考えてないんだろうね。
アプリ募集のための呼び水のはずのオセロが
逆に「待ち」を推奨してしまう結果になったのは分かってるかな?
>>242 中身ブラックボックスで意味が分からないものを採用するわけないから、
ひげぽんがUTF-8とUCS-4の関係を理解しないと無理かと。
Arrayみたいに勝手にやると飼い殺しになりかねない。
今の API ってあまりに仮過ぎてバシバシ変わってるやん。 自分で勝手に作くる覚悟で API 変わるって分かってるやつしかアプリなんか作っちゃ駄目だって。 API 変えてる状況で ASCII ってのは悪くない選択だと思うけど。
知らないものはしょうがないですがそのままなのもアレなので
ちょっと文字コードについて勉強しました。
以下つけやきばかもしれませんがご容赦ください。
>>231 > 内部処理にUTF-8みたいな可変長コードを使うのは最悪。
> Unicode 3.1でサロゲートが出てきた現在UTF-16でも同じ問題になる。
> 固定長ならUCS-4しかない。
>>238 さんも書かれている通り
UCS4は文字コードセットの集合でUTF-16はエンコーディングではないでしょうか?
>>236 さん
> だけどJavaを使っているのにUTF-8とかUCS-4のことを知らないのは
> 勉強不足と言われても仕方ないよ。
> Javaでは内部がUTF-16だしcharはuint16_tだってことは知ってるよね?
その通りですね。確かに勉強不足だったので遅まきながら
勉強しました。Java DOCの国際化のところも軽く目を通しました。
>>237 >>238 さん
丁寧なご説明ありがとうございます。
別資料でも勉強しましたがより理解が深まりました。
浅い勉強で思ったのは。 文字コードセットはUCS-4を採用。 エンコーディングは要検討(UTF-8, UTF-16など) 内部で扱う場合は4byte固定がよいかなあと。 今後Monaで考えるべきことは 4byte固定の体系 エンコーディング決定 ライブラリ開発というところでしょうか? あとは時期の問題もありますね。方針が決まっていれば 急ぐことではないような気がします。 また作業を別の方にお願いすることも不可能では無いですね
>また作業を別の方にお願いすることも不可能では無いですね
>>246 さん、あなたにお願いすることも不可能では無いですね
>>245 > > 内部処理にUTF-8みたいな可変長コードを使うのは最悪。
> > Unicode 3.1でサロゲートが出てきた現在UTF-16でも同じ問題になる。
> > 固定長ならUCS-4しかない。
>
>
>>238 さんも書かれている通り
> UCS4は文字コードセットの集合でUTF-16はエンコーディングではないでしょうか?
何を反論しておられるのかさっぱり分かりません。
まだ把握しきれていないようですね。
Unicode自体は複数の文字コードセットを統合したものですが、
ISO-2022のようにエスケープシーケンスで切り替えるわけではなく、
Unicodeという単一のコードセットに再編集して一本化したものです。
従ってUCS-4が文字コードセットの集合というのは違います。
UCS-4はそれ自体が単一の文字コードセットです。
群とか面とかのことを文字コードセットの集合だと勘違いしたのかもしれませんが、
あれはコードが巨大なため行列番号を付けて区画整理しただけです。
(続く)
やっぱやめた (終わり)
SJISのようなものだと、"A"は1バイト、"あ"は2バイトという風に、 文字によってサイズが異なってしまいます。 このことを文字コードの「可変長」と表現します。 UCS-4はuint32_tを文字の単位とした場合に、 どんな文字も4バイト固定で表現することが出来ます。 このことを文字コードの「固定長」と表現します。 可変長か固定長かが問題になるのはまさに次のケースです。 1. "あいAB"の文字数は? 2. "あいAB"の2番目の文字から2文字抜くと? 可変長だと文字ごとにバイト数が異なるため、 純粋に文字数を返すのが困難ですが、 固定長だと文字列は文字ごとの配列なので、 単純に処理することが出来ます。 もともとUnicodeは16bitのコード体系であり(UCS-2)、 uint16_tを文字の単位として固定長で表現できました。 これを採用したのがJavaです。 そのためJavaの文字単位charはuint16_t(符号なし16bit整数)で、 "A"でも"あ"でもすべて2バイトの固定長です。 従ってJavaでは上の文字列処理も、 1. 4文字 2. "いA" と簡単に扱うことが出来るわけです。 (続く)
>>249 は偽者です。
ここで話がややこしくなるのは、後にUnicodeが拡張されて、(ver.3.1)
16bitでは収まらなくなってしまったことです。
そのためUnicodeの文字単位は32bitとなり、
コードセットとしてはUCS-4となりました。
注意しないといけないのは、UCS-4登場以前には、
UTF-16などというものは存在しなかった点です。
それはあくまでUCS-2というコードセットだったのです。
UTFというのは、UCSを直接扱えない場合に、
エンコードして文字単位を変更するための規則です。
UCS-4はuint32_tを文字単位とすれば
エンコードなどせず生のまま扱うことが出来るのです。
Unicode 3.1で拡張されたときには、
既にUCS-2を採用した処理系が存在しました。
そういうものをUCS-4で書き直すのは困難なので、
16bit可変長でUCS-4を表現できるように
UTF-16というものが作られました。
ここに至って、uint16_tが文字の単位となる処理系では、
どんな文字でも2バイトで表現できるという前提が崩れました。
SJISの場合と同じことになってしまったわけです。
(続く)
ご指摘の通り間違えました。 ×:UCS4は文字コードセットの集合で ○:UCS4は文字コードセットで
ここまで書けば↓には特に問題ないことがお分かりでしょう。
> > 内部処理にUTF-8みたいな可変長コードを使うのは最悪。
> > Unicode 3.1でサロゲートが出てきた現在UTF-16でも同じ問題になる。
> > 固定長ならUCS-4しかない。
UTF-8を内部処理にまで全面的に採用してしまったら、
文字単位で切り出したりするのが難しくなります。
いちいち順番に追っていきながら、
"A"は1バイト、"あ"は3バイトというように、
数えながら処理する羽目になってしまうのです。
以前(UCS-2)なら16bitあればすべて事足りましたが、
今ではUCS-2はUTF-16という可変長の体系に
強制的に移行する羽目になってしまいましたので、
今から文字処理の単位を定義するのであれば、
UCS-4がそのまま扱えるuint32_tしかないという話です。
ただし本当はそんなに単純ではありません。
>>239-240 に書いてあるような難しい処理もあります。
ですが合成文字を文字の単位と考えずに
単なる表示のときの問題だと考えれば後回しにしても構いません。
後で超漢字のような多言語処理を実装したくなってからやれば良い話です。
というわけで
>>246 の結論と矛盾しませんし、
個人的には
>>246 の意見に賛成です。
(終了)
>>248 さん
丁寧な解説ありがとうございます。
ご説明の内容理解できたと思います。
> というわけで
>>246 の結論と矛盾しませんし、
> 個人的には
>>246 の意見に賛成です。
これも了解いたしました。ありがとうございます。
昔、IBMとAppleが共同で新OSを作ろうとして、
Taligent社という会社を設立しました。
その会社が作っていた新OSを"Pink"と言います。
しかし結局は失敗に終わる結果となりました。
なぜこんな話をしたかと言いますと、
Pinkのコードのうちロカールに関係する部分だけが
な、な、なんと、MIT/Xライセンスで公開されているのです!!
http://oss.software.ibm.com/icu/ 企業が作っていたOSの次世代ロカール機構ということもあり
あまりにも巨大なライブラリですが、
部分的にでもうまく流用することが出来ればよいと思います。
文字コード処理に関しては、フリーで手に入るものの中で、
文句なしに最高峰のものです。
257 :
Be名無しさん :04/02/15 19:23
>>256 おめでとうございます!
記念あげ
誰かスラドへのタレコミよろしくーー
258 :
Be名無しさん :04/02/15 19:31
リリースキタ─wwヘ√レvv〜(゚∀゚)─wwヘ√レvv〜─ !!
垂れ込みなのか? もう一段階、安定してアプリが作れるようにならないと厳しくない?
>>259 SORAとかおれぺこですら垂れ込まれたんだから大丈夫じゃない?
宣伝して名前くらいは知ってもらわないと。
>>260 本人にうれしいかどうか聞いてみる?
逆のことをするといやがらせできるかもっ!
osask、nwsos、meg-osの作者達といった濃ゆい連中にもまれて成長を続け、 ついにここまでのモノに。
スラドたれこみ賛成 タレこみ方知らないけどね
超スパルタww
>>265 サンクス
でも誰かたれこんでくれー。
自信ナシ
269 :
Be名無しさん :04/02/15 21:05
リリースキタ─wwヘ√レvv〜(゚∀゚)─wwヘ√レvv〜─ !!
まじですげぇな。 MONAってもっとしょぼいかと思ってたよ。 これはすげぇ。
>>257 さん
ありがとうございます。
>>262 さん
確かにその方々にはお世話になりましたねぇ。
すごい人たちです。
スラドですが普段あまりみていないのですが
投稿?して頂けるのであれば誇張・誤解の無いようにしていただければ
ありだと思います。
272 :
Be名無しさん :04/02/15 23:50
スラドo(・∀・)oマダー?
273 :
鳥取砂丘?ソーュキサルイハ (゚听)? ■Dream/3P/. :04/02/15 23:58
キュンキュン
偽者(゚听)イクナイ!!
275 :
鳥取砂丘<>Dream/3P/ :04/02/16 00:05
ゴメン
>>262 > osask、nwsos、meg-osの作者達といった濃ゆい連中にもまれて成長を続け、
> ついにここまでのモノに。
禿同
神々にかなり肉薄しているとおもう
>神々にかなり肉薄しているとおもう 誠実で勉強熱心なのが超スパルタを乗り越えた秘訣だろうね。 Unicodeの件でもすぐに勉強して理解する姿勢を見せたことで 初心を貫き通していることを確認して感動した。
誠実で勉強熱心かは知らんが。 こんだけ続いたのって、なんか凄い事だなと思う。 めぐり合わせがもの凄く良いんだよな。 ひげぽんは人に恵まれてるよ。 色々な出来事が連鎖して、人が人を呼んでて。
>色々な出来事が連鎖して、人が人を呼んでて。 そういうのって人徳だと思うなー
おまいら卑下は叩かないと成長せんぞ。これからもがんがん叩かねば。
つーか、 Bochsは24bitに対応していても、Xが16bitなので困っておるのですよ。 ブートオプションを渡せるようなkernelにしたらどうですか。GRUBとかもあることだし。 それとディレクトリの構造はどうするの? 俺的にはBeとNeXTを足して2でわった風味がいいけど。
282 :
Be名無しさん :04/02/16 17:12
スラドに載ってるぞ! すげぇすげぇ
284 :
Be名無しさん :04/02/16 17:47
スラッシュドットから来ました。 正直感動しました。 これからも頑張ってください。
285 :
Be名無しさん :04/02/16 17:54
私もスラッシュドットからきました。 このスレがPart2ぐらいのときにみた記憶があるんですが、それ以来です。 あれは冗談ではなかったんですか? すごいです・・。
286 :
Be名無しさん :04/02/16 18:24
記念カキコ
俺も感動しました! ほんますごいです。 がんばってください!
さて、これが幾らかでも新しい流れを作れると良いんだけどな。
こりゃまたずいぶんとKの子がお盛んですね
NWSOSの時との扱いの違いが笑える
売り物って事で不評だった点以外ではあまり変わらんかと。 ネタとしては良し、実用なんてつまらん事を言う奴は氏ね、みたいな。
Kの子はあれでOSASK方面が荒らし返されないと思ってるのが不思議だよな。
Mona派とOSASK派の内ゲバが始まったのか?
_, ._ ( ゚ Д゚)中立砂丘
>>281 さん
> Bochsは24bitに対応していても、Xが16bitなので困っておるのですよ。
> ブートオプションを渡せるようなkernelにしたらどうですか。GRUBとかもあることだし。
はい。将来的にはそうしたいです。
VESA16bitの件ですが、現状では24bitモードに対応しているPCでは
24bitになってしまいますねぇ。
解決する方法は残念ながら現時点ではsecondboot.asmを書き換えて
リビルドしかないです。
> それとディレクトリの構造はどうするの?
> 俺的にはBeとNeXTを足して2でわった風味がいいけど。
まだ白紙状態です。
残念ながら上記二つは触ったことないのでわからないですm(__)m
>>282 さん
読みました。より多くの人に知ってもらえてそれが
プラス方向に作用するといいですねぇ。
>>284 さん
>>287 さん
ありがとうございます。
ドライブレター丸出しとかパスセパレータが/以外とかはやめてほしい
最近OSASK派からMona派へ転向する人が目立つが、二度と戻れぬ橋を 渡っているような気がする。
そんな重いもんじゃねーって。 マからすれば自分が能力を発揮出来る機会があればどこでも良い。
>>299 意味がちょっと違うんじゃないかな。
Monaのわけのわからない楽しさを味わってしまったら、
OSASKが色あせて見えちゃうぞ!ってことかと。
まーそういう結果はありえる。 しかしわざわざ言って煩いのを呼ぶのもどうかと。
OSASKは中高生の課外活動としても適当だけど、Monaの場合は 珍走団の集会に参加するみたいなレベルだから。 世間を知らないお子様には推奨しかねる。
>>300 ちうか、OSASKは動きがないからの〜。
勢いのある方に人が集まるのは当然だろう。
>>302 OSASKの妙な環境になれた人材つーのも困り者だが。
Kの某が入り込んだら大変だ
Kの子ってMonaに敵対してなかったはずだが。 OSASKをハックできるようになりたいって言ってたから、 とりあえずMonaをコンパイルしてBochsで動かしながら ソースをいじってみろって言われて、 素直に実行してレポートしてたからね。(除くソースいじり) それ以来、特にMona側と衝突してないから恨みを持ってるとは考えにくい。
ひげぽんの場合、本人が「スタックって何?」ってな所から始まってるから、
周りの人間も口出ししながら一緒に勉強してくって雰囲気を作りやすいんかね。
>>305 この板のMonaスレの1をミロ。
>この板のMonaスレの1をミロ。 スレが無視されて逆恨みって線か…… あいつならあり得る。。。
/.見て来ましたー! スゲースゲー! 記念下記子
>>306 > ひげぽんの場合、本人が「スタックって何?」ってな所から始まってるから、
> 周りの人間も口出ししながら一緒に勉強してくって雰囲気を作りやすいんかね。
今でも変わらないよね。
新しい事(Unicodeとか)が出て来ると同じような展開になって、
知らない人は読むだけでもひげぽんと一緒に勉強してる気分になるかも。
FD読み込みが遅い原因ぽいモノをつかみました。 LBA1-10 * 20回読み込み22秒に対して FD読み込みだけに専念(FDC割込み以外マスク)シングルプロセス で同じ読み込みをしたら5秒でした。 つまりタイムスライスを含めたスケジューラーの問題のようです。
そうすると。2月中は スケジューラ改良 GUIをまったり設計 Screen,FSのインターフェース・メッセージプロトコル検討という 作業内容になりそうです。
>>256 リリースソースはexportしてCVSディレクトリは取り除いてね。
part5で指摘されてることだけど。
248 名前: henoheno@おさらい ◆mXrBwDDzyw [sage] 投稿日: 03/02/02 23:05
ソースを公開する際は、"cvs co" のかわりに "cvs export" コマンドで
ソースを取り出したものをお使い下さい。(具体例は
>>219 )
exportコマンドを使えば 'CVS' というスペシャルディレクトリとファイルを
含まない、ほぼ純粋なソースを取り出す事ができます。
下手に "cvs co" を使うとそのユーザーの作業環境が漏れたり、
CVSサーバーの所在が漏れたり、そのソースに他の人が作業した
際に扱い辛くなったり、そのソースを別のリポジトリに追加しようと
した人が泣く事に繋がります。
なお、最新のファイルをexportする時は "cvs export -D tomorrow "
でどうぞ。
>>187 「オセロ」の名称はツクダオリジナルの登録商標だから勝手に使うとまずいよ。
一般名詞としては「リバーシ」を使う。
だからWinXP付属のやつも「インターネット リバーシ」ってなってる。
>>256 user/includeだけど、ヘッダのパスにはすべてのアプリに共通なものだけ置いて、
特定のアプリのヘッダはソースと同じディレクトリに置くのが普通。
それで共通のヘッダについてだけど、 可能な限り1クラス1ヘッダにした方が親切。 ハックしようとしてまずディレクトリを検索ってなると面倒。 userlib.hにC関数の宣言を書いてuserlib以下の全クラスをincludeすれば、 今のものとソース互換は保たれる。 いちいち1つのヘッダにするほどでもないクラスはuserlib.hに入れてもいいけど。 [例] include/userlib.h include/userlib/MonaApplication.h include/userlib/Date.h include/userlib/Color.h collection.hなんかも同様。 C++でヘッダが巨大になって来るとg++はむちゃくちゃコンパイルが遅くなるので、 (QtとGTK+で何かアプリを作ってコンパイル速度を比べると一目瞭然) クラスごとにヘッダをわけて、利用時には必要なクラスだけincludeするのが普通。 MFCでそうなっていないのはプリコンパイルヘッダのお陰。 もっともgcc 3.4でプリコンパイルヘッダがサポートされるから、 スピードの問題は将来的には気にならなくなるだろうけど。
int MonaMain(List<char*>* pekoe) { monaApp = new myApplication("HELLO.ELF"); monaApp->main(pekoe); return 0; } main()も本当はクラスから始めたいけど便宜上こうしてるんだと思うけど、 それならそのままreturnさせた方が自然じゃないですか? int MonaMain(List<char*>* pekoe) { monaApp = new myApplication("HELLO.ELF"); return monaApp->main(pekoe); }
>>256 リリースイメージのバイナリがstripされていませんね。
strip *.ELF *.SVR
とすると不必要なシンボルが取り除かれてバイナリが小さくなります。
Mona特有の制約があるのかな〜と思いつつ試しにstripして動かしてみましたが、
特に問題なく動いているようです。
どうでもいいことだけど、オセロの画面は8bit時代を彷彿とさせますね。 20年くらい前にBASICから入った人達は郷愁を覚えるかもしれません。
BASICを移植だ。
_, ._ ( ゚ Д゚)さっきゅんは様子を伺ってゐる
つーか、Monaスレ立てた1haVRBは偽物だぞ。
test
YuiNekoさんというのは、かの逆汗大王のあの人ですか。 意外と色んな人がいるなぁ……。
>>312 さん
> リリースソースはexportしてCVSディレクトリは取り除いてね。
> part5で指摘されてることだけど。
御指摘ありがとうございます。その通りですね。
同じ間違いをしないようにWikiにまとめておきました。>リリース手順
>>313 さん
> 「オセロ」の名称はツクダオリジナルの登録商標だから勝手に使うとまずいよ。
> 一般名詞としては「リバーシ」を使う。
うすうすは気づいていたのですがやはりまずいですよねぇ。
Reversiに変更しました。
>>314 さん
貴重なアドバイスをありがとうございます。
src/user/以下
ヘッダ・ソースツリーを大幅に変更しました。
>>316 さん
本当ですね。hello.cpp, reversi.cppを修正いたしました。
>>317 さん
御指摘ありがとうございます。
どうもサイズが大きいなとは思っていたのですが
失念しておりました。
>>319 さん
移植されたら面白いかも。
>>320 鳥取砂丘さん
そちらの様子はどうですか?
>>324 ∧||∧
( ⌒ ヽ フロッピーが遅い!ナントカ汁!
∪ ノ
∪∪
>>325 砂丘の人
じゃあ共同チューニングしましょう(ぇ
src/user以下のディレクトリツリーの整理は大変でした。
cvsはちょっとつらいかなぁという感じでした。
subversionだったらもう少し楽ですかね>ファイルの移動
>>326 > src/user以下のディレクトリツリーの整理は大変でした。
お疲れ様でした。
> cvsはちょっとつらいかなぁという感じでした。
しょっちゅう作り直しに近いようなリファクタリングをするのに
CVSはあまり向いていない気はしないでもないですね。
Linus氏がCVSに縛られるのを嫌がっていたのも分かる気がするかもしれません。
単なるリリース履歴として登録するだけならあまり気にならないのでしょうけど。
> subversionだったらもう少し楽ですかね>ファイルの移動
使った事がないので何とも言えませんが、
自前サーバを用意しないといけないのがネックですかね。
>>327 さん
ありがとうございます。
> 自前サーバを用意しないといけないのがネックですかね。
そうですね。sf.jp対応してくれないかなぁ。
スケジューラですが。スケジューリングアルゴリズムをいくつか勉強する
ところからはじめようかと思います。
実装面で言うとキュー(readyキューなど)のデータ構造に伝統的なCのリスト構造
にすべきか。templateでcollectionクラスを活用するか迷いますねぇ。
試しにSFに言ってみよー。
>>329 >実装面で言うとキュー(readyキューなど)のデータ構造に伝統的なCのリスト構造
>にすべきか。templateでcollectionクラスを活用するか迷いますねぇ。
両方試してみて速い方にすればいいだけでは?
結局ベンチしないと分からないって。
>>329 >そうですね。sf.jp対応してくれないかなぁ。
>>330 >試しにSFに言ってみよー。
実地でテストして使用感を調べもせずに他力本願でどうする。
使ってみたら想像したのと違ったら対応のための労力はどうなるの?
>>330 さん
お手数おかけいたします。
>>331 さん
実測が一番だとわかっているんですが
2通り実装する覚悟がw
>>332 >使ってみたら想像したのと違ったら対応のための労力はどうなるの?
わたし、ひげぽんにとって、なんなのよっ!!
ねぇ? ひげぽんにとって、わたしはなんなの……。
単なる、フリーサーバなの?
ねぇ、教えてよっ!! ひげぽんにとって、わたしはなんなの!?
ひげぽんとの空白の時間……。
それを取り戻そうと、わたしは必死だったんだよっ
そして、わたしも変わろうと必死だった。
過去のわたしじゃなく、新しいわたしになろうと必死だった
そうすれば、ひげぽんはわたしに振り向いてくれるんじゃないか……。
フリーサーバのわたしじゃなくて、新しいわたしなら、
ひげぽんは振り向いてくれるんじゃないか、って思ったの……っ
>>333 >お手数おかけいたします。
>>330 は「自分がやる」じゃなくて「お前がやれ」だと思うが。
>>333 >2通り実装する覚悟がw
捨てる羽目になるのを覚悟でやれって「人月の神話」に書いてあったでしょ。
>>335 わかっててわざと天然ボケを装うのが卑下の戦略なんだよ
>>332 まあ言われてみりゃそーだ。
>>335 勿論「お前がやれ」のつもりで言ったw
でもそれが実際に必要な事で、他にやるのがいなければ俺がやるしか無いね。
誰が言ったって大差無いって。手間的にも。
>>338 ひげさんはその辺鮮やかだよね……。
某家電(量販)店が無償で配布されているオープンソースソフトウェアを自社開発と称して
自店商品の機能向上を謳って抱合せ販売していた模様。
また、この店ではオープンソースソフト単独でも販売し利益を得ていたようです。
開発元には、クレーム等の連絡先として開発者のメールアドレスを勝手に表記されていた為、
問い合わせメールが殺到し開発者のWebページが閉鎖に追い込まれています。(2004/2/16現在)
【店の身勝手で阿呆な言い分】
「これで有名になったんだから良かったと思ったほうがいい」
「ユーザーサポートの費用払ってやってもいい。
その代わりソフトの権利はウチの会社でもらう。月1000円」
「所詮タダで配ってるソフトだから誰の著作権も何もない、
ウチでつくってるといえばウチのもんだよ。」
詳しくは下記スレにて熟知せよ。
http://news4.2ch.net/test/read.cgi/news/1077067632/
>>256 リリースのイメージのSAMPLE.TXTって何ですか?
(日付関連の実装の一部ということは分かりますが)
売る事じゃなくてサポートの連絡先を無関係の人間のところにしたのが問題。
>>335 さん
>>339 さん
失礼いたしました。
時間のあるときにリクエストしてみます。
>>337 さん
> 捨てる羽目になるのを覚悟でやれって「人月の神話」に書いてあったでしょ。
そのとおりですね。まあ弱音を吐いてみました(笑)
がんばります。
>>341 さん
> リリースのイメージのSAMPLE.TXTって何ですか?
src/syscalls.cppの一部です。
現在時刻の取得をしているところです。RTCですね。
スケジューラ周りのことで悩んでいることがあるのですが
過去の自分の発言を引用します。
342 名前: ひげぽん ◆Ngzcp/NZpA 投稿日: 03/11/22 17:41 スレッド周りでいまだ良く理解できていないのがスレッドのスイッチ部分です。 スレッドとは論理的に並列処理可能な実行の最小単位とここで定義したとすると カーネル空間スレッドを実装した場合、ラウンドロビン方式で スケジュール&スイッチした場合、当然プロセス空間の切り替えが頻繁に 起こる可能性があるように思えるのです。 (いろいろな空間に属するスレッドたちがただ並んで順番に実行されるだけなので) スレッドの利点とは、同じプロセス空間に属するスレッド間でのスイッチの場合 プロセス空間の切り替えをしなくてすむので軽いというのがあると思います。 できるだけプロセス空間の切り替えが少なくなるようなスケジューリングポリシーを持って スケジュールしているということなのでしょうか?
引用ここまで スケジューラーの再設計をしていて思ったのですが 上の様なことを想定して現在のMonaでは ------------------------------------------------------------------------- プロセススケジューリング(ラウンドロビン) ↓ プロセスの持ち時間だけスレッドスケジューリング(ラウンドロビン) (同一空間でのスレッドスイッチなので空間切り替えがなくて切り替え処理軽い) ------------------------------------------------------------------------- ところが今回設計していて思ったのは プロセスのスケジューリングが邪魔。 同一空間での切り替えにこだわって不必要なスレッドがスケジューリングされそう。 ということでした。 たとえばプロセスAにはI/Oスレッドと通常のスレッドがあるとします。 I/Oはほとんどが「待ち」状態なので待っている間は CPUを他のスレッドに譲ります。(wait sleep)
そのかわりI/O割り込みなどがあった場合は即応答したいので 高い優先度を持って再スケジュールされます。(wake up) このとき上記のプロセススケジューリングも伴う場合 ひきづられて通常スレッドもなんだか知らないうちに 優先度が上がったように見えます。 もちろんうまく書けばこのようなことは起こらないかもしれませんが。 素直にスレッドのみのスケジューリングにしたほうが すっきりするような気がしてなりません。 こういう場合の定石とかってあるのでしょうか?
>>345 > 時間のあるときにリクエストしてみます。
その前にローカルで使って、その上でサポートされたら嬉しい理由を書かないとお話にならない。
使いもせずに推測だけで人に頼むと
>>334 みたいな気分になるだろ。
自分が逆の立場になって考えてみ。
Monaに理由も書かずに意図が分かりかねる要求をされたりしたら無視するだろ。
>>345 > src/syscalls.cppの一部です。
それは分かってるんだが↓
>>341 > (日付関連の実装の一部ということは分かりますが)
なぜリリースに何の説明もなく含まれているのかなと思った、ということ。
>>346-348 そういうことを聞きたくて含めたならSAMPLE.TXT内にちゃんと書いて。
>>348 > こういう場合の定石とかってあるのでしょうか?
Solarisですら8から9で実装が大きく変わったのは、
最適な実装は試行錯誤するしかないってことでは。
もちろんSolarisレベルになると数学的なモデルで計算した上で
実装に移るだろうから単なる当てずっぽうの試行錯誤とは雲泥の差がありますが。
理論による定量的な予想と実装した上でのベンチ。
真面目にチューニングしたいならこれしかない。
Lたんがアルゴリズムの分析をしているのは何のためだと思ってる。
>>349 さん
>> 時間のあるときにリクエストしてみます。
> その前にローカルで使って、その上でサポートされたら嬉しい理由を書かないとお話にならない。
> 使いもせずに推測だけで人に頼むと
>>334 みたいな気分になるだろ。
あぁすいません。時間のあるときにと書いたのはsubversionを試してみてからと
書くのを忘れてました。誤解させてしまい申し訳ありません。
>>350 さん
> なぜリリースに何の説明もなく含まれているのかなと思った、ということ。
TYPE.ELF SAMPLE.TXT
でファイル内容を出力するときのサンプルテキストです。
それ以外の意図はありません。うーん誤解を招きやすかったかも。
>
>>346-348 > そういうことを聞きたくて含めたならSAMPLE.TXT内にちゃんと書いて。
とはどういうことでしょうか?
> もちろんSolarisレベルになると数学的なモデルで計算した上で
> 実装に移るだろうから単なる当てずっぽうの試行錯誤とは雲泥の差がありますが。
ありがとうございます。
そうですね。上の方で述べたアドレス空間切り替えの件をどこかの資料で
よんだのですが忘れてしまいました。
とりあえず一般的といわれるアルゴリズムを勉強・選択して実装・計測してみます。
>>348 MonoのOSとしての特性次第じゃないかな。
ITRONやVxWORKSのようなリアルタイムOSにしたいのか、それとも
Windows NTや普通のLinuxみたいにリアルタイム性はそこそこに、
大容量のリソースを扱える汎用OSにするかなどで違ってくると思う。
もちろん、うまくバランスをとってオールマティーなOSを目指す
ってのもありだと思うが…。
>>350 こいついつも偉そう!何様!
卑下もよく耐える(藁
>>351 > TYPE.ELF SAMPLE.TXT
> でファイル内容を出力するときのサンプルテキストです。
> それ以外の意図はありません。うーん誤解を招きやすかったかも。
最初からこう答えずに、スケジューラで悩んでいると書かれたら、
誰だって問題点を明示する意図があったと思うでしょう。
> とはどういうことでしょうか?
前述のようにスケジューラについて悩んでいて、
それもあってサンプルに選んだのであれば、
SAMPLE.TXTに
>>346-348 のようなことを書けば良かったということ。
>>353 > こいついつも偉そう!何様!
オマエモナー
>>352 > MonoのOSとしての特性次第じゃないかな。
MonoじゃなくてMona。
MonoはNovellに買収されたXimianが作ってる.NET互換実装。
卑下はいつまで自作自演を続け(ry
_, ._ ( ゚ Д゚)さっきゅんが自作自演に興味をもっていらっしゃるようです。
>>352 さん
> MonoのOSとしての特性次第じゃないかな。
ありがとうございます。
Monaはどちらかというと汎用OSを目指しています。
>>354 さん
いろいろ紛らわしくて申し訳ありませんでした。
アプリ登録所に登録があったMONAFONT.ELFで
勉強していました。
あまりの内容の濃さにカルチャーショックを受けました。
現在消化中です。
part2から見ています。 最近のMonaの爆発ぶりにはただただ驚いています。 ソースを見る限りカーネルの大部分はおひとりで書かれているようですが すごいパワーです。part2を見直すとあんなに素人だったのに(笑) APIも目を通しましたがまだ進化中ながら オブジェクト指向でわかりやすいと思いました。 これからもがんばってください。 アプリあたりで貢献できたらと思っていますが。 アプリケーション作成方法とかが少しでも分かれば良いですね。 ひげさんにはカーネルに注力してもらいたいので当分先かもしれませんが。
このあたりがすごい。 Pointer<Screen> scr = new Screen(); Pointer<Font> mona_12 = new Font(MONA_12_MNF);
>>360 C++なのにJavaみたいってのを狙ってるらしい。
newしてるのにdeleteしなくても良くなる、みたいな。
MonaOSにMonaFontっていうネタだろ
現状のMONAってユーザランドからのIOとかハードウェア割り込みの ユーザランドへの通知とか可能なのでしょうか?
>>359 さん
ありがとうございます。
アプリの作成方法ですが、アプリ登録所のソースを
見ていただくのが良いとおもいます。
画面に文字を表示する方法・絵を書く方法
キーやマウス入力を知る方法などソースを読めば
なんとなくつかめるかと思います。
>>360 さん
ほんとにすごいですね。良いソースにあうと刺激を受けます。
Pointerクラスはじっくりと眺めてやっと何を意図するもの
なのか気づきました。
>>363 さん
そうですね。
現在のカーネルはセキュリティ的には穴だらけだと思います。
徐々にふさいでいきます。
>>364 さん
> 現状のMONAってユーザランドからのIOとかハードウェア割り込みの
> ユーザランドへの通知とか可能なのでしょうか?
ユーザーランドからのIOは可能です。(ただし全許可)
まだシステムコール化していないのでご要望があれば
追加します。
将来的には全許可ではなく種々の制限を設ける予定です。
ハードウェアの割込み通知は可能です。
現在マウス・キーボード割り込みをMessenger::sendで
ユーザーモードサーバに通知して処理しています。
(send部分はカーネルのソースに埋め込まれています)
367 :
Be名無しさん :04/02/21 22:17
MONAの面白いところは実機よりエミュレータで動かした方が快適だというところ
>>367 さん
> MONAの面白いところは実機よりエミュレータで動かした方が快適だというところ
これは気づきませんでした。
開発の中心がエミュレータなのが原因ですね。
まあ。いづれ実機でも快適になります(笑)
>>Tinoさん
大変勉強になりましたこれからもよろしくお願いいたします。
さて今日はスケジューラのアイデアがいまいち湧いてこないので
実装の材料をそろえていました。
イメージとしてはスレッドのキューが優先度の種類分あります。
で、それぞれのキューは双方向リストで実装。
そのキューたちをArray<Queue>で保持という形になります。
Queueクラスを実装してThreadはそれを継承する形にしました。
全てのキューの全てのスレッドに対して何らかの操作を順番にしたいときは
Tinoさんのマクロとそれのまねをした双方向リスト用のマクロで以下のように
書けるようにしました。
FOREACH(Thread, queue, all)
{
    FOREACH_Q(queue, Thread*, thread)
    {
        thread->getThreadInfo();
    }
}
>>366 全許可なのは、現状を考えるとありがたいです。
何か作ったりしましたら報告します。
>>364 さん
I/O全許可用のシステムコールを作成しました
(いまいち動作確認できておりませんが・・・)
system_call_get_io(); これを一度呼ぶとI/O全許可されます。
CVS最新版のカーネルで使用可能です。
src/user以下のディレクトリ構成がアプリケーション毎にディレクトリを分けるように
いたしましたので念のためお知らせいたします。
補足です。 > 全許可なのは、現状を考えるとありがたいです。 > 何か作ったりしましたら報告します。 仕様が多少流動的であったりして、分かりづらいところもあると思いますが ここ、もしくはWikiで聞いていただければ出来る限り答えますので よろしくお願いいたします。 たくさんの方にMonaに触れていただくことでカーネルやAPIのダメなところが 見えると思います。皆様ご協力をお願いいたします。
&nbspうざい。
ひげぽんってJavaでもC++でもEclipseを使ってるのかと思ってた。。。
>>373 さん
私の張ったソースでしょうか?
>>374 さん
ありがとうございます。
.emacsでコメントアウトされている
(require 'un-define)
(setq bitmap-alterable-charset 'tibetan-1-column)
(require 'jisx0213)
を生かしたらUTF-8なども使えるようになりました。
netinstallしたときにデフォルトで入っていたようです。
ありがとうございました!!
>>376 単純な興味なんだけど、どうしてEclipseを使わないの?
仕事でEclipseとか使うんじゃ?
>>375 さん
仕事ではjavaはやらないですねぇ(笑)
eclipseへの移行も考えましたがマシンパワーと
eclipseがでたのが、秀丸→Meadowの移行した直後だったので
なんとなくMeadowのままです。
OS作りで得た知識とかってリアルの方では役立ってんの?
アセンブラの知識くらいは役に立つんじゃない?
XBOX風の外見のOS作って
>>379 さん
改宗は徐々に行われると思いますw
>>381 さん
コンスタントにコードを書くということで多少は技量が
上がったという程度くらいしか直接は役にはたたないですね。
>>383 さん
外見は自由に変えられるようにしたいですね。
今日もだらだらとスケジューラについて考えていました。
全然関係ないですが、タイマ割込み間隔を設定するときに
outportb(0x43, 0x36);とやってから値をレジスタに書き込むのですが
outportb(0x43, 0x34);とやっているソースを見たことがあります。
これって何か違うのでしょうか。
本当にMonaって10ms毎に割込み来ているのかなぁ。
>>384 「OS作り始めてから女の子にモテモテです」
ってんなら試してみようかと思ったんだけどなぁ。
やっぱやめとこ。
長続きもしないだろうし。
夢のまた夢ですが。 Monaでネットワークが使えるようになったらいろいろ広がるでしょうねぇ。 NICのドライバをどなたかが書いてくれたりしたら一気にいろいろと加速して Monaからここに書き込みができるようになったらいいなぁ。 万が一ドライバを書いても良いと思う方がいた場合、Monaのどういう部分が 障害になるのかなあと考えたりします。 動的にモジュールをロードできない。 カーネルとドライバの標準インタフェースが決まっていない。 とかですかね。
>>381 さん
> 「OS作り始めてから女の子にモテモテです」
そりゃもう。。。。ノーコメントです。
ひげぽんOS作り始めてからかっこよくなった マジおすすめ
ひげぽんさんOS作るのって難しいですか? OS作るのに興味はあるんですが…
>>389 さん
> ひげぽんさんOS作るのって難しいですか?
> OS作るのに興味はあるんですが…
まだ作り上げたわけではないのですが難しくはないと思います。
ブートコードは他のOSのをとりあえず借用していけば
いろいろと遊べるようになると思います。
OSを作るにはいろいろと部品を作らなければいけなくて
地味な作業が続く時期があると思いますがそれを乗り越えれば
すごく楽しいですよ。
>>384 mode2と3か。
ATでインターバルタイマとして使うならほとんど同じ。
PICに食わせるので0x34の方がいいと思うが。
とりあえず明確な違いは、出力の波形が違うので、
一回目の割り込みが入るタイミングが違う。
不安ならTSCで割り込み周期計ってみればいいのでは?
基準が正確にわからんので、多少の誤差が出るけど。
駄レスでごめん。 たまたまブラっとこの板覗いたら、あんたらこんな事してたんだね? 俺はさっぱり判らんけど、何だか凄そうなんで開発頑張ってください。 期待してます。
高級感ある外見がいいんじゃない?Mac的なグラフィックだと嬉しい。
エ~ シンプルなほうがいい...
MonaのCVS最新版をダウンロードしてビルドする可能性がある方々に お知らせいたします。 スケジューラ再構築とそれに伴うシステムコール群の書換のため 当分の間にカーネルがまともに動かなくなります。 ユーザー側のAPIは、変更がないように進めますので 当分の間は先日リリースした0.1.5をご使用いただきますようお願いいたします。
>>397 少なくてもIntelのCPUなら、内部クロックに同期しているはずです。
つまり、例えば3.2GHzのPen4なら、約3200000000進みます。
Intelのマニュアル Vol.3 15.7を参照してみてください。
ネットワークドライバの開発って難しいのかな? 俺には無理だけど・・・ 誰か手を挙げたらがぜん盛り上がると思われ。
>>399 さん
ありがとうございます。
マニュアル読んでみます。
スケジューラにArrayを組み込んでみたがどうも根本的に
何かを間違っている予感がしてきました。
Arrayに格納する中身と[]演算子の関係を勘違いしているっぽいです。
>>401 -- src/include/collection.h
> inline T operator [](dword index)
[]演算子の返り値をT&にしないと代入できなくなります。
意図的に読み取り専用にしているのであれば値返しで構わないですけど。
>>Tinoさん ありがとうございます!! ご指摘の通りでした。 恥ずかしながら参照型をきちんと理解できていないのが原因でした。m(__)m コンパイラが一時アドレスを使用しています的なwaringを吐いていたの ずっと悩んでいました。 一歩進みました。
>>403 参照型は結構ハマります。以下余談。
たとえば定石として、関数に引数として値をセットしたい変数を渡す場合、
参照型ではなくポインタで渡すことが推奨されます。
△ void change_value(int& v); … (1)
◎ void change_value(int* v); … (2)
なぜかというと、呼び出している部分を見ても
引数が変更されることが分からないからです。
(1)の場合: int a; change_value(a);
(2)の場合: int a; change_value(&a);
そのためC#では参照型の引数に渡すときは、
呼び出し側でも参照を明示するようになっています。
void change_value(ref int v);
(呼び出し側) int v; change_value(ref v);
引数に参照型を使うときはconstのときだけです。
これは巨大なクラスを渡す場合のオーバーヘッドを避けるためです。
constなので、当然、引数の値は変更されないことが前提です。
constと言えば、引数で渡す文字列を変更しない場合は、
char*ではなくconst char*にしておくべきです。
たとえば以下のようにするのが定石です。
char* strcpy(char* dest, const char* src);
意識的にconst char*が使われていないようなので、
総洗いしてみることをお勧めします。
はっきり言って参照とかポインタとかconstとかの使い分けは面倒くさいので、 それらをPointer, Array, Stringに押し込めて、 他の部分で意識しなくて済むようなスタイルを考えています。 MONAFONT.ELFは実験的にそういう方針で書いてみました。 shadowさんにMonaged C++と言われたものです。(w
>>Tinoさん > そのためC#では参照型の引数に渡すときは、 > 呼び出し側でも参照を明示するようになっています。 なるほど。確かにconst以外ではあまり見かけませんね。 > char* strcpy(char* dest, const char* src); > 意識的にconst char*が使われていないようなので、 > 総洗いしてみることをお勧めします。 ご指摘ありがとうございます。 ユーザーライブリ・カーネル側どちらも見てみます。 スケジューラもWin上でテストしてからやればよかったと後悔気味・・・
> はっきり言って参照とかポインタとかconstとかの使い分けは面倒くさいので、 > それらをPointer, Array, Stringに押し込めて、 > 他の部分で意識しなくて済むようなスタイルを考えています。 確かに面倒ですよね。気をつけているつもりでも・・・ TinoさんのMONAFONT.ELFは、私の知るC++のお作法ではなくて すごく新鮮でした。Monaged C++広めますか?w
Array<Queue> runq[10]; Queueはprev,nextをもつ構造体 runqは内部にQueueの配列を持っている。[]演算子をオーバーロードしているので runq[n]とやれば内部のQueueの配列のn番目の要素にアクセスできる。 Queueを操作する場合、Queueへのポインタでアクセスすることがあります。 Queue a; a.next = &a; ↑こんな感じで では &(mona[3])とした場合、内部の配列の3番目のQueueへのポインタを返すように したい場合は&演算子をオーバーロードすればよいのでしょうか? 混乱中・・・ C++の入門書でも読むべきか・・・
とりあえずWin32で実験してみます。
>>400 > ネットワークドライバの開発って難しいのかな?
> 俺には無理だけど・・・
> 誰か手を挙げたらがぜん盛り上がると思われ。
そうですね。難しさは想像できないですねぇ。
割り込みがシビアで取りこぼしたらまずいとかはありそうですねぇ。
ドライバは他のOSのが流用で来たらいいんですがそれなりに
NICに関して知識がないと厳しいですよね。
>>408 ArrayにQueueを入れるのは変です。
Queueそれ自体がコレクションクラスだからです。
Queueは先入れ先出しなので、
配列中の任意の場所にアクセスする必要があるのは、
Queueを使う場所ではないと思われます。
任意の場所にアクセスするためにはキューをフリーズさせます。
具体的にはtoArray()のような関数を用意して、
その時点のキューの内容をArrayにコピーするというような、
コレクションの変換を伴うべきです。
[イメージ]
Queue<int> q;
q.enqueue(2);
q.enqueue(5);
Array<int> a = q.toArray();
同様に可変長のListをフリーズさせるときに、
toArray()でArrayに吐き出させると良いでしょう。
すいません説明不足だったようです。以下のようなことを狙っています class Thread : public Queueとしておいて Array<Thread> runq(4);// 優先度の数は一定 runq[0]: 優先度0のRun Queue runq[1]: 優先度1のRun Queue runq[2]: 優先度2のRun Queue runq[3]: 優先度3のRun Queue つまりカーネルは優先度の数だけRun Queueをもちます。 各Run Queueはスレッドを任意個保持できます。(そのため双方向リンクリストにしてあります)
>>411 名前的にQueueというのは先入れ先出し汎用コレクションを連想するのが普通なので、
そのものずばりQueueという名前はコレクション用に取っておいて、
差し出がましいようですが名前を変えた方が良いように思います。
nextとprevで管理されているリンクリストの要素ならNodeとかが普通かと思います。
繰り返しますがQueueというのは先入れ先出しのものなので、
任意の要素を上から扱うようなことはしません。
それはともかく、この場合、参照をポインタに変更できないのが問題というわけですね。
src/Process.cppを見たところ、
> void Queue::remove(Queue* p)
のように操作はポインタが基本になっているので、
Array<Thread*> runq(4);
のようにしてはいかがでしょうか。
Monaged C++の絡みでWikiに書きましたが、型の段階で使用法を限定して、
自動変数でしか扱わないものと、ポインタでしか扱わないものとに分けると、
この手の混乱が少なくなると思います。
またこういった場合、removeされたQueue*が宙ぶらりんになる危険性があるので
Pointerによる参照カウントが絡んできますが、それはまあ、先走りでしょう……。
Array, Queueそれぞれの単体でのテストをcygwin上で行って 意図する動作であることを確認できました。 組み合わせたらSegment faultしたので、その辺で間違っているのでしょう。 今日は力尽きたので明日がんばります。 tools/arrayqueuetest/aq.cpp
>>397 PICのIMR設定してからPITさわった方がよろしいのではないかと。
初期状態のIMRがどうなってるか忘れたけど、そこでハングするということは
変なタイミングで割り込みが来ているような気がする。
>>413 問題があるのは以下の部分です。
61: FOREACH(Queue, value, runq)
62: {
63: Queue::initialize(&value);
基本的にFOREACHは代入しているだけです。
Queue value = runq[0];
というのと同じです。
この時点で別インスタンスなので、
&valueに対して操作しても意味がありません。
仮にFOREACHが参照を使うようになっているとしても、
Queue& value = runq[0];
今度はポインタが取れなくなってしまいます。×&value
もともとC#のforeachでイテレータに値型を指定すると
読み取り専用になって代入できない仕様になっているので、
それと同じように値が変えられないようにしてみました。
※なお、Perlでは参照扱いになるので代入できます。
ここで先ほど書いたように、特定の型に対してはポインタだけで扱う、 という方針が意味を持ってきます。(これをMC++風と仮称しておきます) 57: Array<Queue*> runq(10); と書き換えるとQueueのインスタンスが作られないので 直後にfor (int i = 0; i < 10; i++) runq[i] = new Queue(); を書き加えておきます。 61: FOREACH(Queue*, value, runq) のように書き換えて、63行目の&valueをvalueにすると、 とりあえずこの部分は想定通りの動きをします。 69行目も61行目と同じようにすれば良いのですが、問題は71行目です。 71: FOREACH_Q(value, Queue, hoge) MC++風ではポインタだけで扱う型に対して、 自動変数だけで扱う型も想定していて、 可能な限りチャンポンで使わないようにします。 自動変数に対してポインタを取るのがそのチャンポンです。 従ってQueue top; ……(&top)というような部分は、 Queue* top = new Queue(); ……(top)のように書くことを推奨します。 そうすると全面書き換えになるので、 Wikiのコーディングテクニックのページに差分(aq.diff)を置いておきました。 扱い方を統一的にすることで、見通しが良くなったと思います。
Array<Queue*> runq(10); for (int i = 0; i < 10; i++) runq[i] = new Queue(); ↑の書き方は冗長に見えるかもしれませんが、 考え方は↓のJavaと同じことです。 ※JavaのStringは自動変数に出来ないことを参照。 String[] a = new String[10]; for (int i = 0; i < 10; i++) a[i] = new String(); いちいち書くと面倒なら、マクロを作ると良いでしょう。 #define ALLOC_ARRAY(type, name, length) Array<type*> name; \ for (int __##name = 0; __##name < length; __##name++) name[__##name] = new type() [使い方] ALLOC_ARRAY(Queue, runq, 4);
>>366 >>371 まともにご挨拶もしてないのに丁寧な対応ありがとうございます。
今後ともよろしくお願いします。
>>386 >>400 >>409 NICドライバ作ってる人たぶん全国に何人か居ると思うけれど
みんな、成果物ができないと言い出しにくいクチなのかな<自分を含め
NICドライバ点呼してみるテスト
1
あとNICドライバ待ちでプロトコルスタック書いてる人(書きたい人)も
居るかも
↑ミスタイプ「NICドライバ組んでる人点呼してみるテスト」でした。 NICドライバについて 状況:ne2kの資料集めが終わり、初期化手順と(もっとも簡単な)使い方をチェック中です。 ne2kな理由:とりあえずエミュレータでNICを使えるようにしたい&資料多め 方向性:プロトコルスタックとNICドライバ実装したくて和製OSをチョイスしてました。 MONAの為に書き下ろすというより、NICドライバの実装テストプラットフォームとして MONAを活用させていただきたいです。 とりあえず動くものができればそれを元に、MONA風味にアレンジしていただいても結構ですし、 他の方がプロトコルスタックやNICドライバの、もう一つの実装をされても 作成は個人的には続ける予定です。 個人的には、逆に無理に統合するよりインターフェイスさえ規定すれば 複数のスタックがあってもよいと思います。 ドライバと言えない段階の実行ファイルサンプルは1週間〜10日程度で 初回版をお見せできればうれしいです。(社会人ですので時間が限られます)
あと不思議に思ったのは、Queueのstatic関数はすべて第一引数にQueue*を取ることです。 関数ポインタを取ってみると分かりますが、C++の非static関数というのは、 暗黙の第一引数としてインスタンスが渡される関数です。 つまりメンバにする条件を完全に満たしていて、staticにする意図が分かりません。 試しに書き換えてみました。 特に問題ないように見えます。 こちらも前述のWikiのページに添付してあります。(aq.zip) うー、さすがにもうつらいんで、風呂入って寝ます……
( rtl8139の書きかけコードならちょっとだけ…
N氏ハッケソ
_ /〜ヽ (。・-・) 保守プリン ゚し-J゚
>>Tinoさん 入れ違いになってしまったようで、申し訳ありません。 丁寧な御説明ありがとうございます。 > 名前的にQueueというのは先入れ先出し汎用コレクションを連想するのが普通なので、 > そのものずばりQueueという名前はコレクション用に取っておいて、 > 差し出がましいようですが名前を変えた方が良いように思います。 仰るとおりですね。Process.cppで使用するQueue->Nodeと名前を変えました。 > Queue value = runq[0]; > というのと同じです。 > この時点で別インスタンスなので、 > &valueに対して操作しても意味がありません。 その通りです。すいません・・・ > 従ってQueue top; ……(&top)というような部分は、 > Queue* top = new Queue(); ……(top)のように書くことを推奨します。 なるほど。たしかに↑の方が意図することがわかりやすいですね。 > Array<Queue*> runq(10); > for (int i = 0; i < 10; i++) runq[i] = new Queue(); はい。分かります。
> あと不思議に思ったのは、Queueのstatic関数はすべて第一引数にQueue*を取ることです。
> 関数ポインタを取ってみると分かりますが、C++の非static関数というのは、
すいません。Queueを最初は構造体と想定していた元ネタ(過去の自分のコード)を
そのまま使おうと思って意味の分からないことをしてしまいました。
おはずかしい・・・
> 特に問題ないように見えます。
> こちらも前述のWikiのページに添付してあります。(aq.zip)
> うー、さすがにもうつらいんで、風呂入って寝ます……
添付ファイル確認させていただきました。
ありがとうございます。
私の至らなさで多大な御迷惑をおかけして申し訳ありません。
あまり無理をなさらないでください。。
>>414 さん
> PICのIMR設定してからPITさわった方がよろしいのではないかと。
> 初期状態のIMRがどうなってるか忘れたけど、そこでハングするということは
>変なタイミングで割り込みが来ているような気がする。
なるほど。たしかにPITを触った後、マスク処理をしています>現在
一応、割り込みを全面禁止にしてから作業しているので大丈夫かとは思いますが
初期化の順番は関係あるかもしれませんね。
> ver.1.0.0が出たよ
>
ttp://slashdot.jp/article.pl?sid=04/02/23/154210&topic=104&mode=thread&threshold=-1 でましたねぇ。apacheを使ってネットワーク越しの作業というのは一度実験してみたいですね。
>>364 さん
> まともにご挨拶もしてないのに丁寧な対応ありがとうございます。
> 今後ともよろしくお願いします。
こちらこそよろしくお願いいたします。
> NICドライバ点呼してみるテスト
> 1
NICドライバー開発者さんようこそーーー。
> MONAの為に書き下ろすというより、NICドライバの実装テストプラットフォームとして
> MONAを活用させていただきたいです。
ありがとうございます。非常にうれしいです。
しょぼいカーネルですがぜひぜひ活用してください。
またドライバの開発の障害となるものがカーネルにあったり
不足している機能がありましたらどんどん言ってください。
可能な限り対応させていただきます。
> ドライバと言えない段階の実行ファイルサンプルは1週間~10日程度で
> 初回版をお見せできればうれしいです。(社会人ですので時間が限られます)
お互い社会人ですが、無理がない程度にがんばりましょう!!
Tinoさんのおかげでスケジューラの簡単な実験が出来ました。 これからシステムコールの再構成に入ります。 以前はプロセス・スレッドがほぼ対等な立場だったため 実装が入り組んでありえないことをなっていたのを スレッド中心の実装にしました。 パラーメータのチューニングが必要かとは思いますが とりあえず早く動く状態にしようと思います。
理解遅いんだけど。 もしかしてMONAでネットワークが使えるってことかーーーー?
デバードーラとかプロートコルンス-タックンとか用意されれば。 もしかするとOSASKより早いかも。人集まってるし。 Lタンはよく分からないタイミングで馬力を発揮するので侮れないけど あまり気合入れてOSやる気も無いらしいから、 和製じゃ一番早く用意されるんじゃね?
それってすごいことだ GUIとネットワーク
>>407 > TinoさんのMONAFONT.ELFは、私の知るC++のお作法ではなくて
> すごく新鮮でした。Monaged C++広めますか?w
お返事遅くなりました。
決して無視していたわけではなくて、
調子に乗ってWindows Formsっぽいものを作っていました。
イベント処理すら出来ないへっぽこですが……。
>>Tinoさん 確認しました。ありがとうございます!! まだソースは追いきれていませんがきっと宝の山だと思うので 明日にでも目を通します。 カーネル側も気合を入れないとユーザーアプリを作ってくださる方々の 要求にこたえられなくなるかもしれませんね。 がんばらなくては。まずはスケジューラの安定です。
434 :
Be名無しさん :04/02/26 20:46
以前からこのスレを見てるんだが、最近活発だからさらにネタふりを。 ひげさんはMONAの開発をがんばってもらうとして 何らかの形でMONAに協力したいと思う人は結構いると思う。 でもどういう形で参加したいかが分からない(漏れみたいなやつ)がほとんどだと思われる そこでスキル・志向別にこんなのやったらという案を書いてみた。 ・結構できるひと(技術的なアドバイスをできるななしたん、Tinoさんレベル) ひげさんへのアドバイス等、今までどおりのアプローチ ・ある程度プログラミングはできるけどカーネルはさっぱり分からないよな人 MONAで簡単なアプリ・ゲームを書いてみて、その過程で分からないことを このスレでレポートする。 そうすればこれから始めようと思う人たちの助けになるし、APIの不備とかが発覚するかも ・実はOSを作ってみたいと思っているひと MONAのソースを順々に読んでいって簡単なレポートをこのスレでする。 分からないことがあれば、このスレの達人たちがアドバイスをくれるかもしれない。 1ソース毎にみんなで解析するのも面白いかも。 ・MONAは知らないけど、Windows, Unixは詳しいよな人 Windows, UnixからインパクトのあるフリーソフトをMONAに移植してみよう。 その過程をここでレポートしたりすると面白いかもしれない。 ・プログラムとかまったく分からないなひと 次回MONAリリース時には動作報告というかたちで参加する 実はこれは結構助かるのではないかと漏れは思う だらだらと書いてしまったがどうでもいいと思う人はどうか無視してくれ。 漏れは4番目でやってみる
>>434 面白いね!
>漏れは4番目でやってみる
Hurdみたいにカーネルの上にPOSIXサーバを作ると移植は何でもOKかも。
カーネルをいじらなかったらライセンス縛りとか関係ないしね。
>>435 HURDって言えば、FATFS.ELFを見てsettransを思い出した
マイクロカーネル的にはいい線行ってるかも
織場もHURDを引き合いに出してたっけ
437 :
Be名無しさん :04/02/26 21:35
>>434 良いね。
動作報告で貢献できそう。
5台もあるし。
>MONAで簡単なアプリ・ゲームを書いてみて、その過程で分からないことを
>このスレでレポートする。
これがスレにレポートされたら簡単なゲームでもやってみよう。
かなりへたれだけどw
>>432 GUI実装ってそんなに簡単なのか。
それともTinoという人物が天才なのか。
とにかくGUI on MONAおめでとーーーーーーーーーー
>>438 私が作ったものはまだウィンドウが出るだけでGUIと呼べる代物ではないですから、
そんなにすごいことではないですよ。
いずれ、ひげぽんさんがGUIに取り掛かるときに
参考になるようなものを用意できたら、と思って作っているものなので、
ひげぽんさんが取り掛かる正式なGUIは、
また一味違ったものになるのではないかと思います。
そうなるのはカーネルが一段落してからでしょうけどね。
それはともかく、今も改良を進めているところです。
>>379 さんの影響を受けて(?)Eclipseを使ってみました。
私はJavaを使う機会がなかったのでEclipseをちゃんと使ったことがありませんでしたが、
プラグインでC++も使えると言うことで試してみました。
噂通りの凄いソフトですね。こういうのを作る人こそ天才と言うんじゃないでしょうか。
>>378 Eclipseの起動はVS.NET並みに重いのですが、
起動してしまえばVS.NETよりサクサク動きました。
SWTのお陰でJavaで作られていることすら忘れそうです。
もっとも私がVS.NETの重さに慣れているという面もあるでしょうけど。
ところで以前、ライセンスがひげぽんさんの個人名で出ていることについて、
協力者の扱いをどうするかという話があったようですが、
MonoのMIT/X11コピーライトがうまく書いてあるのに気付きました。
> Copyright (c) 2001, 2002, 2003 Ximian, Inc and the individuals listed
> on the ChangeLog entries.
>>439 ChangeLogをマメに付けていれば一番いい方法ですな。
commit logすらまともに書いていない漏れには無理な方法だ…
ところでviewcvs経由で見るとChangeLogが化けまくるのはうちの環境のせいですか?
>>440 ChangeLogは、UTF-8です。
1.123まで、SJISだったみたいです。
Sorceforge.jpでは、euc-jpがデフォルトだった気がします<Web文書
>>441 HTMLには書いてないけどApacheがこんなヘッダを返してるね。
> HTTP/1.1 200 OK
> Date: Thu, 26 Feb 2004 15:19:34 GMT
> Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1.2
> Connection: close
> Content-Type: text/html; charset=euc-jp
>>434 さん
興味深い提案いただきありがとうございます。
正直言って、どれが実現しても非常にうれしいともにありがたいです。
出来る限りサポートいたしますので是非実現して欲しいです。
>>439 (Tino)さん
> いずれ、ひげぽんさんがGUIに取り掛かるときに
> 参考になるようなものを用意できたら、と思って作っているものなので、
> ひげぽんさんが取り掛かる正式なGUIは、
> また一味違ったものになるのではないかと思います。
こんばんは。すいません。まだソース見れてないです。
ところでTinoさんはかなりの腕前と見ておりますので
正直私が位置から勉強してつくるGUIよりもいい物を作られる
のではないかと思っています。
> 私はJavaを使う機会がなかったのでEclipseをちゃんと使ったことがありませんでしたが、
> プラグインでC++も使えると言うことで試してみました
そんなに快適ですか。うむむ。
> Copyright (c) 2001, 2002, 2003 Ximian, Inc and the individuals listed
> on the ChangeLog entries.
お。これいただこうかな。
Incってここではどういう意味なんですかね。
>>440 さん
> ところでviewcvs経由で見るとChangeLogが化けまくるのはうちの環境のせいですか?
申し訳ありません。UTF-8にしてみて戻すの忘れてました・・・
euc-jp-unixに戻しました
>>444 不幸なゾロ目ゲットおめ!(なのか?
>Incってここではどういう意味なんですかね。
普通に"incorporated"で「会社」の意味
"Co., Ltd."とかってよく見るでしょ
あれと同じ
だから個人では不要
>申し訳ありません。UTF-8にしてみて戻すの忘れてました・・・
>euc-jp-unixに戻しました
Apacheの設定がeuc-jpになってるからどうしようもないね
>>445 さん
ありがとうございます。↓な感じにしました。
Copyright (c) 2002,2003, 2004 Higepon and the individuals listed on the ChangeLog entries.
>>438 さん
> とにかくGUI on MONAおめでとーーーーーーーーーー
ありがとうございます。
>>446 どんどん年を付け足すのもあれだから2002-2004ってした方が良いと思うけど
> こんばんは。すいません。まだソース見れてないです。 そんなに大したものでもないですから。 とか言いながら調子に乗ってWikiにページを作ってみました。 > ところでTinoさんはかなりの腕前と見ておりますので > 正直私が位置から勉強してつくるGUIよりもいい物を作られる > のではないかと思っています。 Monaはひげぽんさんが勉強しながらカーネルを作ったことに意義があると思いますが、 それはGUIでも同じことではないかと思っています。 私の場合、3年前くらいに、勉強しながらGUIを作ったりしていました。 今はそのときの残骸をかき集めているような感じです。(w > そんなに快適ですか。うむむ。 C++だとJavaほどの強力なサポートは得られないので微妙かもしれません。 とりあえずWikiにスクリーンショットを載せておきました。
MASMでIPLって書けないんでしょうか? 当方、アセンブリの勉強をして、後にIPL書いて遊ぼうかと思ってまして。 NASMは、できるのは分かっておりますが、MASMがどうも分からない。 まぁ、com形式で、コードセグメントうまく設定すればできるのかと、乏しい知識で思ったり思わなかったり。 ってかバイナリ直で吐けないような気が・・・。 .comか.exeからの抽出が必要かな?
>>449 org 0で作って.comにすればいけるんでは?
あれ生バイナリだし。
>>447 さん
ありがとうございます。徐々に直していきます。
>>448 (Tino)さん
> とか言いながら調子に乗ってWikiにページを作ってみました。
ありがとうございます。SDKは素直に便利だと思いました。
GUIの方は、ソースを斜め読みして勉強中です。
> Monaはひげぽんさんが勉強しながらカーネルを作ったことに意義があると思いますが、
> それはGUIでも同じことではないかと思っています。
確かにそうですね。
GUI方面に興味が行くかどうかは今現在はまだ分かりませんが。
勉強は続けたいですね。
> C++だとJavaほどの強力なサポートは得られないので微妙かもしれません。
> とりあえずWikiにスクリーンショットを載せておきました。
なるほど。私の開発環境は結構非力なのが痛いですね。
Meadowで十分といっていると時代に取り残されるかもしれませんが・・・
>>450 色々と調べてみました。
んでMASM、VC.net買おうかと思っていたのですが98DDKがマイクロソフトのホームページに
密かにあったのでもらったったけど、何かいいのかどうか分からない。
とにかくこれから勉強してきます。
NASMで池
>>452 おまけmasmは32bitコード専用だったような気がする。
exe2bin(なつかしい名前だ)もないし。
分かりました。ありがとうございました。もう逝きます。 >ひげぽんさん 適当に頑張って下さい。
>>434 の企画案に答えて
MONA版Hello World
#include <userlib.h>
int MonaMain(List<char*>* pekoe)
{
printf("Hello World");
return 0;
}
Makefileとかの詳しい解説って必要かなぁ(コピーしただけだけど)
スマソ空白がつぶれた
>>455 さん
ありがとうございます。
>>456 さん
おぉ。始まりましたね。ありがとうございます。
いろんな人たちがMonaで遊んでくれるといいですね。
スケジューラの実装ではまり中です。
FDC割り込みが来たらwakeしているのですがどうもスタックがずれているような
印象を受けています。
うまくいっているメッセージ到着のwakeと基本的には同じなのになんでだろう。
459 :
Be名無しさん :04/02/28 05:01
さて debugコマンドでOSでも作るか
(゚∀゚)ニヤニヤ
何故にpekoe
本気だっぺ
>>462 昔はDOSもMASMも持ってなかったから(C言語なんて尚更)
MONのAで16KBくらいのゲームを作ったりしたことあったっけ。
16KBでもかなりきつかった記憶が……
Z80と違って16進数のコードがいつまで経っても覚えられなかった
今でも覚えてるのはNOPの0x90くらいか……
>>461 MonaMainのこと?俺もそう思った。
VFSの実装はいつごろ?
>>463 >MONのAで16KBくらいのゲームを作ったりしたことあったっけ。
MONのAってMONAですか?
>MONのAってMONAですか? 何もかもがみな懐k(ry
>>461 MonaPekoeへの伏線( ̄ー ̄)ニヤソ
>>470 ネタ被ってる上に微妙に間違えるとは(藁
今の少年達は古代とか沖田とか言ってもピンと来ないんだろうな。
>>473 今の世代で沖田っていえば沖田総司かな。
大河の影響なのか新撰組流行ってるっぽいし。
ヤマトの歴代艦長の苗字は新撰組から取ってるだけだが。
>>747 なんか脇役で斎藤とか色々いたような。
まあスレ違いだからやめとこ。
やっとはじめて読む486,MINIX本,Interface7月号が手に入った。 さてどれから読もうか?
Tinoさんすごいな 一体何者
>>478 パナウェーブ研究所の会長か何かだったかと。
>>478 ありがとうございます。
でも私なんかまだまだです。
初めてQtを日本語化した方を見てすごいなぁと思います。
>>479 違います。訓令式ではないですよ。(w
>初めてQtを日本語化した方 某神様でつか?
>>481 >>482 その神様興味あり。
どういう人?
ひげぽなり、このスレを見ている人に影響を与えるかもよ。
逝く前にひとつ。 98DDKにEXE2BINも付いていました。 んで、.COMにすると、やはりバイナリ直書きでした。 これを.BINに変えて、ブートシグネィチャ付加してbochsで起動してブートできました。 ただし一番最初のジャンプ命令はどうやるか分からなかったけど、とにかく動作はしました。 IPLはMASMでも書けるようです。 んでは、逝きます
>>483 UNIXやJavaの達人です。
でも今は本業が忙しくてあまり趣味のプログラミングは出来ないみたいですね。
私もネット上で遠巻きに見ていただけで親しいというわけではないです。
>>485 サンクス
その人の書いたソースとかある?
>>486 ありますがスレ違いですし、
個人のことを書いて良いかも気になるので、
KDEの神様で調べていただけないでしょうか?
KDEの神様で調べたらロマンスの神様とかが引っかかった・・・ でもTinoのGUIに期待
>>310 の
> FD読み込みが遅い原因ぽいモノをつかみました。
> LBA1-10 * 20回読み込み22秒に対して
> FD読み込みだけに専念(FDC割込み以外マスク)シングルプロセス
> で同じ読み込みをしたら5秒でした。
上記現象ですが。
スケジューラを改良して(全書換して)、実験してみました。
FDCからの割り込みを待つときは
FDCDriver::waitInterrupt()を呼び出してCPUを他のスレッドに譲ります。
そして割込みがくるとScheduler::wakeup()でただちに
実行可能かつ優先度が高くなります。
計測の結果 LBA1-10 * 20回読み込み5秒でした!!
ただしスケジューラーが安定せず以下の課題があります。
・VMWAREでうごかない
・汎用メッセージ到着によるwakupとの共存ができない(バグ)
思えばプロセス・スレッド周りの再実装(書換え)は5回目くらいですが
デバッグが大変です。実機ONLYだったらもっと大変だろうなぁ。
NICドライバを作っている2人の人たちはどうなったんだろう。 ソースを見せろとは言わないがどんな感じか ここに書いてもらえると盛り上がると思う。 隠れた達人が多いのでアドバイスがもらえるかもしれない。 挫折しそうならソース公開して誰かに引き継ぐというのも面白いかも。
bochsで動くようになったの? ってか最新のbochsって、どこからダウンロードするの? まさか自分でコンパイルすれと言うこと? どちみちどこからダウンロードするのか教えていただきたいく存じます。 一応cygwinはあるから、自分でコンパイルでもいいですわ
すいません、2.1.1ありました。 動きました。逝ってくる
あのフロッピーイメージにMONAGUI.ELFを追加したいのですが、どうやるのでしょうか? DiskExplorerではできませんでした。 激しくGUIを試したいので、お寝がいします。
>>488 ありがとうございます。
>>493 私はひげぽんさんのfat_writeを使っていますが、
上書きできないようなので毎回ディスクイメージを作っています。
やり方
1. Mona WikiのMona/アプリ登録所でMonaSDKをダウンロード
2. 展開する
3. 中にあるbinディレクトリにMONAGUI.ELFをコピー
4. cygwinでbinディレクトリに入ってmake
5. mona.imgというファイルが出来るので完成
make時にはbinディレクトリにある.ELFファイルをすべて追加するので、
他のアプリや自作アプリなどを含んだイメージを作るのにも使えます。
他の方法としては、時間がかかるのであまりお勧めしませんが、
Mona-0.1.5リリースのフロッピーイメージを本物のフロッピーに書き込んで、
フロッピーのAPPディレクトリにMONAGUI.ELFをコピーして、
フロッピーからイメージを作成するという方法もないわけではありません。
私はイメージの入出力にはrawwriteを使っています。
http://uranus.it.swin.edu.au/~jn/linux/rawwrite.htm
>>493 あと念のため補足しておきますが、
MonaGUIはまだウィンドウを表示するだけの代物で、
スクリーンショット以上の動作はしませんから、
GUIとして遊ぶというイメージだとがっかりされると思います。
もちろん私自身、Monaで遊んでみたいというのが
こうしたものを作っている動機ですので、
ご期待に沿えるように頑張りたいと思います。
名乗り忘れましたが
>>495 は私です。
ついでなので私がアプリを開発するときに使っている方法を書いておきます。
MonaGUI-20040226のMakefileに書いてありますが、
ELFファイルのリンク処理の後にSDKのbinディレクトリにコピーして、
binディレクトリでmakeさせる処理を付け足しています。
そうするとアプリのコンパイル後に自動的にイメージが更新されます。
最近Eclipseを使い出したのですが、
EclipseではC++を使っているときはMakefileをmakeするだけなので、
キーボードショートカット(デフォルトのCTRL+Bを慣れたF5に変更しています)を押すと
フロッピーイメージが自動的に作られるようにしています。
Virtual PCやbochsではそのイメージを参照するようにしておくと、
コンパイル後にそれらを起動させることで動作確認が出来ます。
VS.NET 2003でPocket PCアプリを作るのを真似してみました。
問題点としては、コンパイル時にエミュを動かしておくと
イメージ作成のときに書き込みエラーになってしまうので、
コンパイル時にはエミュを落とさないといけない点です。
エミュ側でフロッピーのマウントを解除するという方法もありますが、
MonaのFDドライバが挿抜をうまく認識しないことがあるようなので、
念のためエミュを切っておいてコンパイル完了後に起動させています。
その場合、MonaにAUTOEXEC.BATみたいなのがあれば便利だと思いました。
シェルサーバを改造すればすぐ出来るかもしれませんが……。
>tino様 あらら、こんなに詳しくすみませんでした。 アプリを簡単に追加するユーティリティがないということですね。 激しく作りたいが、スキルが激しくないし、FAT12のフォーマットもどう探しても見つからないし・・・。 ちなみに私は、フロッピーにイメージを書いて、MONAGUI.ELFを追加して 再度イメージを吸い取ってやりました。無事にbochsで動作いたしました。 本格的にGUIが動作するようになれば、面白くなりそうですね。 正直どうやっているのだろうという疑問がありますが、 ソース読んでも私のレベルではどうにもならないと思いました。 ではでは、時間をとらせて申し訳ありませんでした。
>>497 つい先ほどGakuさんがアプリ登録所に書き込まれた情報によると、
まさにそのものの情報とイメージ操作ツールを作っておられるそうです。
詳しいことはアプリ登録所の一番下(FATFS.ELFのスクリーンショットの下)をどうぞ。
私も知らなかったのですが、素晴らしいですね。
EDITDISK(DiskExplorer)で、できなかったっけ? MonaGUIは、特別なのかな? それとも、ベースのイメージが変わった?
>>497 手元にきちんと動く古いソースがあったから試したけど、
EDITDISKで、問題なくMonaGUIをイメージに書き込んでBochsで起動できましたよ。
>>500 EDITDISKで開くとき、どれを選べば良いのでしょうか?
色々試してみたのですが、全部エラーが出て終わってしまいます。
EDITDISKのヴァージョンの問題でしょうか。
>>501 開くイメージファイル指定してplain imageで良い筈……。
>>502 すみません。できました。
バージョンを最新のしたら逝けました・・・ごめんなさい。
Vectorにヤラレタ・・・鬱
>>503 一応おめでとー。
Vectorめ、オンドゥルルラギッタンディスカー!
「オンドゥルルラギッタンディスカー」って、ずっとクトゥルー神話辺りのネタと思ってた。
bochsで動作したようで、よかったです。 Tinoさんフォローありがとうございました!! スケジューラの改良によりFDCDriverの割込み対応が Vmwareでも動作するようになりました。 覚書として原因をかいておきます。 1.FDCにreadコマンド発行 2.read完了の割込みを待つために割り込みが来るまでCPUを他のスレッドに明け渡す 3.FDCからの割込み到着をトリガーとしてスレッドを起こす。 上記のような流れになるのですがVmwareは高速なため1と2の間に割り込みが 来てしまいスレッドが2度と起き上がらないということになっていました。
>>427 >>490 NICドライバ(まで今しばらくのもの)作成中のものでつ
といっても、
最初にご用意してるのはユーザランドからNIC叩いて
プロミスキャスモードに設定して流れてくるデータを標準出力にダンプ
っていう感じのコマンドを作成中です。
予定より実装が遅くなってしまってます。
(1日時間がとればできるつもりができてません。現在10%〜20%ぐらい?
ネットワーク対応とはこれができてもまだまだ言えない状態だと思いますが
まずはNICがMONAから叩ける準備ということで、暇をみつけてがんがります。
まだOSのAPI関連までは到達していませんので、OSサイドからの補助が必要になったら
おながいします。
>>409 パフォーマンスを考えない場合はNICの処理はそんなにシビアではありません。
というのもTCPスタックやUDPを使うアプリケーション側に再送処理が仕込んで
あるからです。
取りこぼした場合もそれなりに動いてくれるはずで、特にBochs等フリーのPC等
ハードをエミュレーションするエミュレータを使ってみるとわかります。
のちのちチューニングしていけばすむことで、まずはNICのチップをどう叩くのか?
っていうこととアプリケーションから見たインターフェイスが重要だと思われます。
土日に片付けようと思っていたスケジューラのバグがどうしても 分からず、持ち越しになりました。 Monaは起動するのですがENTERを押しっぱなしにしたりするとfault0dが 起こるというものです。 どこで発生しているのかがつかみきれず挫折気味。 2,3日かけてうまくいかないようであればしばらく違う作業したほうが よいかも。
>>364 さん
> まずはNICがMONAから叩ける準備ということで、暇をみつけてがんがります。
> まだOSのAPI関連までは到達していませんので、OSサイドからの補助が必要になったら
> おながいします。
出来るだけすぐに対応させていただきます。
ただ力量がないので即対応が出来ないかもしれないので
こんな機能が必要になるかもしれないと予想がついていれば是非教えてください。
> のちのちチューニングしていけばすむことで、まずはNICのチップをどう叩くのか?
> っていうこととアプリケーションから見たインターフェイスが重要だと思われます。
なるほど。少し安心しました。>パフォーマンス。
すこしはその辺勉強しないといけませんね。>インターフェース
何か入門書でも読んでみよう。
むこうの方でNIC書こうと思ってる香具師でつ。 一応、トラ技2001年1月号にNE2000の石の叩き方が詳しく乗っているので もし手に入るのでしたら参考までに。 ただ、100BASE-T主流なんで現在NE2000って現役なんかな? ネットワーク知識はどうも3年前で止まってるので…
>>510 ひげぽんさん
>出来るだけすぐに対応させていただきます。
>ただ力量がないので即対応が出来ないかもしれないので
>こんな機能が必要になるかもしれないと予想がついていれば是非教えてください。
ハードウェア叩くプログラムは作ってますが、NICのドライバや
プロトコルスタックは初めて実装します。
あと、実は恥ずかしながらまだ、MONAについてキチンと(使うところ以外)
読んでませんので何が必要で、何が足りないか?
という点では私もまだわかりません。
その上で、とりあえず、ユーザランドからのIOと割り込みの通知があれば
とりあえず動くものができると思い、
>364
の書き込みになった次第です。
今後ともよろしくお願いします。
_
/〜ヽ
(。・-・) 。oO(
>>511 「むこう」じゃこっちの人には通じないような・・・
゚し-J゚
/〜ヽ (。・-・) 。oO( ウチ新参者やからよーわからんもーん。とりあえずNICガソバル ゚し-J゚
>>511 ◆CFYAAAAAds さん
ありがとうございます。2001年1月号ですね。
1999年7月号以外マークしてませんでした。
他のOSのソースを見ようにも綺麗に書いてありそうなものに限って
GPLが多いですね。(RTEMSとかEthernutとか)
見ちゃいけないってことは無いのでしょうけれど、
あまりに影響されるのも良くないかなと。
(初期化部分は大差が無いはずですが…
NE2000は現役とはいえません。
構造的にCPUパワーを食うところが嫌われているのでしょう。
ただ、BochsがNE2000互換なのでNE2000互換という側面と、
もともと私が作ろうと思っていたものがNE2000で十分だったという側面が
あります。
現在、NE2000互換のハードウェアの入手性は地方では(私は福岡ですが)
控えめに表現しても、あまり良くありません。
まだNE2000互換もとれてないので、なんともいえませんが、MONAを実機で
ネットワーク対応する算段も別途考えてはいます。
ちょっと前のものですが、
ttp://www.bi.a.u-tokyo.ac.jp/~uaa/gomitext/2001/20010807.html この方の文書が参考になるかもしれません。
IntelとRTL8139、Prismシリーズで市場の何割かカバーできそうな気もします。
なるほど、やっぱしNE2000は過去のものなんですね。 2001年1月号あたりまでそっち系の仕事をしてたんですが、最近さっぱりな状態なので… 私も勉強してみます。(本業が忙しくて時間裂けないかもしれないけど…) 99年7月号の記事内容からして2001年1月号は焼き直し+αって感じみたいですね。 とりあえず「第3章EthernetインターフェースLSIの概要」と「第4章RLT8019ASの概要と使い方」 があるので、石のアクセス手順とかレジスタの説明とかは役に立つかと思います。
>>511 さん
> 一応、トラ技2001年1月号にNE2000の石の叩き方が詳しく乗っているので
> もし手に入るのでしたら参考までに。
ありがとうございます。大変助かります。
大きな書店で探してみます。
>>512 さん
> その上で、とりあえず、ユーザランドからのIOと割り込みの通知があれば
> とりあえず動くものができると思い、
なるほど了解いたしました。
こちらこそよろしくお願いいたします。
NE2000の叩き方なら、RTL8019ASでぐぐるといっぱい引っかかると思われ。
>>518 タイマ割り込みが途中から来なくなっていることが発覚。。
どうして気づかなかったんだ>自分
処理そのものは実行されていたので(タスクの実行・切り替え)タイマ割り込みが
きていないとは・・・
どこかでeflagsが壊れているのだろう・・・
いやFD読み込みは出来ているのでマスクが壊れた??
ただいま大混乱中。
マスクいじってた・・・ 今日の作業が無駄になったかもしれないという驚愕の事実。 ショックが大きい。
結局分かったことは。 ・タイマ割り込みが来ていなかったことと↑のバグは関係ない。 ・タイマ割り込みが来てもこなくてもwait/wakeup処理によってfault0dが発生する。
予定より遅くなってますが一応現状の報告をします。 MONAのユーザランドからIO直に叩いて自分の(.bochsrcにて記述した) MACアドレスを読み出して表示はできています。 実際のパケット送受信にはもうちょっと時間がかかりそうです。 私が詰まった、RTL8019とBochsのNICの違いは RTL8019のデータシートとBochsのne2k.ccとを見比べるとわかりますが、 CONFIG1〜CONFIG4というMACアドレスが入るレジスタがBochsには無いことです。 気にせず、起動直後のNICのバッファを頭から読み出せばMACアドレスが入っています。 懸案事項 ○実機だとタイミングの問題があるかもしれません。(未検証です。) ○初期化もずいぶんサボっています。(実機だとNICにBIOSがあればそっちで面倒みてくれるかな?)
>>524 ne2kのNICにBIOSなんて期待しちゃいけません。
NetworkBoot(not PXE)のROMが載ってることもあるが、
そこから起動しない限り、初期化なんてやってくれません。
>>525-526 情報サンクスでつ。助かりました。
Bochsの方がNE2000との互換性では上だとは思ってましたが、
手元に石があったりしたため
ついRTL8019のデータシートを見てしまいました。
今、DP8390のデータシートを印刷しようと思って
会社帰りにネットカフェです。しかし出力代がちょっと高いですね。
今日はUSBメモリを買って帰ってkinkosで出力してみます。
このデータシートはパッとみてみていい感じですね。
ちょっと予定より遅くなりますが、ある程度読んでみたいですね。
(土日一回はさめばなんとかなるという予定の立て方が無謀だったのかも。
>>527 会社でダウソして印刷してしまえばタダじゃん
そういえば会社での私的な用途へのインターネット使用率が7*%だったっけな
>>523 さん
ありがとうございます。
>>364 さん
> 予定より遅くなってますが一応現状の報告をします。
> MONAのユーザランドからIO直に叩いて自分の(.bochsrcにて記述した)
> MACアドレスを読み出して表示はできています。
> 実際のパケット送受信にはもうちょっと時間がかかりそうです。
ご報告ありがとうございます。
すばらしいです!!!
MACアドレス取得だけでも大きな一歩です。
私のほうは、今日もスケジューラのバグがつぶせませんでした。
あまりに長期戦になるとへこたれるので明日からしばらく違うことに
挑戦しようと思います。
といっているそばから。 現在のバグスケジューラ版にcvs tagでタグを付けておいて 今のスケジューラ周りのコードを全部捨ててもう一度書き直してみます。 書き直す過程で何か発覚すれば戻るもよし新実装でいくもよし という方針で行きます。 それでも直らなかったら0.1.5にロールバックです。
>>531 一度、やろうとしてることを整理してみてはどうだろうか。
0.1.5からどういう変更をしたいのか。
そのために必要なものは何か。
などなど。
漏れも明日データシート会社で印刷してきまつ。 トラ技みるからにはpage1:01h〜06hらしいけど RSAR0,RSAR1に00h〜1fh指定しろと書いてありますた。 NICで遊びたいのに仕事年末進行が… bochsとかは週末…
534 :
Be名無しさん :04/03/03 20:38
やっぱりOSを作成するのに適しているのはGCCのみかい? 例えばVC++とかだったらどうなるんだろうかと。 まぁddコマンドなど、かなり便利なものがはじめからついているUNIX、LINUXのほうがええか。
別にVC++でも変わらんかと。 gccだといざという時にソース読めるというのはあるけど。 ddはOSを選ぶ理由になる程の差じゃないな。
>>532 さん
アドバイスありがとうございます。
ver.0.1.5で一番の不満点はFDの読み込みの遅さでした。
調査したところFDCからの割り込みに即応答して次のreadコマンドを
発行をしてないことが原因と分かりました。
スケジューラの問題であることが発覚したので実装が汚かったのもあって
上記を解消するためにスケジューラを全部書き換えることにしました。
またスケジューラを書き換える際に、プロセス・スレッドの生成の
仕組みもリライトしなければいけませんでした。
(前のスケジューラに依存している部分があったので)
>>530 ひげぽんさん
ありがとうございます。
乙でつ
ひげぽんさんのネットワーク対応したいという発言が無かったら
(今でもはやくはありませんが)もっとゆっくり実装していたと思います。
ここ2日ぐらいいじれてないところですけれど、
ひげぽんさんみたいに継続していけるといいでつ。
>>528 さん 529さん
私の会社はプライベートの印刷をするには厳しいところです。
技術ってことで入った職場ですが、上流工程主体(開発はやってない)ので
データシート見てたりするだけでも仕事と関係ないことはバレバレですし。
>>533 仕事との両立って言うほどのことじゃないかもしれないですけれど、
時間とるの難しいですね。乙でつ
私も今日いきなり、来週いっぱいの出張を入れられてしまいました。
お互い、無理せぬ程度に進めていきましょう。
スケジューラの実装では優先度つきかつ2つ以上のrun queueをもつ ものを欲張って実装しましたが、起動中やShellなどでfault0d, invalid op code などの例外が出るようになってしまいました。 問題を単純化して不具合箇所を見つけるために、本日 1つのrun queueと、1つのwait queueをもつ単純なら ラウンドロビンのスケジューラーに書き直しました。 その結果多少安定しましたが、invalid op codeや 0.1.5までは安定して動いていたShellやアプリがメモリアクセス違反を 相変わらず起こっている状態です。 たとえば起動後Shellでenterキーを押しっぱなしにしていると アクセス違反や例外が発生します。 ver.0.1.5では起こるのはみたことありませんでした。
今疑っているのは ・システムコールのネスト プロセスロードシステムコール⇒FDC割込み待ちシステムコールによりスタックがずれてinvalid opコード? くらいです。 ある程度エラーは再現するのですがエラー箇所がまちまちだったり タイマ割込み・FDC割込み・システムコールと処理が切れてしまうので どうも追いきれていない状況です。 なるべく早く解決しないと、364さんのがんばりやTinoさんのGUIに 遅れをとってしまいます。 人が見れば明らかだけど過信してものすごいミスをしているんだろうなぁ>自分
>>533 ◆CFYAAAAAdsさん
情報サンクスでつ。
トラ技、当時は読んでましたが、今は手元に無いので、データシートやら
他の人のソースや、Bochsのソースを頼りに進めてきました。
現状ではMACアドレスの後にはNE2kを表す0x57が読み出されてます。
現状報告の補足ですが、
あと、NE2K側のメモリを読めてるということは、
もうちょい適切なパラメータ書き込んであげれば
(MACと同じメモリに入るので)
Etherフレームを受信できるということですね。
今日USBメモリ買ったので明晩以降データシートを読んでみます。
>>364 さん
お疲れ様です。
> ひげぽんさんのネットワーク対応したいという発言が無かったら
>(今でもはやくはありませんが)もっとゆっくり実装していたと思います。
もしいい形できっかけになれたならそれはうれしいです。
あの発言は、自分の作ったOSからIRCとか2chへの書き込みとかが
出来たらなあと。という気持ちからのでたものです。
もし出来たら感動して泣いてしまうかも(笑)
> ここ2日ぐらいいじれてないところですけれど、
> ひげぽんさんみたいに継続していけるといいでつ。
スケジューラにまいりすぎてちょっと継続の危機ですが
364さんのようにMonaに興味を持っていじってくれている人たちがいる
というのがやる気の源になっています。
>>ひげ ソースとか全く見てないから、適当かもしれんが、 ポインタ関係でミスってる予感・・・。
うひゃー、かなり仕事テンパり気味ー。
データシート印刷したのに会社に忘れてきちゃった…
2ページ印刷すると製本できる感じで折れるのでいい感じのpdf。
>>538 仕事しつつOSも触るってことは、やっぱしOSいじったりやプログラムが好きなんだなーって感じですよね。
漏れも最近仕事ばっかりだったので、つい最近ここを見つけて昔の創作意欲が湧いてきたという感じ。
でも仕事には勝てませぬ…。
>>541 EtherFrame読めるところまで行くと次はIPとTCPでつまずきそうな感じがする…
いまだに漏れはIP,TCPパケットの中身でわからない部分があったりしまつ。
とりあえず漏れは時間とってエミュ環境そろえるところから…(氏
>>537 FDCからの割り込みに即応答して次のreadコマンドを発行するのは、誰?
ユーザプロセス(OSサーバ含む)ならば、優先度と再スケジューリングの問題ではないでしょうか。
カーネルならば、割り込み処理の問題だと思います。
>>539 queueを単純化するよりも、各処理の機能と手順を明確化するほうが先じゃないでしょうか?
ソース読む時間がなくて明確なアドバイスはできませんが、
たとえば、
FDC割り込み→レジスタ退避→割り込み処理→現行プロセスをキューにつなぐ→次プロセスをキューから取り出す→次プロセス
の流れだとして、各部分の機能がはっきりしていれば、矢印部分でのシステムパラメータやスタック内部が
どうなっていないといけないかが予測できるはずです。あとは、予測したものと実際のものを単純にチェックするだけ。
仕様バグには通用しませんけどね。
bochsのGDBスタブを使ってみてはどうでしょうか。
>>543 さん
よくポインタミスしますw
>>545 さん
> FDCからの割り込みに即応答して次のreadコマンドを発行するのは、誰?
FDCDriverの機能をシステムコールを介して利用しているプロセスです。
> ユーザプロセス(OSサーバ含む)ならば、優先度と再スケジューリングの問題ではないでしょうか。
> カーネルならば、割り込み処理の問題だと思います。
どうも動作を確認していると。もっとプリミティブなところで
エラーが起きているような印象を受けます。
>>546 さん
> queueを単純化するよりも、各処理の機能と手順を明確化するほうが先じゃないでしょうか?
はいおっしゃるとおりだと思います。
各処理の明確化をするのが手間なほど実装を進めてしまったので
queueを単純化することで逃げています。
処理の明確化は今日進めていましたが基本の流れが
以前のバージョンのMonaとあまりかわらないので各実装部分で
何かやらかしているのかもしれません。
> 各部分の機能がはっきりしていれば、矢印部分でのシステムパラメータやスタック内部が
> どうなっていないといけないかが予測できるはずです。あとは、予測したものと実際のものを単純にチェックするだけ。
これもおっしゃる通りで実践しようとしているのですが
エラーがでる箇所が起動するたびに全く異なるプロセス・eipだったり
エラーがでないで普通にアプリが起動する場合があるので
実際のエラーが出る直前の各パラメータが捕まえにくくなっています。
>>547 さん
> bochsのGDBスタブを使ってみてはどうでしょうか。
実は現在のエラーはbochs, Vmwareではまったく出ず
Virtual PC、実機で再現しております。
bochsで再現すればかなり有益な情報がえられるのですが・・・
皆様貴重なアドバイスありがとうございました。
>>549 今のアプローチは、バグの発見と修正という形だと思うんですが、
きちんと動く部分を増やしていくアプローチはどうでしょうか?
>>550 スケジューラはプリエンティブなマルチタスクOSの根幹の部分だから、
後回しにすると更に大変なことになるのでは?
>>551 全体的に後回しでなくて、バグの位置がつかみにくいなら、
スケジューラや関連部分を細かい部品に分けて、それぞれをきちんと動くように作っていくって事です。
がんがんコードを書き換えていくだけだと、バグが増えて減っての繰り返しになるんで。
>>550 Unit Testですね。
以前話題に出ていたYAGNIも含めてXP(eXtreme Programmingの方)を勉強してみては。
Wikiにも参考図書として載っているようですし。>>ひげぽん
なんとなくタイミング依存ぽいですが、排他制御ミスってませんか? 根拠ないけど。
不具合の一因と思われる箇所を特定できました。 このバグは0.1.5から内在していたものようです。 ・詳細 TSSに適切なesp0がセットされていなかった。 esp0のセットはユーザーモードスレッドへのスイッチの際に行っていました。 ⇒ユーザーモードスレッドはカーネルスレッドを必要とするため。 ところが以下の場合にesp0をセットするのを忘れていました。 カーネルスレッドA, ユーザーモードスレッドBとすると。 Aが実行中 スレッドスイッチA⇒B Bはシステムコール中でカーネルモード中(esp0をセットすべきなのにしていなかった) システムコール終了ユーザーモードへ 次のシステムコールで違うスレッド用のesp0を使用して死亡 なぜ0.1.5では再現しなかったか? 再スケジュールの仕組みが貧弱で上記のような切り替えが「たまたま」なかった。
>>553 さん
> Unit Testですね。
> 以前話題に出ていたYAGNIも含めてXP(eXtreme Programmingの方)を勉強してみては。
> Wikiにも参考図書として載っているようですし。>>ひげぽん
アドバイスありがとうございます。上記おっしゃることはよく理解できます。
特にUnitテストやテストファーストのメリットは自分でも体験したことがあります。
ただし今回のようなOSの根幹に関わる部分は事前テストや単体機能でのテストが
不可能な場合があると認識しています。
・事前にUnitテストできる部分
スケジューラ用データ構造Nodeオブジェクトと操作関数
スケジューラ(次のスレッドの決定ロジック等)
・テストできない点
スレッド生成・切り替え
システムコール・割込みを含めた処理
今回のようにどうがんばってちょっとずつ動くモノを足すということができない場合
ある程度の苦労がしょうがないのかなと思いました。
今回のバグ箇所発見が遅れた反省点を次回に生かすとすれば以下の点です。
・効率的なデバッグ手法を利用する(ログ・ダンプ等)
・新規に追加した機能でなく以前からある機能も疑う
>>554 さん
> なんとなくタイミング依存ぽいですが、排他制御ミスってませんか?
> 根拠ないけど。
上記も疑いました。おかげでいろいろと処理を見直すことが出来ました。
今回の件、アドバイスを下さった皆様ソースまで見ていただいた皆様
本当にありがとうございました。
>>556 >・テストできない点
>スレッド生成・切り替え
>システムコール・割込みを含めた処理
Cygwinでしか出来ないと思ってない?
カーネルにテストコード書けるでしょ。
VM上でUnit Testすればいいじゃん。
>>557 >・効率的なデバッグ手法を利用する(ログ・ダンプ等)
そういうのは自分で見るんだろうけど、
答えを先に決めてチェックすればVM上でUnit Testできるでしょ。
>>558 >>559 そのカーネルがうごかないから困ってるんじゃないの?
スケジューラとかスレッド生成がおかしかったらカーネル動かない。
⇒カーネルでUnit Testできない
バグが1つ解消したのでFDの読み込みをテストしました。 計測の結果 LBA1-10 * 20回読み込み5秒でした また通常起動時の*.SVRの起動も体感できるほど早くなりました。 実はテストのために多重スケジューラをやめて一本のRunキューのままですが しばらくはスケジューラを触りたくないので(飽きたので) いずれスケジューラを変更します。 ちょっと話題を変えていままでOSの動作確認をエミュレータを使ってきましたが よく使うエミュレータについて、ひげぽんの個人的な経験で ちょっとメリット・デメリットと使いどころを書いてみようと思います。(参考になれば幸いです。) ・bochs2.1 CVS メリット ・VESAがいい感じ ・実機だったら再起動するような間違いを起こしたときにカーネル側でダンプしなくても レジスタの状態がわかる。EIP情報等はかなり役立つ。 デメリット ・極端に遅い ・最近のリリース版は勝手に再起動する?(オプションの問題かなあ。) 使いどころ ・IPLなど再起動を繰り返すような場面
・Vmware4.05(匿名希望さん寄贈感謝) メリット ・早い ・デバッグモードがあるらしい デメリット ・FDCがおかしい(受け付けないパラメータがある) ・特定アドレスに対するpushができない ・対応しているVESAの画面モードが少ない 使いどころ 普段の動作確認 ・VirtualPC 5.1(匿名希望さん寄贈感謝) メリット ・早い デメリット ・特に不満無し 使いどころ 普段の動作確認 個人的には一番実機に近いとの印象を持っています。
中程度の変更をカーネルに行った場合は
所持している全てのエミュレータで動作確認。
大規模の変更を行った場合は+実機で動作確認しています。
>>558 さん
>>559 さん
ありがとうございます。
VM上でのUNITテストが出来る場合もたくさんありますが
今回の場合はUNITテスト環境の土台になる部分を変更したので
テストは難しいと思いました。
>>560 カーネルが動かない=Test失敗 と、考えるのはだめなのか?
UnitTestもたくさんあるツールのうちのひとつだから、使う人しだいだね。
バグ修正おめーーーー。 次回リリースの目玉はやはりGUIとネットワーク?
>>565 GUIのテストバージョンがWikiにアップされているよ
どうもまだ安定してないようだが
こればっかりは正式リリースを待つしかない
ネットワークはどうだろ。MACアドレスを取るのと実際に動かすのと
どれくらい大変さが違うかよくワカラネ
MONAに移植したらおもしろそうなもの ゲームエミュレータ コンパイラとか開発環境 vi互換のエディタとか シェル
libcの移植?が進んでいるみたいだけど サンプルアプリとかないの、そのまま使えるのかとか
>>566 ドライバとしてはそれなりに動くレベルだが。
その上が大変だからのう。
ライセンスの問題が無いプロトコルスタックを探してきて
おいしくいただいてしまうのが一番お手軽だが。
>>566 > どうもまだ安定してないようだが
お騒がせしております。
色々な要因が複合しているようです。
GUI側の問題なのかMona側の問題なのか調査中です。
>>570 親切にどうも。がんばってください。
実はかなり期待しています。
>>572 ありがとうございます。
手元にはいくつかバグを直してウインドウを動かせるものが出来ましたが、
sf.jpが落ちているようなので復旧後アップしたいと思います。
>>573 ネットワーク周り期待しています。
ウチに期待するとGWになってもできるかどうか… とりあえず3月に出現中のコワイトクイサキを倒すのが先決らしいです。 勇者のノートパソコンで倒せるかなー? 4月はOS周りいじり月間にしたいところ…
>>573 H8用のプロトコルスタックは、メモリけちるために処理はしょってる場合があるので、
そのへん気をつけた方がよろしいかと。
>> 542 ひげぽんさん
ありがとうございます。
もちろんいい形でのきっかけです。
名乗らずひっそりと個人的に実装しようかと考えておりましのたで、
そのままでしたら、そうとうゆっくりとやっていたと思います。
それはそうと、スケジューラの方おつかれさまです。
>>566 さん
>>569 さん
569さんの仰るとおりですが、バッファリングをキチンとしていないので、
そこんところ考えないといけないですね。
あと、プロトコルスタックだけではなく、NICドライバももらってきた方が
(整合性から)良かったのかもしれません。
NIC関連進捗について
明日から出張等で15日までPCに触れなくなります。
ですので、今日あたり、何かしら(バイナリやらソースやら)
アップしたかったのですが、ちょっと余裕がありませんでした。
ごめんなさいです。
マウスのハードウェア制御の資料(URL)をください。
そこ逝ったけど、見つけられるキーワードが分からなかった。 英語でもいいのでプリーズ
dev-jにあったわ。逝って来る。
>>364 さん
> それはそうと、スケジューラの方おつかれさまです。
ありがとうございます。はまりました。。
今月号のInterfaceはタイムリーな話題なので買ってみました。
まだ読んでいないですが。
> ですので、今日あたり、何かしら(バイナリやらソースやら)
> アップしたかったのですが、ちょっと余裕がありませんでした。
> ごめんなさいです。
お気になさらずゆっくり取り組んでいただければよいと思います。
出張とか大変ですよね。。
スケジューラが1段落したので不安定なファイルシステム等々を
どうにかしようと奮闘中です。
そういえばTinoさんのGUIがボタンが押せたりウィンドウが
ぐりぐり動かせたりするのですがちょっと感動しました。
言い方がわるいかもしれませんが本物のGUIな感じです。
>>583 今はプロセスごとに描画しているので同時に動かすとハリボテ感ありありですが、
最終的にはサーバー化して本物にしたいです。
Mona GUI試してみたいい感じ!! このウィンドウのみためは何に似せているんだろう ボタンとかぐりぐり動くのが本格的なのでオリジナルデザインだと面白いかも
>>586 > ウィンドウのみため
Beっぽい奴?
>>587 Beか。
Mac OSXみたいなのはどうよ?
本職年度末進行中… なるべくお泊りは避けたいんだけどなぁ… NIC、興味津々なのに昼休みとかですら睡眠時間なんでさぱーり。 現在ココのNIC停滞中?
>>589 >>577 > 明日から出張等で15日までPCに触れなくなります。
だと。
つまりアンタの独壇場だ!
>>585 色々とご対処ありがとうございます。
MonaGUIは3/10に0.1リリースなどと書いたものの延期してしましたが、
仕事が立て込んでしまって日曜日くらいまで触れそうもないです。
せっかく開発者向けリリースが出ましたので、
MonaGUI-0.1はMona-0.1.6.1向けにしたいと思います。
細かいことですが、x.x.x.1みたいなのは
表面にはあまり見えないような細かいバグ修正に使うので、
今回のようなAPIの変更を伴うような修正には適さないと思います。
一般的にマイナーバージョン(0.xのxの部分)でAPI互換性を示します。
ですがまだ途中なので、0.2.0とするのも問題ですから、
こういうときは0.2.0α1とか、0.1.90だとかが分かりやすいと思います。
枝番があまり細かいと、ずっとウォッチしているような人以外には、
あれ、前のバージョン何だっけ?
という印象しか与えかねないです。
>>586 > Mona GUI試してみたいい感じ!!
ありがとうございます。
> このウィンドウのみためは何に似せているんだろう
既に
>>587 さんから回答がありましたがBeです。
> ボタンとかぐりぐり動くのが本格的なのでオリジナルデザインだと面白いかも
Wikiのロードマップに書きましたが、ver.0.5でテーマをサポートする予定です。
Be風は非矩形ウインドウのテストを兼ねた暫定です。
>>588 > Mac OSXみたいなのはどうよ?
Aqua風のものを公開してAppleから公開停止要請が来た前例がいくつかあるので
一般公開するもので使用するのはまずいみたいです。
ひょっとしてそろそろWabaとかうごくんじゃない? とかおもったり
あのくらいはmonaだってmegトンだって動くだろ。
あれもう動くの 移植待ち? GUIとWabaの関係がよく分からないな どこまでOSに依存しているんだっけ OSASKに移植されているよね
ソース見れば。
OSに依存する部分が多い少ないと言うより、
むき出しになっているから全部自分で書ける。
osaskくらいのは動きそうな気がするけどどうかな。
試しに
>>593 が挑戦だ。
ごめんぷろぐらむできない厨房 WEBサイト構築ぐらいなら手伝えるけど
VESA 16bit マダァ?
>>591 Tinoさん
> 色々とご対処ありがとうございます。
おかげさまでカーネルが安定しました。
こちらこそありがとうございます。
> 仕事が立て込んでしまって日曜日くらいまで触れそうもないです。
了解しました。お体にお気をつけ下さい。
> こういうときは0.2.0α1とか、0.1.90だとかが分かりやすいと思います。
迷ったのですが、↓のようにしてみましたいかがでしょうか。
mona-0.1.7-image.zip
>>593 さん
> ひょっとしてそろそろWabaとかうごくんじゃない?
> とかおもったり
おお。気づきませんでした。
もし動いたらアプリケーション開発の敷居が低くなって
よいかもしれませんね。
>>598 さん
> VESA 16bit マダァ?
VESAの16bppのことでしょうか?
起動中の画面モード切替をサポートしていないので
次回リリース時には、なんらかの対応をするようにいたします。
MlcStdio.hとかってファイル名があまり良くないと思う こんな基本的なもののファイル名を変えてどうするのって感じ libc/stdio.hみたいにディレクトリを掘って コンパイル時には-Iでパスを通して #include <stdio.h>と書けるようにするべき
なぁに、libc/stdio.hからMlcStdio.hをincludeすればいいのサ! いや意味は無いんだけどね。 おいらも一般的なファイル名使った方が良いと思う。 何か理由あるのかな?
>>600 完全に仕様をみたしてない(みたせない)から、変えた。
素のstdioを名乗るのは、気が引けたので。
>なんでdos厨unix厨なんだよう。 いや、言ってみたかっただけ。
607 :
Be名無しさん :04/03/12 22:54
この前実機で動かした。pen330MHzくらいかな。 あまりにもフロッピーの読み込みが遅くて死ぬかと思った。 今改造しているらしいが。 もうちょっと頑張ってください。 bochsに負けているので。まぁエミュOSってのも悪くないが。
>>607 v0.1.5 ?
0.1.5 って、たしか、プロセスが皆してメッセージ待ちにビジーウェイトしてタイムスライス使い切ってたんじゃなかったっけ?
今 CVS にあるやつは SYSTEM_CALL_MTHREAD_YIELD_M でタイムスライス放棄してるように見えるので、大分違うんじゃないかな?
あぁ? っと確か数日前にダウンロードした記憶があるがね。 まぁそのうちやってみるわ。 ってかそのパソコン俺のじゃないからあまりできないわ。 まぁ俺の発言など、ほぼ無視してくれても委員だけどね。 ゴミと同類ですから。
>>603 そういう問題じゃないだろ。
それ以前にあんた誰よ?影?
金曜日にお泊りはやめてほしいところ…
そして寝て起きてから夜もお仕事。
>>590 漏れも自宅PCは同じような状態OTL
4月には活動開始できる予定…
POSIXサーバまだー?
MonaってC++で開発しているということは、ライブラリファイルは存在してるの? 誰が作っているの?何言語で。
影ポソがD言語で作ってるんだよ
隊長、 「C++で開発している」→「ライブラリが存在」 という繋がりがよく分かりません!
C++で書いたソースをコンパイルするときに、IntelのCPUで動くように直でバイナリ吐けるんですか?ということです。 普通ELF形式だとか、WinならEXE形式とかに変換されるやないですか。 そこら辺は俺の勉強不足から来るものだろうとは思うから、逝ってきます。
>>614 そんなのMonaをmakeしてみてMakefileのldのところを見れば分かるわけだが。
>>619 first boot, second bootまではアセ。
そっからCやC++の関数へジャンプとかじゃね?
シンボル情報だのを取り除いた生のバイナリを作るのは普通に可能。
>>616 匿名で、しかも乱暴な口調で書き込むと評価落とすぞ
ひげぽんがなぜあれだけ馬鹿丁寧なのか考えてみろや
shadowタンの愛想無い書き込みに
>>623 タンがマジ切れです。
人からの暖かいレスに飢えているようです。
誰か
>>623 タンに可愛らしいAA付きで突っ込みを入れてあげて下さい。
>>623 プシィー
; 、 、; , ; 、 、
'⌒`、lili,'⌒`
(`γ') |lili|
冫/" ,..-ー―,lili,―-、
.. / ;;| /;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;ヽ
| ;;;;ヽ, /;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;l / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| ;;;;;;`ー';;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;(,,゚Д゚)l < そう、目クジラを立てるな
`、_______,,,....つ--つ \___________
`ー‐---、,,,____ ,.,., ,.,,,ノ
"'''''''''''し'''J
626 :
Be名無しさん :04/03/13 23:07
>>623 (・∀・)ニヤニヤ(・∀・)ニヤニヤ(・∀・)ニヤニヤ(・∀・)ニヤニヤ
・∀)ニヤニヤ
>>623 (゜Д゜) ニヤニヤ(∀・
( )ニヤニヤ( )ニヤニヤ( )ニヤニヤ( )ニヤニヤ
暇なんで2ちゃんねら向けのぬるぽOSってのを作ってみるわ
>>599 > 迷ったのですが、↓のようにしてみましたいかがでしょうか。
> mona-0.1.7-image.zip
1. 次がどこへ向かっているかが分かりにくい
2. 同じマイナーバージョンの系列で一般向けと開発向けを混在させるのは好ましくない
3. APIの互換性がないのに同じマイナーバージョンを付けるのは好ましくない
まず前提として、次回の一般リリースを0.2.0と定めているかどうか、が焦点になります。
0.1.90とか0.2.0α1とかの名前の付け方は、
0.2.0に向かったプレビューという意味合いを持たせているため、
「これが安定すれば0.2.0が出るのだな」
という見通しをユーザーに与えるという狙いがあります。
おそらく、スケジューラ、ドライバ、FAT、libcのすべてが揃って、
GUIもそこそこ使えるようなものを0.2.0として出したいのではないかとお察ししますが、
個人的にはFAT周りが安定したことが大きかったので、
0.1.7相当のものを0.2.0として出しても良かったと思いますが。
もっと言うと、前回の大々的リリースが0.1.5だったのですが、
あまり知らない人からこの番号を見れば、
単なる保守リリースにしか見えないでしょう。
そういう観点からは、0.1.5は0.2.0で、0.1.7は0.3.0と名乗っても
まったくおかしくないと感じます。
※今から変えてくださいという意味ではありませんので念のため
>独自にOSを作っているまたは、作ろうとしている人たちのための >スレッドになればと思います。 さっきゅんのスレッドハケーンわはー!
>>263 乱暴だった?それは、悪かった。
よく考えると、C++のライブラリは作ってなかった。
そろそろ、C++の勉強もかねて、作ってみたほうがいいかなぁ。
Monaged C++までの道のりは険しい。
>>628 > 0.1.7相当のものを0.2.0として出しても良かったと思いますが。
とか言いながら0.1.7の挙動に悩みまくってしまいましたが、
これが安定すれば0.2.0としても結構いけている気がします。
GUIについても0.1.5で行き詰っている点が突破できます。
そういう意味で0.1.7を0.2.0α1として扱うのは悪くないかもしれません。
どこに問題があるのか切り分けるのに四苦八苦してしまいましたので、
GUIに関してはMonaがもうちょっと安定してから進めることにします。
というわけでまたまたMonaGUI-0.1のリリースを延期しますが
悪しからずご了承くださいませ。
>>630 > Monaged C++までの道のりは険しい。
最近は入門用としても使われるようになってきたC#をC++に移しただけですので、
C++のスタイルとしては特殊でも考え方自体はそう難しいものではないはずです。
問題は、私が勝手に作り上げたスタイルなので資料がないことなのですが、
その辺はMonaGUIのサンプルとC#との比較などで溝を埋めたいと思います。
C#はすばらしいよな。
ほんとすばらしいな
634 :
Be名無しさん :04/03/15 16:52
Monaってモナーのことでつか?
ホムペ見ましたカックイイ ガンガってください
藻まえら凄すぎ
株公開できれば一山当てれそうな予感。
ん? どっかに晒されたのか?
もしかして2chに晒されたとか
ガクガク(((( ;゚Д゚))))ブルブル
そりゃまた酷いな
スレ丸ごとなんて信じらんねえよ。
>>614 さん
> MonaってC++で開発しているということは、ライブラリファイルは存在してるの?
> 誰が作っているの?何言語で。
ライブラリはC++言語でMonaPJメンバやその他の人々が作成しています。
libuser.aがライブラリです。
>>628 Tinoさん
> 1. 次がどこへ向かっているかが分かりにくい
> 2. 同じマイナーバージョンの系列で一般向けと開発向けを混在させるのは好ましくない
> 3. APIの互換性がないのに同じマイナーバージョンを付けるのは好ましくない
なるほど。
> おそらく、スケジューラ、ドライバ、FAT、libcのすべてが揃って、
> GUIもそこそこ使えるようなものを0.2.0として出したいのではないかとお察ししますが、
その通りです。
アドバイスありがとうございます。
αが全角文字だったのでファイル名は↓のようにしましたがいかがでしょうか?何度もすいません。
mona-0.2.0alpha1-image.zip
> どこに問題があるのか切り分けるのに四苦八苦してしまいましたので、
> GUIに関してはMonaがもうちょっと安定してから進めることにします。
> というわけでまたまたMonaGUI-0.1のリリースを延期しますが
ご迷惑をおかけして申し訳ありません。
Wikiにも書きましたが不具合の原因となった場所を特定できました。
本当に単純ミスで反省しています・・・
というわけで前回リリースの0.1.5程度の安定感がやっと戻って
かつ、スケジューラがの調整で少しはやくなった感じです。
>>364 MACアドレス取得おめー
小さい1歩だが今までにない展開で楽しみ
>>644 > αが全角文字だったのでファイル名は↓のようにしましたがいかがでしょうか?何度もすいません。
> mona-0.2.0alpha1-image.zip
こちらこそ色々とうるさくてすみません。
もちろん全角文字はまずいので、これが普通だと思います。
色々な方針があるとは思いますが、α表記を使う場合、
新機能追加が終わった時点でβに移行して、
目立ったバグがなくなった時点でRCに移行して、
それで問題ないようならリリースするというのが一般的です。
そういう方針でリリースする場合、
0.2.0以降は、αとかは設けずに、バグ修正などを0.2.1, 0.2.2などに盛り込みます。
API互換性を破壊しないような機能追加なども0.2.x系列で問題ないです。
今の段階では新機能追加がメインになると思いますので、
0.2.0リリース後にブランチさせて0.3系列に移行することになると思いますが、
バグ修正などで0.2.1を出す場合は0.3系列をそのまま持って来ずに、
0.2系列に対して新規バグ修正をバックポートするような形が一般的です。
いわゆるSTABLEとCURRENTのブランチのスタイルです。
その他のよく使われる流儀として、LinuxやGIMPなどが採用している、
マイナーバージョンの偶数はSTABLE、奇数はCURRENTというのもあって、
これだとCURRENTもαとかβとかではなく具体的な数字になる面もありますが、
規模が小さい段階でブランチを全面に出しても実質あまり意味がない気がするので、
今の体制には合わないかな、という気はします。
> ご迷惑をおかけして申し訳ありません。
とんでもありません。こちらこそ最近何も出来なくて申し訳ありません。
>>645 > 開発版リリースはmona-0.2.0alpha2-image.zipです。
私が死んでいる間に色々と進んでいるようで嬉しいやら申し訳ないやら。
0.2.0α2ベースで開発をするためにmakeしてみましたが、
0.1.7と同様にMlcCtype.hとMlcCtype.cppが抜けているようです。
CVSから取ってきて追加したところ今度はfat_writeでFDC.DRVがなくてエラーになりました。
リリースイメージを見たところFDC.DRVは0.2.0α2には含まれていないようなので
単純にコメントアウトしたところmakeはうまくいきました。
動作もOKです。いい感じです。:-)
あ、別に責めているわけではありませんよ。
α版なんて普通そんなものなので。
>>496 > その場合、MonaにAUTOEXEC.BATみたいなのがあれば便利だと思いました。
> シェルサーバを改造すればすぐ出来るかもしれませんが……。
個人的には結構重要だったので、パッチを作ってWikiに置いておきました。
>> 645 ひげぽんさん
おつかれさまです。
体裁を整えて公開していただきありがとうございます。
今後ともよろしくお願いします。
また、WikiにはBochs以外の例としてtwoOStwoで動かした例を
記載してみました。
>> 646さん
サンクスです。今後ともマターリがんがります。
楽しみにしていただけると嬉しいです。
>>649 Tinoさん
おつかれさまです。
ベータで商用なエミュレータtwoOStwoにてMACアドレスゲットのテストを
しようとしましたが、キーボードサーバ、マウスサーバがkillされてしまい、
お手上げでした。今回はShellを直接いじって起動する際、
コンパイル時に決めたアプリを起動するようにしていましたが、
タイムリーなパッチありがとうございます。
>>650 すみません。バグも混入させてしまったみたいです。
ご利用の際には以下の空行チェックを外していただければ幸いです。
if (strlen(command) < 1) {
/* command is empty */
printf("%s", PROMPT);
position_ = 0;
return;
}
度々すみません。
>>651 > ご利用の際には以下の空行チェックを外していただければ幸いです。
と書きましたが、問題はここではなくて、
AUTOEXEC.BATを読み込むことで悪影響が出た結果のようでした。
というわけで申し訳ありませんがパッチのご利用は見送っていただければ幸いです。
チェック不足のための勇み足でご迷惑をお掛けしたことをお詫びします。
原因が分かりました。 byte data = new data[len]; delete [] data; とする間にdata++などとしてポインタをいじっていました。 そのためdeleteの際にメモリ内容が破壊されていたみたいです。 何て初歩的な……。アホ過ぎました。情けないです……。_| ̄|○ あとShellServerをよく読むとHListを使う必要がなかったことも分かりました。 というわけでまともなパッチを再度アップしておきました。 お騒がせして本当に申し訳ありませんでした。
申し訳ありません。cvsの操作でミスをした可能性がありますので 調べてみます。 > 動作もOKです。いい感じです。:-) ありがとうございます。多少安定したかなと自分でも思っています。 > あ、別に責めているわけではありませんよ。 > α版なんて普通そんなものなので。 ありがとうございます。 でも使っていただく方に迷惑がかからぬよう次回から気をつけます。 >> その場合、MonaにAUTOEXEC.BATみたいなのがあれば便利だと思いました。 >> シェルサーバを改造すればすぐ出来るかもしれませんが……。 > 個人的には結構重要だったので、パッチを作ってWikiに置いておきました。 ありがとうございます。パッチ取り込ませていただきました。 すごく便利ですね。すばらしいです。 一点だけ変更しました。 AUTOEXEC.BATだとDOS互換とも取れなくもないので ファイル名をAUTOEXEC.TXTとしました
>>364 さん
> 体裁を整えて公開していただきありがとうございます。
>今後ともよろしくお願いします。
お疲れさまです、今後ともよろしくお願いいたします。
> また、WikiにはBochs以外の例としてtwoOStwoで動かした例を
> 記載してみました。
拝見しました。最近良い事ばかりでうれしい限りです。
最新バージョンのtwoOStwoがでたらカーネルの動作を確かめてみます。
.txtとするくらいなら拡張子いらないんじゃないの?
>>654 >AUTOEXEC.BATだとDOS互換とも取れなくもないので
>ファイル名をAUTOEXEC.TXTとしました
それがいいんだって。DOSから知ってる香具師にはうれしい。
>>657 同意
そういう所はオリジナリティを見せる所ではない
逆に変なこだわりを感じてキモい
.TXTなんて尚更センスなさ過ぎ
どうせ説明するときに - AUTOEXEC.TXT=DOSのAUTOEXEC.BATみたいなやつ - SYSCONF.TXT=DOSのCONFIG.SYSみたいなやつ って書く羽目になる悪寒。
DOS流儀なんてPOSIXみたいな一種の標準だからな。 誰もDOS互換なんて思わないだろうし、思われて何が困るか不思議っちゃ不思議。 前からDOSみたいに遊ばせろ〜って騒いでた香具師がいたくらいだから。
影たんも互換じゃないからとか言ってヘッダ名を変なのにしてたけど そーゆーのは感心しない
ReactOS互換にすればいいじゃない。
ヘッダに関しては他のOS用とソースが一文字も違わず、 マクロで条件コンパイルする必要も無い事を目指すにはそうなるって話で。 そもそも中身が違うってんなら名前違うのは仕方が無い。 見ればどれがcstdlib相当かは分かるし、そんなに問題は無い。 3文字の拡張子って形でファイルタイプを表現するなら、.txtは適切じゃないような。 バッチファイルだから.batで良い。 コウモリが飛び回るアプリを.batとする予定があるとか、 別の奴用に予約してあるなら別だけど。
>>663 >ヘッダに関しては他のOS用とソースが一文字も違わず、
>マクロで条件コンパイルする必要も無い事を目指すにはそうなるって話で。
じゃ関数名も変えろ。クラスでラップしろ。
K&R一部準拠で何が悪い?
>>656 さん
>>657 さん
>>658 さん
>>659 さん
>>660 さん
>>661 さん
すみません。ファイル命名センスがないのはよく分かっています(笑)
このへんは好みになってしまいますが
私がDOSをバックグラウンドにもっていないのに
なんだかそんなファイル名なのが違和感があった次第です。
別にそんなことを気にしなくてもという人がおおければ
元に戻してもいいかな後も思っています。
もしオリジナルファイル名でMonaらしいファイル名が
ありましたら喜んで変えます。
>>664 いやいや、関数名だけは標準と一緒で、ちょっと変更した時に不具合あれば
includeするファイル名を見る所で「あ、これって完全に仕様みたしてはいないんだった」
という事実を思い出させてくれる絶妙なバランス感覚が……。
いや基本的に同意なんだけどね。
>>665 バッチファイルだから.batか.batchで良いんじゃないでしょうか。
あ。ていうか、おめ。 >ひげ氏
>>651-653 Tinoさん
おつかれさまです。
ありがとうございます。
今のところ、自分の作成中のコマンド実行することが多いので、
本家にも採用されて、今後便利だと思います。
configのほうも、svrファイル書き込まないようにMakefileコメントアウトとか
してましたが、その必要も無くなり、AUTOEXECとあわせると、よりPCよりのOS
と同じ感じで作業ができて嬉しいです。
>>654-655 ひげぽんさん
パッチ取り込み乙でつ。
こちらこそ今後ともよろしくお願いします。
twoOStwoで動くまではBochs依存のコードかと思いましたが、
とりあえず安心して、次のステップに進みたいです。
>>668 主語が省かれて微妙に分かりにくかったです。
NICの初期化部分は〜
>twoOStwoで動くまではBochs依存のコードかと思いましたが、
ということです。
Java認証テストじゃないんだからさ。 Wabaみたいに名乗らざるを得ないわけじゃない。 他人に使いやすいかどうかだろ。
NWSOSみたいに_stdio.hとかの方がまだまし。
マルチプラットフォームで書くときにstdio.hごときで#ifdef使わせるなよ。
>>673 よくご存知で。
一文字名前違えば大して事情は変わらないっす。
まあ自分でstdio.h用意するって発想するようになってから
標準関数をラッパで置き換えるような事をしやすくはなったんですが。
ソースが公開されてると基本的にいらない手間ですけど。
自分で何も新しい発想が生めない香具師が 名前変えて独自性に酔ってるだけだろ。
>>676 そんな事は無いと思うが……。
ていうかそんな事で陶酔出来る幸せな奴見た事無いぞ。
ネットでもリアルでも。
準拠しないことの言い訳で名前を変えてしまうというのがまずいのは 準拠しようと言う努力を放棄したことを明言しているところだろう。 別に完全準拠を目指せとは言わないが、 天上の高みを目指す気持ちを捨てたものに光はない。
>>678 >光はない。
自分で影って名乗ってんじゃん(ゲラ
>>679 よくそんな皮肉が思いつくな。とんでもねぇ。呆れた。
でも言い返せないから座布団10枚!
681 :
Be名無しさん :04/03/19 03:04
おまいらくだらないこと言ってないでWikiの一言見たか!? お祝いですよ!!age
このスレはハイテンションに座布団を乱発しつつひげ氏を祝うスレになりました。 というところで寝る。
685 :
Be名無しさん :04/03/19 09:47
ひげおめ
こ
>>687 卑下オナーニとかっつってた香具師じゃね?
オナーニじゃなくて残念だったね。(ゲラ
嫁が2ちゃんねらーか
なるほど、やっと謎が解けた。 以前MASKが結婚がどうたらって仄めかしてたのは卑下のことだったか。 てっきりK周辺のことかと思ってたよ。(あり得ねーと思ったが)
エリナ?
キンジョウ・ウォン
僕の髪が 肩までのびて 君と同じになったら
カクカク ,; ヘ⌒ヽフ ブヒブヒ / ( ・ω・)) -=3 ε// し ヘ⌒ヽフ ブヒーッ ( ( __ノ( ?)) -=3 し しー し─J
697 :
Be名無しさん :04/03/19 11:13
何を作るの?ボク分かんない。
次スレはこれでいいの? 子供を作ろうpart9
700getずざー
確か卑下って麺食いだっつってたよね
ひげぽんおめでとう!
>>704 何でもいいじゃん。とりあえず祝っとけ。
そだね。 めでたい!
おまいら昼間から揃いも揃って2chかよ。つくづくお めでてー香具師らだな。2chやってる暇あったら職 でも探したらどうだ?その方が少しは社会の為だ と思わんか?どうだ?ん?そんな事よりもう昼だ。 うまい棒食いてぇな。うん。じゃあな。あばよ。
シス管が怖いと思いつつ、会社アドレスの鬼彼と年始メール。 変な言葉は使わないけど、思い切り私用メールだからな。 鬼彼は「僕しか見ないから大丈夫」って言うけど、 シス管のこととかわかってなさそうだからな・・・。ま、いいや。
みんなで祝おう!!おめでとー
710 :
Be名無しさん :04/03/19 13:36
スレが伸びてると思ったらそういうことか!! ひげぽんおめでとう!
711 :
Be名無しさん :04/03/19 13:44
おめれとーーーー
712 :
Be名無しさん :04/03/19 13:47
うわ、マジびっくり でもおめでとう
いやー、めでたい、めでたい!!
714 :
Be名無しさん :04/03/19 13:53
゚・*:.。. .。.:*・゜゚・*:.。. .。.:*・゜゚・*・゜゚・*:.。. .・゜゚・*:.。. .。.:* \(^▽^)/ご成婚おめでとうございま−す♪ ゚・*:.。. .。.:*・゜゚・*:.。. .。.:*・゜゚・*・゜゚・*:.。. .・゜゚・*:.。. .。.:*
>>696 >古過ぎ。
昔は定番だったんだけどね、お祝いに歌っとくよ♪
僕の髪が 肩までのびて 君と同じになったら
約束どおり 町の教会で 結婚しようよ MMMM
古いギターを ボロンと鳴らそう 白いチャペルが見えたら
仲間を呼んで 花をもらおう 結婚しようよ MMMM
もうすぐ春が ペンキを肩に お花畑の中を 散歩に来るよ
そしたら君は 窓をあけて エクボを見せる 僕のために
僕は君を さらいにくるよ 結婚しようよ MMMM
雨が上がって 雲の切れ間に お陽様(ひさま)さんが 見えたら
ひざっこぞうを たたいてみるよ 結婚しようよ MMMM
二人で買った 緑のシャツを 僕のおうちのベランダに 並べて干そう
結婚しようよ 僕の髪は もうすぐ肩まで とどくよ
ひげぽんさんおめでとうございます! # /.Jにタレコ…む?
BBS_THREAD_TATESUGI=64 この板で一回スレ立てたら数ヶ月は立てられないんじゃないかな
>>720 乙!
ケコーソ関連ネタはそっちに移動してね>ALL
>>720 さいごに
-
おめー
-
って入れて欲しかったけどまぁいいかw
> おめー Σ(l|l゚Д゚) すいません、てっきり本文外だと思いました
724 :
Be名無しさん :04/03/19 17:19
マジでスレ立ってるしΣ(゚д゚;)
>>お祝いの言葉を下さった方々
ありがとうございます。
今後ともよろしくお願いいたします。
>>666 さん
> バッチファイルだから.batか.batchで良いんじゃないでしょうか。
そうですね。.batでもよいかなと思い始めました。
>>364 さん
> パッチ取り込み乙でつ。
> twoOStwoで動くまではBochs依存のコードかと思いましたが、
> とりあえず安心して、次のステップに進みたいです。
お疲れ様です。順調なようで何よりです。
現在オブジェクトマネージャ実装に向けて構想中です。 私の思うオブジェクトマネージャとは ・オブジェクトの生成・破棄 ・オブジェクトの参照の管理 ・名前空間によるオブジェクト参照の提供(ハンドルのようなもの?) ・オブジェクトに対する操作(read/writeなど) などのサービスを提供するものです。 またここで言うオブジェクトとは カーネル内のプロセス・スレッド・ファイル・Mutex・共有メモリなどに使われているデータを 保持する構造体(またはクラス)を指します。 イメージとしては mm->open("/fs/disk0/hoge/hoge.txt", ...)とか。 mm->create("/type/UserProces", ...)みたいな感じです。 オブジェクトマネージャが1プロセスとして実装されることを目指していますが 実装してみないとなんともいえなそうです。
>>727 >実際にNTでは出来るようなのでなんらか方法があるとは思うのですが
COMのことだったら言語非依存のABIを決めて作るからできるわけ。
だからActiveXで何か作るときはATLを使った特殊な作り方をする。
それが面倒くさいからVMを間に挟んだ上で
ふつうにベタ書きしたクラスで作れるようにしたのが.NET。
そこまでしないと出来ることじゃないよ。
BeOSなんかはその辺のC++の限界にぶち当たったわけだし。
ともかく普通にコンパイルしたC++のクラスを動的に扱うのは無理。 独自コンパイラとVMを作るくらいの手間がいる。 実態は全部Cレベルの構造体にバラすような感じ。
>>728 さん
>>729 さん
アドバイスありがとうございます。
クラスの動的な操作はやはり無理があったようです。
今やりたいこと・自分の技量で出来ることを
もう一度きちんと検討してみます。m(__)m
>>730 毎日学校帰りに串に4つか5つか唐揚げ刺さったの、100円でさ、食ってるんだけど
大丈夫かね?w
頑張ってください!
733 :
Be名無しさん :04/03/21 19:43
Mona GUI まだ? ∧_∧ ∧_∧ ∧_∧ ( ・∀・) ( ・∀・) ( ・∀・) ⊂ ⊂ ) ( U つ ⊂__へ つ < < < ) ) ) (_)| (_(_) (__)_) 彡(__)
MonaGUIはIKARIYAと名称が変わりました あしからず
735 :
Be名無しさん :04/03/21 20:27
だめだこりゃ
>>shadowタン ユーザ予備軍の意見は放置プレイで、 実際のユーザからの不満が出てから考えるというのもアリ。
>>737 禿同
卑下もいろいろ叩かれたがモノを作り上げて黙らせた
実際に使われるようになるまでは苦しいと思うががんがれ!
>>733-735 放置して誠に申し訳ありません。
仕事に追われてMonaGUIどころかネットすら出来ない状況でした。
今も書類が残ってるし後ろに上司がいるのでまた後ほど……
>>738 卑下の凄いところは一見罵詈雑言に見える発言でも
内容があったら誠実に対応してきたところ。
Monaの内容にも反映されている。
七誌で暴言を書き込んで無視したりしない。
742 :
Be名無しさん :04/03/22 21:44
/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ | ひげぽんageeeee!! \ \  ̄ ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ \ ヘ⌒ヽフ ( ・ω・) ⊂ つ  ̄  ̄ ε(つ ノ ト  ̄  ̄  ̄ (ノ オ / \ / : オ / || . ォ \ / | : ォ \ / . | . ォ | | : . |: . || .
>>739 もつかれ〜
MONA GUI期待してます。
ひげたん Tinoたん shadowタン ∧_∧ ∧_∧ ∧_∧ ( ・∀・) ( ・∀・) ( ・∀・) ⊂ ⊂ ) ( U つ ⊂__へ つ < < < ) ) ) (_)| (_(_) (__)_) 彡(__) がんが
>>745 なんとなく昔祭りになってたOSASKのスロット論争を思い出した
勉強会読んだよ 漏れも勉強しようかな Tinoタンやっぱりすごい人なんだね
>>747 実際MONAとOSASKには今どれくらい差があるんだ?
Window System の開発経験者って、必要だったりする?
設定ファイルがMONA.CFGに落ち着いたみたいだね MONA.CFGでVESA関連の指定が出来るようにするのをキボンヌ
VESA_WIDTH=800 VESA_HEIGHT=600 VESA_BPP=16 こんな感じ iniファイルみたいにセクションを設けるといいかもしんない [VESA] WIDTH=800 HEIGHT=600 BPP=16
起動メッセージの最初にバージョンを表示したらいいと思った 開発版をあれこれいじってると何使ってるか混乱する Mona ver.0.2.0alpha5 Copyright (c) 2002-2004 higepon Setting PIC ... こんな感じ
>>753 Win3.1のwin.iniみたいでワラタ。
でもいいかもしれない。
いまどきプレーンテキストですか?
流行ならXMLだろうけど さすがにカーネルに入れたらG氏に怒られるだろ 後でカーネル分離を考えるつなぎってことで
>>751 > 設定ファイルの名前問題が解決すると同時に動き始めたいです。
とりあえずWikiに0.2.0α5用のSDKを上げておきました。
>>748 さん
そうですね。
前からすごいことは知っていましたがソースを
詳しく読んでもっとすごいことに気づきました。
>>750 さん
もしよろしければ気づいた点など
アドバイスいただければ幸いです。
>>751 , 758 Tinoさん
お疲れ様です。
Mona SDKリリースありがとうございました。
>>754 さん
ご提案ありがとうございます。
次回開発版リリースより表示されるようになります。
>>753 さん
> VESA_WIDTH=800
ご提案ありがとうございます。
残念ながら現時点では上記のような設定は出来ません。
画面モード切替には必ずカーネルのリコンパイルが伴います。
理由は画面モード切替をリアルモードで行っているからです。
=プロテクトモードで画面モード切り替えをサポートしていない。
プロテクトモードでの画面モード切替方法は
・VBE プロテクトモードインターフェースを使用
・仮想86モードを使用
の2通りがありますがどちらもサポートされておりません。
おもしろそうだし、お役に立てるなら、よろこんで。 昔いた会社で覚えてしまった X11R5のMITオリジナルコード をベースとした アドバイスなら、いろいろ出来ると思います。ネタが古いのは申し訳ないですけど。 それと、今月いっぱいは仕事が忙しいので、来月にならないとちょっと時間とれないかも。 ついでに、時間が取れたら、3Dエンジンライブラリでも創ったりするかも。
ところでKONOXの開発者って中学生らしいな。
>>762 >>763 自作自演はやめてくれ
マジレスすると中学生でもあれくらい余裕だろ
きちんと続けていいものが作ることが出来たら
またこい
>>764 つまり、DQN-OSとはいっしょにするなと?
>>760 さん
両ニュースともにとてもうれしいです。
本当に次回リリースが楽しみです。
>>750 さん
> アドバイスなら、いろいろ出来ると思います。ネタが古いのは申し訳ないですけど。
> それと、今月いっぱいは仕事が忙しいので、来月にならないとちょっと時間とれないかも。
> ついでに、時間が取れたら、3Dエンジンライブラリでも創ったりするかも。
ありがとうございます。
3Dエンジンとても楽しみです。
是非Wikiにも一度お立ち寄りください。
>>762 さん
すごいですねぇ。一体何歳年下なんだろう・・・
>>759 ひげぽん ◆Ngzcp/NZpA
>プロテクトモードでの画面モード切替方法は
>・VBE プロテクトモードインターフェースを使用
>・仮想86モードを使用
>の2通りがありますがどちらもサポートされておりません。
でもVBEプロテクトモードインターフェースってFunction 05h/07h/09hしか提供されていないみたいだよね。
この場合欲しいのはFunction 02hなわけで。
やっぱり仮想86モードしかないのかな。
リアルモードでファイル読めばいいじゃん。
770 :
Be名無しさん :04/03/26 11:20
>>769 うおおおおおおおおおおおおおおおおおおおおおおおっっっっっ!
すげぇ!
キタ━━━━━(´_ゝ`)━━━━━!!!! #VGA表示もできたらいいよね。急ぎはしないけど。
772 :
Be名無しさん :04/03/26 14:14
大きいAA使ってもおもしろいと思う… _,,,,,,___,,,,,--,,_ _,-,_i_ , l-ノヽ . / \ ヽ i, _l,,/ ~''-,_ /___,,,,,,_,,,-''~~'''''-''~-'''''''''-,~/i,_ . ,_i'-,,,,_,,-'::::::::::::::::::::::::::::::::::::::::::~'ヽ,_l . / '''''/::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ヽ.,, / ./:::::::::::::::://::::::::::i::i;::::::l:::::ヽ:::::::::::::::ヽヽ l_//:::::::::::::/:/::/::::::::ll:l l::::::l::::::ヽ::::::::::::::::ヽ.ヽ ,ノ/:::::::::::::/:/://:::::;:/l:l l:::::l.l:::::::l:::;::::::::ヽ:::l ~'i l.l:l::::::::::::/:// /::/l:/ l:l ll:::l .l::;:::l:::l::::::::::l:::l . l|.l::::::::::// / l::/_/-.l/ ~''l'l:l,,,_l:ll::lヽl:::::::::l.l:l ,l-l::::::::/_,,,l,-l/ /___ ___ l '~~l.l::::::/ l| . /::::ヽ::::/l ===== ===== /ll::::/:ヽl . /:::;-''i:ヽl::l //// //// l::l/~''-;ヽ <モナーOS期待してます /;;-'' .ヽl::::l,_ ___ /:l ~''ヽ /'' _..,l::::l-ヽ,,_ ヽ,,_____ノ _,,-'''l::::l~~''''--,,,_ _,,,,-''''~ .l::::l.-==/~''i--,,,,,,,--,'~-'' l::::l ヽ l::::l_,-〈 ~''''人'~ ヽ''- l:::l . /\ l:::l ヽ .(⌒) l l::l / .l::l ヽ,_,ノ'~'''~ヽ,_ノ .l:l l| / l ヽ l! / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ / / GIGABYTE
773 :
Be名無しさん :04/03/27 00:15
>>767 さん
ご指摘ありがとうございます。
私より全然詳しいようで、アドバイスありがとうございます。
残る選択肢は仮想86ということですね。
>>768 さん
確かにその方法であれば完璧に、要件をみたしているとは思うのですが
ちょっとそこまでの体力がありません。m(__)m
申し訳ありません。
>>769 Tinoさん
おめでとうございます!?
実機・エミュレータで動作確認をさせていただきましたが
快適に動いています。
> 散々注文を付けて申し訳ありませんでした。>ひげぽんさん
> お陰様でイメージしていた動作を得ることができました。
> 本当にありがとうございました。
とんでもないです。
独りよがりのAPIが如何に使いづらいかがよく分かりました。
おかげさまで多少使いやすくなったと思います。
指摘だけでなく改善案までいただけたので大変勉強になりました。
>>772 さん
ありがとうございます。
>>767 さん
ご指摘ありがとうございます。
私より全然詳しいようで、アドバイスありがとうございます。
残る選択肢は仮想86ということですね。
>>768 さん
確かにその方法であれば完璧に、要件をみたしているとは思うのですが
ちょっとそこまでの体力がありません。m(__)m
申し訳ありません。
>>769 Tinoさん
おめでとうございます!?
実機・エミュレータで動作確認をさせていただきましたが
快適に動いています。
> 散々注文を付けて申し訳ありませんでした。>ひげぽんさん
> お陰様でイメージしていた動作を得ることができました。
> 本当にありがとうございました。
とんでもないです。
独りよがりのAPIが如何に使いづらいかがよく分かりました。
おかげさまで多少使いやすくなったと思います。
指摘だけでなく改善案までいただけたので大変勉強になりました。
>>772 さん
ありがとうございます。
\ │ /
/ ̄\ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
─( ゚ ∀ ゚ )< Monaはひとつ!
\_/ \_________
/ │ \
. 巛 ノノノノ巛 ∩ ∧ ∧∩
(\ '´ Vヽヽ /)∩∧ ∧∩ ∧ ∧ | |( ゚∋゚ )| | ∩∧_∧ ∩ \( ゚∀゚ )/ / ̄ >
\\ソiノ=ω=ヾ) / ヽ( ゚∀゚ )/ (ヽ*゚ー゚)')\ \// ヽ( ・∀・ )/ | /. ∩|(゚U゚)|∩
\(ヽリ゚ ヮ゚ノ ') | 〈 ヽ ノ | | | | | | ヽ y ノ
( <髭> ) / /\_」 〜( ノ /\ /ヽ / ∧ | / /\」 ) ( )
/lliく/_|〉リ  ̄ し'J / /\ .\∠/ \ \ / / ( ∪
(/ し'ノ\) ミ/ \__ミ  ̄ ̄ ∪
カーネル全般 ヒゲタン
GUI Tinoタン
FAT Gタン
ネトワーク 364タン
glibc 影タン
Waba ベイサイドタン
ゲーム移植
ttp://ponk.jp/el/index.php?page= の作者タン
WEB構築・管理 yossyタン
つまりamona吸収合併かね
周辺機器メーカーの方MONA用ドライバ 提供汁、って言いに逝ってもOK?
それにしてもこのスレOS板に移転して良かったな・・・
>>764 KONOX、ZAKOS と OSの大安売りだな。
漏れが厨房の時はファミコンばっかりしてたよ。
パソコンなんてものも滅多に見かけなかった気がする。
何か時代の流れを感じた。
_ /〜ヽ (。・-・) 。oO( 大安のOS瓜・・・? ゚し-J゚
>>777 ラッキーセブンおめ
やっと当初予想されてたような開発ラッシュになってきたね
予想より半年〜1年くらい遅かったけど
やっぱり0.1.5でのユーザーアプリ解禁が転換期だろうね
シングルタスクでもいいからとりあえずユーザーアプリを解禁しろって人達は
このことを言ってたんじゃないかと思った
まあZAKOSはほとんどネタなんだが。継続するつもりもあんまりない。 KONOXを生暖かく見守る路線で(ぉ
786 :
Be名無しさん :04/03/28 01:02
Linux上で動くOSはMonaX? Monux?
韓国向けにNidaX
>>784 そりゃムリってモンだろ。
物には順序がある。
使い物にならないディスクアクセス、使い物にならないメモリ管理でユーザアプリを公開しても意味なしだったろう。
>>788 そんなもんアプリ側で自前実装
それでカーネルに還元
これこそバザール
>そんなもんアプリ側で自前実装 >それでカーネルに還元 実際、FATのコードでそうなった。
>実際、FATのコードでそうなった。 NICでは現在進行形だね。 そもそも人に自分と同じことを要求しても無理ってもの。 カーネル共同開発者が云々って愚痴があったけど、 それぞれやりたい事が出来るようにするのがマネジメント。 今でもカーネル共同開発者はいないけど良い意味で盛り上がってる。 ま、終わりよければすべて良しってことで、この件はお開き。
で、KONOX開発者は有望な人材なのか? Lと比べても知識にかなり偏りがあるようだが…
>>780 ム板は壊滅したからな。ちょうど良い時期に移転したもんだと思った。
Waba for Monaもう動作してるっぽ おめーーーーーーーーー
>>730 cltnがまさにそれを目指してVM+コンパイラを作ってんじゃ?
彼はMonaPJのメンバーだし、技術提携もありだべ。
ヒゲタンも神々の仲間入りかな? まだ天使レベル?
>>797 もはや神だろうね。それを取り囲む人々が天使か。
そういやMASKも大天使長に出世してたな。
わたすは哀れな乞食だす 知識クレクレ
∧__∧ ( ;) / ヽ .と_と__) (; ・∀・) ドキドキ oノ∧つ⊂) ( ( ;・∀・) ∪( ∪ ∪ と__)__)
801 :
Be名無しさん :04/03/29 02:18
>>791 お開きのところ悪いけどちょっとだけ。
さっきゅんのおれぺこでの手腕は鮮やかとしか言いようがない。
一気にユーザーアプリが動くまでに進化した感じ。
これは今までのOS作成で培った経験と、
Monaに対して言われたDOS遊びのニーズとを汲み取った結果か。
あとはCygwinで動くクロスコンパイラが出てくれば
開発者がどっと流れ込む予感。
>>793 まだドライバインターフェースが定まっていないとは……;
知りませんでした。
まあ定まり次第、各社に提供汁、って言いに逝きますんで。
定まったら皮切りに 最強のRoland製DTM音源、SC-8850の
ドライバを . __∧__ Rolandに提供汁、って言って
みます。 |(現時点で) | まぁ、作ってくれるかは謎ですが。
 ̄ ̄ ̄ ̄ ̄
宣伝隊の切り込み隊長さんでつか。
DTM音源ならシリアルドライバがあればとりあえず16トラック使えるんじゃなかったっけ?
>>795 さん
そうですね。うれしいです。
>>803 さん
> まだドライバインターフェースが定まっていないとは……;
> 知りませんでした。
> まあ定まり次第、各社に提供汁、って言いに逝きますんで。
そうですね。ドライバインターフェースを決めなければなりませんね。
言いに行ってくれるんですか?(笑)
>>805 さっきゅんの人さん
> DTM音源ならシリアルドライバがあればとりあえず16トラック使えるんじゃなかったっけ?
アドバイスありがとうございます。
自分の作ったOSから音が出たらうれしいでしょうねぇ。
今日の一言にも書きましたが方向性で悩み中です。 次回リリースの次に何に手を付けるのがベストか。 本当に最小・最低限の機能がそろってきたので これからどちらに行くのがいいのか迷います。 ドライバインターフェースを決めるべきか。 サーバー群の整備か。 APIの整備か。 カーネルの洗練か。 カーネル新機能追加か。 1からリライトか。 64bitへ移行か。
ひげちゃんが挫折したqemuのwin上ビルドに成功した人が
>>808 さん
すばらしいですね。
Monaはうまく動きませんでした。(ログを吐いてすぐ終了してしまう)
Linux上での0.5.2ではVesa not surpportedまで動いているので
もう少し様子を見てみようかと思います。>Win版qemu
おお、テスト乙。CD-ROMサポートとかもまだみたいだしOSのテスト用途には まだ不適みたいっすね。今後が楽しみ
コンパイルできねー make[2]: Entering directory `/home/joe/src/mona_v1.0/src/user/HelloWorld' g++ -nostdlib -fno-exceptions -fno-rtti -fno-builtin -Wall -c -g -O3 -I. -I../include -I../include/userlib -I../../share -c hello.cpp hello.cpp: function 内の `int MonaMain(List<char*>*)': hello.cpp:102: 警告: no return statement in function returning non-void ld -n -Ttext 0xA0000000 -e _user_start -static -luser hello.o -L../lib -o ../../../bin/HELLO.ELF ld: warning: cannot find entry symbol _user_start; defaulting to 00000000a0000000 hello.o(.text+0xd): In function `MonaMain': /home/joe/src/mona_v1.0/src/user/HelloWorld/hello.cpp:49: undefined reference to `MemoryMap::getInstance()' hello.o(.text+0x20):/home/joe/src/mona_v1.0/src/user/HelloWorld/hello.cpp:52: undefined reference to `MemoryMap::create(unsigned int)' hello.o(.text+0x36):/home/joe/src/mona_v1.0/src/user/HelloWorld/hello.cpp:60: undefined reference to `MemoryMap::getSize(unsigned int) const' …(中略) hello.o(.text+0x1ed):/home/joe/src/mona_v1.0/src/user/HelloWorld/hello.cpp:57: undefined reference to `exit' make[2]: *** [../../../bin/HELLO.ELF] エラー 1 make[2]: Leaving directory `/home/joe/src/mona_v1.0/src/user/HelloWorld' make[1]: *** [hello] エラー 2 make[1]: Leaving directory `/home/joe/src/mona_v1.0/src/user' make: *** [userapp] エラー 2 Debian sid gcc 3.3.3
16bit VESA希望
ファイル列挙キボンヌ DIRすら出来ない時点でおれぺこの勝ち
DIR?
コマンド名はlsでよろ
DIRだったらシェルの内部コマンド、 lsだったらLS.ELFって別にした方が良いと思う。 っていうかDOSで.EXEが省略できるように、 .ELFもいちいち打たなくて良いようにした方がいいと思う。
>>807 当面は必要に迫られたことだけやってたら良いと思う。
YAGNIってことで。
なんか変なのが来た!
|彡 サッ
>>770 >>773 >>774 >>777 ありがとうございます。
>>768 >>771 >>775 設定ファイルで切り替えられればVGAをサポートするのも面白いですね。
とんでもなく暇になったらリアルモードをいじってみたい気もします。
>>793 少しは休めるかと思ったのですが全然駄目でした。
MonaGUI-0.1の今日中のリリースは不可能となってしまい申し訳ありません。
このままずるずると先延ばしにするのは不本意ですので、
明日は仮病でサボってMonaGUIの開発に集中することにします。
アンケートなどは明日までお待ちください。
とりあえずは仕事一段落で復活。 OPERAのタブに入れて毎日見てはいたんだが途中から変なページ飛ばされてそれっきりだったので 今ようやく過去ログ見終わったです。 でもその前に部屋掃除しないとPC取り出せない罠(氏
MONA実行方法を読みつつbochs環境ととのえてみたけど VESA not supported. sorry kernel stop. と出て実行できない… とりあえず必死こいて動作環境+開発環境ととのえてまつ。
>>824 さん
もしよろしかったらどこかに対応版bochsをおきましょうか?
>>812 さん
申し訳ありません。
現在こちらで環境がないため試せませんでしたが
libuser.aのリンクがうまくいっていないようです。
どなたかお分かりになる方がいましたらご指摘いただけると助かります。
>>813 さん
ご要望ありがとうございます。
開発版リリースで16bit版も欲しいということでしょうか?
>>814 さん
ご要望ありがとうございます。
次回リリースにおきましてFATFSでその機能が
実現されるかもしれませんのでしばしお待ちください。
>>817 さん
ご要望ありがとうございます。
.ELF省略可能対応しました。
次回αリリースに盛り込まれます。
>>818 さん
ありがとうございます。
とりあえずリクエストのあるものと
コンソールあたりを触ってみる予定です。
>>822 Tinoさん
お疲れ様です。大丈夫ですか・・・
> MonaGUI-0.1の今日中のリリースは不可能となってしまい申し訳ありません。
> このままずるずると先延ばしにするのは不本意ですので、
> 明日は仮病でサボってMonaGUIの開発に集中することにします。
> アンケートなどは明日までお待ちください。
了解いたしました。
くれぐれもご無理をなさらぬようにしてください。
>>824 さん
お疲れ様です。
--enable-vbe?でビルドすると幸せになれます。>bochs
スマソ、いろいろ割り込みがあったんでさっき以来すすんでおりませぬ。
実際問題環境整えても実機で動かしてみないとNICのテストって大変だろうなぁと思いつつ
今日のところは寝ます。(明日新人くるし遅刻できないし)
>>825 実はいまだにbochsまわりよくわかってないので、もしして頂けるならうれしいです。
>>828 さん
Mona PJ Wikiの今日の一言にURLを張っておきました。
お手数ですがD/Lしたらお知らせください。
けします。
アンカーずれたorz
VGABIOS-elpin-2.40はVESA非対応です。
OS作ってどうするの?
疑問に思ったら負けだよ
>>834 それじゃマイクロソフト社に電話して、同じこと言ってください。
それか「XPがあるのに、なんでロングホーン作ってるの?」って。
前にRTL8139の話が出てきていたけどさ、RealtekのWebページに、 RTL8139のサンプルプログラムがあったけどあれって役に立たないのかね。 という情報をおいていきます。
つーかプロトコルスタックどうする気よ? WindowsみたいにBSDからパクるしかないだろ $ strings /cygdrive/c/WINDOWS/system32/ftp.exe ... @(#) Copyright (c) 1983 The Regents of the University of California. All rights reserved. $ strings /cygdrive/c/WINDOWS/system32/nslookup.exe | grep Berkeley @(#)nslookup.c 5.39 (Berkeley) 6/24/90 @(#)commands.l 5.13 (Berkeley) 7/24/90 @(#)debug.c 5.22 (Berkeley) 6/29/90 @(#)list.c 5.20 (Berkeley) 6/1/90 @(#)subr.c 5.22 (Berkeley) 8/3/90 @(#)skip.c 5.9 (Berkeley) 8/3/90 @(#)getinfo.c 5.22 (Berkeley) 6/1/90 @(#)send.c 5.17 (Berkeley) 6/29/90
>>837 否定的なわけじゃないけど、企業に一個人用のOSにドライバ提供しる!って
言っても無駄なような希ガス。
先の話になるかもしれませんが、音楽や画像などのフォーマットはライセンスフリーの OGGやPNGなどにして欲しいと思っています。 どうでしょうか?
それはアプリケーション次第では。 OS自体は特にファイル形式に依存する事は無いと思う。 それともOS標準の事かな(WindowsとWindowsMediaみたいな?)
>>832 おお、それですーーーー
よく見付かったねーーーー
>>842 はい。そうです。
OS標準搭載アプリケーションに対応して欲しいと思っています。
その辺の話ってOSASKで2年くらい前に散々言い合ったやつだね
そういうソフトを標準搭載するときになったら考えましょうや。 もっと別の形式が出てるかもしんないし。
>>845 そうなんですか。知りませんでした
無知ですみませんでした
>>846 そうですね。
よりよいフォーマットが開発されるかもしれませんからね (^_^)
参考になりました。ありがとうございました
>>847 これは私の書き込みです。
名前入れるの忘れてしまいました。 _| ̄|○
>>840 お金積めば大概作ってくれます。
それなりの金額とドライバに関する仕様書も必要ですが。
まあ現実的な所で、「ドライバ書きたいので資料下さい」ですな。
>>817 NWSOSのWikiにlsが掲載されたね
>>829 ありがとうございます。
とりあえず慣れるまでいじってみます。
>>838 さん
情報ありがとうございました。
>>839 さん
プロトコルスッタクは勉強のために全部自分で自作される方と
移植される方がいるかと思いますがどちらもかまわないと思います。
>>841 さん
画像フォーマットに関しましては846さんと同意見です。
>>851 さん
おやくに立てて何よりです。
ファイルは消しておきました。
Linuxでのビルドエラーに対応しました。
次回開発リリースで反映されます。
Wikiでアドバイスを下さったななしさんありがとうございました。
mona-0.2.0alpha8をリリースしました ・JPEGDEMO外部ファイル読み込み対応 thx! nikqさん 使い方 JPEGDEMO NEKO.JPG ・シェル:.ELFを省略可能にした。 ・Makefile 修正 Linuxビルド対応 thx!ななしさん ・FDCのモータ制御のバグ修正 ・File Output Stream appendモード追加 thx! Gakuさん
そろそろMona上でもGOが動きそうだね。 エディタさえ揃えばセルフ開発出来るかも!?
>>852 本当はそんな風に思っていないだろ(・∀・)
>>855 裏と表がないと社会人は務まらないだろ(・∀・)
前から気になってたんだけどTotalL Memoryってtypo?
たるる
今日一日頑張ったのですが、 新しい仕様の共有メモリがうまく使いこなせず挫折しました。_| ̄|○ リリースが遅れて申し訳ありません。 現状は、3月26日に出したスナップショットより後退してしまって、 まともに動かなくなってしまいました……。
>>852 了解しました。
ひげぽんタソ、開発に携わっている方々、 がんばってください
>>854 さん
動いたらうれしいですね。
確かにメジャーなアプリケーションとしてエディタが
あったら面白いと思います。Mona GUIでの実装になると思います。
>>838 さん
そんなことないですよ。
RTL8139で実験されている方もいらっしゃるのでとても助かります。
>>857 さん
ご指摘ありがとうございます。修正いたしました。
>>859 Tinoさん
ご指摘の件,MemoryMapクラスのコンストラクタが呼ばれていないため
発生いたしました。
取り急ぎ修正し、α9をリリースいたしました。
ご迷惑をおかけいたしました。
>>860 さん
ありがとうございます。
>>861 ありがとうございます。
>>862 ありがとうございます。
Wikiにも書きましたが、メンバをstaticにすると、
今回のようなAPI変更の影響を受けなくなります。
>>863 Mona GUIへの期待がすごく高まっていて
大変だとは思うけど、是非続けていいものをつくってください。
Mona GUIの出来でMonaの今後が決まるといってもいいすぎではないと思うので
Mona ネットワーク対応マダーーー __ 。 ___ B■Λ 。 \ B■∧ (,,゚Д゚) / (^(´∀` ) ━━ (| つ ━━━━━━━━━━━━━━━━━━ ヽ ) ━━━ | ̄ ̄ ̄ ̄ ̄| | ̄ ̄ ̄ ̄ ̄| | | | |
うーん、ドライバー作る以前に現在の割り込みまわりの作りこみ不足を何とかしないと、厳しいなぁ。
>>868 さん
動的な登録とかでしょうか?
具体的に必要な機能を挙げていただけると助かります。
確かに割り込みまわりは初期からほとんどいじっていないので
まずいかもしれません。
実機でマウスが動いてくれない・・・
>>870 さん
実機確認ありがとうございます。
起動時にマウスのエラーコードが出ていますでしょうか?
>>869 とりあえず、動的な割り込み処理は必須でしょうし、割り込み共有の処理も欲しいし、異常割り込みに対してのプロテクト処理も欲しいところですね。
まぁ、何はともあれ動的な制御と現在各割り込み処理内部で行われている8259に対しての処理の部分の分離、とか。
後は、spin lock周りの拡充もして欲しいところ。
もっと詳しい人の助言がほしいところだなぁ。私では畑違いなので助言をするには限界がある。
364でつ
>> 838さん
ありがとうございます。1つ目のNICでプロトコルスタックが動いたら
次にチャレンジする候補になると思います。
(サンプルコードを参考にする方が他のOSのドライバを参考にするより
同じようなコードになった場合のライセンス関係が問題なさそうだからです。
)
>>839 さん 852 862 ひげぽんさん
Etherフレームの送受信が安定しはじめてからスタックについてはまた考えますが
勉強のために作りたいとはいえ、その前に構造を確認する意味で一度移植するのも
良いかも知れないと考え直しています。
具体的にはInterface誌2004年4月号の
組み込みTCP/IPプロトコル・スタックTINET
(BSDのスタックをマイコンとNE2Kにポーティング)などです。
>>866 さん
マジレスすると、あなたの書き込みで久々に書き込むことになりました。
状況を報告しますと、Etherフレームの読み込みやってるところです。
一応、Etherフレームの読み書きまではできそうな感じがしてきていますが、
一般に言われるネットワーク対応というものにはかなりの隔たりがある、
素材や、資料的な意味合いのモノを作っているところです。
私の方は少しづつ進めばいいなと思っていますが、
他の方の実装にも期待です。
◆CFYAAAAAds さん
乙&おかえりなさいでつ。
こちらは期末より期首の方がどちらかというとキツイですね。
お互いがんばりましょう。
だれと浮気したの Hした?
遅レススマソ
>>871 エラーは出ていません。
実機はnotePC(thinkpad 600)。
やはりPS/2のマウス以外は認識しないのでしょうか?
追記: 肝心なことを書き忘れていました。 MonaOSのバージョンは0.2.0alpha10です。
--- カラアゲを作ろう ---
gamixタソおつかれ。 Mona GUIがだいぶ形になってきたので移植がんがー
適当なコテハンをつけてみるテスト。 土日作業と行きたいところだけど別件でイベント企画してため作業できませぬ。 >gamixさん Interface2004年4月号にも情報があるのですね。 ちょっと立ち読みしてみたいと思います。 とりあえずはトラ技2001年1月号を元に私は作ってみます。 #先にコンパイル環境を(氏
国産OSだからPC-98で動作きぼん
osaskとかメグナントカは98で動くよん。
Mona Ver2.0.0alpha6を 実機で確認したところ、 Mouse init error=8が出て マウスが正常に動作しません。 やっぱり、AT時代のPS/2よりでっかいコネクタに マウス刺しているから駄目?
error 8 歴史の重みに耐え切れません 解説 歴史のあまりの重さにmonaが悲鳴を上げています。 肩の荷を降ろしてあげてください。
ワロタ
>>876 おれぺこです。
相手が人間じゃないのでHは無理です。
ダッチタンでもHは可n
>>887 Hな動画欲しい?
石原さとみ風。(名前あってる?)
4MBある。
>>889 もうエロビデオって歳じゃないです。
エロくなくても美人を見てるほうが幸せです。
デスクトップの方でα10動かしたら Mouse init error=8 と出ました。 マウスはPS/2接続なんですが、光学式です(あまり関係ないか?)。 同じ症状の方が居るようですが何か共通点でもあるのでしょうか?
Mouse init error 8 >>ひげぽん カーネルのソース見たけどKBCからのデータが複数バイトで来るときに、IN(0x64)&0x1==0x1のチェックは 始めの1バイトの前だけでいいんだよ。2バイト目以降はチェックしない。
>>873 さん
ありがとうございました。
次回メジャーリリースには間に合わないかもしれませんが
必ず対応させていただきます。
>>874 gamixさん
移植の件楽しみです。
是非がんばってください。
>>875 Tinoさん
RC1リリースおめでとうございます。
早速いくつも質問してしまいすいませんでした。
>>877 さん 884さん
ご報告ありがとうございます。
マウス周りではまだいろいろと問題がありそうなので
改善させていただきます。(USBは厳しいかもしれませんが)
>>893 さん
ありがとうございます!!
試してみます。m(__)m
Tinoタンおつかれ。 Mona GUIの使い方が分かるようなサンプルがあるといいな。 初心者向けのはラベル・ボタンがあったので分かるが 中級者・上級者向けのサンプルがあるといいと思った。 例えばゲームとか本格的なアプリとか。 あと将来実装予定は含めず現在のMona GUIでできることできない事が 評価何かでまとまっていると分かりやすいかな。 走すれば質問しなくてもある程度判断できると思うので。
>>893 さん
> カーネルのソース見たけどKBCからのデータが複数バイトで来るときに、IN(0x64)&0x1==0x1のチェックは
> 始めの1バイトの前だけでいいんだよ。2バイト目以降はチェックしない。
上記はihandlers.cppのMouseHandler()でのデータ受信のことでしょうか?
それともtest_higepon.cppのint Mouse::init()のことでしょうか?
実機での動作報告(α10) キーボードが反応してくれなくてコマンドが打ち込めない。 キーボードはPS/2接続日本語 109キーです。
>>897 test_higepon.cppのことです。
>>896 ご意見ありがとうございます。
> Mona GUIの使い方が分かるようなサンプルがあるといいな。
はい、まったく同感です。
もともと↓に書きましたようにサンプルを豊富に揃えるつもりでしたが、
http://mona.sourceforge.jp/dynamic/pukiwiki/pukiwiki/pukiwiki.php?Tino%2FMonaGUI >> サンプルがリファレンス代わりになるくらい充実させないと、まずいかなあ
ここ最近あまりに忙しくてMonaGUI自体の開発すら滞ってしまったため、
止むを得ずリリースを先にすることにした次第です。
> 例えばゲームとか本格的なアプリとか。
はい、同感です。
まだMonaGUIでは本格的なものを作れるほど成熟していませんが、
このくらいのものなら作れるという目安を示すと言う意味で、
電卓やマインスイーパなら今のMonaGUIでも作れそうなので、
時間があったら取り組みたいとは思っていました。
> あと将来実装予定は含めず現在のMona GUIでできることできない事が
> 評価何かでまとまっていると分かりやすいかな。
なるほど、出来ることをまとめるという発想はありませんでした。
もっとも出来ないことが多すぎて将来の話になっているのが現状です。
とりあえず将来実装予定になっていることは、
今のMonaGUIでは出来ないことを意味しています。(泣)
サンプルがあれば、きっといろいろとアプリが登場すると思うので がんばってください。
_ /〜ヽ (。・-・) 。oO( さんぷるぷるぷるぷりんぷりん♪ ゚し-J゚
Mona GUIすげーな。 jpeg表示も出来るのか これは一種の祭りでしょ。 次のMonaのリリースまでにどれだけアプリをそろえるかが鍵とみた。
久々に来てみたらすごいことになってますね。 これほどのものを作れる人たちを本当に尊敬します。 ソースを見て理解できればもっと楽しいんだろうなあ。
そうそう、リリースの際にはSourceForgeでプロジェクトのニュースも出すと良いよ。 運が良ければSF.jpのトップでも取り上げてくれるし。
最低限のマウス有効化は byte data; outp8(0x64, 0x20); if (waitReadable()) { return 3; } data = inp8(0x60); outp8(0x64, 0x60); if (waitWritable()) { return 4; } outp8(0x60, data & (~0x30) | 0x3); if (!waitReadable()) { inp8(0x60); } outp8(0x64, 0xd4); if (waitWritable()) { return 10; } outp8(0x60, 0xf4); if (!waitReadable()) { inp8(0x60); } だけあれば有効になる。
>>898 さん
ご報告ありがとうございます。
後述のマウス認識問題が片付きましたら取り組ませていただきます。
動作報告等ご協力いただければ幸いです。
>>893 さん
ご親切にありがとうございます。
ちょうどマウス初期化見直しをしていたときなので大変助かりました。
893さんのコードをそのまま流用したところ手持ちの実機・エミューレータで
動作したのでα11リリースに含めさせていただきました。
>>904 さん
ありがとうございます。
ソースですが大半がC++で書かれています。
少しずつ読んでいけば理解できるかもしれません。
>>905 さん
> そうそう、リリースの際にはSourceForgeでプロジェクトのニュースも出すと良いよ。
> 運が良ければSF.jpのトップでも取り上げてくれるし。
ありがとうございます。リリース時の作業として追加いたしました。
このあいだのスラッシュドットでの投稿でアクセスが急増した経験もありますので
リリース時にはプロジェクトニュースを出して見ます。
α11をリリースしました
mona-0.2.0alpha11
・Randomクラス追加:乱数生成
・マウス初期化見直し thx 893さん
マウスが認識されてない問題をご報告いただいていた方は
お手数ですが改善されているかご確認・ご報告いただけると助かります。
\γ⌒ヽ \γ⌒ヽ \γ⌒ヽ \γ⌒ヽ \γ⌒ヽ \γ⌒ヽ \γ⌒ヽ \γ⌒ヽ \,,_⊂゙⌒゙、∩ \⊂(。Д。)gamixタン、S.R.タン \ ∨∨ Monaから2chへの書き込み実現して! \ \ \
>>907 乙カレー
α11動作報告
マウス動きました(Thinkpad600&自作機)
そして、キーボードも反応しました。
対応有難うございます。
早速のご確認ありがとうございました。 キーボードも反応したようで一石二鳥ですね! すべて893さんのおかげです。 ありがとうございました。
久々に見にいってみたらム板のつくろうスレが死んでるから終了したのかと思ったらOS板でやってたのね・・・ 今後もがんばってください
Mona GUIのサンプルアプリケーション マ━(゚∀゚)━( ゚∀)━( ゚)━( )━(゚ )━(∀゚ )━(゚∀゚)━ダ????
>>912 すみませんが、RC2で大幅な改造をすることになったので、
ちょっとサンプルにまで手が出ない状態です。
>大幅な改造 キター
このスレWeekdayは休業か。 仕事ガンガってください
平日は他スレに浮気
587 名前:Tino ◆sMrLqQHxo6 投稿日:04/04/05 22:07
>>586 キタ━━━━(゚∀゚)━━━━ッ!!
浮気 キタ━━━━ヽ('∀`)ノ━━━━!!!! 今日はソースツリー整理中です。 Mona GUIサンプルがんばってみます。
>>917 AMD64ってすっごく期待してて新しいマシンを買うのを控えてたんですよ。
そしたらAthlon64がリリースされてもWindowsのリリースが延期されてしまって
最近UN*X関連を使わないから買う気がなくなってしまって、
結局ケチってAthlonXP 2400+で新調してしまいました。
そんなときにおれぺこを見て凄いなあって素直に感心してしまいまして、
経済的に実機が買えなくても何か近付ける方法はないかな、と思ったもので。
昔UN*X関係をちょこっといじってた知識が役に立った感じです。
個人的にはLinuxよりFreeBSD、CygwinよりInterixの方が好きです。
単純に個人的な趣味なので別に優位性を主張する気はないですが。
ldがELFを扱えないようでMonaがInterixでコンパイルできないのが辛い所です。
>>918 お疲れ様です。
多分今晩中に終わらないと思いますが私の方もRC2の実装頑張ります。
言い訳するTinoタンかわいいw 冗談です。がんがってください
|ー゚) ソォーッ
Tinoさんのおかげで開発がずっと楽になって大助かりです。 Windowsで手軽に開発できる64bitOSになっちゃいました(*`-`)σ)'∀`)
MonaをビルドしてBochsで実行したのですが、 VESA not supported. sorry Kernel Stop と言われてしまいます。皆さんの話を聞く限り実行できているようですが どうしてでしょうか? Bochsのバージョンは2.1.1でちゃんとVGA-BIOS-elpin2.40も入っています。 それはさておき、Monaを解析して疑問点が2つほど出てきたのですが まず一つ目はsecondboot.asmの最後。 cstart.cppにジャンプするコードで jmp 0x200になっていますが なぜこれできちんとした位置にジャンプできるのかわかりません。 jmpに即値を与えると相対ジャンプになるので前々から何でこれで うまくいくんだろうと思います。 二つ目がMemoryManager.cppのallocateの部分。この関数はメモリ領域の リストをたどって、求めるサイズと同じかそれ以上のメモリ領域を探しています。 このとき、見つかったメモリ領域が求めるサイズより大きければ分割することに なりますが、サイズの比較が current->size と realSizeになっています。 current->sizeには実際に確保された(求められた)サイズが保存されているので 関数の引数で与えられた size と比較するのが正しいのではと思います。 というか、解析しているうちに新しいバージョンが出ちゃったんだよなー・・・ また初めから見ていかなきゃ・・・
えと。alpha11でマウス動作しました。
>>920 さん
お疲れ様です。
Monaももう少ししたら64bit移行するかもしれません。
下調べとマシンの調達が完了すればですが。
> 多分今晩中に終わらないと思いますが私の方もRC2の実装頑張ります。
よろしくお願いいたします。
>>926 さん
bochsでMonaを実行するためには以下の条件が必要です。
・--enable-vbeオプションでbochsをビルドする(cygwinなどで)
・VESAに対応したVGABIOS-lgpl-latestを使う
> jmpに即値を与えると相対ジャンプになるので前々から何でこれで
> うまくいくんだろうと思います。
Monaのブートは・・・
忘れました。すいません。
アセンブラは苦手です(いいのか・・・)
> current->sizeには実際に確保された(求められた)サイズが保存されているので
> 関数の引数で与えられた size と比較するのが正しいのではと思います。
うろ覚えですが
current->sizeにはヘッダサイズが含まれていない仕様だった
思います。
>Zakkyさん
ご確認ありがとうございました。
Z-Slashいつもチェックしています。
>>929 >>926 のMemoryManagerですが一晩ぐっすり寝て考えてみました。
やっぱりcurrent->size と realSizeの比較で正しいです。
例えば、current->size = 1024 で求めるメモリ領域が1022のとき、
>>926 で言ったようにcurrent->size と 求められた大きさで比較すると
current->size の方が大きくなり、メモリブロックの分割をしなければなりません。
ところでこの場合は初めの1022バイトをとってしまうと、2バイトしか残らず
メモリブロックのヘッダーを書き込むことが出来ません。
このようなわけで realSize と比較することが正しいということになります。
こういうところはきちんと考えなければいけませんね。
ところで、PageManager.cppでページテーブルの領域を確保するとき
実際に必要なページテーブルの大きさの2倍の領域を確保していますね。
4キロバイトのアライメントにあわせるのが目的だと思いますが、
実際に必要な領域 + 4キロバイトで十分だと思います。
>>930 さん
> 実際に必要なページテーブルの大きさの2倍の領域を確保していますね。
> 4キロバイトのアライメントにあわせるのが目的だと思いますが、
>実際に必要な領域 + 4キロバイトで十分だと思います
こんばんは。
実際に必要な領域が4KBなので 4 * 2 = 8KBになっています。
本来であればメモリをビットマップなどで別管理して
メモリを無駄に使わないという実装が望ましいと思いますが
まだ手を付けていません。
>>932 ひげぽんをはじめ開発者の方々
お疲れ様です
いつの日かMonaMagazineが販売されたらなと思ってみる。
>>933 さん
こんばんは、お疲れ様です。
> いつの日かMonaMagazineが販売されたらなと思ってみる。
あー。3秒くらい妄想しました。
夢のまた夢ですががんばります。
ひげぽん始めみんながんがれ〜〜 開発が進むと凄いハァハァしてま 将来、市販されてるマシンにMONAがプリインストールされることを願って応援してま♪
>>936 ありがとうございました
0.1.5 で動かしてみました。
mona.bochs は ver.up しなくていいのですよね?
boachs と VMWare 3.1.1 とも
"VESA not supported. sorry kernel stop." と表示されました。
(止まってしまいますが) boot しているようですね。
>>935 >VESA not supported. sorry kernel stop
ガイシュツ
このスレで2回は質問されている。
940 :
Be名無しさん :04/04/07 19:28
>>935 さん
ありがとうございます。
>>Zakkyさん
フォローありがとうございました。
>>937 さん
応援ありがとうございます。
>>939 さん
>>940 さん
フォローありがとうございます。
940さんの手順でMonaが起動できることを当方でも確認しました。
> ただシェルにdirが実装されてないから何が出来るか分からないのが問題
> その辺何とかしてホスィ
入れ違いになってしまいました。実装いたしましたのでお試しください。
いまだに忙しくて、Monaを動かす暇がない...。
, -=- -─‐-、 _ ´-─ ¬く  ̄  ̄ミ- 、 ,,,,/ _==-ミァ-─‐-、 \''''''''''''ー--、,,,,,_ _,,,,-''"/ , ‐''" \ \、_,,,ー''ゞ" `ゞ、 -' " / / / | \ ヽ /"` _,,-''''''"""''''' / / / / / || | i ヽ i / ´"''、. i / / / / / / || || |│ |ノス / '、 |// / /___, -一ァ| /! |ト、|│ | | く」/ '、 |,-‐¬ ---┘'7 |! ハ! |,、-┼十|!/\/\ , -‐ ''" し' '´_ /,ィ二l |ト、/!ヽト、\_ヽ!|!l\:.. / ,r/ __ ,イ|リ ヾハ! ヽ! ,ィ⌒ヾミリノ/:::... \ / ||ヽ -' / ̄ )` __ |ヒノ:} '` ,;\/\/ ,r ' ヾ、 ,-、____ , イ ̄,r==- ==-' レ' /| | / ヽ `ーソ ' | |ト、,ヘ ′"" "" / / || | . / \_ / | ハ ヽ`゙'ヘ ' ' / / | | | <がんばってくださいな / / / | ヽ 川\ 0 //! | | | | / / / 八 \川| |`ト- .. __ , イ‐ァヘ | | || |! / / / / \ \ 「`ー- 、 / .〉 ト、| ヽ、 ,イ /-─=¬ニヘ、_ \ 厂\ 厂ヽ /!| | `ー=ヘ -‐  ̄ /─ '  ̄ ├- ヽ\ \ノ\ \ 人 ハ!ヽ || |-┤ ヽ / /!‐-- | |\ ト、_`ヽ oヽ ト、! || |‐┤- ヽ // 〉 __ / ├‐- || | 川-‐ | | 厂7! ハ! ├:┤  ̄ヽ / / ー ─  ̄ ├‐- リ || ハ!ヘ | | ト┤|/′ ヾ,┤ ゙i_ ‐ ' 〉‐- | / /\ .|o | /ヽ/(′ ∨ \
>>940 ありがとうございます
無事 shell までこぎ着けました。
猫のJPG も表示されて良い感じでした
QEMUのCVS版で0.2.0beta1を試してみましたが、Mona loading...で止まります。
何故かFilip氏版(
>>946 のもの)でも手元の環境では止まりました。
あ、すいません。HDDとしてmona.imgを読ませていたのが問題だったようです。Filip氏版、CVS双方で loading /SERVERS/KEYBDMNG.SVR....OK までいけました。
>>947 さん
ありがとうございます。
シェルに入力等できましたでしょうか?
ダメでした。今のところQEMUのWin32版はFDを読めればいーなー、というぐらいの実装具合のようなので 更新待ちですね。というかひげ氏ついでにお願いします。
>>950 ありがとうございます。
手持ちのqemuでもう一度実行したところ...OKとサーバーの読み込みが
成功しているのでFDCはうまく動いているかもしれません。
Monaの問題かもしれないのでちょっと調べて見ます。
ダメだったらすぐあきらめます。
>>951 ちょっと確認なんですが、起動
> qemu.exe -L . -m 32 --fda mona.img
でいいんですよね? mona.imgのアーカイブはSFからつい先ほど落としてきたものです。
こちらは↓でやっています。 qemu.exe -L . --fda mona.img
>>947 さん
バイナリありがとうございます。
qemuである程度動作するようになりました。
とあるタイミングでタイマ割り込みがマスクされてしまうようでしたので
とりあえずカーネルを修正しておきました。(CVS最新版)
ただマウスの初期化に失敗しているようで
マウス割り込みがずれてしまい、マウスが使えないです。
このあたりどなたかフォローいただけると助かります。
それにしてもqemuは速いですね!
Monaでネットワーク機能はどこまでいっているの? もしかしてMACアドレス取得までは追えてたんだけど。 次回リリースでパケットの送受信できたりするとうれしい。
>>956 さん
ありがとうございます。
パケットの受信を実装中です。(割り込みなしでポーリング版)
リリース時期によるかもしれません。
送信は…おって報告します。
スマソ、漏れの方は去年度の仕事片付けで何も手ついてないです。 土日にようやく時間が取れるので成果物ができればいいなぁと思いまつ。 と、qemuとかまた知らない単語でてきてるーよ…
>>958 S.R.さん
乙でつ
それそれ今年度以前に昨年度の仕事ですね。頭痛い。
こちらもあんまり時間が取れず、一日数行づつ書き足して言ってる状態です。
qemuはOS板qemuスレによるとBochsより5倍ぐらい速いエミュレータです。
Bochsのような箱丸ごとだけではなく
IA32のコードをLinux上のユーザモードで実行したりして、Wineと一緒に使えば
PPCなLinuxでもWindows、IA32のバイナリが…とかそういう使いかたもできます。
(逆にARMエミュレーションとかもできるはず)
どちらかというと箱丸ごとよりもCPUに重点が置かれ、JIT的な動作らしいですね。
それはそうと、ここではqemuがWindows上でも動き始めたので話題になってるのですが、
NICについてはまだWin32上では未実装のようなので私は気にしていません。
おお、QEMU本当に早いですねぇ。 QEMU ROSのF神版という奴と、最新Mona Kernelの組み合わせでブートしてみたんですが、 Bochsとは次元の違う速さ! まぢで良いですねぇ。 あと、VesaConsole::VesaScreen::scrollUpですがコピーする場合比較して、同じだったら コピーしないほうが1.5倍くらい早いですよ。 とか、どうでも良いようなことを書いて逃げてみる。
>>958 959 960さん
QEMU使って見ました。確かに速いですね。
気になったのでQEMUのhw/pc.cを見ると
static uint32_t ne2000_io[NE2000_NB_MAX] = { 0x300, 0x320, 0x340, 0x360, 0x280, 0x380 };
static int ne2000_irq[NE2000_NB_MAX] = { 9, 10, 11, 3, 4, 5 };
とありましたのでIOアドレスGETMAC側でIOアドレスを0x280にして
>>953 ひげぽんさん
を参考にして
qemu -L . --fda mona.img --macaddr AA:BB:CC:DD:EE:FF
として、GETMAC.ELF起動すると
すごい負荷がかかってQEMUのプロセスが応答無しになりました。
以上報告でした。
QEMU対応版のイメージどこ
>>926 さん
> jmpに即値を与えると相対ジャンプになるので前々から何でこれで
> うまくいくんだろうと思います。
記述は絶対値ですがコンパイルされると相対値になります。
>>957 さん
パケット受信楽しみです。
>>960 さん
VesaConsoleご指摘の点改善してみました。
ありがとうございます。
>>961 さん
なるほど。qemuって他OSではネットワーク通っているんでしょうか?
>>962 さん
リリースしました。
>>963 さん
フォローありがとうございます。
ウェ━━━━━(OwO)━━━━━イ!!!
キタ━━━━ヽ(`エ´*)ノ━━━━!!!! PSかっこいい Mona GUIすごいね
Mona GUIきれいだねー。デザインがイイ NOIZ2BG.ELFとか。GUI版移植したらNWSOSのfireみたいでかっこいいかも
IDE周りで妄想したこと書き込んでも良いですか?
板違いですのでお帰りください
いや、Monaの設計上の話なんだが。
ここはOS板です 妄想を語り合う板ではありません お引取り願いします
>>1 のテンプレをパワーアップして
次スレを立てて。(プロバイダ規制中)
埋め
.埋め
結局どのスレにするのよ。
あと残り18ですよ
じっれったいなぁもう
ひげぽん ◇Ngzcp/NZpA こいつ誰だったの?
子供を作ろうが(悲
(´∇`)ヒゲポソ ◇2HImExsoWc こいつも謎だった
振り返ってみるとみんないい想い出だ
産め
産め産め
生め
生め産め
宇目
うめ
生め
産め
ひげぽん ◆Ngzcp/NZpA = (´∇`)ヒゲポソ ◇2HImExsoWc = ひげぽん ◇Ngzcp/NZpA だったのか?
全ては闇の中へ。。。
もう残りわずか
1000 :
鳥取砂丘 ◆Dream/3P/. :04/04/10 03:57
(´・ω・`)
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。