OSを作ろうpart5

独自にOSを作っているまたは、作ろうとしている人たちのための
スレッドになればと思います。

Monaプロジェクトページ
ttp://mona.sourceforge.jp/

OSをつくろうpart4
http://pc3.2ch.net/test/read.cgi/tech/1037096449/
OSをつくろうpart3
http://pc3.2ch.net/tech/kako/1027/10270/1027080631.html
OSをつくろうpart2
http://pc3.2ch.net/tech/kako/1024/10244/1024411711.html

プロジェクトメンバーになりたい方は、
[email protected] までメールをどうぞ。

最新のイメージファイルは以下のURLから落とせます。
ttp://mona.sourceforge.jp/Download.html

ソースファイルの閲覧はここからできます。
ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/

ｽﾞｻ━━━━⊂(ﾟДﾟ⊂⌒｀つ≡≡≡━━━━!!

新スレおめ

3GET、ごめんなさい･･･（確○犯

あ・・・

嗚呼･･･

嗚呼…

乙

（＾＾）

読んでみた。
前半は難解だったけど最後まで読んだら
ネットについての理解が格段に深まった。
ありがとう。

他の人も、煽ってばかりじゃなくて
一度読んでみるといいと思う。

age

>>10
何を読んだの？
>>1 のソース？

俺も暇だからブートの部分だけ勉強してみよ

前スレ落ちた？

>>14
落ちたみたい

もっとガンガン埋めとくべきだった、、、

（＾＾）

http://pc.2ch.net/test/read.cgi/os/1031404041/904

>Mona が Unix user にちょっとだけ出てた

だそうですが、読んだ人いませんか？

>>17
bochsの記事で、bochsのデバッグ機能が『mona』のブート部分の開発に役立った
というものでした。

>>18

ありがとうございますた。

>>18
なんかそれだけみると。bochsの何のために有るか分からん機能が
monaに役に立った。って書いてあるように見えるなぁ。

>>18
ひげぽん「また落っこちました〜」
まわり「だからbochsのログだせやぁ」

の流れを思い出しました。ｗ

>>21
>の流れを思い出しました。ｗ
あの時も、今もたくさんの人のお世話になっているということですね（笑）

ところで今日は、TSSを使わないタスクスイッチの簡易実験に成功しました。
eflags, csがいまいち更新されてなくて怪しいなど
不確定な要素満載ですが、一歩前に進みました。

アドバイスを下さったたくさんの方々、本当にありがとうございました。m(__)m

マーはニーしる！
を思い出しました。

>22
「タスク切り替え」なんてものは、定義が適当だし、今の段階では
実際的な「タスク切り替え」とは程遠いので、あんまり大したこと
ではない。

>>24
>「タスク切り替え」なんてものは、定義が適当だし、今の段階では
>実際的な「タスク切り替え」とは程遠いので、あんまり大したこと
>ではない。
全くおっしゃるとおりです。
ただ今回の実験を通していろいろ勉強できたので
自分的には収穫は大きいです。

何か最近Monaの進歩状況がよくわかんないな〜
知りたきゃCVSから取ってこいってのは敷居高くない？
わざわざトップページ更新するほどじゃないのかもしれんが、
SF.jpに日記機能あるんだし、開発日誌みたいなの公開しないの？
https://sourceforge.jp/developer/diary.php?diary_user=2006

CVSを取ってこないと分からない例
1. STLがどうなったのか
2. VPC対応がどうなったのか
3. タスク切り替えがどうなったのか

あと64bitの話が出てたがどう考えてるの？
新規開発者が加入されたようだけどHP更新されてなくて可哀想...

ま、辛口だったかもしれんが、応援してるんで頑張ってちょ

>何か最近Monaの進歩状況がよくわかんないな〜
>知りたきゃCVSから取ってこいってのは敷居高くない？

ご意見ありがとうございます。
こういうところは、なかなか自分で気付かない所なので
ご指摘は大変ありがたいです。

以下ひとつずつ、回答いたします。

>わざわざトップページ更新するほどじゃないのかもしれんが、
>SF.jpに日記機能あるんだし、開発日誌みたいなの公開しないの？
>https://sourceforge.jp/developer/diary.php?diary_user=2006

開発のソースレベルの変更をお知りになりたいのであれば
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/ChangeLog
よりChangeLogを見ていただくのが良いかと思います。
CVSにコミットする場合は何らかのコメントを入れています。

それ以外に必要であれば、どこかに近況を入れようかと思いますが
どこが良いでしょうか。皆さんのご意見をうかがいたいです。

(1)sourceforge.jpの日記
(2)MonaBBS
(3)Monaトップページ
(4)作ろうスレ(ここ)
(5)メーリングリスト作成(現在非公開の開発者用メーリングリストはあります)
(6)その他

長くなってしまったので分けて。

>1. STLがどうなったのか

STLPortが使えるようになりました。
カーネルの実装にはまだ用いていませんが、いずれ使う事になると思います。
特にコレクションなど。

>2. VPC対応がどうなったのか

昨日にやっと、VPCでのブートとタスクスイッチが動作しました。
ただイメージとして公開している物は古いバージョンなので
VPCでは動きません。

イメージとして最新版を公開していないのは
現在タスクスイッチ(TSSを使用しないバージョン)の動作がまだあやしいためです。
安定後公開したいと思います。

もしどうしても最新版のイメージがほしい場合は、Make環境を整えていただくか
ひげぽんに言っていただければ、何とかいたします。

>3. タスク切り替えがどうなったのか

ここ最近、ずっと実験中かつ、実験が失敗していたので特に進捗はありませんでした。
昨日やっと、少しめどがたったのでいろいろな実機で実験しようと思っています。

>あと64bitの話が出てたがどう考えてるの？

IA32アーキテクチャの理解もままならないのでしばらくは
64bit化を見据えた開発はしないと思います。
ただ、どなたか詳しい方がいらっしゃって
アドバイスいただけるのであれば、積極的に今からある程度
準備するのはありだと思っています。

>新規開発者が加入されたようだけどHP更新されてなくて可哀想...

すいません、なるべく早く追加いたします。
yuryuさんこれを見ていたら、開発者メーリングリスト宛に
メールください。

>ま、辛口だったかもしれんが、応援してるんで頑張ってちょ

貴重なご意見ありがとうございました。
他にも同じような事を思われていた方もいらっしゃると思うので
できるだけ改善していきたいと思っています。

> ここ最近、ずっと実験中かつ、実験が失敗していたので特に進捗はありませんでした。
> 昨日やっと、少しめどがたったのでいろいろな実機で実験しようと思っています。
こういうようなことを、自分の言葉で書ける日記は特別な意味があると思う。
→「あれやった、でも駄目だった、と思ったら勘違いだった」みたいな
他人にとっても泥臭さを通じてmonaを身近に感じる人もいるだろうし、
後で自分のやってきたことを見返すときにもきっと役立つ。

>1. STLがどうなったのか
こういう書き方だと、
2chブラウザとかで >>1 と混同される

これに限らないがこの手の混同を避けるため
引用符と引用文の間はスペースを空ける慣習があるんだよ

何でひげぽんさんはこっちではトリップ付けないの？
MonaBBSではこんなにはじけちゃってるのに（藁
> (´∇｀)ﾋｹﾞﾎﾟｿ ◆Ngzcp/NZpA

トリップは自衛の手段なんだから。
偽者がめちゃくちゃ書く可能性を自分で作ることになるよ。
こっちでもはじけちゃいなよ（藁

>>32
なんかあってからそのトリップつけりゃいんじゃない？

おまい、しんでからシートベルトつけても遅いんだぞ

つーか、書いてる内容でだいたいわかるだろ。
荒らすような偽者には、このスレは敷居高いと思う。

>>34
ぬ、MonaBBSで >>32 のトリップ使ってるのかと思ったんだが、
どうやらさっき確認した限りではそういう例が見つからなかった。
勘違いですた。

というか、トリップなんて後で適当に決めちゃってもオフイシャルページで宣言しちゃえば問題ないじゃん。

>>35
まぁね。分かるよね。騙すにはそれなりに技術レベルも必要だし。

>>36
一体全体、どこ探したの？？？
http://pc3monaos.hp.infoseek.co.jp/cgi-bin/2ch/test/read.cgi/entrance/1042291353/l50

あと誰も書き込まないMonaBBSで付けてるのに
荒らしの巣窟の2chで付けないことをなぜ擁護するか理解できん。

> 荒らすような偽者には、このスレは敷居高いと思う。
ひげぽんさんが登場するのはこのスレだけではないと思われ
それこそOSASKとかNWSOSとかの絡みでしょっちゅう引き合いに出されてるし

ていうか前はトリップ付けてたけど…

ほんとだpart3みたらついてる、、、

にしても、NWSOSの進行が速いな。さっき最新版ダウソしたら
いつのまにか、いろんなGUIアプリが動いてた。ってかメモ帳程度の
ものが当たり前に動いてるし、

なんなんだ、いったい

MONAもNWSOSも自作組み立て機で動いた。わーい

＃会社のPCなんで、linux入れてProxyキャッシュサーバとして稼動させる
のが本来の予定だったんだけど、NWSOS動かしたら周りの人が、なにそれなにそれ
みたいな感じで群がってきた。MONAは、今のところBIOSっぽい画面なんで
BIOSと思われてるらしく、あまり注目されてなかった。
ってことで、MONA頑張れ。

>>41-42

桜？
頑張れ。

>>43 は友達がいないタイプだな

>>31
> 引用符と引用文の間はスペースを空ける慣習があるんだよ
了解しました。

> 何でひげぽんさんはこっちではトリップ付けないの？
> MonaBBSではこんなにはじけちゃってるのに（藁

>>32-40
面倒だったので付けていませんでした。＞トリップ
なのでつけてみました（笑）
トリップを付けるかどうかは、結構気分かもです。ごめんなさい。

>>42
> みたいな感じで群がってきた。MONAは、今のところBIOSっぽい画面なんで
> BIOSと思われてるらしく、あまり注目されてなかった。
> ってことで、MONA頑張れ。

NWSOSと比べられたら、大負けですね。
というか、どのOSと比べても負けてる。
もっといえばBIOSのほうがすごい・・・
でもがんばります、ありがとうございます。

トリップ失敗。。。

さてMonaの進行状況は技術的なことであれば、なるべくここに書いていこうと
決めました。

昨日はタスクスイッチ実験成功コードを見直していたところ
どうも動いていたのは奇跡かもという結論に達しました。

iretではなくretで切り替わっていた模様。
なのでEFLAGS,CSチェンジが起こっていなかった。

またスタックに積まれていると予期していたものと
実際でいろいろ勘違いがありました。

ある時点でスタックに積まれている内容を
そこで処理がとまっていいので表示したい場合は
汎用レジスタにpopして表示でいいんですよね？自信なし

自分でスタックを初期化して作ったプロセスのほうは
popaように0を積んで、eflags,cs,eipとやってiret
切り替えられました。(process2)

ただ起点となる(process1)の切り替えがうまくいかない
timerHandler
    schedule
        switchProcess
            ここで切り替え

インテルのマニュアルを読むと
エラーでない割り込みであれば
/* EFLAGS */
/* CS     */
/* EIP    */
と積まれているはずなのに、うまくいかないっす。
それぞれtimerHandler,scheduleのアドレスが
pushされているかと二つpopしてやってみたがうまくいかず・・・

スタックの内容が表示できるよう
#define _syspop(count)           {  \
                        \
   for (int i = 0; i < count; i++) {     \
     dword __eax;              \
     asm volatile("xor %%eax, %%eax\n"   \
           "pop %%eax    \n"   \
           "mov %%eax, %0  \n"   \
           : "=m" (__eax)       \
           : /* no input */      \
           );             \
    _sys_printf("_sysPop(): %x\n", __eax); \
   }                     \
}

作ってみたけどいまいちきちんと動いてなさそうな気がする。
うーんうまくいかず。

ところでCSて16bitだけど
割り込みでスタックに積まれる時は32bit?
かなあ。

表示が乱れてしまいました。
すいません。

> ところでCSて16bitだけど
> 割り込みでスタックに積まれる時は32bit?
> かなあ。

32bitのようです。
サンクスmitkoさん。

非プログラマブル部分があるからね＞CS３２BIT

もうおそいけど、次スレ作る際に現行スレのコピーとっておいて、
どこかのWEBページで見れるように保存しておいてほしかったなぁ。
前スレがDAT落ちしまくって後から来たものにはなにがどうなってるのか
分からない罠。

前スレの保存公開は禁じられてるのなら仕方ないけど。

>>51さんがこう言ってるんだし、
とりあえず過去ログどっかに置いていいんじゃない？＞ひげぽん

とか言うのもナンなのでHTML化されるまで出しておきます。
ttp://guriponn.tripod.co.jp/archives/os-part4.htm

>freedos教徒さん

ご苦労様です。
ありがたく拝見されていただきます。

↑拝見させて、だね

>>48
popしちゃうと戻れなくなるから、popせずにスタックを除き見るだけが吉だとおもわれ。
例えば、
handler:
pusha; 8個のレジスタ分つまり32bytesプッシュする
moveax, [esp+32]; eax <= エラーコード
moveax, [esp+36]; eax <= 割り込み時eip
movax, word [esp+40]; ax <= 割り込み時cs
moveax, [esp+44]; eax <= 割り込み時eflags
popa
iret
Cの関数にする場合は
void handler(unsigned long eip, unsigned short cs, unsigned long eflags)
{
interror_code = (&eip)[-1];
/* 割り込みの処理 */
asm("leave");
asm("addl $4, %esp"); /* エラーコードをpopする替わり */
asm("iretl");
}
とかするとよろし。

しまった。タブ入れ欄内の忘れてた。ｽﾏｿ

漢字むちゃくちゃだ。ﾓﾁﾂｹ漏れ

まさに今スタックのぞきみを思案中です
インラインとprintfでやってますがうまくいかないです

>>58
上の例を説明すると、

- 32bitモードの場合push対象が16bitでも32bit分のスペースをとる。
- esp は最後にpushした値を指す。
- Ｃ言語の関数は一般に以下のようにコンパイルされる：
　func:
　　　　push ebp
　　　　mov ebp,esp
　　　　; 関数の内容
　　　　leave
　　　　ret
- Ｃ言語の関数の引数としては call 前にpushした値が逆順に与えられる。
　例：

　　　　push dword 0x1234
　　　　call func

　void func(unsigned long x)
{
　　/* x=0x1234 */
　}
- C言語の関数は leave, iret ではなく leave, ret で終わるので注意。（前スレあたりでがいしゅつ）
- 例外の場合はエラーコードがプッシュされる場合があるので注意。

なんか要約したつもりが余計長くなってしまった。

>>48
やりたい事が良く分からないので的外れかもしれないけど
無理にインラインアセンブラにしないで
↓みたいな関数にしちゃだめなの？

; eax,ecx,edxが破壊されretで返るルールの場合
__syspop proc near
  push esi
  push edi
  push ebx
  mov edi, dword ptr[esp+16]
  xor ebx, ebx
  test edi, edi
  jz _syspop_02
syspop_01:
  push dword ptr[esp+ebx*4+20]
  push offset _syspop_buf ;printfの第1引数
  call _printf
  add esp, 8
  inc ebx
  inc edi
  jnz _syspop_01
syspop_02:
  pop ebx
  pop edi
  pop esi
  ret
__syspop endp

(昔の雰囲気が戻った)

#define _sysdumpStack() {

　dword stack0, stack1, stack2;

　asm volatile(
　　　　 "pusha                 \n"
　　　　 "mov  32(%%esp), %%eax \n"
　　　　 "mov  %%eax, %0        \n"
　　　　 "mov  36(%%esp), %%eax \n"
　　　　 "mov  %%eax, %1        \n"
　　　　 "mov  40(%%esp), %%eax \n"
　　　　 "mov  %%eax, %2        \n"
　　　　 "popa                  \n"
　　　　 : "=m"(stack0)
　　　　 , "=m"(stack1)
　　　　 , "=m"(stack2)
　　　　);

　_sys_printf("_sysdumpStack(): %x %x %x\n"
　　　   , stack0, stack1, stack2);
}

皆さんのご教授をもとに作って見ました。
とりあえずこれを使って、昨晩はtimerHandler突入後のスタックを
調べてみましたが
CS=0x08らしきものすらスタックに積まれている様子がなくて
戸惑っています。

考えられる可能性は
・_sysdumpStack()がバグっている
・_sysdumpStack()の前にすでにスタックが破壊されている
・ひげぽんの大きな勘違い
・その他。

とりあえずいきづまったので寝てから、もう一度冷静に考えてみます。

>>52
FreeDOS教徒さん
フォローありがとうございます。
yossyさんと検討してみます。＞過去ログ

＜　｀ー´＞y-~~ スタック見るならこれだけでええやん

dword* stack;
mov stack,ebp

printf("cs=%x,eip=%x,flag=%0x",*(stack+0),*(stack+1),*(stack+2));

// (stackframe) <- esp
// [cs　　] <- ebp
// [eip　　]
// [eflags]

ちなみに、関数のプロローグは、標準的には、
push ebp
mov ebp,esp
sub esp,(AUTO変数のサイズ)

で、しかも、csとeipの順序が反対なので、

// <- esp
// [AUTO変数領域
// ...
// AUTO変数領域]
// [ebp ] <- ebp
// [eip　 ]
// [cs　　]
// [eflags]
// [外側esp](もしあれば)
// [外側ss](もしあれば)

と夢の中でお告げがありましたのでご報告いたし上げます(南無)。

だって。

>>65
>>66ありがとうございます。
#define _sysdumpStack2(str) {　　　　　　 \
　　　　　　　　　　　　　 \
　dword* stack;　　　　　　　　　 \
　asm volatile("mov %%ebp, %0 \n" : "=m"(stack)); \
　_sys_printf("_sysdumpStack2(%s):%x %x %x\n" 　 \
　　　 , str, *(stack + 0), *(stack + 1) 　 \
　　　 , *(stack + 2));　　　　　　 \
}

#define _sysdumpStack3(str) {　　　　　　 \
　　　　　　　　　　　　　 \
　dword* stack;　　　　　　　　　 \
　asm volatile("mov %%esp, %0 \n" : "=m"(stack)); \
　_sys_printf("_sysdumpStack2(%s):%x %x %x\n" 　 \
　　　 , str, *(stack + 0), *(stack + 1) 　 \
　　　 , *(stack + 2));　　　　　　 \
}

スタック覗き見作戦ということで
やってみました。

timerHandler()の頭で呼んだ場合(それぞれ単独の呼び出し)
_sysdumpStack2(timer):0x002FFF6C 0x00001ED0 0x00000008

_sysdumpStack3(timer):0x00001DAD 0x00001DCA 0x00001DAD


ProcessManger::schdule()
_sysdumpStack2(schedule):0x002FFF58 0x00001DEF 0x000098E0

_sysdumpStack3(schedule):0x000053DF 0x000053FC 0x000053DF

timerHandler()ないでは0x00000008があるので
もしかしたら惜しいかも。

でも今日はよくわからず、力尽きました。
最近ずっと動くものが作れていないので、CVS コミットしてません。
ちょっと不安。

Makeは出来るけど途中で動きが止まってしまうようなやつを
コミットしても良いかと迷うのですがどうなのでしょうか。

ソースチェックアウトしてMakeしたけど
スタックダンプしてとまるぞと、怒られそうで・・・

定常的にチェックして、
ソースからMakeしている人っているのだろうか。。。

C++なんだから、マクロなんか使わないで、インライン関数にしては？>>ﾋｹﾞﾎﾟｿﾀｿ

>>69
そのためのブランチでしょ。
新しい実験を開始するたびにブランチすればいい。

>>71
スタック扱うのに？

>>73
インラインですが何か？

>>74
保証ない

>>75
逆汗してみ

>>76
コンパイルオプションを変えただけで動かなくなるかもしれない方法を薦めないように

>>78
だから逆汗してみっていってるでしょ
インラインアセンブラで書いた部分が最適化の影響を受けるとは初耳

>>78
インライン関数がインライン展開される保証は無いのですが
ＶｉｓｕａｌC++なら__forceinlineなんてものがありますが

>>71
今回みたいにちょこっと実験してみるにはマクロが便利でつ
コンパイルオプションとかコンパイラとか、なるべく関係ないように書くには
アセンブリ言語が一番だけどﾅｰ

で、実際に逆汗してみた香具師いるわけ？
-O付けなければ一切インライン展開されない。
-Oが付いていればレベルに関係なく100%インライン展開される。
よって>>77は正しいが、-Oさえあれば保証はある。

ま、普通のコードでさえ-O3以上だとまれにバグるので、
環境に一切左右されないのは>>80の言うようにオール汗だな。
今のmonaの開発方針とは正反対になるけど。
だから最終的には気持ちの差。

#############　終　了　#############

>>71
スタックを扱うので、ちょっとインライン関数は怖かったです。

>>72
ありがとうございます。
CVSコミットしちゃいました。

関係ありそうな箇所について-Sオプションでアセンブラコードを出してみました。
http://mona.sourceforge.jp/higepon/

timerHandler()
　ProcessManager::schedule()
　　ProcessManager::swtichProcess2()

＜　｀ー´＞y-~~ やっぱりinline展開されてない様子。 >switchProcess2
initProcessでtimerHandlerへの戻り先他を積んでおかないとダメか。

そもそもコンテキストスイッチをesp切り替えでやるのはあまりお勧めできないが・・・。

>>83
CVSでCFLAGSを見る限り、-Oが付いてないですね。
これではインライン展開されないです。

>>82
インライン関数はなるべくヘッダに書いた方が良いですよ。
他のクラスから使うのであれば絶対に。

>>83
超先生さん
>initProcessでtimerHandlerへの戻り先他を積んでおかないとダメか。
なるほど
二つ手があると思っています。
(1)switchProcess2()は、インライン展開されていないので
schedule()からtimerHandler()に戻るために
initProcessでスタックにtimerHandlerへの戻り値を
格納しておく。
そしてtimerHandler()でiret
(2)iret(つまりタスクスイッチ）をswitchProcess2()で行ってしまう。
この場合はinitProcess()で初期化する場合には
timerHandler()への戻り値を格納しておく必要はなく
適当な値を積んで置く。
そしてタスクスイッチの前にスタックの値を
ひとつ捨てる。
（捨てられるのはtiemrHandelerのアドレスか初期化時に設定された適当な値）

うーんどちらがよいのでしょうか。

>そもそもコンテキストスイッチをesp切り替えでやるのはあまりお勧めできないが・・・。

現状は、この方法しかわからないというのが真実です。
ほかに、もっとよい方法があるのでしたら
簡単でよいので教えていただけないでしょうか。

>>84さん
アドバイスありがとうございます。

> CVSでCFLAGSを見る限り、-Oが付いてないですね。
> これではインライン展開されないです。

了解しました。
この辺の-Oオプションに詳しいサイト等ありましたら
教えていただけないでしょうか。
できれば、必ずインライン展開される/されない等
の情報があればありがたいです。

> インライン関数はなるべくヘッダに書いた方が良いですよ。
> 他のクラスから使うのであれば絶対に。

はい一応認識しています。
一応私の方針としてクラスメンバ関数のうち
インライン化するのはprivateなものだけにしようと
思っています。
まあなんとなくですが・・・

>>81
> -Oが付いていればレベルに関係なく100%インライン展開される。

この情報のソースある ?

VC では、forceinline 指定にもかかわらず、インラインにならない時があるんだけど。

>>88
monaのソースを逆汗して確認。

>>89
それってたまたまそうなってたってことじゃないのか ?

もしそうなら、「100%インライン展開される」とか書くなよ。

>>90
とりあえず、確認もせずにえらそうなことを言うのはやめてくれ。
インラインにならない経験があるんだったら、
それと同じケースがmonaの開発に使っている環境で再現することを示せば
背理法で何も議論する必要ないんだから。

>>91
要するに、100% インラインになることは、保証されてないわけね。

議論以前の問題だよ。

と、とにかく、、コンパイルOPTIONによって動くとか
動かないとかいうのはシステム的になんか嫌だな・・・。
OS作る前にもっとコンパイラとかオブジェクトコードの勉強しないと。。。

>>92
何一人で熱くなってんの？
とりあえず、Monaをダウンロードして、コンパイルしないと始まらないよ。
手を動かしましょうよ。そう思って逆汗逆汗って言ったのに。

Inline Limitを超えなければInlineになることは保証されてる。
それくらい自分で見つけると思ったんだけどなあ。

>>94
わかった、わかった。
貴方の環境では、100% インラインになるわけね。

これでいい ?

俺の環境で、100% 保証されない事がわかればどうでもいいです。

>>94
殺伐とした雰囲気には余りしたくないんだが、、、一つだけ言わせてもらう。
>>90 が言うように「たまたま」そうかもってのは考えた方がいいと思う。
注意事項とか、前提条件、仮定とかはなるべく少ない方がいいからな。
そういうのが多いと、人には理解してもらいづらいし、自分で書いたソースだって
一月もたてば結構忘れてしまうから、用心するには越したことがない。

>>95
はい、結構です。で、本題。
興味の方向から考えるに、貴殿は組み込み用のOSを手がけておられるとお見受けしますが、
タスクスイッチはどういう風に実装しておられましたか？

けんか（・Ａ・）ｲｸﾅｲ!

>>96
と言うか、inline にする/しないなんて、コンパイラのバージョンで変わったりしそうでしょ ?
それに依存するのは、あまり良くないと思ってる。

>>97
> 興味の方向から考えるに、貴殿は組み込み用のOSを手がけておられるとお見受けしますが、
> タスクスイッチはどういう風に実装しておられましたか？

普通に TCB (Task Control Block) にレジスタセーブして、SP を再設定するだけ。
当時は、メモリ管理などはなかった。
また使ってた、68020 は、SP がユーザー/システム/割り込みで独立していたから、結構綺麗に書けた。

一人インライン信者がいるだけ

インラインスケート信者？

>>99
失礼しました。やはりそうでしたか。
gccは2.95の頃から-finline-limit-Nで決めていたので、
そんなに不安定なものだという感覚じゃなかったんです。
inline信者というより、gcc信者の厨房ですみません。

貴殿の書き込みを拝見していると、
コンパイラの面で色々と苦労されておられることが伝わってきて、
特にコールとスタックとかCしか使わない人は気にしないようなところに
非常に気を遣っておられたので、ひょっとしたらと思っていました。

喧嘩みたいになって皆様にはご迷惑をお掛けしましたので自分は逝きます。

>>98
すまん。

>>102
> gccは2.95の頃から-finline-limit-Nで決めていたので、
> そんなに不安定なものだという感覚じゃなかったんです。

>>96 も指摘してるし、>>99 にも書いたけど。それをもって 100% なんてあまり書かない方が良いと思うよ。

GCC のマニュアルにも...

Note:
　pseudo instruction represents, in this particular context, an abstract measurement of function's size.
　In no way, it represents a count of assembly instructions and as such its exact meaning might change from one release to an another.

と書かれてるぐらいだから。

> 特にコールとスタックとかCしか使わない人は気にしないようなところに

ちょっと勘違いしてるかと...。
俺は、>>88=>>90=>>92=>>95=>>99 だからスタックどうのこうのは書いてないよ。

ただ、このスレ見てる奴は、スタックがどうのこうのぐらいはだいたいわかってると思う。
(でないと、ちんぷんかんぷんだろうし...。)

えと、一応、CPUメーカに勤めてて、gccにも明るいと自負している自称gccハカセですが、
-O2オプション以上をつけてれば、gccはinline展開を必ず試みます。
が、例外があって、例えば inline 関数を展開した結果、己のinline関数を
呼び出すような場合、無限inline展開に陥るので、その場合、inline属性は
無視されます。これは、C++のinline展開にも言えることで、標準委員会でも
「inline展開は必ずしもinline展開されるとは限らない」と定義されてます。

仕事でだいぶ不規則な生活になって来ました。
早く持ちなおさないと

現状を整理してみようと思います。
(1)現在スタックポインタを切り替えることでTSSを使わないタスクスイッチを試みている
(2)割り込みハンドラではeip,cs,eflags,error(あれば)がスタックに積まれる事は
わかっている
(3)iretでは(2)とは逆にeip,cs,eflagsがpopされて実行元に戻ることがわかっている
(4)上記を踏まえてタスク初期化時にはeip,cs,eflags等をあらかじめ積んであるような
スタックを用意すれば良いという事がわかっている。
(5)(1)〜(4)のようにタスクスイッチすることは可能である。(理論的には）

問題点
・関数のinline展開等により割り込みハンドラによって積まれたはずの
eip,cs,eflagsがみつからない。
・スタックダンプマクロをつくりスッタク内を覗き見るがそれらしきものがない。
・そもそもスタックダンプマクロそのものがスタックを破壊せずに、覗き見できているか
ちょっと不安。
・esp,ebpのつじつまあわせがだんだんとよくわからなくなってきた。
とくに完全には割り込みハンドラまで戻らずiretする場合とか。。。
・スタックマクロもebp,espどちらを基準にすべきか・・・

大混乱中です。

やっちゃった。ｽｯﾀｸｺﾞﾒｿ

bochsdbg.exe等のデバッガ付きのもので追跡してみては？

>>106
新手のタクシーですか

ｽｯﾀｸ（・∀・）ｶｺｲｲ！！

>>105
>・スタックマクロもebp,espどちらを基準にすべきか・・・

push pop しても値変わらんので、
ベースポインタって名前の通り ebp をベースにするのが便利でつ。
インテルアーキテクチャー上だったら普通は enter か push ebp + mov ebp, esp の組で
始まるから、ebp + 2 がコール直後の esp の値になるし。

32bit モードなので ebp + 4 の間違いですた。

>>110
> ベースポインタって名前の通り ebp をベースにするのが便利でつ。

フレームポインタの省略とかやられると辛いので、ここはきちんとアセンブラでスタックの値をとって、表示は C++ とかでやるのが良いと思う。

>>112
う、確かにそうだな。
gcc のinfoページ読んだら、-fomit-frame-pointer か -O2以上をつけると
フレームポインタ省略されてしまうってか言ってあった。フレームポインタ省略を
禁止する方法も無さそうだし。

楽しげだ。でも仕事忙しくて傍観してるしか能がないおれ。

>>114
ここでレスするだけでもちょっとは助けになるんじゃない？
参加の仕方も色々。

>>110,112
ありがとうございます。
やはりespからたどるのがよさそうですね。

必要なeip,cs,eflagsが積まれてから
二つの関数に突入するので、だいぶ深いところ
にいってしまうのが難点ですね。

> ・スタックダンプマクロをつくりスッタク内を覗き見るがそれらしきものがない。
> ・そもそもスタックダンプマクロそのものがスタックを破壊せずに、覗き見できているか
> ちょっと不安。

あたりが、まだ解決していないのが痛いです。

>>107
> bochsdbg.exe等のデバッガ付きのもので追跡してみては？
bochsのドキュメント読んでみます。

>>114
>楽しげだ。でも仕事忙しくて傍観してるしか能がないおれ
最近私もだんだんと仕事が忙しくなってきました。
お互いがんばりましょう。

Bochs&GDBデバッグはもしかしてWindowsでは
できないのかな？
cygwinでMakeすれば出来そうだけどバイナリはないのだろうか・・・

明日ちょっと調べてみます。

>>117
バイナリパッケージ入れたら bochsdbg.exe ってやつが入ってるからそれ使えばいい。

>>118
それを起動させて
cygwin　gdbで
gdb
target remote localhost:1234
とやってみましたが
connection refusedとなりました。

bochsのドキュメントを軽く読んだところ

./configure --enable-debugger --enable-disasm

./configure --enable-gdb-stub

内部デバッガ用、GDB用二つのバイナリがありそうな予感です。

ヌヒ等よ、ＯＳをつくために頑張っているヌヒ等よ。
ところで新しいＯＳができたというﾆｭｰｽはまだ聞かないが、ヌヒ等よ何をしている？
ヌヒ等よ、早くやれ！！

>>119
bochsdbg.exe は ./configure --enable-debugger --enable-disasm の方だと思われ。
これを普通の bochs みたいに起動すると、bios の一番最初の命令で停止した状態で
プロンプトが出るから、ブレークポイント置くとかいろいろ準備した後で c で実行開始する。

>>119
ごたくはいいから早くつくれ！！

↑酷ぇなおい

>>123
何か沢村の名を騙った偽者に見える。

>>124
122はあきらかに偽物だろ。
違うのか？

（＾＾）

こんなのを作ってみました。
ループはあえて使ってません。

#define _sysdumpStack4() \
\
static dword* stack; \
asm volatile("mov %%esp, %0 \n" : "=g"(stack)); \
_sys_printf("%x ", *(stack + 0)); \
_sys_printf("%x ", *(stack + 1)); \
_sys_printf("%x ", *(stack + 2)); \
_sys_printf("%x ", *(stack + 3)); \
_sys_printf("%x ", *(stack + 4)); \
_sys_printf("%x ", *(stack + 5)); \
_sys_printf("%x ", *(stack + 6)); \
_sys_printf("%x ", *(stack + 7)); \
_sys_printf("%x ", *(stack + 8)); \

これをタイマハンドラでこんな風に使ってみます。
void timerHandler() {

    asm volatile("pushl $0x87654321");
    asm volatile("pushl $0x87654321");
    asm volatile("pushl $0x87654321");
    asm volatile("pushl $0x87654321");
    _sysdumpStack4();

    /* EOI is below for IRQ 8-15 */
    outportb(0xA0, 0x20);
    outportb(0x20, 0x20);

    /* determine next process or thread and run it */
    ProcessManager& pm = ProcessManager::instance();
    pm.schedule();

    iret();
    return;
}

その結果
0x00001DBF　0x00001DBF　0x87654321　0x87654321　0x0000000E　0x00000014　0x002FFF
6C　0x00001FAB　0x0000000
と表示されます。
0x87645321が二つ消えてしまいます。
該当部をディスアセンブルしたのは
00000FD0　55　　　　　　　　push ebp
00000FD1　89E5　　　　　　　mov ebp,esp
00000FD3　83EC08　　　　　　sub esp,byte +0x8
00000FD6　6821436587　　　　push dword 0x87654321
00000FDB　6821436587　　　　push dword 0x87654321
00000FE0　6821436587　　　　push dword 0x87654321
00000FE5　6821436587　　　　push dword 0x87654321
00000FEA　892530800000　　　mov [0x8030],esp
00000FF0　A130800000　　　　mov eax,[0x8030]
00000FF5　C70424BF1D0000　　mov dword [esp],0x1dbf
00000FFC　8B00　　　　　　　mov eax,[eax]
00000FFE　89442404　　　　　mov [esp+0x4],eax
00001002　E849F8FFFF　　　　call 0x850
00001007　A130800000　　　　mov eax,[0x8030]
0000100C　C70424BF1D0000　　mov dword [esp],0x1dbf
00001013　8B4004　　　　　　mov eax,[eax+0x4]
00001016　89442404　　　　　mov [esp+0x4],eax
0000101A　E831F8FFFF　　　　call 0x850
0000101F　A130800000　　　　mov eax,[0x8030]
00001024　C70424BF1D0000　　mov dword [esp],0x1dbf
0000102B　8B4008　　　　　　mov eax,[eax+0x8]
0000102E　89442404　　　　　mov [esp+0x4],eax
00001032　E819F8FFFF　　　　call 0x850

表示ロジックでスタックが上書きされたりするのでしょうか。
大混乱です。
観測しようとすると状態が変わるのか
もともと状態がおかしいのか
正常なのか。
・・・・・・・

>>127
ebpを基準にしないとダメポ・・・。

>>131
あ、もしかして他の関数をcallしてしまうとおかしくなるかも。。。
ってことでしょうか。

ということは
その関数に入ってからスタックには積まれた者はebpからするとマイナス
ということですよね。あれちょっと自信ないです。

mov　dword　[esp],0x1dbf
mov　[esp+0x4],eax
でスタックの内容を書き換えているので正常です

>>134
ありがとうございます。
書き換えが起こっているのは、関数callのせいなのでしょうか。

ebp基準にして0x87654321を探ってみたところ
3つしか表示されませんでした。

スタックに全く影響を与えるのは無理なのでしょうか。
いやそんなことはないですよね。

>>130
> 観測しようとすると状態が変わるのか
量子力学の不確定性みたい...

>>132
> あ、もしかして他の関数をcallしてしまうとおかしくなるかも。。。
先日のinline論議真面目に読んでないんだね...

こんな感じか。

asm volatile("mov %%esp, %0 \n" : "=g"(stack)); \
00000FEA　892530800000　　　mov [0x8030],esp
00000FF0　A130800000　　　　mov eax,[0x8030]


00000FF5　C70424BF1D0000　　mov dword [esp],0x1dbf ; 引数 "%x "

00000FFC　8B00　　　　　　　mov eax,[eax] ; 引数 *(stack + 0)
00000FFE　89442404　　　　　mov [esp+0x4],eax

00001002　E849F8FFFF　　　　call 0x850 ; _sys_printf

>>>132
>> あ、もしかして他の関数をcallしてしまうとおかしくなるかも。。。
>先日のinline論議真面目に読んでないんだね...

もちろん読んでいますが理解が遅いのです。申し訳ありません。m(__)m

_sys_printf("%x ", *(stack + 0)); \
_sys_printf("%x ", *(stack + 1)); \
_sys_printf("%x ", *(stack + 2)); \
_sys_printf("%x ", *(stack + 3)); \
_sys_printf("%x ", *(stack + 4)); \
_sys_printf("%x ", *(stack + 5)); \
_sys_printf("%x ", *(stack + 6)); \
_sys_printf("%x ", *(stack + 7)); \
_sys_printf("%x ", *(stack + 8)); \

を、

unsigned int value[9];
value[0] = *(stack + 0);
value[1] = *(stack + 1);
...

printf("%d\n", value[0]);
...

でやったらどうですか？

>>138
いい人 (*^_^*)

>>139
0x87654321  0x87654321  0x87654321  0x87654321  0x34353536  0x00000034  0x000000
と表示されました。
ありがとうございます。

すばらしいのですが
何故解決したかと、なぜ_sys_printfの引数がスタックを上書きしたかが
わかりません・・・

>>135
関数callというか
00000FD3 83EC08 sub esp,byte +0x8
でコンパイラはメモリアクセス用の一時変数を確保しているのですが
その後の
push　dword 0x87654321
でスタックポインタが変更されたのに気付いていないのが原因です

↓泣けてきます。 (TдT)
>>103
> ただ、このスレ見てる奴は、スタックがどうのこうのぐらいはだいたいわかってると思う。

あ、スタック仕様はエクスパンドアップ、それともダウン？どっち？

>>141
とりあえずここは一旦Monaのカーネルから離れて、
簡単な関数を書いてアセンブリ出力と睨めっこすることをお勧めします。

コンパイラまでお作りになってるL様の偉大さを思い知る……か

>>142
なるほど。
ということは、インラインアセンブラなどを使わなければ
一番最初の_sysdumpStack4()は普通にスタック内を表示
できているのでしょうか。

そもそもの動機として
割り込みのハンドラへ行くときにスタックにpushされているはずの
eip,cs,eflagsが見当たらないので

・もともとスタックが壊れている
・表示ロジックがスタックを壊している
・表示ロジックが間違っている。
の切り分けをしたいというのがありました。

なかなか難しいです。
でも勉強になります。

こんな感じ。

[引数格納用] +--|<=Stackframe <- esp
[auto変数郡] +--|　　　　　　 　　<- ebp
[旧ebp]
[eip]
[cs]

>>145
実は最近それはやってみました。
引数がどのように格納されるか戻り値がどこに格納されるか。
AUTO変数の確保のされ方等
基本は学んだつもりなのですが
応用が利きません・・・

146
またあらわれたLﾀﾝ。
キャリアが違うと思うんだけど

>>150
#146は、わてちゃいますよーー

Lﾀﾝが実際に登場した。
ではなくて、またLﾀﾝの話が引き合いに出された。
という意味だと思ふ。

＜後ろ頭＞y-~~~ 参考URL
Linking C++ and Assembly
ttp://www.cs.uakron.edu/~margush/306/LinkingWithCplusplus.html

>>113
-fno-omit-frame-pointerで、出来ない？

>>154
ｶﾞｰﾝ(ﾟдﾟ|||)　知らなかった。 no- つけると逆になるんだ、、、
info 見直したら書いてあるし、、、

>>113
gccでx86なら、-fomit-frame-pointerを明示的につけない限りフレームポインタは省略されません。
-Ox時に省略されるのは、省略してもデバッグ可能なアーキテクチャのみ。

それはともかく、俺なら割り込みハンドラでいきなりCコードに飛ばずに、asm glue codeを一回経由するけど。

>>153
資料提示ありがとうございます。

スタック切り替えによるタスク切り替え、テストに *一応* 成功しました。

関連するコードは
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/monaIhandler.cpp?rev=1.23&content-type=text/vnd.viewcvs-markup
のtimerHandler()
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/ProcessManager.cpp?rev=1.54&content-type=text/vnd.viewcvs-markup
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/include/ProcessManager.h?rev=1.23&content-type=text/vnd.viewcvs-markup
辺りです。

ただ何度もタスクスイッチを切り返すとfault0dが発生します。
これはただいま調査中です。

すごく悩んでいろいろ考えた結果の実装が
なんとなく動いたのはうれしいのですが
漏れがありそうで怖いですね。

ちょっと時間を置いて見直してみます。

リリースのお知らせです。
Mona develop beta 0.02bをリリースしました。

ダウンロードは↓からお願いいたします。
ttp://mona.sourceforge.jp/higepon/image/mona_beta0_02b.lzh

現バージョンの特徴は

・TSSを使わないタイマー割り込みによるタスクスイッチの実現

・STLの導入。std::swapは実際にタスクスイッチで使用しています。

・VirtualPC対応(匿名希望さんに感謝)

・cpuid命令によるベンダーIDの表示

・FAULT時のレジスタ・スタックダンプ

もしよろしかったら
MonaBBS動作報告版に専用スレッドを作成いたしましたので
動作報告をお待ちしています。
ttp://monaos.hp.infoseek.co.jp/cgi-bin/2ch/test/read.cgi/run/1043500934/l50

>割り込みハンドラでいきなりCコードに飛ばずに、asm glue codeを一回経由するけど。
激しく同意。

timerEntry:
pusha
movl %esp, %eax
pushl %eax
call timerHandler
addl $4, %esp
popa
iret

typedef struct {
dword edi;
dword esi;
dword ebp;
dword esp2;
dword ebx;
dword edx;
dword ecx;
dword eax;
dword eip;
dword cs;
dword eflag;
dword esp;
dword ss;
} StackFrame;

void timerHandler(StackFrame *frame)
{
printf("eip %d", frame->eip);
}

こんな感じ。
既存のOSのコードを軽く眺めてみるのも良いと思う。

>>・STLの導入。std::swapは実際にタスクスイッチで使用しています。
をー！
OSカーネルにSTLを採用した例としては、世界初では？

（MSの人に、WinNTカーネルをSTLで記述しなおすみたいな話は
聞きましたが･･･バッファオーバーラン対策だそうで、でも未確定情報なんで）

>>160
>>161
なるほどありがとうございます。
上記のメリットはスタックをきちんと
自分でコントロールできることでしょうか。

>をー！
>OSカーネルにSTLを採用した例としては、世界初では？

もしそうならうれしいですね。
キーボードドライバにstd::queueを使ってみて遊んでいます。

クラスKeyBoardManagerにgetCharacter()メソッドを追加してみました。
while ((ch = km.getCharacter()) == -1);
_sys_printf("%c", ch);

とやることで、入力されたキーを出力できるようになりました。

ソースはこの辺です。
ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/KeyBoardManager.cpp?rev=1.7&content-type=text/vnd.viewcvs-markup

これはシングルタスクではうまくいくのですが
マルチタスクだとwhileループを抜けてしまいます。
つまり何も初期化されていないchを表示してしまう。
なんでだろう。。
調査中です。
でもだいぶ楽しいです。

プログラムの勉強しようと思うんだけど、
何から始めれば良いの？
Visual BasicとかC言語とかあるけど、
最初はどれ？
Visual Basic？

>>165 は誤爆です。すいません。

>165
アセンブラとＣ言語。
アセンブラのみでもいいのだけど、アセンブラだとＪＭＰしまくりで、
スパゲッティに慣れるとよくないから、Ｃのような構造化言語と併用
していくといいよ。

>>167
誤爆にﾏｼﾞﾚｽ．．．

ていうか、アセンブラとＣを併用するようなプログラムは入門には高度すぎだろ。
確かに両方やっておいた方が機械の仕組みがわかっていいのだが、、、

＞キーボードドライバにstd::queueを使ってみて遊んでいます。
キーボードドライバは std::deque のほうが向いてるよ。
historyたぐるときなどは、queueよりも高機能実装できるのだ！

なんて、ツッコミが後から来ても、元の型を queue -> deque へ
変化させるだけで実装できてしまうのがSTLの強み。

Ｌ氏が指摘するように、STLを使うとコードが太る傾向があるが、
これも将来的にコンパイラ技術が上昇すると共に解決される問題なので
あまり危惧することでもないと思われ。

Mona上にSTLportを移植された件、ベースになっているバージョンは
4.5.3という事でよろしいでしょうか。（　´∀｀）ネソノタメ

>>169
>キーボードドライバは std::deque のほうが向いてるよ。
>historyたぐるときなどは、queueよりも高機能実装できるのだ！

なるほど。

>なんて、ツッコミが後から来ても、元の型を queue -> deque へ
>変化させるだけで実装できてしまうのがSTLの強み。

ですねぇ。うれしいです。

>>170
こんばんはhenohenoさん。
>Mona上にSTLportを移植された件、ベースになっているバージョンは
>4.5.3という事でよろしいでしょうか。（　´∀｀）ネソノタメ

はい、あってます。
ところでバージョンが何か問題でしょうか。
気になります。

キーボード入力を二つのタスクを走らせた状態で
片方のタスクで取得する実験をしてみました。

キー入力取得タスクの肝
while (true) {
    while ((ch = km.getCharacter()) == -1) {}
    _sys_printf("%c\n", ch);
}

これを実行するとchが不定の状態で
なぜか_sys_printfのところが実行されることがある。

「実行されることがある」とは
タスク実行中キー入力がない場合whileの条件は
ほとんどtrueになるが50回に1回くらいnot trueになる

getCharagter()の実装はまじめにキーを返すバージョンや
return -1;
オンリーだけでも上記の現象がおきる。

(1)
while ((ch = km.getCharacter()) == -1)
⇒
while ((ch = km.getCharacter()) == 120)
とやっても
この現象は起きます。

(2)
while ((ch = km.getCharacter()) == -1)
⇒
ch = -1;
while (ch == -1)
ではこの現象は起きません。

(3)
while ((ch = km.getCharacter()) == -1)
⇒
while ((ch = testkey()) == 120)
クラスメンバではなくて普通の関数でも
この現象は起きます。

またシングルタスクモードではこの現象は起きません。
なんでだろうなあ。

>>172-173
MutexやWaitForSingleObjectみたいなの実装しないと
その手のことは安定して使えないと思われ

↑すまん、MONAのカーネルの仕組み良く知らんのだけど、
キーボード系などの資源は、タスク側に解放するのではなく、完全に隠蔽した
ほうがいいかと。キーボードの入力状況は、カーネル内の一箇所のみに蓄える。

std::deque< char > core_keybd_history;
と定義し、唯一のカーネルプロセスで
if( any_keybd_input == true )
{
core_keybd_history.push_front( km.getCharacter() )
}
という感じで蓄える。
で、km.getCharacter() とやらは、アプリ側には非公開。

で適切なタイミングで、カーネルが保持しているプロセス・デスクリプタに
historyを適切に集配する。
この適切なタイミングとは、そのプロセスに処理権利が移る瞬間かと。（本当にすまん、MONAについて何も知らないので他にもっと適切なタイミングがあるかも）
各プロセス・デスクリプタに以下のようなヒストリーバッファを用意。
std::deque< char > process_keybd_history;

アプリ側は盲目的に
process_keybd_history.end()で取り出し、不要になったら
process_keybd_history.pop_back()で実現かと。

物理的なキーボード状態が格納されてる唯一のバッファをcore_keybd_historyに絞り
あとは配布次第ってことで。

process_keybd_historyは
カーネルからはpush_front()で書き込まれ
アプリ側からはend() -> pop_back() 読み出されると。

>>172
キューに何も入ってないタイミングで、取り出そうとしたら駄目だろうね。
最初はスピンロックからでもやると良いかと。

私もOS書いてみたいのう…でも時間がない…
上の割り込みハンドラのコードの
00000FF0　A130800000　　　　mov eax,[0x8030]
でeaxを壊してるみたいだけど、これだと割り込みから帰ったときに動かないよ
全体を読んでないからわかんないけど

>>174
>MutexやWaitForSingleObjectみたいなの実装しないと
>その手のことは安定して使えないと思われ

アドバイスありがとうございます。
Mutex調べました。
http://yougo.ascii24.com/gh/13/001328.html
なるほど、この辺の機構はタネンバウム本に
書いてあった気がします。

ただし今回のケースは
タスクは2つありますが、キーボード情報を取得するのは片方の
タスクのみなので原因がつかみきれません。

>>175
>>176

> historyを適切に集配する。
> この適切なタイミングとは、そのプロセスに処理権利が移る瞬間かと。（本当にすまん、MONAについて何も知らないので他にもっと適切なタイミングがあるかも）
> 各プロセス・デスクリプタに以下のようなヒストリーバッファを用意。
> std::deque< char > process_keybd_history;

なるほど勉強になります。

適切なタイミングでpushと。
std::deque< char > core_keybd_history;
↓
std::deque< char > process_keybd_history;

あとは各プロセスにキーボードバッファを持たせればよいのかな。

>>178
すいません、現段階でどの部分に当たることなのか
分かりませんが、_switchProcess()マクロに
eaxを壊すところがあったので直しました。

>>177
> キューに何も入ってないタイミングで、取り出そうとしたら駄目だろうね。
> 最初はスピンロックからでもやると良いかと。

一応keyQueue_.empty()チェックを入れてるので
取り出しはしないはずです。

char KeyBoardManager::getCharacter() {

    if (keyQueue_.empty()) return -1;

    KeyInfo info = keyQueue_.back();
    keyQueue_.pop();

    if (info.modifiers & KEY_MODIFIER_UP) return -1;
    if (info.keycode < 'a' && info.keycode > 'z') return -1;

    return (char)(info.keycode);
}

>>182
if (keyQueue_.empty()) return -1;

で、-1 返してるじゃん。
とりあえず、そこで、スピンロック。

>>159
そういうちょっとしたバイナリでも
リリースとして↓に置いておいた方が良いと思うよ。
https://sourceforge.jp/projects/mona/files/

ダウンロード数も分かるし。

詳しく呼んで見たけど
void timerHandler()
がいろんなレジスタ壊してるように見える…
(ほかの人もいってると思うけど、割り込みハンドラの入り口ぐらいは
アセンブリで書いたほうがいいのではないかなあ)

>>171
> ところでバージョンが何か問題でしょうか。
> 気になります。

いずれ実装する方や将来のバージョンに合わせる方や
検証する方が来歴を知りたくなるのではないかと思い
ましたので、さわりだけ聞いてみました（　´∀｀）

＜後ろ頭＞y-~~~
timerHandlerだけpusha/popaで括ってないのは何故・・・？

>>184
ご指摘ありがとうございます。
https://sourceforge.jp/projects/mona/files/
にリリースいたしました。

>>185
>詳しく呼んで見たけど
>void timerHandler()
>がいろんなレジスタ壊してるように見える…

すいません。
どの辺がレジスタを壊しているのでしょうか。
ご指摘いただければ幸いです。m(__)m

>>186
henohenoさん
>さわりだけ聞いてみました（　´∀｀）
了解です。

>>187
>＜後ろ頭＞y-~~~
>timerHandlerだけpusha/popaで括ってないのは何故・・・？

すいません単純に_switchProcess()の最後でiretしているからです。
やはりまずいでしょうか。

>>188
その時点のソースが見れたら便利なので、
（CVSで合わせて取って来させるのは敷居高すぎ）
一緒に置いておくとよいと思います。

ほとんど利用されないと思うのですが、
GPLという建前もありますし、
ソースのサイズでコード量の増減が一目で分かりますし。

>>190
>その時点のソースが見れたら便利なので、
>（CVSで合わせて取って来させるのは敷居高すぎ）
>一緒に置いておくとよいと思います。

ご指摘ありがとうございます。
ソースつきのファイルもリリースしておきました。
次回からはソースつきのみのリリースとなるかと思います。

みなさんいっぱいダウンロードしてください（笑）

お前ら動作報告しる

失礼しました。私は58氏とは関係ない人物です。
別のスレに書いたCookieに引きずられていました。

>>191
ソースとバイナリを分けて提供するのが普通ですが、
なぜ「ソース込みのバイナリ」なのでしょうか？
私が誤解を招くような書き方をしたのが原因かもしれませんが。

あともう一点、ビルドにLinuxやCygwinが必要なのに、
ソースをLZHで提供する意味がよく分かりません。
Mozillaのソース配布物を見ていただくと一目瞭然ですが、
ソースが巨大になってくるとtar.bz2が群を抜いて圧縮率が高くなるので、
UNIX(的)システムを前提にするならtar.bz2をお勧めします。

バイナリなら別にLZHでも構わないとは思いますが、
MeやXPではデフォルトでZIPが扱えることも考慮されると良いかと。

>>192
Pentium100MHz + ASUS P/I-55TP4 + その他 の自作ＰＣで動きますた。
って動作報告はどこにするのが正しいでつか？

ぬるぽの実装はどうなっていますか？

　　 （　・∀・）　　　|　|　ｶﾞｯ
　　と　　　　）　 　 |　|
　　　 Ｙ　/ノ　　　 人
　　　　 /　）　 　 < 　>__Λ∩
　　 ＿/し'　／／. Ｖ｀Д´）/ ←>>196
　　（＿フ彡　　　　　 　　/

>>196
単純に落ちます。
カーネル内例外で落ちないOSないっしょ。

……ってネタにマジレスしてみた。

>あともう一点、ビルドにLinuxやCygwinが必要なのに、
>ソースをLZHで提供する意味がよく分かりません。
LZHではいけない理由もわかりません。

>Mozillaのソース配布物を見ていただくと一目瞭然ですが、
>ソースが巨大になってくるとtar.bz2が群を抜いて圧縮率が高くなるので、
これは同意。

>UNIX(的)システムを前提にするならtar.bz2をお勧めします。
UNIX(的)システムを前提にしているのですか？
UNIX(的)システムを前提にするならtar.bz2でないといけないのですか？

>バイナリなら別にLZHでも構わないとは思いますが、
>MeやXPではデフォルトでZIPが扱えることも考慮されると良いかと。
LhasaもDLできない人がMonaをDLするとは思えませんが。

動作報告を掲示板でやると、
書く側にとってはコピペとか面倒くさいですし、
受け側にとっても集計能率が悪いです。
Webフォームみたいな形にできないですかね？
もちろん集計はリアルタイムにCGIで行われて皆で見れるような。

CGIなんか作ってる暇ない？（ｗ
メンバ公募なんだからさ。

国産ってだけで有難がるとことかLHa厨ってRuby厨に似てるな
OSASK厨もよく似てるけど、不思議とNWSOS厨っていないな
Mona厨が発生しないことを祈る

>>199
UNIX風なシステムだったら殆ど必ず標準インストールされている .tgz が一番便利だとおもわれ。
「ｘｘｘじゃないといけない」じゃなくて、「ｘｘｘだと便利」って発想のがいいんでは？

Linuxカーネルの解説だけどかなり勉強になるサイトだと思うので、どうぞ
http://lkh.linux.or.jp/kernel.html
いろいろな日本語資料がどっさりです！
JavaとC#しか扱えないくせに、OSを作ろうと勉強中に見つけました。

>>201
信者がいるようなソフトを作れるプログラマーに私はなりたいのですが．．．

>>201さん
いまは人数が少ないからいいけど、じきに出てくるって。
虫がいないソフトには夢がないでしょ。

>>203さん
> JavaとC#しか扱えない
それもそれで(ﾟдﾟ)ｳﾗﾔﾏｽｨ...

>>193,194
いろいろアドバイスありがとうございます。
image,source共に　.tgz , .zipで提供できるよう
リリースを更新しました。
関係者にご迷惑をおかけしましたことをお詫びします。m(__)m

>>195
動作テストありがとうございます。
専用掲示板を用意しましたので
こちらから動作報告していただけると助かります。
ttp://monaos.hp.infoseek.co.jp/cgi-bin/2ch/test/read.cgi/run/1043500934/l50

>>200
ご提案ありがとうございます。
各バージョンごとに動作検証項目が違うと思うので
それを管理するのは大変かもしれませんね。

現在プロジェクトページを管理してくれているyossyさんも
お忙しいので実現は難しいかもしれません。

もちろん作ってくださる方がいらっしゃるなら
大歓迎です（笑）

Wikiみたいなのもありだと思っていますが。。。

>>203
資料ご提示ありがとうございます。
この資料は知っていたのですが、久々に読み返すと
以前とは違う意味で、勉強になりました。

>>JavaとC#しか扱えないくせに、OSを作ろうと勉強中に見つけました

あーそろそろ。C#本格的に勉強しなければ。。。
マイクロソフトの虫遊び依頼さわってないっすC#

>>206　以来でした。

今ふと思いついたのですが
timerHandler()に入った瞬間にスタックからcs,eip,eflagsを取り出しておいて
タスク構造体に入れておいて

あとからゆっくりと任意の場所でスタックに戻してあげてiretすれば
便利かなあと思ったんですが、何か落とし穴があるのでしょうか。

　　　　　＿,.'⌒)
　　　, ´f二ｺヽ
　 　 ! l !ﾉ ﾘ i l　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　ノiﾊl.ﾟ ｰﾟﾉﾘ　　＜.　>>207 それが一般的な実装です。
　　　 ⊂)允つ　　 　 ＼　同時に汎用レジスタもTCBへ保存するべきですね。
　 　 　 く/_|〉　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　 　 し'ﾉ

>>208
んで、新しくタスクを作るときはスタックに積んどいて iret でスタートさせると。

>>208 209
アドバイスありがとうございます。

やっと一般的な実装にたどり着いたということですか。
喜んでいいのかな・・・おそいけど。

>>200, >>205

PukiWikiのBugTrackプラグインをご紹介。
ttp://pukiwiki.sourceforge.jp/dev/index.php?BugTrack

ただし、これはこれで(PukiWikiの)メンテナが要ります。
PHPが直せないならお勧めできない。

>>210
ついでに、スレッドの開始アドレスを関数の先頭にしておいて、iretの戻りアドレスとして積んだその関数アドレスの
下にスレッド終了関数のアドレスと、終了関数への引数を積んでおくと、スレッドの関数からリターンしたときに
スレッドが終了するように出来る。

>>henohenoさん
おー。イメージ的にはそんなかんじですね。
ただPHPを勉強する暇はないので厳しいかもです。

>>212さん
なるほど。
話が変わりますが
eipは直接自分でとることは出来ないんですよね。
割り込みとかがトリガでないと取れないのでしょうか。

>>205
.tgzはちょっと……（ファイル形式じゃなくて拡張子）
何で.tar.gzって冗長なことになっているのかご存知？

>>213

GetEIP:
　　　　mov　　dword [esp], eax
　　　　ret

よく考えたら eip 取りたいポイントにラベル置いとけばいいだけだったｳﾄｩ

必死で対処しておられるのは伝わっては来ますが、
今のファイル名の付け方は独自過ぎます。
多分DOS経験が長くてUNIX文化をあまりご存知ないのかと。

うるさいやつと思われるかもしれませんが、
ちょっと知ってる人が見たらすぐ分かるという意味で、
標準的な名前の付け方に従った方が良いです。

まずtgzとzipと両方で4つは冗長すぎます。
いちいちこんなことしていたら収拾付かなくなります。

mona_beta0_02b_img.tgzというファイル名も悪いですが厨房くさいです。
ピリオドを1個にして拡張子tgzにするというのは
DOSの慣習に従ったと思われますが、
そもそも8.3形式じゃないので意味ないです。
区切りもピリオドもアンダーバーになっているので見難いです。
imgとかsrcとかの略語は8.3形式制限の産物なので無意味です。
区切りはハイフン、ピリオドは臆せず何個も付けた方が良いです。

あとβというのはリリース（完成）直前のものを指すのであって、
今の段階ではαでさえないので変です。
普通、αとかβとかは1.00αとか完成が視野に入ってから付けます。
それ以前に0.02というナンバリングが初期段階を表しているので
αとかβとか謙遜する必要もないです。
あと最近はバージョンニングは3つに区切るのが主流です。

UNIX系ではソース提供が普通なので、
ソースにはいちいちsrcなどと付けず、バイナリを補足します。
ですから次のような2つのファイルを提供することをお勧めします。

mona-0.0.2-image.zip
mona-0.0.2.tar.gz

>>214
>何で.tar.gzって冗長なことになっているのかご存知？

私も、最近までUNIXのことをほとんど何も知らなかったので、
「誰がこんな意味不明の"拡張子"の付け方を広めたんだろう。全く、、、。」

と思っていたのですが、今ではなんと賢い付け方を考えたのだろう、という
風に考え方が変わりました。(^_^;)

ようするに、aaaa と言うファイルを bbbb という形式に変換した時、に、
aaaa.bbbb
というファイルができるという規則を何度も連続して適用しているんですね。

これを繰り返して、aaaa.bbbb というファイルを、さらに cccc という形式
に変換すると、
aaaa.bbbb.cccc
に変わると。

だから、aaaa というファイルを、tar でまとめた後、gz 形式に変換すると、
aaaa.tar.gz
に変わる。

逆変換（展開など）をすると、後ろの方から拡張子が消えていくと。


だから、tgz という拡張子にするより、実はtar.gzの方が凄く合理的だと
いう、、、。

>>214
どのような意味でしょうか？

>>205
gzipの圧縮オプションは最大にして下さい。

以下は以前書いたもの。
-----------------------------
$ cat targz.sh
#!/bin/sh
#

echo "tar cf - \"$1\" | gzip -9 > \"$1.tar.gz\""
tar cf - "$1" | gzip -9 > "$1.tar.gz"

-----------------------------
$ cat release.sh
#!/bin/sh
# Release

if [ -z "$1" ]
then rel=0_9_4
else rel="$1"
fi

mod=cvsknit
CVSROOT=':pserver:[email protected]:/cvsroot/cvsknit'

cvs -z3 -d "$CVSROOT" export -r "CK_REL_${rel}" "$mod"
tar cf - "$mod" | gzip -9 > "${mod}_${rel}.tar.gz"

>>219
これMakefileで何とかなりませんかね。distターゲットとか作って
make distとかでできると楽だと思うのですが、、、
# 俺には期待しないでね &heart;

>>219
> どのような意味でしょうか？
218でLightCone氏が詳しく説明しておられます。

＜後ろ頭＞y-~~　ピリオドはファイル名の単なる区切り。
そもそもfile system上の"拡張子"という概念はFAT固有のものだしね。

ま、解凍してでてきた物がすばらしけりゃ
どーでもいいんだけどね。

>>220
autotoolなら自動でルール作ってくれるけど

×ルール
○ターゲット

最近のディストロならunzipくらい標準ではいってるだろうから
tar+gzipじゃなくてzip一本でいいと思われ

>>224
ひげぽんがcygwin使っているので、configureは時間がかかる気がする。
メリットもあまり無いと思うし、、、
# 楽なんだけどね (^^;

>>226
圧縮率が全然違う

配布厨、圧縮厨uzeeeeeeeeeeeeeeeeeeeeeeeeeeep

>>217 219
アドバイスありがとうございます。

MakeFiel

dist :
cd ../bin; zip -9 ../../mona-$(VERSION)-image.zip mona.img
cd ../../; tar cf - mona_v1.0 | gzip -9 > "mona-$(VERSION).tar.gz"

こんな感じでよいでしょうか。

Fiel⇒File

皆様いろいろアドバイスありがとうございます。m(__)m
こういうご指摘は大変ありがたいです。

配布形式等で違和感・不親切感が感じられるのは
マイナスなので改善していきます。

tarの前にmake cleanしたほうがよさそうですね。

今週末は
>207
あたりの実装をしようかと思っています。

>>230
MakeFileではなくてMakefileが普通（大文字・小文字の使い方のこと）

ひげぽんは、本当にいいやつだ。
俺ならもうキレてるｗ

キレそうになりましたら、近所の人を数発殴ってから作業を再開していますので、
問題ないです。はい。

>>ひげぽんさん
お疲れ様でした。
さっそくダウンロードさせていただきました。
今後とも応援していますので頑張ってください。

>>235
こういう時のためのトリップですね。

度々要望ですみませんが……

トップページに
> Monaダウンロード : Mona Develop Beta 0.02b　がダウンロードできるようになりました。
とアナウンスがありますが、
そこからダウンロードページへリンクした方が親切だと思います。

>>237
MonaBBSに書こうゼ

御意

ハンドラ内でのレジスタセーブマクロを作りました。
#define _saveRegisters(process) {　　　 \
　　　　　　　　　　　 \
　asm volatile("movl %%ebx, %0 \n" \
　　　　 "movl 4(%%ebp) , %%ebx \n" \
　　　　 "movl %%ebx , %1 \n" \
　　　　 "movl 8(%%ebp) , %%ebx \n" \
　　　　 "movl %%ebx , %2 \n" \
　　　　 "movl 12(%%ebp), %%ebx \n" \
　　　　 "movl %%ebx , %3 \n" \
　　　　 "movl %%eax , %4 \n" \
　　　　 "movl %%ecx , %5 \n" \
　　　　 "movl %%edx , %6 \n" \
　　　　 "movl %%esi , %7 \n" \
　　　　 "movl %%edi , %8 \n" \
　　　　 : "=m"(process->ebx)　　 \
　　　　 , "=m"(process->eip)　　 \
　　　　 , "=m"(process->cs)　　 \
　　　　 , "=m"(process->eflags)　 \
　　　　 , "=m"(process->eax)　　 \
　　　　 , "=m"(process->ecx)　　 \
　　　　 , "=m"(process->edx)　　 \
　　　　 , "=m"(process->esi)　　 \
　　　　 , "=m"(process->edi)　　 \
　　　　 ); 　　　　　　 \
}　　　　　　　　　　　 \

>>236
>お疲れ様でした。
>さっそくダウンロードさせていただきました。
>今後とも応援していますので頑張ってください。

ありがとうございます。

>>237
>そこからダウンロードページへリンクした方が親切だと思います。

近いうちに改善できるよう要望を出しておきます。
ご指摘ありがとうございます。

>>240

process がグローバル変数かスタティック変数へのポインタでなければ、
gcc が process の値を計算するときにレジスタを使って内容を壊してしまわないか心配。
というか、多分使う。

>>242さん

気づきませんでした。ありがとうございます。
ProcessManagerクラスのpublic static変数としました。

>>243
一応 gcc -S でアセンブラソース吐き出させて、レジスタ壊してないか確認した方が吉

　　　　　＿,.'⌒)
　　　, ´f二ｺヽ
　 　 ! l !ﾉ ﾘ i l　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　ノiﾊl.ﾟ ｰﾟﾉﾘ　　＜.　>>243 pushaでスタックへ吐き出してから
　　　 ⊂)允つ　　 　 ＼　*(ebp+n)で取得するのが安全・確実です。
　 　 　 く/_|〉　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　 　 し'ﾉ

#define _switchProcess(currentProcess, nextProcess)

  /* no switch */
  if (currentProcess == nextProcess) iret();

  /* switch to next */
  asm volatile(
      "movl %2, %%ebx  \n"
      "movl %3, %%ecx  \n"
      "movl %4, %%edx  \n"
      "movl %5, %%edi  \n"
      "movl %6, %%esi  \n"
      "movl %7, %%esp  \n"
      "movl %8, %%ebp  \n"
      "pushl %9    \n"
      "pushl %10    \n"
      "pushl %11    \n"
      "movl %1, %%eax  \n"
      "iretl     \n"
      : "=m"(currentProcess->esp)
      : "m"(nextProcess->eax)
      , "m"(nextProcess->ebx)
      , "m"(nextProcess->ecx)
      , "m"(nextProcess->edx)
      , "m"(nextProcess->edi)
      , "m"(nextProcess->esi)
      , "m"(nextProcess->esp)
      , "m"(nextProcess->ebp)
      , "m"(nextProcess->eflags)
      , "m"(nextProcess->cs)
      , "m"(nextProcess->eip)
      );

プロセススイッチの際に
プロセス構造体にレジスタをセーブするように変更しました。

何とか動いております。
ふぅっと。ひといき。

　ソースを公開する際は、"cvs co" のかわりに "cvs export" コマンドで
ソースを取り出したものをお使い下さい。(具体例は >>219)
　exportコマンドを使えば 'CVS' というスペシャルディレクトリとファイルを
含まない、ほぼ純粋なソースを取り出す事ができます。

　下手に "cvs co" を使うとそのユーザーの作業環境が漏れたり、
CVSサーバーの所在が漏れたり、そのソースに他の人が作業した
際に扱い辛くなったり、そのソースを別のリポジトリに追加しようと
した人が泣く事に繋がります。

　なお、最新のファイルをexportする時は "cvs export -D tomorrow "
でどうぞ。

>>248
henohenoさん
おさらいありがとうございます。
cvs export次回から使わせていただきます。m(__)m

３つのタスクを実行してみました。
ttp://mona.sourceforge.jp/higepon/multi.PNG

アドバイスを下さった方ありがとうございます。m(__)m

コンテキストの操作にはインラインアセンブラを使わない方が賢明だと思われ。

>>250
>コンテキストの操作にはインラインアセンブラを使わない方が賢明だと思われ。

おっしゃることは良く分かります。
インラインにするといろいろ考慮しなければいけないことが
多いです・・・

yossyさんの努力でMonaBBSの統合が行われました。
ttp://monaos.hp.infoseek.co.jp/bbs.html

更に書き込みやすくなりましたので皆さん
どうぞ奮って書き込みください（笑）

あとこちらもよろしくお願いいたします。m(__)m
ttps://sourceforge.jp/projects/mona/files/

http://mona.sourceforge.jp/ に、
http://sourceforge.jp/projects/mona
へ移動するためのテキストリンクを所望します。（もし無ければ・・・）

＃MonaBBSに書いたら混んでいると言われたのでこちらで（ ;´∀｀）

あら、しまったのでトリップ変えなきゃ・・・
http://minix-up.sourceforge.jp/ の末尾に書くことにします（ ;´∀｀）

こちらで。

>>253 henohenoさん
http://mona.sourceforge.jp/
の下のほうにMonaPJというラベルでリンクがあります。

もっと便利な場所がいいですかねぇ。

>>256
そんなの普通見つけられないと思いますが……
エロサイトの入り口並み（ｗ

>>257
>そんなの普通見つけられないと思いますが……
>エロサイトの入り口並み（ｗ

そうですよねｗ
実はあそこのリンクは結構使ってます。
mona.sourceforge.jpのほうが覚えやすいので・・・

printf(const char *str, ...) {

_sys_printf(str, ...)
}

というようなことをやりたい場合(実際にやるのは違うことですが)
printfが受け取った、引数はどうやって_sys_printf()に渡せばいいんだろう。

C言語入門からやり直そうかな・・・

スタック走査すればいいんじゃ。。

そういう意味ではないと思うけど

>>259
標準ライブラリが使える場合は va_start, va_arg, va_end 等を使うけど、
mona では使わないので、結局 >>260 が言うようにスタックを操作するマクロを自分で書くしかないでつね。
というか、それ _sys_printf() でやってるじゃん。

変換仕様も作らないといけないのか。
始めは%s, %dくらいかな。ひげぽんがんばれ。

Windows NT互換を目指すReactOS 0.1.0リリース
http://slashdot.jp/developers/03/02/03/221257.shtml?topic=1
オープンソースでWindows NT 互換OSを作るReactOSプロジェクトが、
ReactOS 0.1.0をリリースした。
アプリケーションおよびドライバーにむけてNTバイナリ互換性 を確保しようというもの。
現在、CD-ROMブートが可能で、GUIア プリケーションも初歩的ながら動いている。
GUI周りはWINEの助けを借りているそう なので、案外早くに大化けするかもしれない。"
ダウンロードのページからは実験用にBochs 2.0で起動できるイメージとBochsが
セットになったパッケージをゲットできる。


ひげぽんもｶﾞﾝﾊﾞﾚ！

gcc,g++なら<stdarg.h>はマクロとビルトイン関数だけだから、
インクルードするだけで、ランタイムライブラリ無しでも使えた
と思うよ。

sprintfに対するvsprintfのようなものを用意して、
前者は後者を呼び出すだけにして、
実装は後者で行うようにすると簡単。

>>264
いわゆるLindowsみたいな感じ？

成果をマージしてるってだけだろ、
LindowsはOSとしてはDebianベースのLinuxで、WINEが動いてるだけ。

新しいＯＳを作ろうとすると、
やっぱり、ＰＣ−ＵＮＩＸ系のＯＳがベースになりますねぇ？

>>269
そうとは限んないですね。
PC-UNIXの空気が合わなくてOSを作る人も
当然いるはずですから。

むしろ、新規にOSをつくる理由はだいたい、
既存のOSにない機能性を求めるところからきてるのでは？

Windowsの成り立ち
CP/M-86
↓パクリ
86DOS
↓開発元シアトルコンピュータを買収して、MSが発売
MS-DOS
↓Macに対抗し、GUIベースAPIを追加
Windows

実行時のどのタイミングでもハードウェアのつけ外しができるようなOSｷﾎﾞﾝ。
まぁ、最低一つのマザーボード、一つのCPU、一つのメモリは必要だろうけど。

>>272
そんな貴方は、ギガバイト製のマザーで自作しましょう！
USB接続のFDD,HDD,CD-ROMからＯＳを起動できます。
PCI接続でない限り、ホットプラグが有効です。

>>262
>>263
ありがとうございます。
実は
(1)VirtualConsole* console = new SystemConsole();
(2)VirtualCosole* console = new LogConsole();

console->printf("hoge");

出力先はconsoleの中身次第みたいな作戦を目論んでいました。
SystemConsole#printfの中身は_sys_printfに任せようと思ったので
例の質問をした次第です。

>>264
ご紹介ありがとうございます。
ReacOS試してみました。すごいですねぇ。
ソースを見てみたら、結構綺麗でした。
日付を見ると98年とかあるのでリリースまでに結構かかってるのですね。
Monaはあそこまで動くまでどれくらいかかるんだろう・・・

>>266
>sprintfに対するvsprintfのようなものを用意して、
>前者は後者を呼び出すだけにして、
>実装は後者で行うようにすると簡単

なるほど。ありがとうございます。

>>270
>むしろ、新規にOSをつくる理由はだいたい、
>既存のOSにない機能性を求めるところからきてるのでは？

ですね。

また勉強中ためしばらく
ソースの更新はないかもしれません。

やっぱり継承は微妙に使えないかも。⇒今の環境では。

EOTAはGCCの動作ができたようです。

http://home.interlink.or.jp/~s-nakani/doc/application.html#gcc
http://s-nakani.hp.infoseek.co.jp/eota/gcc-eota.html

OSASKもGCC 3.2からcc1やcpp0を切り出して移植できたらしい。
ttp://www.imasy.org/~kawai/osask/index.html

>>276
>やっぱり継承は微妙に使えないかも。⇒今の環境では

SystemConsole
ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/inclue/SystemConsole.h?rev=1.2&content-type=text/vnd.viewcvs-markup
ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/SystemConsole.cpp?rev=1.2&content-type=text/vnd.viewcvs-markup

VirtualConsole
ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/include/VirtualConsole.h?rev=1.1&content-type=text/vnd.viewcvs-markup

呼び出し
monaKernel.cpp
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/monaKernel.cpp?rev=1.42&content-type=text/vnd.viewcvs-markup

bochsででるエラー
00000648489i[CPU ] write_virtual_checks(): no write access to seg
00000648489p[CPU ] >>PANIC<< exception(): 3rd (13) exception with no resolution

継承をはずすとこのエラーはでません。
仮想関数テーブル？

>>279
>00000648489i[CPU ] write_virtual_checks(): no write access to seg
>00000648489p[CPU ] >>PANIC<< exception(): 3rd (13) exception with no resolution

このエラーですがカーネルサイズによるものっぽい。
うーんどこかでメモリをこわしてるっぽい。

デバッグか(涙）

  switch ( seg->cache.type ) {
   case 0: case 1:  // read only
   case 4: case 5:  // read only, expand down
   case 8: case 9:  // execute only
   case 10: case 11: // execute/read
   case 12: case 13: // execute only, conforming
   case 14: case 15: // execute/read-only, conforming
    BX_INFO(("write_virtual_checks(): no write access to seg"));
    exception(int_number(seg), 0, 0);
    return;

このへんかな。

継承するときに自己書き換えしてるんじゃない？

>>282
それも疑ったので、SystemConsoleを使う部分を
コメントアウトして、リンクすらやめてみました。
するとエラーは起きませんでした。

ただ、適当な_sys_printfのコードを大量に埋め込んでカーネルのサイズを
大きくすると同じエラーが出るのでメモリを壊してる予感大です。

参考Monaメモリマッピング(うそが含まれるかも)
ttp://mona.sourceforge.jp/higepon/mona_mmap.png

203です。
FreeDOS教徒、ひげぽんさん
趣味でやってるだけだから、JavaもC#もレベルはへたれですよｗ

本題ですが、私も勉強中なので間違ってる可能性大ですが．．．
ひげぽんさんも、仮想関数テーブルが怪しいと思われてるみたいなのですが、
私も、Monaのデータセグメント領域外に、仮想関数テーブルがあるのではないかと思います。
gccがどこに仮想関数テーブルを作るかがわかればはっきりするのですけどね．．．
また知っておられたら恐縮ですが．．．
http://www.microsoft.com/japan/msdn/vs_previous/visualc/techmat/feature/jangrayhood/

>> 284
おそらく仮想関数テーブルが原因ではないと書いてあるよ。

>>285さん
281の内容は、エラーで発生した例外割り込みを処理してる部分じゃなくて、
この部分そのものがエラーの原因？

いいかげんなこと言ってしまいすみません。
もう少し勉強して物言います(泣

>>284
こんばんは。アドバイスありがとうございます。
ご紹介いただいたURLは、以前一度だけ見たことがありましたが
もう一度みなおしてみます。

上のほうに書いたbochsエラーの原因が半分分かりました。

テスト用プロセス3のスタックが原因でした。
今は適当に何も考えずespを設定しているのですが
これがまずかったようです。(当たり前か)

VirtualConsole問題は相変わらず解決していません。

難しすぎて面白いネタの部分が分からないよﾏﾏﾝ

VirtualConsole問題は解決しました。

プライベートでないstaticオブジェクトの初期化が問題でした。

解決の糸口を下さったniqkさん、超先生、Yas2さんありがとうございました。
m(__)m

Monaでは仮想関数も使えることが分かりました。
これからはガシガシ使います。

age

最終的にはどうしたいの？そこまでいきたいの？

bochs,Virtual PC,実機でフロッピィドライバの実験をしているのですが

bochsのFDCにcalibrateコマンドを送っても処理後にinterruptが発生しない。
bochsのFDCにmotorリセットコマンド送っても処理後にinterruptが発生しない。

という現象が見られます。
ただし目的のコマンドに合った動作は得られている。

これは、
「FDCによっては処理後にinterruptを発生させないものもある。」
「bochsは、FDC部のエミュレーションに未実装部分がある」
どちらなんだろう。となやんでいます。

>>292
実FDCもチップ毎に挙動が異なるらしい
intelのチップセットでも妙な物もある
仕様通りに動くとは期待しないほうがよさそう

>>293

処理終了のにinterruptが来てなくても
MSRの状態を見て処理終了を判断、という仕様でいいのかなあ。
bochsで動かないのはまずいなあ。

>>293

すいません293へのコメントが抜けてました。
もしよろしければ作成の体験談・妥協点を教えていただけたら幸いです。

>>295
メモリ上に読み込む事のみが目的でしたから、
割り込みはマスクしてFDCのポーリングで逃げました。
並列動作などを考えると大変でしょうね。

はじめてこのスレ読ましてもらいました。
とっても敷居の高いスレでしたが自分も作ってみたいなぁと思いました。
アセンブラの勉強から早速やってみたいと思います。
、、、、到底追いつけるとは思えないですが、、、

>>296
ありがとうございます。
なるほどやはりポーリングしてだめならタイムアウトですかね。

>>297
こんばんは。
>アセンブラの勉強から早速やってみたいと思います。
>、、、、到底追いつけるとは思えないですが、、、

いえ全然すぐに追いつけると思います。
是非がんばってください。

このスレに触発されてマシン語の勉強を始めてしまいましたｗ
ひげぽんさんOS制作がんばってください

このレス、いつも拝見させてもらってます。
わたしも勉強中・・・・・。でも忙しくて進んでない罠が・・。
ひげぽんさん、ﾌｧｲ�dです。

さっそくはじめての４８６を勉強中なのですが、質問です。
firstboot.asmのファイル中で

TEMPSEGが9f00と宣言されているのが
その少し下のほうで
ES:DI 9fe0:0000となっていて、
どこで換わったのか分りません。。

ひょっとしてすごいダメダメな質問？？

>>301
現在最新版のfirstboot.asmでは
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/src/firstboot.asm?rev=1.8&content-type=text/vnd.viewcvs-markup
%define TEMPSEG 0x9f00

xor ax,ax
mov ds,ax
mov si,0x7c00 ; src = 0000:7C00 (DS:SI)
mov ax,TEMPSEG
mov es,ax
xor di,di ; dst = 9FE0:0000 (ES:DI)
mov cx,0x0200

となっています、コメントが間違っていますが
一応整合性は取れていると思います。

すいません回答になってますでしょうか？

>>299
>>300
ありがとうございます。
私も最近忙しくてくじけそうですががんばります。m(__)m

FDCドライバをゆっくりと作成中です。

あ、単なる間違いですか。
なんか特別な仕組みがあるのかと。。
特にRAWRITEがどうのとかの所とか。

interfaceの７月号が売ってないですぅ。。
秋葉でも神保町でも新宿でも。。
どっかに売ってないでしょうか？

またpart2からやりなおしですか。はぁ。

>>304
神保町にないなら見つからないと思われ。
出版元に問い合わせたほうが早いんじゃない？

>>305
すいません、なるべくここでの質問は避けるようにしますんで。。。

開発メモ
bochs2.0.2にて現象確認(Monaの環境だけの現象かもしれません)

(1)FDCのDORに対してリセットコマンド0x00を送ると
not ready , busy状態になりいくら待ってもその状態は変わらない。

その後 not ready を無視して motor onコマンドを設定すると
ready ,not busy状態になる。

(2)recalibrateコマンドを発行後(senseInterrupt前)に割り込みが
発生しない。
ただしコマンド発行前後でready -> not ready -> readyという状態遷移はする。

>>308
Bochsがおかしいと思うんだったら、
Lﾀﾝみたいに調べてみるべきじゃない？
そんな難しいことはできませんとか言われそうだから、
OS作るのも充分難しいと釘を刺しとく。

おかしいと思う事があったら報告があるのは良いのではないかな。
ついでに言えば、ココに書くだけで情報が集まるならそれは良い事だ。
情報収集の努力はしておいて損がない。
しかし、自分で調べることが重要なのもまた事実。

あまり覚えていないのですが
DORに0x00(NORMAL->RESET)を書き込んだ後、
DORに0x04(RESET->NORMAL)を書くのでは？
あと、この二つの間にwaitが必要だったかもしれません。

まずはおしらせ
要望があったのでMonaBBSにOS勉強・資料部屋 というスレッドを作りました。
http://monaos.hp.infoseek.co.jp/cgi-bin/2ch/test/read.cgi/developmona/1045154170/l50

OS作成の資料を貼り付けたり、いろいろと活用してください。

>>309
>Bochsがおかしいと思うんだったら、
>Lﾀﾝみたいに調べてみるべきじゃない？
>そんな難しいことはできませんとか言われそうだから、

おっしゃることはもっともです。
たまにBochsのソースをgrepしたりしてますが、
今回の件は全然調べていません。

調べていない理由としては実機、VPCで動いていること
Bochsでも、特に大きな障害になっていないことがあげられます。

よっぽど障害にならない限り、とりあえずはFDCDriverの開発を
優先しようかと思います。(すこしでもMonaの開発に時間をかけたいため。）

>>310
>おかしいと思う事があったら報告があるのは良いのではないかな。
>ついでに言えば、ココに書くだけで情報が集まるならそれは良い事だ。
>情報収集の努力はしておいて損がない。

フォローありがとうございます。
意図としては、単純に開発メモ(忘れないように)と
情報共有と知っている人がいたらいいなあの３つがあります。

>しかし、自分で調べることが重要なのもまた事実。

御意

>DORに0x00(NORMAL->RESET)を書き込んだ後、
>DORに0x04(RESET->NORMAL)を書くのでは？

アドバイスありがとうございます。

私の想定ではDORに0x00(NORMAL->RESET)の直後に
割り込みが発生するとおもっています。

DORに0x04(RESET->NORMALに関しては
MonaのMFDCDriverではモータスターと同時にこのコマンドを送っています。
この操作のあとの割り込みはBochs,VPC,実機で確認しています。

9801/9821 Vol.2 メモリ・I/Oポート編
http://www.webtech.co.jp/undoc/
どぞ

>>314
ん？PC98？FDCのチップ名がD765AでＡＴ互換機のPD765と似てるけど、
互換互換性あるの？ポート番号だけ変えれば話が成り立つとか、、、

>>315
「D765A」じゃなくて「PD765A」の間違い。脱字ｽﾏｿ
あ。「互換」も余分だ。重ねてｽﾏｿ

某OSのFDCドライバはPC98版とAT互換機版で90%くらい同じコードだよ

>>315
uPD765ですな。Aは改良版と言うことです。
コマンドなんかは同じじゃなかったかな。

　　　　　＿,.'⌒)　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　, ´f二ｺヽ　　　 ／ そもそもSuper I/O chipに統合されてるので
　 　 ! l !ﾉ ﾘ i l　　＜.　　NEC uPD765(A)そのものじゃないですしね。
　　ノiﾊl.ﾟ ｰﾟﾉﾘ　　　 ＼　NT4 DDKに付属するFD driver sampleは
　　　 ⊂)允つ　　 　 　＼ 完成度としては最高だと思います。
　　　　　　　　　　　　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

結局、DORのbit3を立てないと割り込みが発生しないということのようですね

さて。
こっちに１度も書いたことなかったので、ちょっと書いてみよう
yuryu で参加してます。

>>29
ごめんなさい、ずっとさぼってました。

早く gcc が mona で動けばいいね・・・

>>314さん
ありがとうございます。

>>319
NT4DDKって簡単にてにはいんるんでしょうか。

>>320
そのようですね。ありがとうございます。

>>321
ゆりゅさん
一緒にがんばりましょう。

プロセス管理をきちんと実装したい。
のに、FDCDriverがうまくいかない。
GPLのソースを導入するのも良いとアドバイスをうけたので
最悪その手もあるがここまでやったので・・・

DMACの設定とかを丸ごとぱくってて理解していないのが悪いのだろう。

seekはできないが、readができない。
早く先に進みたい・・・

>>323
NWSOSみたいにBIOSってのも手だと思う

>>324
　実は、FDCのドライバ書くより、はるかにBIOSを呼び出すほうが技術的に
難しいといって置きます。

　32BITプロテクトモードから、BIOSを呼び出すのはかなり大変なんです。

　最低でも仮想8086モードを利用するのですが、割り込みなども全部
「V8086へのリフレクト」が必要になります。

　レベル遷移も上下とも自由自在に行う必要があり、かなり複雑になります。

（失礼ですが、FDCドライバが難しいと感じる人には無理だと断言しても
過言ではないと思います。）

>FDCドライバが難しい感じる人には無理
資料が無いから難航しているのでは？

>>326
　FDC μPD765Aは、PC-8001の時代から使われていたCHIPで、資料というより
出来上がったソースが一杯あるはずなのです。
　歴史が古いので、既に最適化も限界まで行われているはずで、セクタ
リード、ライトルーチンなどはそのままコピーして使えるほど簡単なん
です。BIOSのソースもあるでしょうし、それを32BITに変えることは非常に
基本的なことですよ。

>>325
いずれにせよVESAに手を出すとやらないといけないから脅すのもどうかと

>>323
> GPLのソースを導入するのも良いとアドバイスをうけたので
> 最悪その手もあるがここまでやったので・・・
別に最悪でもないと思う、ていうか現実的
FDCに限らず色々なハード全部をサポートしきれるわけない

Windowsのドライバ流用はほとんど絶望的だけど
Linuxのドライバならソースもあるしやりようはあるだろう
でも新しいOSを作るのとは技術的に趣向も違うし
誰か古狸の応援でも受ければ良い分野ではあるな

ひさしぶりに来てみました。
いまはファイルシステムいじってるのかな？
過去レスみてきま〜。

がんばれ、ひげぽん！

>>327
いや、小学生の頃からアセやってる様な人には簡単かもしれんが、
最近始めた人間にとっては例えソースや資料があったとしても、
デバイス相手はなかなか勝手が分からん物なのだよ。
ワシも最初は随分苦労したよ。要は慣れの問題。
今はアレでもそのうちなんとかなるさ。
このスレはそういう場所。

>>325
今日できなくても、明日できるかもしれない。
明日できなくても、一週間後にはできるかもしれない。

自分の趣味の時間を使ってやってるのだから、
今できるかではなく、出来るようになってやる、という気持ちのが大切。
と思われるが如何か？

>>332
それは一向に構わないんですよ。

でも、Monaのページにご覧になったかどうかは分かりませんが、
正直言って:

「今、一番将来性のあるOSかもしれません。」

は誇大だと思います。

なぜなら、もっとできる人が世の中には山ほどいるからです。

はっきり言ってMonaはまだ何も出来てなくてOSなんて呼べる代物じゃない。
それは作ってる人間が一番良く知ってるだろ。
でも、何も出来てないって事は同時にこれから何でも出来るかもしれないと
いう可能性を秘めてるわけだ。
あそこの「将来性」ってのはそういう事が言いたいんじゃないのか？
そういう意味での「将来性」ってのはWindowsやLinuxやNWSOSにはない。
Monaの専売特許だよ。あのページはそれを希望とちょこっとのアイロニー
を添えて書いてるんだよ。だから誇大でもなんでもないだろ。
アゲ足とるのはヤメレ。

Windows, Mac, Linuxのような物は、それなりの人数と年月がないと作れない以上、
ぶっちゃけ、OS作りなんて、趣味以外の何者でもないと思う。

OSASK や Mona のように、大きな夢を掲げて楽しくみんなで開発するのも良し、
MEG-OSのように萌え路線に走るのも良しで、楽しいことが重要ではないのか？

334にかぶるが、あげ足とるのはやめて楽しめと

ﾒｸﾞﾀｿは別に「萌え」に走ったわけじゃないょぅ。
たまたま「萌え」を実装してみたらみんながそっちに注目してるだけだょぅ

でも、「MOE」は最近実装しましたがヽ(｀ー´)ノ

>>336
違ったのか．．．ｽﾏｿ
OSのことはさっぱりだが、ガムバレ メグタン

がんばるょぅヽ(｀ー´)ノ

>>333
何様ですか？

>>333
('A`) ぬるぽ

>>339
ﾁﾐも十分「何様ですか？」だがな。

>>339
LightCone様です。
http://pc.2ch.net/test/read.cgi/os/1039075591/

ヽ(｀ー´)ノ らいこんたま、らいこんたま、わーい、わーいヽ(｀ー´)ノ

>>330
>がんばれ、ひげぽん！

ありがとうございます。

えーと。
私のしょぼい技術のせいで、ちょっとした
騒動？になっていて申し訳ありません。m(__)m

この場であまり弱音を吐かず、技術を着実に少しずつでもつけられるよう
精進いたします。

Lﾀﾝ、MONAに脅威をもってついに攻撃を始めたか。
よっぽど脅威に思ったと見える(藁

ある意味MONAにとっては大人の仲間入りの洗礼だね。
OSASKでもそういうことあったしね。

Lﾀﾝは、自分がプログラムに費やした時間と
ｱｾを半年前にはじめたﾋｹﾞﾎﾟｿを比べて言っているのだろうか。

>>345
ある人が学習に費やした時間の間も、別の人にも時間があったはずです。
その間にやったことが今を作ります。もちろん、年齢も関係あるとは
ありますけれども、、、。

>>346
そこまで分かってるなら、話が早い。
ﾋｹﾞﾎﾟｿは、今までLﾀﾝがまあまあ得意な分野とは
違う分野に時間を費やしていたのでは？

Lﾀﾝ冷静になれ、この分野での経験年数・基礎知識をよーく考慮してみれ。

>>347
「ﾋｹﾞﾎﾟｿは、今までLﾀﾝがまあまあ得意な分野とは
違う分野に時間を費やしていたのでは？」
それはわかります。

しかし、その状況で、

「今、一番将来性のあるOSかもしれません」

と繋がっていくのかが分かりません。

（アセンブラも知らない、FDCの制御も出来ない、時間もない、資料も集め
られない、学習速度も個人的には早いとは思えない状況下で、、、。）

「二重かきこ」と言われそうですが、気になるので追伸。

自分の作っている作品の事を「将来性がある」と豪語することと、
「私は何も知りません」と言って、2chで聞きまくっている状況とが
全くか合わないように感じるのです。

（実は本心では自信過剰で、猫かぶってるんじゃないかと）

FD Read実験成功しました。
ただしVPCと実機のみ(Bochs)はまだです。
DMACのステータスレジスタの様子がBochsだけ違うので
ちょっと調べ中。

（L氏とH氏の一騎打ちか？わくわく）

おいおい、いい加減止めようぜ。こんな話題。
ひげぽん氏の>>350の書き込みがなんだか縮こまって見えて可哀想だ。

個人的にはLightCone氏の意見に近いが、
こんなところに書いても不毛な議論(?)だろ。

>>348
＞今、一番将来性のあるOSかもしれません
こういうキャッチコピーはふつう大げさなもんだって。
真面目に考えちゃいかんよ。

そういうこった。ﾏﾀｰﾘしる！

まぁ、同じOS作成経験のあるものからすれば、Lﾀﾝが現在のMonaについて歯痒い思い
をしててそれで噛み付いてるってのも分からんでもないが、実力があるんならあるで
どっしり構えて超先生みたく暖かく見守れないものだろうかね。どうよ？＞Lﾀﾝ

＞（実は本心では自信過剰で、猫かぶってるんじゃないかと）
よく言った!!
実はみんなそう思ってるんだろうけど...

理屈で叩くより感情で叩いた方が有効な場合が多いことを学んだらしい
どうせばれるにしろ名無しで叩かないところは流石です

良スレなので余り反応したくないのですが、念のため一言だけ：

　荒　ら　し　は　放　置　の　方　向　で

Mona develop beta 0.02b のタグがない様です。大雑把に
cvs rtag -f -D 2003/1/30 develop_beta_ver0_02 mona_v1.0
タグを打って、これをチェックアウトしたものと
配布パッケージを diff -r で比較しながら
cvs tag -F -r (rev) develop_beta_ver0_02 path/to/file
タグを調整すると楽ですよ

ところで、MEG-OSって今どこにあるの？
meg-os.org逝ったらアダルトサイトだったんだけど…(;´Д｀)

ちょっと入り口変わっただけだょぅ。昔から18禁だったょぅヽ(｀ー´)ノ

ガーン。初めて行ったから間違えたかと思ったよ。ありが�d

ところで今ﾒｸﾞﾀｿはｽｯﾄﾞﾚ実装中なんですけどｽｹｼﾞｭｰﾗの
参考になるサイトとかないんですかね？

現状のスケジューラは禿しく糞らしいんで(つД｀)

なんとなく見つけた記事だが、
http://www.atmarkit.co.jp/fpc/xp_feature/display/display.html
>最新版であるVBE 3.0には、いわゆるVGA BIOSの拡張だけでなく、
>プロテクト・モードから拡張機能（VGAに対する）を呼び出す
>エントリ・ポイントが用意されており、Windows XPの標準ドライバは、
>このプロテクト・モード・インターフェイスを用いている
プロテクトモードでそのままVGA BIOSが使えるということで？
識者の解説キボン

>>364
そのための呼び出し手順が拡張されている様ですな。
詳細 http://www.vesa.org/vbe3.pdf

>>364
プロテクトモードで対応するVBEファンクションが
呼び出せるというだけです。

「VGA BIOSがそのまま使える」というわけではありません。
ちなみにこの機能はVBE 2.0から実装されてます。

>>365,366
多謝。PDF見ると、初期化が複雑そうなﾖｶﾝ

てすとん

本当の所、Lﾀﾝは、ﾋｹﾞﾎﾟﾝﾀﾝに口を出したいけど
口を出すと、自分のOSとの区別がつかなくなってくるから
それを嫌って、口を出せないのが悔しく
また、ﾋｹﾞﾎﾟﾝﾀﾝの作業が遅々として進まないのも
もどかしく、黙って見守るのが辛くなって
口撃してみる事したのでは？
と、今更むしかえしてみる



















こんな事書いてるけど、別に二人の事を馬鹿にしてる訳ではないよ
本当に

http://qb.2ch.net/test/read.cgi/saku/1027998169/
このｽﾚは面白いな
削除依頼ｽﾚに愚痴を書くLﾀｿ萌へ

スレと関係ないレスは自粛汁！

http://pc.2ch.net/test/read.cgi/os/1039075591/682
このレスをLightConeはよく読み返してみるべきだと思う
ゴチャゴチャ口出しされたくないといいつつ、MONAや
ひげぽん自身に対して要らぬレスをしすぎ。
自分が散々叩かれたからここで憂さ晴らししてるのか。

ﾒｸﾞﾀｿもｿｰｽ公開したら叩かれたょぅ。えう〜ヽ(｀ー´)ノ

>>372
そうか？　確かにここに来て、批判的な書き込みもあるが
少なくともこのスレシリーズでは、LightCone氏はヒゲポン氏に対して
「良き先輩」としての暖かいアドバイスを送っている方が多いと思うぞ｡

　IRCでも指摘されたんですけど、Monaのページを作っているのは、ひげぽん
さん自身じゃなかったんですね。

　ですので、#348, #349は言いすぎでした。すみません。

　（でもまあ、取り立ててひげぽんさんの学習速度が早いとは思えま
せんね。すみませんが。）

>>375 LightConeさん

こんばんは。
>　IRCでも指摘されたんですけど、Monaのページを作っているのは、ひげぽん
>さん自身じゃなかったんですね。
>
>　ですので、#348, #349は言いすぎでした。すみません。

いえ。
LightConeさんが、そう思われた経緯も理解できますので
全然気にしてないです。

というわけで、これからもよろしくお願いします。

>　（でもまあ、取り立ててひげぽんさんの学習速度が早いとは思えま
>せんね。すみませんが。）

自分でも早いと思っていないので（笑）

>>1
最高にくだらないもん作ってるなｗｗ
俺こういうくだらない笑いが好きだｗｗｗ

正直、電波飛び交ってるよな。
ま、冷静に考えたら、酔狂だ。
そんな漏れも、ここ読んでる時点で、糞馬鹿。（ｗ

>>375
一言多くないですか？

>>379
俺もそう思う。
別に誰もひげぽんが早いなんて言ってないのに
いちいち言わなくてもいいんじゃない。
早くないことを指摘すると何かいいことあるのか？

まあ、アレだ。
コンピュータにだけ向かい合って来たんで、
言葉を"オブラートに包む"事が出来なくなったんだろ。

最小限の労力で的確に急所を突くという動作は、
ある種の職業病ですが、何か？

つうか、おまいら。寒いです

コンピュータに携わると人を見下す性格がデフォルトとなるようです

端的に言うと、
自分の（画期的、先進的な）アイデアは真似されたくないのに、
自分がやっていることは高度であると自慢したいから、
このスレに居着いて先輩面して箸にも棒にもかからない中途半端な助言だけしてるわけだ。

自分が中心でないと気が済まない。
このスレはタテマエはともかく、主人公はひげぽんなわけだし、
ひげぽん寄りな意見の人が多く集まるのは当然なんだが
それが理解できず、自分に賛同しない物が居るとひげぽんを叩く。

>>384
ひげぽん寄りな意見の人が多く集まるのは当然なんだが
それが理解できず、自分に賛同しない物が居るとひげぽんを叩く。

そうそう。Ｌは自分がなにやってるのか分からないんだろうな。
というか、ここで、このスレと関係ない話題で盛り上がるのはｲｸﾅｲから

Ｌ　の　話　題　は　Ｌ　の　ス　レ　で

ってことでどうでしょう？

↓のスレOSの勉強になりそうですよ

次はNetBSDがきますVol.1
http://pc.2ch.net/test/read.cgi/os/1045830003/

はじめまして、NWSOS信者と申します。

教祖様が叩かれているのでフォローしますと、
教祖様は単純に自己にある物差しで、人や物を観察、評価し表現するのです。
その結果、周囲が不愉快になるかどうかはまた別問題ですが、大抵の日本人は
その問題を丁寧に処理します。つまり、大多数の人が気を使うとこなのね。

だけど、教祖様はそんな情的なことには関心がないの。
そこで、謝った判断材料で「○○さんは覚えが早いとは思えません」など
国内の常識人が見れば一言多い言動となるわけです。

OSを開発している稀有な人材が集まってるのだから、つまらない揚げ足どりで
膠着させるのは止めましょう。

part2に逆戻りと言われそうですが、どうしてもエラーの原因がわからない
ので、御教授ください。
少々長いですけどすみません。
0x07C0:0x0000 から 512バイト (ブートセクター)
0x07E0:0x0000 から 1024バイト (カーネル)

＜Bochsのエラー＞
Event type: PANIC
Device: [CPU ]
Message: exception(): 3rd (13) exception with no resolution

00000573597i[CPU ] protected mode
00000573597i[CPU ] CS.d_b = 16 bit
00000573597i[CPU ] SS.d_b = 16 bit
00000573597i[CPU ] | EAX=60000011 EBX=000007c0 ECX=00000002 EDX=00000000
00000573597i[CPU ] | ESP=0000fffe EBP=00000000 ESI=000000d9 EDI=000007e0
00000573597i[CPU ] | IOPL=0 NV UP DI PL NZ NA PE NC
00000573597i[CPU ] | SEG selector base limit G D
00000573597i[CPU ] | SEG sltr(index|ti|rpl) base limit G D
00000573597i[CPU ] | DS:07c0( 0000| 0| 0) 00007c00 0000ffff 0 0
00000573597i[CPU ] | ES:07c0( 0000| 0| 0) 00007c00 0000ffff 0 0
00000573597i[CPU ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00000573597i[CPU ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00000573597i[CPU ] | SS:07c0( 0000| 0| 0) 00007c00 0000ffff 0 0
00000573597i[CPU ] | CS:07c0( 0000| 0| 0) 00007c00 0000ffff 0 0
00000573597i[CPU ] | EIP=000000da (000000da)
00000573597i[CPU ] | CR0=0x60000011 CR1=0x00000000 CR2=0x00000000
00000573597i[CPU ] | CR3=0x00000000 CR4=0x00000000
00000573597i[ ] restoring default signal behavior

[bits 16]
jmp 0x07C0:start ;CSコードセグメントを設定する。

start:
;セグメントの設定
mov ax, 0x07C0
mov ds, ax
mov es, ax
mov ss, ax

;ブートスタートメッセージを表示する
mov si, BootStart_Msg
call print

;FDからセカンドセクター以降を0x07E0:0x0000へ読み込み
call read
mov bx, 0x07C0
mov es, bx

mov si, KernelLoad_Msg
call print

lgdt [gdtr]

;割り込みの禁止
cli

;CR0の1bit目をセットし、プロテクトモードへ移行する
mov eax, cr0
or eax, 1
mov cr0, eax

jmp flush_q1;
;--------------------------------------------------
;グローバルディスクリプタテーブル(GDT)定義
;--------------------------------------------------

gdtr:
dw gdt_end - gdt0 - 1 ; gdt limit
dd gdt0 ; start adderess

gdt0: ; segment 00
dw 0 ; segment limitL
dw 0 ; segment baseL
db 0 ; segment baseM
db 0 ; segment type
db 0 ; segment limitH
db 0 ; segment baseH

gdt08: ; segment 08(code segment)
dw 0xffff ; segment limitL
dw 0 ; segment baseL
db 0 ; segment baseM
db 0x9a ; Type Code
db 0xcf ; segment limitH
db 0 ; segment baseH

gdt10: ; segment 10(data segment)
dw 0xffff ; segment limitL
dw 0 ; segment baseL
db 0 ; segment baseM
db 0x92 ; Type Data
db 0xcf ; segment limitH
db 0 ; segment baseH

gdt18: ; segment 18(stack segment)
dw 0 ; segment limitL
dw 0 ; segment baseL
db 0 ; segment baseM
db 0x96 ; Type Stack
db 0xc0 ; segment limitH
db 0 ; segment baseH

gdt_end: ; end of gdt

;-------------------------------------------------------------------
; 文字列を表示する
;入力レジスタ ds:si(文字列の先頭アドレス)
;使用レジスタ ah, al
;-------------------------------------------------------------------

print:
mov ah, 0x0E
mov al, [si]

cmp al, 0x00
je print_return

int 0x10 ;１文字表示(int 0x10, ah=0x0E, al=文字コード)
inc si
jmp print

print_return:
ret

;-------------------------------------------------------------------
; 　　　　　カーネルをFDから読み込む
;-------------------------------------------------------------------
read:
;ディスクリセットをする
mov ax, 0x0
mov dl, 0x0
int 0x13 ;ディスクリセット(int 0x13, ah=0x00, al=ドライブ番号)
jc read_err

;0x07E0:0x0000へFDから読み込む
mov ah, 0x02
mov al, 0x02
mov ch, 0x00
mov cl, 0x02 ;セクタ番号だけは0x1から始まるから
mov dh, 0x00
mov dl, 0x00
mov di, 0x07E0
mov es, di
mov bx, 0x0000
int 0x13 ;(*)
jc read_err
jmp read_return

read_err:
mov si, DiskReadErr_Msg
call print
jmp read

read_return:
ret

;メッセージ一覧
BootStart_Msg:
db 'now boot starting!!...', 0x0D, 0x0A, 0x00
DiskReadErr_Msg:
db 'disk read err', 0x0D, 0x0A, 0x00
KernelLoad_Msg:
db 'kernel load success!', 0x0D, 0x0A, 0x00
[bits 32]
flush_q1:
;ここでエラー終了する。
;セグメント間ジャンプ命令によってCSレジスタに0x0008をロードする。
db 0eah
dw set_cs_desc1 + 0x7C00
dw 0x0008
set_cs_desc1:
mov ax, 0x10 ; ds & es
mov ds, ax ; selector is
mov es, ax ; 0x10
mov ax, 0x18 ; ss selector
mov ss, ax ; is 0x18
mov esp, 1024*1024*8 ; sp is 8MB
jmp kernel
;$ 現在の行の先頭アドレスをさす。
;$$ 現在のセクションの先頭アドレスをさす。
;($-$$) セクションの先頭からのバイト数
times 510-($-$$) db 0 ;510-($-$$) bytesを0で埋める
dw 0xAA55 ;ブートシグニチャ
kernel:

大量消費ですみません。
どこかにUpした方が良かった．．．
御教授お願いします。

どこからツッコんだらいいか分かりません。。

エラーで止まった、EIP=000000da　の場所は最後の方の
;ここでエラー終了する。
;セグメント間ジャンプ命令によってCSレジスタに0x0008をロードする。
db 0eah
dw set_cs_desc1 + 0x7C00
dw 0x0008
にあたるのですが、そこを逆汗してもきちんと正しいと思われる内容が
表示されていて、何故エラーなのか原因がわかりません。

パクッテル、そして、、、それがうごかない。

>>398
IDT関連の部分は、パクリました。ゴメンなさい。
後々、独自に設定します。

一度はプロテクトモードでVRAM出力まで行けたのですが、
どういうわけか、後々のことを考えたコードに書きなおすと、
エラーで動かなくなりました。
読みにくければ、どこかにUPします。
どうか御教授ください。

IDT間違い GDTです。

懐かしいなあ。
今すぐはわからなそうです。ごめんなさい。
というか忘れてる・・・

VirtualConsole作戦は時期尚早だったと後悔気味です。
newしないと、文字出力できないということは
メモリ管理オブジェクトのデバッグが非常に困難・・・

安定していると思っていた、カーネルメモリ管理クラスの挙動が怪しい。

http://www.geocities.co.jp/SiliconValley-Sunnyvale/1176/os.zip
IDT部分はまだ途中なので気にしないでください(コメントアウトしています)。
Make わからないので、バッチファイル使っていることも許してください．．．

ひげぽんさん
Part5まで、ひげぽんさんより時間かかる自信あります(笑)
私などから見れば、ものすごいスピードで進んでいるように見えますよ。
頑張ってください。

dd gdt0 + 0x7c00

>>403
どうもありがとうございます！
そんな基本的な部分に抜け落ちがあるとは気づきませんでした。
以後、このような基本的な部分でのミスがなきよう注意します。

BochsではきっちりプロテクトモードVRAM文字出力まで行うことができたのですが、
実機ではブートセクターを読み込んだらすぐに再起動になる現象は
やはりまだ直っていないようなので、もうすこし頑張ります。
startラベル以下でのセグメントの設定をしていなかったのがまずかったのかと
思い、修正した結果がこのバグだったのです．．．

FreeDOS教徒さん、403さん
夜遅くまでお手数かけました。
実機の問題は、明日やってみることにします。

>　hisohisoさん
タグの件ご指摘ありがとうございます。
次回のリリースの際には気をつけます。m(__)m

>>404
スタックポイント(sp)が設定されていないから
だと思います
mov ss,ax
の次の行に
mov sp,0xffff
を追加してみてください

ｽｯﾀｸﾎﾟｲﾝﾀ奇数かよ

>>407
に追加
"mov ss,ax"はstartラベルに近い方の事です

>>407
xor sp,spでもいいんでない？

>>407(409),FreeDOS教徒さん
返事遅くなりました。
start:
;セグメントの設定
mov sp, 0xFFFF
;xorsp,sp
mov ax, 0x07C0
mov ds, ax
mov es, ax
mov ss, ax
と修正したところ、実機の方でもうまく動きました。
御教授ありがとうございます。
セグメント間ジャンプをしたのにSPの設定をしていないためということが原因で、
FreeDOS教徒さんが示された SP = 0x0000 に指定すると言うのは、
SP から -1 すると SP = 0xFFFF ということになり、
無駄なくセグメントを利用できるということなのでしょうか．．．

>>411
0x0000に指定しておけば、次に積まれるスタックの内容は
sp-2=0xFFFEに置かれます。

あと、割り込みの暗黙的な禁止はスタックセグメントの
操作後１命令だけですし、そのような順番はあまり
良くないので、mov sp,〜はmov ss,〜のすぐ後に移し
たほうがよいでしょう。

>>FreeDOS教徒さん
修正しました。重ね重ねご助言ありがとうございます。

突然ですがMONAはGUI実装予定ありますか？

プログラム技術＠2ch掲示板でこんなスレ上がってますが
http://pc2.2ch.net/test/read.cgi/tech/1045907529/l50

＃2ch-OS、マジで頑張ってください。

>>414
>突然ですがMONAはGUI実装予定ありますか？
Monaのホームページ見てから書き込みしましょう。

GUI の代わりに

C-GUI or I(mitation)GUI　なんてどうでっしゃろ。

早く言えば AA の GUI よ。
コレなら俺でも参加できる

GUIがどうとかいってるのはもう少しカーネルというものを
勉強された方がいいかと

ﾊｧ？

Site に FAQ を乗せてくれたらいいな・・・

Windows と違うのは オープンソースだったり軽かったりセキュアだったりで
UNIX と違うのは
　　>>Monaはなるべく過去の負の遺産を引き継がないように
ってあたりっすか？

>>414
GUIはサポート予定です。
ただし現時点では、GUIを実装する段階にはいたっておりませんので
しばらくはCUIのままだと思います。

>>416
> C-GUI or I(mitation)GUI　なんてどうでっしゃろ。

面白いですねぇ。それでもまだ、現段階では時期尚早かもしれません。

>>419
>Windows と違うのは オープンソースだったり軽かったりセキュアだったりで
>UNIX と違うのは
>　　>>Monaはなるべく過去の負の遺産を引き継がないように

そうですね。大雑把に言って
良いものはまねする、悪いものは出来るだけ引き継がないようにするというかんじです。

>Monaはなるべく過去の負の遺産を引き継がないように

　時期がきたら、IA-32アーキテクチャ依存からの脱却キボンヌ

>>421さん
>時期がきたら、IA-32アーキテクチャ依存からの脱却キボンヌ

これもだいぶ先ですが、できれば実現したいですね。

今日は割り込み処理をアセンブラに移行しました。
以前のC++の割り込み処理ではスタックが壊れているような印象があったので
いろいろな方のアドバイスをもとに現在の形に変えました。

２ｃｈ風ってところが、激しく世界を狭くしているな
もっとはっきり言えばヲタク的と言うか・・・いやマジで

>>423
何の世界を？
ヲタク的だって言いたいことはわかるが、だから世界をどう狭くしてるかわからん。
あと世界が狭くてどう悪いのかも。
別に一般的に普及させたいOSを作るスレでもあるまいし・・・

>>424 煽りは放置。釣られんなよ。

>>412
bochs でデバッグしてるときに「espが０だ変だ」って言ってpanicしたことあるけど、
大丈夫かな。

>>426
bochsは使いっぱなしだけど、今のところリアルモードで
xor sp,spして問題になったこと無いよ。

>>426
espではなくspなので
0でも大丈夫なのです

>>428
そうだったのか！Σ（ﾟдﾟ；）

今、640*480(256色)モードで色々VGAに書き込んでいます。

書き込み色プレーン指定、ビットマスクの指定の後、
ビットデータを書き込みたい場所のメモリ位置へ転送することで、１ドットを描画しています。

この方法では、横８ドットを一度に書き込む必要があるので、
赤白黒緑赤白黒緑　のようなランダムなドット絵を描画するには、
同じ場所をビットマスクを変えて８回ビットデータを転送しなければいけません。
色々、アルゴリズム的な最適化をしてもかなり遅いです。
Celeron1.7GのCPUで、Bochsだと全画面書き換えに1.5秒ぐらい、
実機でも書き換えがかんたんに見えるぐらい遅いです。

PC-98では、
Bプレーン 0xA8000〜 Rプレーン 0xB0000〜 Gプレーン 0xB8000〜 Iプレーン 0xE0000〜
となってて、メモリアクセスだけで高速に描画できると思います。

DOS/V の VGA に高速で書き込むには、640*480(2色) or 320*200(256色) モードに
設定するしかないのでしょうか？

（ココに書くの久々だなぁ…

>>430
OS側で色別に仮想VRAMを持って、それを一気に転送とか。
（実際、VGA BIOSってかなり遅いし。
ゲームとかの用途だとVGAサイズはリアルモードでは厳しいね…

プロテクトモードなら、他にVESA BIOSにLiner Frame Bufferを作ってもらうって手がある。
>>365あたり。自分は使ったこと無いんで詳細は頑張って読んで…
ただし、こっちは対応してないグラフィックカードが有るらしい。(具体的にはi815。

Master.Libのソースでも見てみるかな…

書き込み有難うございます。
一応、作成しているプログラムはプロテクトモードOSのつもりｗ
なのでBISOは使えないです。I/Oポートに直接アクセスしています。

概要は、一度ビットマップ形式のバッファを作って、一気に書き込みといった雰囲気です。

素直に描画するのなら、１ドットの描画に、
書き込み色プレーン指定、ビットマスクの指定を、グラフィックコントローラーを操作して行い、
該当のメモリにビットデータを転送しています。工夫すれば、ビットマスクの指定はほとんど
しなくて良くなります。全画面更新のために、これを640*480回繰り返してるのですが、
ホントに遅いです。

VESA BIOSにLiner Frame Bufferに作ってもらうしかないのですか．．．
ちょっと試したことはあるのですが、内容があまり理解できてないというのもあり、
モード指定の時点でもう失敗しているので、避けたいのですけどね。

FD読み込みが実機で失敗する現象がなかなか解決せず悩み中。

リザルトステータスを見る限りでは
ST0= 0x40　コマンド異常終了
ST1= 0x10　overrun FDCからの転送要求にホストが応答しない
ST2= 0x00
C= 0x00
H= 0x00
R= 0x01
N= 0x00

DMACの設定かなと思って調査中。
スタック破壊は原因ではなかった模様。

Nは0でいいの？
俺もちょっとあやしいからどうだかわからんが…

Nは普通2のはず？

>>430
640x480x256って、どのビデオモード使ってるんですか？
ふつー俺なんかだと拡張ビデオモード101hなんかを思いつくわけですが。。

それはともかく、DspVVみたいなディスプレイドライバのソースとか、
あとEOTAのソースなんかも参考になるんでないかなーとか思いますた。

現在全プレーンを一度に更新できる方法探し中。

すみません、書き間違えてます。640*480(256色)→640x480(16色)です。
EOTA では、構造体に描画コマンドとして蓄えてる？　ようです。
Liner Frame Bufferを使うか、描画コマンドを使って、書き込みモードをかえながら描画するのか、
白黒にするのか．．．
あまり複雑なことしても、他の部分を作る時間が無くなりますし。

>>430
ピクセル描画をいまのところサポートする必要性はないんだし、
文字書き込みがきちんとできれば、他のところに挑戦していいんでない？


いずれスクロールで頭を悩ますことになるんだろうけど（汗

文字書き込みはできるので、FreeDOS教徒 さんがおっしゃる通りなのですが、
もう少しだけ、色々試してみて、できそうもなければ、他の部分を作ることにします。
まだ、mallocもなく、バッファもスタックに確保してるだけなので．．．

>>439
この辺から作っていくと面白いと思うよ。
ﾒｸﾞﾀｿは萌えで有名なんだけど、
AAできるフォントが使えたりもしたしね。（モナーフォント？）

ひげぽんは足腰のしっかりした本格的なOSを作ろうとして
肩肘張りすぎてる気がするな〜。
何だかんだいって下馬評通りにバンバン進んでないし。
短期的には430様のアプローチの方が楽しそう。

>>424
打倒M$だっつってるじゃん。

>>440
妥当M$は、たんにいいOS作るだけじゃむりなんだよなぁ……
とか逝ってみる

>>430 もう昔のことで覚えとらんのだが
VRAMへの書き込みが特定プレーンにそのまま書き込まれるように設定してやれば、98と同じように見えるので

グラフィックコントローラの設定　４（プレーン）回
640x480/8(byte)のコピー　４（プレーン）回
ですむんじゃねーか

ライン毎とか８ドットごとでもいいけど

仮にビットマップをpacked pixelでもってるなら、packed->planeへの変換はCPUでやる。

御教授ありがとうございます。
プレーン0 を指定、640*480/8 byte を 0xA0000〜 に書き込み、
そして、プレーン0を指定、640*480/8 byte を 0xA0000〜 に書き込み、
．．．
という方法は実際、やってみたのですが、最後に書いたプレーンの色しか表示されていないので、
できないものかと思っていました。もう少し調べて設定ミスがないか探してみます。

Liner Frame Buffer もわかりやすいサンプルが見つかったので、こちらの方法も視野に入れて
どうするか考えます。
サンプルソース http://www.gameprogrammer.com/1-vbe.html

二行目 プレーン0 → プレーン1 です。
書いたら、見直しているのですが(汗)

いちおうツッコミ入れとくけど、参考資料間違ってるぽ。
もう一度きちんとグラフィックコントローラレジスタ周り見直してぽ。。

ある意味すげーよ、これで動いてるのって（汗
手もとの資料をちとコピペしとくんで、これで試してみそ。
----

Port 03C4 - シーケンサアドレスレジスタ
以下に続くマップマスクレジスタの選択のために必要です。

Port 03C5 index 02 - マップマスクレジスタ
マスクするマップを選択します。0でマスク、1で解除です。
High <- 0:0:0:0:I:R:G:B -> Low (* I=輝度)

Port 03CE - グラフィックアドレスレジスタ
以下に続くビットマスクレジスタの選択のために必要です。

Port 03CF index 08 - ビットマスクレジスタ
マスクするビットを選択します。0でマスク、1で解除です。
ビットマスクを有効にするには、あらかじめ読み取り動作を行う必要があります。

>>FreeDOS教徒 様
ご指摘ありがとうございます。

port 0x03CF index0x01　色設定
port 0x03CF index0x08　ビットマスク
と思っていたのですが、
port 0x03C5 index0x02　色設定
port 0x03CF index0x08　ビットマスク
だったのですか．．．

せっかくのアドバイスなのですが、Liner Frame Buffer を使った方法に成功したので、
こちらで進めていく予定です。

http://www.gameprogrammer.com/1-vbe.html　はよく読むと、
Banked/Windowed Frame Buffer を使った方法のようです。でもかなり読みやすいので、
大部分はこちらを参考にできます。

http://www.geocities.com/SiliconValley/Horizon/6933/vbe2.txt
こちらに、Liner Frame Buffer のサンプルがあります。

>>430
> http://www.gameprogrammer.com/1-vbe.html　はよく読むと、
> Banked/Windowed Frame Buffer を使った方法のようです。
最初タイトル見たとき「(ﾟДﾟ)ﾊｧ?VESA VBE 1.2でリニアフレームバッファ
なんてサポートしてたか？」とか思いましたが、その通りでしたか。。

資料のご提示ありがとうございます。

とりあえず、Liner Frame Buffer 版を公開〜
ttp://www.geocities.co.jp/SiliconValley-PaloAlto/6802/os_05.zip
OSと呼ばれる機能は一つもありません。

>>448
乙〜

これ、うまくmonaとくっつけられないかな
お互いに足りない部分がうまく補完できる気がする
そうすれば面白いと思うんだけど

NWSOSが公開直後になぜ絶賛されたかというとGUIの完成度が高かったから。
MEG-OSが評判になったのも萌えられるから。
しょせん、下馬評なんてそんなもん。

OS/430（仮称）がシングルタスクでGUIだけ突っ走っても、
Windows 3.1や旧Mac OS並みにはなれるはず。。。

が〜んば！

>>449
Monaのブートローダー周りを参考というより、流用の方が近いですが、
こんな感じで、これからもお手本として参考にさせてもらうことになると思います。
それと、グラフィックにこだわってみたいなあと思っていたのと、
参考にしてばっかりのMonaに少しでも、作っていない部分のサンプルを示して
お返しをという気持ちもありLiner Frame Bufferの使用のサンプルになればと思い
作ってみました。

流用に値しないものかもしれないですが、ライセンスはMonaと同じにするので、
よければどうぞ．．．>Monaプロジェクトの皆様

>>450
ありがとうございます。どこまで出来るかわかりませんがとりあえず頑張ります。

いや、おもしろいです。見ててすごくタメになりました。
ありがとうございます >>430

GUI-OSを作ってますがなにか？
http://pc2.2ch.net/test/read.cgi/tech/1045907529/l50

だってさ。

OSASK荒れてるな。無意味な日給叩きが原因か？

ところで最近、朝鮮生、じゃなかった超先生を見ないな。
どこいった？

彼ならWindowがやってるみたいに、プロテクトモードでありながら
VGA-BIOSを叩くテクをご存知かもしれぬ。

>>454
Window？
NWSOS もやってるね。

>>454
テクっていうか、仮想８６モード使えばいいだけ。

だけっていっても結構大変だけど。

>>456
>テクっていうか、仮想８６モード使えばいいだけ。
馬鹿な事をおっしゃらないで下さいませんか？

そんあ程度で BIOS を呼び出せたら苦労しません。

　度が過ぎた知ったかぶりさに、手が震えてまともに文字もまともに
打てなかった（泣）。

＜後ろ頭＞y-~~~
VGA-BIOS程度ならV86モードだけでOKでは？
特に割り込みも必要ないし。

シングルタスクに限れば300行程度でV86 monitorを作れる。

>>459
　他のタスクの動作を、しばらく完全に止めてしまうような動作でよければ
そんなに難しくは無いかもしれませんけれど、はっきり言って、そういうも
のと NWSOSを一緒にされたくは無いですね。

　V8086モードのタスクを、未来永劫、システム全体で一つのみに
限定する場合と、BIOS用のV8086タスク以外にも、V8086モードタスクを
動かせるようにするのとでは全く話が違ってくるでしょう。

　前者のようなものだと、アドレスが1MB以下の領域を、全タスク共通
にマッピングし、その領域では、線形アドレス＝物理アドレスという
恒等写像にしてしまえば、BIOS呼び出し時にタスク切り替えして戻って
くる必要が全くなく、同じタスク空間で呼び出せるので簡単です。

　しかし、後者のようなものだと、BIOSタスクと、一般USE16タスクの干渉を
避けるためには、BIOSタスク用には物理アドレスへの恒等写像を用い、
一般USE16タスクには、全く別の通常RAMを用いなければ成らないでしょう。

（ちなみにページ切り替えを全く用いないセグメントモデルでは、
複数のV8086タスクを干渉させずに存在させるのは基本的に不可能に
なると思います。）

　そうなってくると、BIOSを呼び出すときに、BIOSタスクへスイッチして
から戻ってくるような処理が必要になります。
　
（タスクのラウンドを利用して出来ないわけでもないかもしれませんが、
それなりの設計力を必要とし、決して簡単とはいえないでしょう。）


　（簡単な方式を用いた場合、その後の成長性が確実に下がるでしょう。）

>>459
何度もしつこいようで申し訳ないですが、

>VGA-BIOS程度ならV86モードだけでOKでは？
>特に割り込みも必要ないし。

これは分かりませんよ。

割り込みのリフレクトはやった方がいいと思います。

内部で VSYNC を待つために割り込みを使っていたり、タイミング取りに
タイマーを使っているかもしれませんし。


少なくとも、仮にブートもままならないような人ならば、これを簡単と
言える資格はないと思います。

Lﾀｿは最近誰彼構わず叩くのが好きみたいだね

×他のタスクの動作を、しばらく完全に止めてしまうような動作でよければ
そんなに難しくは無いかもしれません「けれど、はっきり言って、そういうも
のと NWSOSを一緒にされたくは無いですね。」

○他のタスクの動作を、しばらく完全に止めてしまうような動作でよければ
そんなに難しくは無いと思います。


×V8086モードのタスクを、「未来永劫」、システム全体で一つのみに
限定する場合と、BIOS用のV8086タスク以外にも、V8086モードタスクを
動かせるようにするのとでは全く話が違ってくるでしょう。

○V8086モードのタスクを、「将来的にも」システム全体で一つのみに
限定する場合と、BIOS用のV8086タスク以外にも、V8086モードタスクを
動かせるようにするのとでは全く話が違ってくるでしょう。


×少なくとも、仮にブートもままならないような人ならば、これを簡単と
言える資格はないと思います。

○「必要なし]


以上、添削しました。

>そういうも のと NWSOSを一緒にされたくは無いですね。
ﾜﾗﾀ
ｽｹﾞ-被害妄想
456のレス先見て見れ。

だれもNWSOSの話題なんてしてねーよ
自意識過剰もたいがいにしとけ

こういう人もいるんだね、ここ
勉強になるなぁ

変なのが寄ってくるからブチギレはやめれ。

Lさんの能力はここの住人は認めてるんだから、
下らない*あげあしとり*に突っ込まれる文章は
謹んでほしいですね。
# 知らん人間が見たらどっちが厨か分からんだろう。

OSを作ってみよう
http://pc.2ch.net/test/read.cgi/os/1046271176/l50

能力があれば人間性はどうでもいいのかと小一時間(ｒｙ
そういう甘やかしは本人の為にもならんぞ。


ってか、「あげあしとり」っていうか、LightConeがｹﾝｶふっかけてるように
しか見えん。
まぁ、素でいやみったらしい口調の奴は現実に見かけるけどな。
現実なら胸の内でムカつかれておしまいってのが、2chだからストレートに
叩かれてるだけ。

しまった。468は釣りか？鬱

いや釣りじゃないです。仕事終って早めに帰ったらこんなんだったんで
私が欝になりそうであんなこと書きました。釣りに見えたらスマン。

> 　度が過ぎた知ったかぶりさに、手が震えてまともに文字もまともに
> 打てなかった（泣）。
自意識過剰、駄目の二乗
（知ってる人いるかな...）

>>473
三石琴乃

実機でのFD読み込み・書き込み成功しました。
読み込み完了の割り込みを待たずにDMACをストップしていたのが
原因でした。

荒れてしまったか。申し訳ない。
申し訳ないので、少し言い訳をしていくことにする。

456 は自分ではないけれど、下に続いた組合せが悪かったかな。
NWSOS の BIOS 呼び出し方法が凄いのは押さえている。
そういう人も居るはずだし、そうでない人は放っておけば良いのでは？

それで、454 に
「誰も知らないようなことではないよ？」
て事が言いたかったんだ。

基礎となる仮想8086モードは書籍にも載っている。
そこから他の用件も満たしながら実装することと
書籍を読んで分かった気になることは全く別問題だけれど。

何だかひげぽんが恐縮気味になってきた気がする。

FD読み込みですが
実機ではうまくいくのですがbochsで
FD READ完了の割り込みがこない。。。

うーん。bochs起動時のパラメータでも調べようかな。

>NWSOS の BIOS 呼び出し方法が凄いのは押さえている。
凄いと主張されてることは押さえている、だろ。

455が関係者で中身を実際に覗いたのなら別だがな

FDをBIOS経由でアクセスしてもマウスカーソルがこけないという話だから
かなり優秀な実装と考えていいのでは？

私のマシン全てでVESA関係の問題で起動できないので確認はできないが

なんか、仕事から帰ってきたらすごいことになってるな（ｗ
名無しにまで牙をむき出すとは。。。

名無しの書き込みだから名誉も何もないのである意味どうでもいいんだけど、
一応弁解しておこうかな（ｗ

> 少なくとも、仮にブートもままならないような人ならば、これを簡単と
> 言える資格はないと思います。

ﾌﾟ、ブートくらい開始アドレス0x7c00で512バイト以下のプログラム作ってそいつで
カーネルなり、セカンドステージローダなりよびだす＊＊＊だけ＊＊＊じゃん（ｗ

Ｌって威張ってる割にはこれくらいのことで相当苦労したようだな。
その他の細かいノウハウは試行錯誤するか、よく考えるか、ひげぽんのように
礼儀正しく相談すればいくらでも手に入る。
一応、上で書いた情報だけで１日でプロテクトモードのローダに制御を移せましたが何か？

VGA-BIOSの件もそうだとおもうがな。VGA-BIOSとFDD制御機能が干渉することは
知らんかったので、その罠にははまるかもしれんけど、まじめに取り組めばクリアできる自信はある。

Ｌは他人の文献とか余り読まないようだけど、自分以外人間のの能力を相当過小評価してるらしいな。
ひげぽんの謙虚さを見習って欲しいよ、全く。。。

プロテクトモードのローダじゃなくてカーネル（の替わり）の間違いだった。
ついでに、「自分以外のの」も間違い。

強気な書き込みしてみたのにミスが二箇所も(´･ω･`)ｼｮﾎﾞｰﾝ

くっだらねぇ…
どっから見ても、揚げ足を取り合ってるだけだじゃん
簡単だと思ってる香具師は簡単だと思ってれば良いし
難しいと思ってる香具師は難しいと思ってれば良いじゃねぇの？

>>481
　自慢になるので言わなかっただけで、私の場合、ブートなんて、半日も
かかりませんでした。

　今のMonaの様な状態になるのも数日でした。

　だからこそ、こんなに時間がかかっている人たちに、BIOSを呼び出せるか
どうか甚だ疑問なのです。BIOSを呼び出すのはそれなりに苦労しました。
是非やってみてください。

>>481
>その他の細かいノウハウは試行錯誤するか、よく考えるか、ひげぽんのように
>礼儀正しく相談すればいくらでも手に入る。

うそを言わないで下さい。

実際に、2chで私が本当に必要とする情報を聞いても誰も答えてくれません
でした。というよりも、事実上、答えられる人が存在しなかったという
事だと思ってます。

経験上、この辺で答えが返ってくるのは、「慣れ」の問題で誰でも習得できる
ような知識ばかりです。例えば、「Linuxでこういう事したい時どうするの？」
といった類の質問には、大勢の人が質問者を誹謗中傷・罵倒しながらワンサカ
答えますね。確かに（笑）。

>その他の細かいノウハウは試行錯誤するか、よく考えるか、ひげぽんのように
>礼儀正しく相談すればいくらでも手に入る。

そもそも、全く逆さまですね。

「細かいノウハウ」というのは、「知識」ではないので優秀な人にしか
答えられないし、考える事も出来ません。

貴方がおっしゃっているような、「0x7c00で512バイト」なんて情報の
方が、2chで入手しやすい情報です。

これは、「知識型」の情報なので、知っている人にはすぐに答えられる
からです。

例えば、ハード会社に勤めてる人なら、営業マンでも資料さえ読めば
答えられるでしょう。しかし、資料がなければ全く分からない事です。

2chが有用なのはこういう部分ですね。

ちゃんとした証拠もあります。

Monaのロジック部分が本質的に成り始めてから、higeponさんがつまづいた時、
突破口となるヒントや修正箇所を提示できたのは、ほとんどの場合、
超先生と、私のみでした。

ここから得られる教訓は、私が質問しても答えられるのは、多くの場合、
超先生しかいないであろう、ということですね。
つまり、私にとっては、2chで質問しても、ロジカルな部分やアルゴリズム的な
部分に関しては、ほとんどの場合、意味がないと予想されてしまうのです。

さっきも言いましたけど、「UNIXの特定のコマンドの使い方」などの
情報は、2chでうまく手に入ると思います。

456もLもよー、どれくらいの期間で何が出来たとか、
簡単だの難しいだのとか子供みたいな争いはやめなさいってば。。
みんなでﾏﾀｰﾘしようぜ。

うんだ。２人ともつまらん口論はヤメロ
マタ〜リ

別に問題解決の場というわけではないのになぁ

たとえ無能に見えたとしても、自分の役に立たなくても
マイナーな分野で自分と同じ方面に興味を持っている人がそれなりにいる
ということが窺えるだけでも価値はあると思うが

あとはLスレでやれよ。

てか、もうL来なくていいよ

>>492
　そう思われるんでしたら、今後一切、NWSOSに関する事も、私とすぐに分かる
ような表記(Lタン、LightCone)も、ここに書かないで下さい。

　「NWSOSで出来ているから簡単にできるはず」なんて論調で語られる事が
多いのが非常にうっとうしいのです。

このスレを検索してみても
特に「NWSOSで出来ているから簡単にできるはず」なんて論調で語られている様子はないようですが？
本当に被害妄想じみてきていますよ

>>493
おいおい…ただでさえ春厨が好みそうな事言ってるのにまだ言うかね
「うっとうしい」事が分ったら進んでやると思うんだけどなー
邪魔する為に。

言いたい事は山ほどありますが皆さんのご指摘の通りつまらん口論で、続けるとスレが荒れるので止めておきます。
昨夜はちょっと酔っていた事もあり、無神経ですいませんでした。

なんか一連のやりとり見てるとやおいサークルのＣＰ論争みたいだ

>>456
話のわかる人で良かったyo!
499からは、
「独自にOSを作っているまたは、作ろうとしている人たちのためのスレッド」

　　　　　　　　　　　　　　　　ﾌﾟｼｨｰ
　　　　　　　　　　　;　､ 、; , ; ､　､
　　　　　　　　　　　'⌒`､lili,'⌒`
　　　(`γ')　　　　　　　 |lili|
　　　冫/"　　　　,..-ｰ―,lili,―-､
..　　/ ;;|　　　　／;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;ヽ
　　 | ;;;;ヽ, 　／;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;l　　　 ／￣￣￣￣￣￣￣￣￣￣￣
　　 |　;;;;;;`ｰ';;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;(,,ﾟДﾟ)l　　＜　そう、目クジラを立てるな
　　 `､＿＿＿＿＿＿＿,,,....つ--つ　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　`ー‐---､,,,____　　　 ,.,., ,.,,,ﾉ
　　　　　　　　　　　　"'''''''''''し'''J

>>498
「独自にOSを作っている人たちを応援するスレッド」もな。

500ｹﾞﾄｰ

>>494

>>454-456 あたりを見て勘違いしてるんじゃ

やおい穴がどこにあるかでもめているのかね

ここは独自にOSを作っている人の作業をLたんが妨害するスレッドになりました。

'K'+1 ﾀﾝもがむばれ。

>>503
ﾜﾛﾀ

基本的に評価は他人がするもので、自分がするものじゃない。
他人に評価させたくないなら自慢すんなよ。
誤解されるといけないが別にオプソにしろっつってんじゃないよ。
NDAって手もある。

いつまでもデフォルトの名無しさんにしておくと、
呼びにくいと思うので、これから、わたもちと名乗るので、よろしくです。

OS的な機能の実現に割り込みがほとんどは関係してくると思うので、
慎重に、割り込みを作りたいと考えています。

スタックの使用は下のように使用される。
|　　　　　　　　　　　　　 |
|割り込み前の使用スタック↑ |
|---------------------------|
|EFLAG(4bytes)　　　 　|
|---------------------------|
|CS(4bytes:下位2bytes使用)　 |
|---------------------------|
|EIP(4bytes)　　　 |
|---------------------------|
|ErrorCode(4byte) (*) |
|---------------------------|
|割り込み後の使用スタック↓ |
|　　　　　　　　　　　　 |
(*)エラーコードをpushする例外としない例外がある。

あと EAX,EBX,ECX,EDX,ESI,EDI,EBP,DS,ES,SS,FS,GS
（EFLAG、CS、EIP以外の一般レジスタです）は、
割り込み前の使用状態のままと考えていいでしょうか？
御教授ください。

あと、上のことが正しいとすると、
タスク切り替えを行う場合、割り込みハンドラをCPL=3のコードセグメントに配置させて、
そこで、タスクのスケジューリングを行い、次に実行するタスクへのCS EIP に、
スタック上の CS EIP を書き換えて、iret でマルチタスク実現というのを考えたのですが、
どうでしょう？
特権命令は、タスクゲートを使って、CPL=0にして特権命令を実行後、
元に戻るということにしようかなと思っています。
問題点等ご指摘ください。

>>508
当然、CS:EIP意外のレジスタの内容も切り替えなきゃいけないけど、
それらをコピーするよりはSS:ESP切り替えた方が簡単なので、漏れはそうしてまつ。
ひげぽんはどうやってたっけ？

荒らしうぜえよ。どっかいけ

>>509
そんなかんじです。
プロセス・スレッドはこれから実装しなおします。

先にレスされてしまいました。
Monaのソース読んでなかったのに今気づいた．．．
sourceforge.jp が落ちてるみたいなので、手持ちのものを見てみると、

スタックから取り出して、現在のレジスタを保存、
次のプロセスの以前保存したレジスタをレジスタにロード

私が考えていたものとほとんど同じだ。
またいらない質問してしまったようです。すみません。

SS:ESP切り替えというとどういうものなんでしょう？
良ければ御教授ください。

pusha
esp切り替え
popa
ということですかね。

やっぱりスタックに保存ということだったのですね。
コピーするよりSS:ESP切り替えとあったので、？？と思っていました。
どうもありがとうございます。

>>513-514
確かにスタックに「コピー」してまつね。
誤解させるような表現ｽﾏｿ

>>509
いえいえ、こちらこそアセンブラなんて全然やったことがなかったもので、
アセンブラ使いでおられる方から見れば、
このぐらいですぐ気づくものだと思いますし。

Linux板の悪口がちょっとあったので（誰とは言わんが）。
あそこの板で上がっているスレは中傷通りの状況だけど、
アプリ開発者も結構いて、ドキュメントされていない質問には
丁寧な回答があったりするんだよね。
カーネルコアな人（らしい人）はあまり来ていないみたいだけど、
Linux板の話題の大半はLinuxカーネル以外の話だから仕方が無いです。
カーネルに興味がある人はYLUGのほうが盛んかな？
# スレ違いかつ板違いスマソ。

>>517
召喚の呪文唱えないでくれよ

前に実装したマルチタスクもどきを
きちんと書き直して、カーネルスレッドを実現しようと
計画中です。

それにしてもわたもちさんは、進むのが早い(´ﾍ｀；)

あとはそろそろ気合を入れて
メモリ管理をきちんと実装しないといけませんね。

ページングはなんとしても実現したいです。
ちょっとボリュームが大きいですが何とかやりたい。

いえいえ。遅いですよｗ
実際に作り始めるのに大分、時間かかりましたし。
まだ、割り込み部分に少し手をつけたくらいです。

ページングといえば、私はメモリ保護でも使おうと思っています。
PTE(ページテーブルエントリ)のU/S、R/Wビットを利用したものになる予定。
いつになるやら．．．

＞ぽんたん
CVSではないソース＆バイナリってどこかにおいてあるんでしょうか？

>>522
最新リリース(といっても古いですが)
http://sourceforge.jp/projects/mona/files/
にダウンロード可能なソースとカーネルイメージがおいてあります。

ソースに限れば
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/mona/mona_v1.0/
でdownload tarballでダウンロードできます。

大きく誤ってそうだったら突込みをお願いします。

thread#yieldは、ソフトウェア割り込みで
カレントスレッドのコンテキストをセーブ後
runキューからはずして、どこか別のキュー(sleep?)
でスケジューラー起動。

スケジューラーはそうすると
yieldまたは、タイマ割り込みで起動でいけそう。

ソフトウェア割り込みでやるなら
呼び出し規約を定めて(レジスタに設定する値等）を
システムコールのようにしたらいいのかな。

OSASKスレッドでシステムコールについて熱い議論があったけど
そんなレベルには到底いけそうにないなあ。(しばらくの間)

>>524
runキューの末尾に移すようにすればいいんじゃない？

システムコールの実装方法の方は、余り気にすると煮詰まってしまうから
気にしすぎるのもまずいけど、一応OSASKすれには目を通しておくといいかもね。

>>524
OSASKスレの話は、システムコールの実装ということに関しては、
あんまり参考にならない様な気がする。
x86ならINT nで実装しないとCPL上げられないし。

>>526
特権レベルを上げるには、intとコールゲートの二種類あるんですが、
Windows/Linux/NWSOS のどれもがintらしいです。

コールゲートなら、スタック渡しの際に外側スタックから内側スタックへの
0〜31 DWORDの自動コピーできるメリットがあるのに、intが使われる理由は
なんなのでしょうか。

intは、命令長が短いのですが、それだけが利点でしょうか？

私なりの推測では、intの最大のメリットは、割り込み禁止可能なことです
（IDTが「割り込みゲート」になっているベクタ番号には、intは割り込み
禁止でハンドラに突入してくれます。）。

CALL GATEだと、外側レベルから内側レベルに変わった直後にどうやっても
割り込みENABLE期間が生じてしまいます。これは非常に大きな問題です。

OSを作っていくと、「全ての」レベル遷移時に割り込み禁止の状態で何かを
やっておきたいことはよくありますので。

>>525
こんにちは
>runキューの末尾に移すようにすればいいんじゃない？
そうですね。waitや、sleepはとりあえずなしで
実装してみるのが簡単そうですね。

>OSASKスレの話は、システムコールの実装ということに関しては、
>あんまり参考にならない様な気がする。

ちょっと私には難しすぎました（笑）

>>527 LightConeさん
>CALL GATEだと、外側レベルから内側レベルに変わった直後にどうやっても
>割り込みENABLE期間が生じてしまいます。これは非常に大きな問題です。

なるほどこれは知りませんでした。
確かに割り込まれた痛い処理というのは存在しますね。
勉強になります。

作ってみようスレッドを見て思ったのですが
画面への出力もシステムコールとしたほうがよさげですね。

ロック機構も考えないと。

個人的に難しく感じて、その後自分なりに解決したようなことを書いておきま
したのでご覧下さい。まだ僅かですが、ご参考になれば幸いです。
ttp://homepage2.nifty.com/nowsmart/Japanese/HowToCreateOS.htm
ttp://homepage2.nifty.com/nowsmart/Japanese/NWSOS_Stack.htm
ttp://homepage2.nifty.com/nowsmart/Japanese/Address.htm

>>530 LightConeさん

>個人的に難しく感じて、その後自分なりに解決したようなことを書いておきま
>したのでご覧下さい。まだ僅かですが、ご参考になれば幸いです。

すばらしいです。
私が将来つまづきそうなところが満載でした。
ブックマークさせていただきます。m(__)m

>>LightCone様
まだ、割り込みハンドラの実装で、エラー続出レベルの私には、
遠い話ですが、きっと役に立つと思います。
どうも、有難うございます。

C言語はやっぱり向いていないなぁと感じる今日この頃ｗ
Javaが懐かしい．．．(泣)

>>528
そうですね。waitや、sleepはとりあえずなしで
実装してみるのが簡単そうですね。

一般的には
　run:　　 現在CPUを使用中
　wait:　　他のプロセスがCPUを使ってるので自分の番まで待機中
　sleep:　ファイル入出力待ち・プロセス間通信待ちなどの外部イベント待ち
ってことなので、runとwaitは必須。
sleepは他のプロセスやFDD等の外部デバイスとの通信をしなきゃ不必要かも。

と、嘆いても仕方が無いので、

Waba(Javaサブセットの組み込み用インタプリンタ)
ttp://www.wabasoft.com/
ttp://www.cc.yamaguchi-u.ac.jp/~shingo/WabaWorld/index.html

これを、そのうち載せたいなと考えています。
スピードは気にしないでください．．．

>>527
割り込み禁止にする必要があるかどうかはOSの設計次第です。
FreeBSDのシステムコールや例外はトラップゲートだし、
NoNameのシステムコールや例外もトラップゲートです。
反対にEseBTRONというOSではシステムコールや例外は割り込みゲートです。
この違いは割り込み処理をプロセスのコンテキストの延長と見るか、
独立したコンテキストとみるかの違いでしょう。
NWSOSの場合はどうして割り込みゲートを使っているのでしょうか？

実はL様はK氏より他人に親切かもしれない、と思ってみるテスト
厳しいお言葉もライオンが子供を谷に突き落とすようなものかも...

>>535
>NWSOSの場合はどうして割り込みゲートを使っているのでしょうか？

IA32は、もともとの設計では、内側レベルを呼び出して、外側レベルへ戻って
くることしかサポートされていません。ひとまず、この呼び出し方向を
「順方向」と呼ぶことにします。

NWSOSでは、「逆方向」の呼び出しもサポートしています。

IA32では、TSSにある各レベルのスタックポインタが遷移時に自動的に変更
される事は有りませんので、逆方向に呼び出してまだ帰ってこない間に、
別のシステムコールを呼び出すと、レベル0のスタックが上書きされてしま
います。

これを避けるためには、レベル遷移時する時は必ずTSSにあるスタックポインタ
を調整する必要があります。

その間、どうしても割り込みを禁止する必要があると思います。

「割り込み禁止」というと、リアルタイム制を損なう感じがするかもしれま
せんが、レベル遷移時にはもともと僅かではありますが、CPU内部で割り込み
禁止期間がありますので、その延長と考えれば、その期間が少し長くなった
と考えることが出来ます。

なるほど「逆方向」の呼び出しですか。
面白そうですね。非常にためになるお話でした。
よろしければ「逆方向」の呼び出しがOSの中でどういう風に
使われているかもついでに教えていただけませんでしょうか。
NWSOSのページの情報からデバドラはDPL1で動くみたいなので、
カーネル（DPL0）からデバドラを呼び出す時に使ったりするので
はないかと推測しているのですが。

>>446
plane pixel方式のノウハウなんてのはDOS時代の古代の技術だから
今から覚えるよりとっととpacked pixelで進めるのは良い判断と思われ

しかしANDしてORみたいなplane pixelの古代の技術が
VESA & packed pixelモードで失われたかと思ったら
windows GDIで復活し、
DirectDraw & ColorKEYで再び失われたと思ったら
DirectDrawより自力描画のほうが速いよ！となって条件分岐より数ピクセルまとめてANDしてORが復活し
DirectX8(7だっけか？）で2Dでもポリゴン&アルファチャンネルだ！となって再び失われつつあるが
いつ復活するかわかったものでないので基本として押さえとくのはいいかも

>>539さん
描画ライブラリの作成が簡単になるようにということで、
Packed Pixel形式が使える方を選択しましたが、こちらで良かったようで
一安心です。ありがとうございます。

Packed Pixel、Plane Pixel形式、世代交代が激しいようですね．．．
この方面もさっぱりわからないので、参考になります。

>>535
もれは例外と割り込みは別の概念だと思う

ﾒｸﾞﾀｿもPacked Pixel実装してみたらフォント描画が禿しく単純になったょぅ。。。

でしょ〜
プレーン方式を使ってた時は、私なんかちょっとした描画でも混乱してました。
タイマー、キーボード割り込み実装したので、簡易マルチタスク機能(というか、
ほとんどスレッド程度なんだけど．．．)をつけたらアップする予定です。

と思ったけどﾒｸﾞﾀｿのﾌｫﾝﾄ描画は事前処理がいろいろあるから複雑に見えるだけで
描画ループはﾊﾟｯｸﾄの方が複雑かもしれん・・・

Packed PixelはBitBltで真価を発揮しそうやね

１byteで、８ドットというのが、慣れてないためか混乱してしまいます。
今まで、Packed形式しか使ったことが無かったもので．．．

>Packed PixelはBitBltで真価を発揮しそうやね
ですね。

レスが大阪弁ですけど、大阪人ですか？ｗ

お嬢は無国籍DAYOヽ(｀ー´)ノ

宇宙人？とか言ってみるテスト

前々から思っていたのだが、ディスク上にファイルシステム構築するのではなくて、
今では256MB〜あるメモリ上にファイルシステムをエミュレートできないのかな？
でも、作成したファイルなどは再起動したら消失してしまうだろうが。。。

検討はずれのこといってたらごめんなさい。

>>548
RAMDISK?

>>549
RAMDISKって聞いたことあります。
やっぱり、二次記憶のディスクより、相当高速アクセスできるんですよね・・？

>>548さん
いえ、私はそういう方向で行こうかな〜と思っています。
やっぱり新しいハードディスクはなかなか用意できないということで、
すべてフロッピーディスクで済むようにと考えています。
保存したければ、終了時にフロッピーに書き込みでもいいかなと思います。

>>548
unix系だとmfsってよばれててインストーラなどで使われてることが多い。
作っておくと後で役に立つ可能性も高いので、最初に実装するのもいいかもね。

>>551

最近ではネットワークも拡大・高速化してますので、
たとえ、1FDのOSであっても、RAMDISKを使えば、ネットから数十MB
の動画ファイルをダウンロードして観ることも可能になりますね。
（ネットワーク対応、大容量RAMが必須になりますが。）

結構魅力的かも。。。
そういえば、RAMDISKでもFATとかいうのかなぁ。。。

mfs=メモリーファイルシステムでしたか。。。

UNIX系では/tmpとかに使われてるみたいです。

実装方法はまだ全然考えていません。
その頃になれば、色々調べて実装したいと思います。

>たとえ、1FDのOSであっても、RAMDISKを使えば、ネットから数十MB
>の動画ファイルをダウンロードして観ることも可能になりますね。
夢を膨らませてもらうのは、非常に嬉しいのですが、
あまり期待しすぎないでくださいｗ

packed時代のplaneテクその２

planeだと8ドット単位の処理が基本になる。それ以外だと両端と中央の処理を分けたり、シフトしたりと「複雑」になる。
packedだと1pixelに1回でアクセスできて楽、かというと、速度を考えると話はそこで終わらない。

例えば8bit/pixelで考える。フツーならbyte*で処理するところだ。
これを例えば32bit/4pixelと考えてuint32*(適宜読み替え)で処理する。
そーするとplaneと同じく複雑になるが、メモリアクセスが1/4になる。キャッシュしない（メモリアクセスの遅い）VRAMにおいては、この差は大きい。
トータルでは４倍-「複雑な処理部分」の速度だ．

全ての描画命令に「複雑な処理」をつけるのはウザいが、blitやfillなど多用されるものにつければ効果は大きい。

#OSカーネルの話と激しくズレてるが

>>556さん
御教授ありがとうございます。

>OSカーネルの話と激しくズレてるが
気にしないでください。

実は、Graphics_cls でその手は使っています。
最初は、素直に byte* へキャストしていたのですが、
強引に unsigned int* へキャストしてみたら、
問題なく動いたので、Java等を使っていた私にしたら、
こんなのありですか．．．な感じでしたｗ

仮想ページに割り当てるための物理ページが足りなくなった場合にページアウト
すべき物理ページを選択するアルゴリズムについて悩んでいます。

基本的に、LRU方式, ワーキングセット方式, FINUFO方式があるようですが、
FINUFO方式が選択が一番高速になると思います。

しかし、この中で一番理想的なのはワーキングセット方式なのですが、
「ワーキングセット」を高速に求めるアルゴリズムが存在するのかどうか
分かりません。

どなたかアドバイスできる方いらっしゃれば、是非教えてください。

簡易カーネルスレッド実装とともに
システムコール実装テストをしようと目論んでいます。

システムコール呼出し手順はこんな感じで考えています。
■ユーザーモード想定
(1)システムコール用構造体に引数を設定
(2)(1)の構造体へのポインタをレジスタにセーブ
(3)int
■ここからカーネルモード想定
(4)レジスタから構造体へのポインタを取得(必要であればカーネルからアクセス可能なように変換)
(5)引数妥当性検討(今回はここは軽め？）
(6)処理実行
(7)必要であればリスケジューリング

システムコール自体はシステムコール構造体で管理しようと思っています。
引数の数・前処理・後処理・システムコール実体など。。。

>>559
引数がレジスタで渡せるうちはレジスタで渡したほうがいいんじゃないかな
将来的に仮想メモリをサポートして、(2)と(3)の間にtask switchがおきて(1)がswap outしたとすると、
(5)の前にswap inする必要がある。少なくともチェックは必要。
まあイマドキのCPUなら無視できる負荷かもしれんけど

>>553
まったくｽﾚ違いで恐縮であるが、
http://www.jumptec.de/product/data/emb_int/webasdisk/webasdiske.htm
みたいなものを使えば、OSのデバッグは楽チンになるのだろうか。

>>558
ちょいと調べてみたんだが「ワーキングセット方式」つーのは
突き詰めると実装はLRU（またはその近似）と同じ、という気がする

>>562
　言葉の遊びみたいになってしまいますが、「OS論」と呼ばれる学問では、
「LRU方式」と「ワーキングセット方式」とは、一応区別されていて、
いずれも、「最も最後にアクセスされたページをページアウトの候補」
とすると言う点は同じなんですが、前者は記録に用いられる時間が
「システム共通時間」なのに対し、後者では「タスクローカルな時間」
である点と、ワーキングセットアルゴリズムの場合、最近の
「利用頻度（N回分の調査記録を利用)」も考慮されるが異なって
います。


なお、「システム共通時間」で測定する場合、タスクの「活動度」が低いと
メモリアクセスがほとんどされていないように見えてしまうので、不公平に
ページアウト対象になりやすくなってしまうのではないでしょうか。

逆に、「タスクローカルな時間」で考慮されるならば、活動度が低くても
「活動している時間に対するそのページにアクセスした時間比率」が
中心的な役割を持ってくるため、そういう問題が起こりにくくなると
考えられます。

>>562

ワーキングセットの推定をするには将来の処理の動きを読まなきゃいけないけど、
それをするには処理終了までのシュミレーションをしなきゃならないけど、
それは計算機にさせるべき処理そのものなので、それが完了した時点でワーキングセットの
推定は無意味になるので、原理的に無理。
つまり、計算量の問題ではない。

ってことで、現実的な解法として過去の挙動からワーキングセットを推定する方法が
いくつか提案されているけど、その一つがＬＲＵ方式。

って、説教たれてる割には、ＬＲＵ方式の効率的な実装方法がわからなくて悩み中。
処理時間、メモリ使用量、ＬＲＵの厳密さ、これらの三つのトレードオフを巧く処理できない。

　今考えている話は、仮想記憶における、「置換アルゴリズム」と言われる
ものですが、日本のOS研究では、ネットや本で軽く見る限りですが、
「なるべく最適な廃棄ページを見つけるアルゴリズム」、に対して関心
が行っているようです。

　しかし、物理メモリが大量に搭載された現状で、実際にOSを作る際には、
「如何に高速にページの使用統計を取るか」の方が重要の様に思います。

　例えばの話、IA32のOSでは、タイムスライスのために、10(ms)程度の
周期のタイマー割り込みを使います。このタイマー割り込み内でページの
アクセス統計を取ると考えてみると、256MB の物理メモリを一杯に使った
状態では、厳密な統計を取るなら、最悪、256MB/4KB = 65536 ページ分
ものページエントリーの調査が必要になります。

つまり、秒間100回も 65536 回の forループ処理をバックグラウンドで
行わなくては成らなくなるということです。

しかも、同じCPUに、メモリを多く詰めば益々自体は悪化する傾向が
あります（なんとかしなければ。）。

>>564
>ワーキングセットの推定をするには将来の処理の動きを読まなきゃいけないけど、
>それをするには処理終了までのシュミレーションをしなきゃならないけど、
>それは計算機にさせるべき処理そのものなので、それが完了した時点でワーキングセットの
>推定は無意味になるので、原理的に無理。

言葉のあやになってしまうのですが、一応、ワーキングセットの厳密な意味は、

t0 <= t < t0 + τ

の間にアクセスされたページの集合と言う意味で、それ自体の計算は可能です。


むしろ、IA32では、厳密な LRU の方が無理です。統計処理を行う時間間隔で
曖昧さが出ます。つまり、10(ms)毎に統計を取るならば、10(ms)の誤差が
出ると言う事です。


おっしゃりたいのは、「OPTアルゴリズム」の方ではないでしょうか。そちらは、
絶対に実現不可能です。証明は簡単です。未来にいくつかの可能性がある場合、
現時点で最適な選択を行う事は絶対に無理だからです。

速度を度外視した場合の厳密なワーキングセットの具体的な計算法を書いて
おきます。

まず、タイマー割り込み内で、物理ページが割り付けられているページエントリ
のアクセスビットを調査します。調査が済むと0にします。

そして、各ページエントリに対応して例えば1BYTEの統計情報を対応させます。
IA32では、ページエントリにはそれだけの余地がないので、別の場所に
入れます。今、k 番目のエントリのアクセスビットを参照し、accessだと
すると、

page_entry[k]->m_bit <<= 1;
page_enetr[k]->m_bit |= access;

とします。

これで、m_bit の 1 のビットの数が、直前の 80(ms)の間のページ k の
アクセス頻度になります。

このアクセス頻度が一番小さいページをページアウトするというわけです。

しかし、この処理は、256MBの物理メモリだと、最悪、秒間 100 * 65536 回の
繰り返し処理が必要になると思います。

>>567
＞page_entry[k]->m_bit <<= 1;
＞page_enetr[k]->m_bit |= access;
それくらいの機能はCPU(MMU)に積んどけってことか。

　物理メモリーを、256 MB も(?)積んでいる機種のCPUは、恐らく 1GHzは
あると考えるのが妥当だという前提に立つと、1エントリの調査に x クロック
必要だとすると、

x * (100*65536)/(1024*1024*1024) = 0.006 x

これが、この処理が必要とする時間の全CPUパワーに対する比率になります。

x = 10 として、6%。

IA32だと、ページテーブルエントリのアクセスビットだけでなく、
ページディレクトリ・エントリのアクセスビットもあるので、そちらで
普段は「カリング」できるので、このアルゴリズムでも余り問題ないの
でしょうか？？

しかし、FLATモデルだと、複数のページディレクトリがあるので、そんな
ことで済まないような気も。

＞普段は「カリング」できるので、このアルゴリズムでも余り問題ないの
＞でしょうか？？
http://home.att.ne.jp/theta/yasunori/linux/LinuxMM/LinuxMM33.html
Linux2.2 on x86で、ちと古いのかもしれんが。
Lﾀﾝがタイマ割り込みで実行したい処理に相当するのは、これかなぁ。
知ってたらごめんね。

>>568
ＭＭＵつーか、メモリに載せなきゃいけない罠。
メモリ全体にこんな機能つけけるのは無駄極まりないけど、
ページテーブル専用の特殊メモリをつけるってのもありかな？

といってみたけど、プロセス数がその特殊メモリの容量に制約受けそうで嫌だな。

L氏へ
>　しかし、物理メモリが大量に搭載された現状で、実際にOSを作る際には、
>「如何に高速にページの使用統計を取るか」の方が重要の様に思います。

　そのとおりです。僕はこれについてうまい方法を既に考えています。僕の方法
では、非常に効率的に使用統計が取れます。もし興味があればOSASKスレッドで
、「OSASKのLRU管理アルゴリズムについて説明してほしい」と書いてください。
L氏が興味を持たなくても、他のどなたかが興味を持たれれば、その方が書き込
んでくださってもかまいません。

　特徴をかいつまんで説明すると、僕の方法では、タイムスライスごとの定期的
な調査が不要です。それでも十分に詳しい(むしろ定期的検査よりも詳しい)使用
統計が取れます。もっというと、PTEのアクセスビットやダーティビットを参照
する必要すらありません。

>>572
FLATでも使えるんですか？

>>559
開発段階においても、(5)は重要。デバッグが楽になると思う。

システムコール用構造体を使うと、アドレス計算の分だけ処理が遅くなる思う。
しかし、誤差の範囲と言えるかも。
ただ、ユーザスレッドや非同期IOなどの実装が楽になるかもしれない。
>>560の言ってる事が起こり得るから、システムコール用構造体はswap禁止とかも有り。
しかし、システムコール用構造体が増えすぎると結局swapが必要になりますね。

やっと、わかりそうな内容になってきた感じなので素人考えを初書き込み。

>>572
お久ー。

>>571
漏れが勘違いしてる可能性大だが、
＞といってみたけど、プロセス数がその特殊メモリの容量に制約受けそうで嫌だな。
統計を残したいのは、物理メモリに読み込まれてるページへのアクセス有無だから、
プロセス数はあまり関係ないと思う。
単一のプロセスが乗っかってる・使ってるページをいつもまとめてページイン・アウト
するわけじゃないから。
>>569
＞普段は「カリング」できるので、このアルゴリズムでも余り問題ないの
ページが4KB単位であること自体が一種の「カリング」なんだろうよ。
256MBもの物理メモリを4KB単位1枚ずつでちまちま管理してたらだめだめだー、ってことかなぁ。

>>576
>ページが4KB単位であること自体が一種の「カリング」なんだろうよ。
まあ、そうなんですが、IA32では、最低でも二段階のページ機構が
あり、4KBのページを1024個集まったものをページテーブルと言い、
1024個のページテーブルへのポインタを集めたものをページディレクトリ
と言います。一つの項目の事をエントリと言い、エントリが集まったものを
テーブルと読んでいます。
ページディレクトリには、1024個のページテーブルへのポインタが格納
されているのですが、NULL に相当するポインタを書くことが出来て、
そこに対応するページテーブルが存在しない事を意味する事が出来います。

あるページ P にアクセスがあると、該当するページテーブルの中の
該当するエントリの A ビットが1にセットされます。もし書きこみ
アクセスだと、D ビットも1にセットされます。CPUが勝手に0にリセット
することはなく、0にしたいときは、ソフト的に行います。

今説明したのは、ページテーブルのエントリのことですが、実は、
対応するページディレクトリのエントリにも、A ビットがあり、そこも
同時に 1 にセットされるということです。

ですので、ページテーブルのAビットを参照する前に、
ページディレクトリエントリのAビットで大まかに調査を省くことが
できるというわけです。#569では、これを「カリング」と表現したわけです。

なお、ページ・ディレクトリ・エントリを、PDE、ページ・テーブル・エントリを
PTEと呼びます。

　IA32の初代ではこのように「二段階」のページ機構を持っていたのですが、
最新のIA32系のCPUでは、三段階にすることも出来ます。

　また、ページのサイズをもっと大きくする事(たしか、4MBと2MB)が出来ます。


　なお、メインフレーム用のCPUでは、A BIT, D BIT 相当のBITだけではなく、
「アクセス時間」などの統計情報も PTE にCPUが書き込んでくれるものが
あるそうです。

>>572
　もしかして、既に実ページが割り当てられているページを、
アクセスした瞬間にページ例外ハンドラに通知させるために、
P BIT = 0 にしますか？


　それとも、「最もページアウトするべきぺージ」を探すのを諦め、
とにかく、以前調査した時に A = 0 にしておいて、今回の
調査で、A = 1 になっているページを、リング状に探しますか？
ちなみに、これは、FINUFO(First In Not Used First Out)
アルゴリズムというそうで、Linux 2.2で使われていたようです
（Linux 2.4 では良く知りません。）。

>>578
わかりやすい説明ｻﾝｸｽ。
＞　なお、メインフレーム用のCPUでは、A BIT, D BIT 相当のBITだけではなく、
＞「アクセス時間」などの統計情報も PTE にCPUが書き込んでくれるものが
＞あるそうです。
物理メモリよりも大きい仮想メモリを基準に据えれば、そうすべきなのかもな。
CPU設計はOS設計と切り離しちゃだめだと再認識。（←だからなんだよ）

ところで、Lﾀｿは、ページングアルゴリズムの実装の工夫で何を解決しようとしてる？
・スラッシングの防止（必要メモリが物理メモリを超えた途端ﾀﾞｻｰ）
・トータルパフォーマンスの向上（曖昧だな）

それとも、単に、
・最低限のページングアルゴリズムを実装した時のパフォーマンスダウンを抑止
したいだけ？ワーキングセットが理想的なのに、それを実装すると、理想に反して
パフォーマンスが落ちるのに耐えられないのか。


OSがどのように使われるかで最適（と思われる）ページングアルゴリズムは
異なるよな。
例：
・RTOS→ページングはハードリアルタイム性を失う原因となるので法度
・サーバOS→多数のプロセスが間欠的に動作。トータルで必要なメモリ大
・ビジネス用途→フォアグラウンドのプロセスを快適に動作
・マルチメディア→RTOSほどでないにしろソフトリアルタイム性を実現

学問的には、どんなサイズでいくつくらいのメモリの塊が必要かの分布の分析に
なるだろうが、味気ないので誤解をおそれず上記のように書いてみた。
こいつらのトレードオフの重心をどこに置く？それともダイナミックに対応したいのかな。

>>580
「ダイナミック対応」．．．おもろいかも

プロセスごとに変えるといいかも。
最初はリアルタイム用のモードで動かして、必要ないようだったらページングをはじめるとか。

>>581
＞最初はリアルタイム用のモードで動かして、必要ないようだったらページングをはじめるとか。
マルチメディア的なリアルタイム（せいぜいソフトリアルタイム）なら、可能。
ハードリアルタイムは難しいというか無理ぽ。

OSASKのちょっと一言ページを見ました。
実は#279でも書いていた通り（ちょっと一言ページでも私が気付いている
事には触れられていましたが）、本当は、実ページを割り振っている
ページに対し、アクセス統計（+書きこみフラグ）を取る目的だけのために
存在ビット(P)を0にすると言うアイデアは、置換アルゴリズムについて考え
始めた当初から気付いていました。

ただし、私のアイデアは、ワーキングセットアルゴリズムでの、
W(t0,τ)を厳密に高速に求めることができるような方法です。

例えば、W(t0,τ)を、10ms に一回調べたいならば、10ms周期で発生
させるタイマー割り込みの中で、調査対象のページのPを全て0にします。
ただし、このアルゴリズムでは、P=1のページはリストに保持できるので、
そのリストを利用してP=1のページだけをP=0にして、もともとP=0だった
ページを初期化するための時間は必要は有りません。

このようにすると、ページにアクセスされると必ずページ例外が発生します
ので、例外が起きたページをリストに加え、同時に、P=1にしておきます。
すると、次のタイマー割り込みまでには、10msの間にアクセスされた
ページのリストが出来上がります。

このリストの過去N回分から、10N (ms)分のワーキングセットを求める
のは容易です。


ただし、速度が少し心配なのと、コピー・オン・ライトや、
オン・デマンド・ページング、プリ・ページングなどと合わさった時の
事情を考慮しなくてはならない部分がちょっと心配です。

>>583 訂正
#279--->#579

>>583
なるほど。
AとかDのフラグをチェックしてアクセス/書き込みがあったかどうかを調べると、
コストがかかる
->アクセス/書き込みが起こったときに例外を起こさせて（しかも1周期に1回だけ）
A,Dフラグをチェックするコストを節約するわけだな。

で、ページ例外のコストはどれくらい？

少しだけですが、今着目しているアルゴリズムを使う場合のページテーブル
の様子を細かく見てみます。

P=0 のページには、最低でも次のような種類があることになります
（まだ他にもあるかもしれません。）。

1. 予約されていない不法なページ（このときは、例外報告後、タスクを終了）
2. ディスクにページアウトされているページ
3. アクセス統計を取るためにP=0にされているだけで、本当は実ページが
が割り振られているページ
4. オン･デマンド・ページングのために予約されているページ。


しかし、3の状態のページは、P=1にしたら、即座にPTEとして利用出来る
ことが好ましいため、上記の4つの状態を区別するビットは、"AVL"の
3BITに置く事になると思います。ただし、1BITだけあれば、3の状態
であるかどうかだけは十分判別できますので、AVLは1BITだけ利用すれば
十分で、他の三つの状態のときは、PビットとこのAVLの1BIT以外の残り
30BITは、全て「ソフトウェアで利用可能」ですので、それを
利用すれば十分区別できます（ただし、2の状態のときのディスク上の
ページアウト装置番号とスロット番号を保持できる予知は必要ですが、
残り29BITが利用出来ます。）。


良く考えてませんが、初期化されないメモリを確保した時には、
オン・デマンド・ページングの状態にするのが良いかもしれません。

>>585
>で、ページ例外のコストはどれくらい？

物理ページが足りなくなる事自体、頻度は余り多くありませんので、
そのためだけに普段から統計を取る重たい処理を行い続ける方針
が正しいかどうかです。

ようするに、ほとんど起こらない事のために、普段から無駄に準備を続けている
ということです。

正確なLRUアルゴリズムや、ワーキングセットアルゴリズムを行うためには、
ハードウェアからの支援が必要だと諦めてしまう方が得策かもしれません。


IA32では、FINUFO アルゴリズムでいいのかも。

>引数がレジスタで渡せるうちはレジスタで渡したほうがいいんじゃないかな
>将来的に仮想メモリをサポートして、(2)と(3)の間にtask switchがおきて(1)がswap outしたとすると、
>(5)の前にswap inする必要がある。少なくともチェックは必要。
>まあイマドキのCPUなら無視できる負荷かもしれんけど

システムコール実装の経験がないので
どちらが良いのかわからないのですが
例えばシステムコールに文字列を渡すときはレジスタ経由でも
結局は構造体のようなものを介さなければいけないですよね。
迷います。

開発段階においても、(5)は重要。デバッグが楽になると思う。

>> 574
>システムコール用構造体を使うと、アドレス計算の分だけ処理が遅くなる思う。
>しかし、誤差の範囲と言えるかも。
>ただ、ユーザスレッドや非同期IOなどの実装が楽になるかもしれない。

そうですね、システムコール用構造体を使用するメリットは大いにありますよね。
ありがとうございます。

>>587
＞ようするに、ほとんど起こらない事のために、普段から無駄に準備を続けている
＞ということです。

linux2.2のカーネルについてのリンク >>570
を見ただけだが・・・

メモリの用途＝ヒープか、コードか、マップトファイルか、などによって、
どうでも良いメモリは（物理メモリが空いてても）積極的にページングされてもいいと
思うのだが。

そうでなくても、 >>569 で検討した数値
＞ x = 10 として、6%。
よりもコストを節約できるなら、「やってみる価値」はあると思う。
他との絡みもあるからそれを今決めるのは大変だろうな。


これはつまらない提案だが、ページングとか、タスクスイッチのアルゴリズムは
簡単なシミュレーションモデルで実装前に検証した方が良くないか？
研究論文関係だとシミュレーションの結果だけ、というのも多いんだろ？（←想像）

後で手戻りできなくて、後悔しつづけるより、今のうちにちょっと苦労して
シミュしておくのは、悪くないと思わない？
パラメトリックなモデルにしておけば、
・メモリ速度
・（ページアウト先の）HDD速度
・物理メモリサイズ
・プロセス数と使用メモリのサイズ
などの影響もある程度（＝傾向）見積もれて、動作報告との照合が可能になるだろう。
あんまり凝るとかえって手数がかかって意味ないが。

　「ランダム・アルゴリズム」がCPU内部のキャッシュアウトに使われた
ことがあるそうです。

　そんなものでも、それなりの性能は得られる、と書いてありました。


　しかし、そもそも、ディスクにスワップアウトした時点で、余り性能なんて
期待しないですよね？　運悪くスラッシングがおきても、ランダムに
ページアウトしていれば、そのうち最悪の事態は回避されると思いません
か？

　故意にやろうとするほど、余計に自体が悪くなる事ってありますよね。

　ひげを剃る時、鏡を見ながら剃るより、適当に剃った方がうまく行くと
聞いた事もあります（笑）。

LightConeは、自分が躁鬱のような状態であるということの気づいて
いるんでしょうか。
本人以外はこのスレを読めば分かるけどね。

　何回も連続してスラッシングが起きるようなときって、ページ単位で
置換する限り、どんなページをページ・アウトしても大抵駄目なんじゃない
かなあ、と思いますね。なぜって、そういう時は、実ページが割り当てられ
ているページ全体をまんべんなくアクセスしてるかもしれないからです。

　そんなときは、どれか犠牲となる（？）タスク全体をディスクに
吐き出してしまうしか方法がないように思いますね。


　今考えている方法は、どうも、実際にやるのを躊躇してしまいます。

　だって、メモリを一杯積んで、絶対スワップファイルが必要ないとき
も、（不在）ページ例外だけは日常的に起きるなんて、話が変だと
思いませんか？

躁だね。

最新版アップしました〜

アドレス書いてないし．．．(汗
ttp://www.geocities.co.jp/SiliconValley-PaloAlto/6802/os_06.zip
色々追加したので、大分時間がかかりました。

何が追加されたのか書いてほすぃ

ReadMeのコピーですけど．．．
プロテクトモードでの実行
Packed Pixel形式での描画
文字出力用メソッド等、少数の描画用メソッド
簡易スレッドの作成、実行、停止
(メモリ保護を実装してプロセスにする予定なので、名前はProcessになっています)
イベントシステムの簡易実装
(キーイベントのみ手抜きで作ってみました)
こんな感じのことが実装されました。

>>592
＞　だって、メモリを一杯積んで、絶対スワップファイルが必要ないとき
＞も、（不在）ページ例外だけは日常的に起きるなんて、話が変だと
＞思いませんか？

確かに変だけど、
・理想的なアルゴリズムを実現するには
・IA32ではハードの支援が足りなくて
・コスト節約のためにわざと例外を起こす
ということなら現実解としては成り立つじゃないか。

理想的なCPU、理想的なOS、理想的なアプリが現実から乖離しているからこそ、
各種パフォーマンスのトレードオフを実装技術で調整するんだろ。
それを逆手に取った使い方とかアプリに対してはそりゃ無力だろうが。
環境やアプリをしぼればしぼるほど、実装技術はいらんだろうよ。
大型コンや、RTOSみたいにな。Lﾀﾝはそれで満足か。

>>591
このスレ見てみ、ちゃんと分かってるよ

OSASKとNOWSMART-OSを褒めちぎるスレッド
http://pc.2ch.net/test/read.cgi/os/1031377826/

>>599
ふーん、かなりイタいね、K,L両氏とも。
日本にはこんなﾔｼらしかいないのか、と思うとかなり
ｼｮﾎﾞｰﾝ・・・。ソフト分野でアメ公追い越すのはだいぶ
先の話だな・・・。それとも現在においてOS制作ってーのは
趣味の領域にすぎないことの現れなのか・・・。

歴史上、偉人や天才と言った人はみなどこかキレてる。

Win32は基本的には64KB単位で処理しているらしいね
GetSystemInfo APIで得られる値なので真偽は不明だけど

16ページまとめることでどの程度性能向上するかは不明だが
少なくとも必要なワークエリアサイズは抑えられるということかな

>>602は間違い
今調べたら普通に4KB単位だった

　今考察中の置換アルゴリズムえで測定周期をT、ページ例外の単位時間あたりの
平均発生頻度をz(T)とすると、ほぼ、

z(T) = (1/T)*h(T)
h(T) = (時間Tの間にアクセスされる仮想ページの平均枚数)

になると思います。また、メモリ・アクセスに局在性が全く無いときに、
h(T)の上限が決まるだろうと予想されるので、恐らく、

h(T) <= (T/T0) * h(T0)

に近い関係式が成り立つと思います。すると、

z(T) <= h(T0) / T0

という式になり、z(T)は、Tによらない右辺の様な式により大まかな上限が
決まることになると思います。z(T)は、”単位時間”あたりなので当然の
結果です。

T0はなんでもいいので、T0=1とすると、

z(T) <= h(1) = (単位時間あたりのアクセスされる仮想ページの平均枚数)

という結果が出ます（ある意味、当然の結果ですね。）。

[続き]
つまり、ページ例外の秒間発生回数は、秒間ページアクセス頻度以下になる
ということで、メモリアクセスの局在性があれば、それより少なくなるとい
うことになります。

今考えているのは、「物理メモリが不足した時にページアウトするページを
選ぶ方法」です。256MBの物理メモリを積んでいて不足する状況を考えると、
行列計算などでは、ほぼ物理メモリ全域をアクセスすると考えられるので、
256MB / 4KB = 64K枚のページにアクセスする可能性が高く、ページ例外
発生頻度は、秒間、最悪で65536回になると思います。

逆に、テキストエディタなどでは、メモリアクセスの局在性が強いので、秒間
数枚程度になると思います。

つまり、アプリケーションの種類によって例外発生頻度の変動が大きくなると
思います。

もしかしてラージページって知らない？

実は、上の議論では、T>=T0と言う条件があって、本当は、

T1 < T < T2
に対し、

h(T2)/T2 <= h(T)/T <= h(T1)/T1

になると思います。定義:z(T)≡h(T)/Tにより、

z(T2) <= z(T) <= z(T1)

つまり、平均的な秒間例外発生頻度は、測定周期が大きいほど小さくなると
いう、これまた当然の結果が得られます。

コンピュータって自然科学を扱うより遙かに簡単だね。

>>585
>>604 >>605 >>607
ページ例外の頻度（コスト）は定性的にしか取り扱えないから、躊躇しとるわけやね。
一方、統計情報の収集を素直に実装した場合のコストは定量的に求まる。
統計が嫌いなら、そもそも比較すべきでないな。

しかし敢えて指摘すると、仮想メモリ機構自体が「アクセスの局在性」に依存してるよな。
キャッシュの類も同じだ。

つまり、
＞行列計算などでは、ほぼ物理メモリ全域をアクセスすると考えられるので、
という前提は、仮想メモリ機構を利用する根拠を台無しにする。

いくら統計が嫌いでも、
「ある頻度で、巨大行列計算が発生すると・・・」と捉えなければ意味が無い。
アプリのモデル化だ。仮定したモデルに近い状態でのみ想定したパフォがでるだろう。
想定外ではちゃんと動かないだろう。それは「いじわるテスト」だ。
ある程度の「いじわるな状況」でもかろうじて動作しつづける必要はあるだろう。
堅牢性や信頼性と呼ばれるかもしれない。

もともと足りない物理メモリ量をパフォの低下というコストを支払ってで実現するのが
仮想メモリなんだろ。実装技術で補えるのは、せいぜい低下するパフォをできるだけ抑えることだけだ。
いくら工夫しても、巨大行列演算は物理メモリ量に依存する。演算のアルゴリズムを変えて、
メモリ使用量を減らした方がよほど性能向上が期待できる。

＞もともと足りない物理メモリ量をパフォの低下というコストを支払ってで実現するのが
おっと、これは単一プロセスを仮定してたな。
多数のプロセスを動かすためにも仮想メモリは必要ﾀﾞﾅ。
もっとも、その場合は「タスクスケジューラ」と総合的にパフォを決められるよな。
物理メモリが足りないことを、この2つの場合で分けて考えてるよな。

>>そうですね、システムコール用構造体を使用するメリットは大いにありますよね。

それを突き詰めると「メッセージング機構」になるんだと思われ

>>611さん
>>>そうですね、システムコール用構造体を使用するメリットは大いにありますよね。
>
>それを突き詰めると「メッセージング機構」になるんだと思われ

なるほど。
ここで言うメッセージ機構というのはシステムコール(または別のサービス）
をメッセージという抽象化された方法でサーバ(OS)に要求するということですよね。

システムコールをメッセージ機構で実装した場合、どのような実装例があるのでしょうか。
マイクロカーネルへとつながるところでもあるので興味があります。

>>612
QNX

私も、そろそろ簡易スレッドを実装したので、カーネルモードと
ユーザーモードの分離のため、システムコールを実装してゆきます。
データの渡し方には、レジスタ渡しと構造体渡しがあり、利点、欠点など、
丁寧な解説ありがたく参考にしています。

さまざまな OS のファンクションコール方法
Windows NT int 2eh eax にファンクション番号
FreeBSD int 80h eax にファンクション番号。パラメータはスタック。
Linux int 80h eax にファンクション番号。パラメータはレジスタ。
らしいです。

>Windows NT int 2eh eax にファンクション番号
>FreeBSD int 80h eax にファンクション番号。パラメータはスタック。
>Linux int 80h eax にファンクション番号。パラメータはレジスタ

おお。すばらしいです。
WindowsNTのシステムコールは引数渡しはどうやっているんでしょう。

>>>612
>QNX

なるほど、たしかにQNXはマイクロカーネルでメッセージを
使用していましたね。
x86での具体的な実装方法を解説したものを探すか、
ソースをみるって感じですかね。
解説はあまり期待できないかも・・・

Windows NT　は記述がありませんでした．．．(^^;

>>615
QNXの解説本って、
「次世代OSアーキテクチャ QNXオペレーティング・システムの世界」
http://www.amazon.co.jp/exec/obidos/ASIN/4875932006/
と、あとはインターフェイス誌の紹介記事くらいしかないな。
漏れはこの本持ってるけど、実装についてはプロセッサ固有部分については書かれてない。

http://pc2.2ch.net/test/read.cgi/tech/1045907529/l50
↑GUIの実装にて、窓の重なり実装に関してどうのこうの。
LかK、教えてやれば？

>>618
そいつらの議論は、実装以前だ。放置の方向で。

>QNXの解説本って、
これじゃいかん?　
http://www.qnx.co.jp/usr/help/product/neutrino_2.11_ja/sys_arch/about.html

アドレス空間としてシステム共有空間とプロセス固有空間を持ち、ユーザープロ
セスのコードやデータは全てプロセス固有空間内に格納され、他のプロセスから
は完全に不可視な状態になります。

　今、アプリケーションが、write(fdsc, buf, size); でファイルへ書きこみを行
った場合を想定します。

　bufは、アプリケーションの固有空間にありますので、FSPからは直接は見えま
せん。しかし、FSPは、bufのデータを読み込む必要がありますので、カーネルの
ページング・サービスを用いて自分のアドレス空間に覗き窓を作ってbufの内容
を覗くか、または、単純にアプリのプロセスにいる間に共有空間にコピーした
ものを参照する必要があるでしょう。速度面から前者を用いる事になるでしょ
うが、そもそも、FSのアドレス空間がアプリケーションと分離されていなけれ
ばこんなことは必要なく、直接見ることが出来ます。

つまり、もし、FSをモノリシック方式で書いていれば、覗き窓もコピーも
必要ないのです。FSは、いくつかのプロセスで同時に実行され、それぞれの
アドレス空間で、直接データをやり取り出来ます。

なお、IA32では、モノリシック方式でもカーネルをFSから保護することは
可能です。やり方は簡単で、FSの特権レベルをカーネルより低くすればいい
だけです（タスク（プロセス）と特権レベルとが、独立した概念としてあり
ますので）。


また、「プロセス」の特徴として、定期的に実行に移される特徴がありますが、
FSでは、キャッシュの遅延書きこみなどに少し便利そうではありますが、それだけ
のためには、少し「大げさ」過ぎるようにも思えます。

>>621 の冒頭に挿入(ｽﾏｿ)

　Linusもマイクロカーネルに懐疑的だそうですが、実は私も懐疑的で、
OSのサブシステムからカーネルを保護するだけなら、IA32では他の方法も
あるのではないかと思っています（懐疑的なだけで、絶対意味が無いとか
そういう意味ではありませんが。）。

　最初に断っておきますが、QNXの資料にも明言されている通り、マイクロカー
ネルはカーネルが小さい事を意味するのではなく、OSの各種サブシステムを
一般プロセスとほぼ等価な形態で構成する方法を言います。

　OSのサブシステムの代表であるファイルシステム(以下FS)をこのような一般
プロセスとして記述した場合を考えましょう。以下、FSのプロセスをFSPと言い
ます。

　現代的なOSでは(Windows/Linux/QNXも)、特殊例を除き、個々のプロセスは、

　私が考えるマイクロカーネルの最大の利点は、サブシステムが壊れた時に、
アプリを巻き添えにしなくていい、と言う点です。

　モノリシックの場合、サブシステムが壊れると、そのサブシステムを呼び
出していた全てのアプリも同時にダウンすると思います。
　しかも、あるアプリが原因となってサブシステムが壊れた場合にも、
そのサブシステムを「同時に」利用していた別のアプリもダウンしてしまう
ことに成ると思います。

　例えば、マイクロカーネルでは、FSがダウンしても、FSを呼び出していた
アプリは、read()や、write()が異常終了するだけで済むと思います。

>>620さん
私も、マイクロカーネルについて調べていたので、大変参考になりました。
ありがとうございます。

>>LightConeさん
モノリシック、マイクロカーネル方式のカーネルについて御教授ありがとうございます。
私は機能と作成の難易度を考慮して、以下のようにしたいと思います。
・モノシリックカーネル方式
・モジュール化をきっちり行い容易にマイクロカーネル方式へ移行できるようにする。
・システムコールは割り込みゲートを使用。パラメータはレジスタ渡し。
メモリ配置は、530で示していただいた資料を参考に、考え中です。
ありがとうございます。

Liner Frame Bufferの物理ベースアドレスが 0xE0000000 となっていたのに、
今気づいたのですが、なぜメモリは4G無いにもかかわらず、
プログラムは正常に動いているのでしょうか．．．
理由をご存知の方、参考になるアドレス等教えていただけないでしょうか？

フレームバッファはVGA内のメモリにあるから本体メモリとは関係なっしんぐ。

>>626さん
御教授ありがとうございます。
物理アドレス 0xE0000000〜 以降は、自動的に、チップセットの方が
VGA内のメモリへマップする言うことでしょうか？

>>626
ﾊｧｯ？ﾈﾀか？
PCIのコンフィグレーション（←違ってたらごめん）で
論理アドレス0xE0000000にVGA内のメモリが割りつくだけだろ。
本体メモリを４GB積んでも、そこの512MBは使えないから、関係オオアリクイだとおもうが？

ボクへの煽り？ｶｺﾜﾙｲ

>>629
（悪）←ｶｺﾜﾙ

ｶｺﾜﾙ(・∀・)ｲｲ!!

Intelのチップセット仕様を見たところ、
ISA Hole 0100_0000〜00F0_0000
AGP Aperture 〜FEC0_0000
その他色々なシステム領域 FEC0_0000〜

とありました。ありがとうざいます。
これを知らなければ、危うく、ISA Hole まで使ってしまうところでした。
システムのメモリ空間に、メインメモリ以外のものが色々割り当てられているようです。

>>632
http://www.cqpub.co.jp/column/books/2001a/34331PC_Legacy/pc-lega1.htm
こういう資料もある。

ありがとうございます。そういえば、このような資料もありましたね．．．
ここは、割り込み部分を作っている時に、よく見てました。

>>623
＞一般プロセスとほぼ等価な形態で構成する方法を言います。
Linuxなどではdaemonプロセスが、そこを補ってるという認識。

QNXを利用したときの幸せはqnetの透過性。分散とか並列とか言わずに潔く
よそのCPUやマシンのリソースを利用できる。
しかもその場合の性能保証/測定・多重化ができる。
ネットといえばイーサしか思い浮かばない向きには関係ないだろうがな。

>>620
知らんかった。ｻﾝｽｺ。日本法人が（やっと）まともに仕事してるんだな。

OSASK3.4でますた。

>>624
FSが落ちた時点でどっちみちそのシステムは死んだも同じだと思われ。
マイクロカーネルはモジュール化の一つの方法にしか過ぎないのでは
ないかとオレは思ってる。ローダブルモジュールでも十分だと。

Ｌたん書き込み多すぎ。他のレスが埋まってしまう。



というか、ＬスレＤＡＴ落ちしかねない静かさだがいいのか？
この際このスレに一本化するというのも手ではあるとおもうが．．．

>639
確かに今のOS板の速度的には
あとわずか6ヶ月ぐらいの放置でdat落ちしかねないな、うん。

>>640
言葉のあやだよぅ

>>625
間違えやすいのですが、「モノ*シリ*ック」ではなく、「モノ*リシ*ック」
です(monolithic)。SFで「モノリス」とか時々聞きますけど、それで
覚えましょう（笑）。小さいリスがコンピュータの中に一匹入っている
様子を想像するとさらにGOOD!

>>638
ハードディスクのFSが落ちた場合は、おっしゃる通り、大方再起不能で
しょうね。でも、GUIサブシステムが落ちた場合などなら、マイクロカーネル
では再ロードできるのではないでしょうか。モノリシックでは、再ロードは、
かなり難しいと思います。ただし、パフォーマンスを落とさずにGUIを
一般プロセスでどうやって組むのか良く分かりませんが。


>Liner Frame Bufferの物理ベースアドレスが 0xE0000000 となっていたのに、
>今気づいたのですが、なぜメモリは4G無いにもかかわらず、
>プログラムは正常に動いているのでしょうか．．．

それは、その物理アドレスにFrame Bufferが顔を出すように組まれている
からです。PCIバスなどでは、バス調停回路があって複雑ですが、
基本的な考え方を説明すると、アドレスのいくつかのビットがある
特定の1,0の組み合わせの時だけ信号線がONになるような回路を「デコーダ」
と呼びますが、そのデコーダが、Frame BufferのRAMのCS(CHIP SELECT)に
接続されているだけです。

例えば、E000 0000 〜 E00F FFFF までを Frame Bufferにしたい場合は、
上位 12 BIT が、E00 になっていればいいので、

bool CS = (PhysAddr[31-20] = 1110 0000 0000B);

みたいな回路を、AND素子とNOT素子を使って作ります。

>>642
頭いいな

>>LightConeさん
ご指摘、丁寧な解説ありがとうございます、
完全に「モノシリック」と勘違いしていました(^^;
ハードウェアーの方まで、よくご存知のようで頭があがりません．．．

>>643
おまえがばかなだけ。でも確かにLﾀﾝはわかりやすく説明できる能力をもってる。
しかし頭いいﾔｼにそんな手間を取らせるのは漏れ達愚民の大罪だな。
長島監督に、毎日少年野球のコーチさせるのはもったいないだろ。

>>644
第2種←今は呼び名違う
レベルの知識と思われ。つまり計算機の基礎。ソフトもハードもない。基礎だ。

小さいリスはいいですな
しかし物知り言っている人って2001年宇宙の旅のモノリスとか知らないのかな

>>646さん
プログラミングは、趣味でやってるだけなので、基礎も発展もさっぱり無く、
多大な迷惑をかけると思いますが、どうぞお許しください。

マイクロカーネルは、さらに小さいリスが何匹もいるのかな。

と、これだけ書いても仕方ないので。
>>642
X window systemは、一般のプロセスなのでは？
パフォーマンスは、落ちているでしょうけど。
プロセッサが限定されますが
MTRR(Memory Type Range Register)てのがありますね。

>>648
情報処理試験の参考書でも買えば。
試験受けろとは言わんけど。
基礎を勉強するのには結構役立つよ。

>>648
知らないことが別に悪いわけじゃないよ。がんがれ。
だけど基礎はしりませ〜ん、だとコミュニケーションに無駄が増えすぎる。
内容は理解していなくてもｺﾄﾊﾞを知ってるだけで、お互いすごく楽になると思うよ。
頭の中のｲﾝﾃﾞｸｽを作るためにも入門書は役に立つと思われ。<-糞本でもな。
「鶏のﾀﾏｺﾞを塩化ナトリウム少量を溶かした熱湯の中で10分間熱してくれ。」
->「ゆで卵作って。」

>>651
半熟で頼む。

>>652
オトコはだまってハードボイルド。

>>651
書き漏らしたてるﾅ。
＞「鶏のﾀﾏｺﾞを塩化ナトリウム少量を溶かした熱湯の中で10分間熱してくれ。」
＞->「ゆで卵作って。」
まずはこれでコミュニケーション確立。で、>>652 が言ってるみたいに、やっと
「どうやって茹でたら欲するゆで卵ができるか」の議論ができるわけ。
塩は純粋なNaClで良いのか、熱湯は常に100℃がいいのか、温泉玉子みたいに
低い温度の方がいいのか、など。
で、実装になったら、長たらしい方の表現に戻らねばならん。厳密さが必要になるからな。
いわゆる仕様書というやつだな。

>>645
＞長島監督に、毎日少年野球のコーチさせるのはもったいないだろ。
だからLﾀﾝ、1週間に1回来てくれればいいよ。(ｗ

何も言うまい何も言うまい・・・

何回リロードしても出てこないよ(´Д⊂ｸﾞｽﾝｗ
F5連打じゃないよｗ

>>657
誤爆です

>>657
時期から察するに、入試結果かな？

たぶん採用の選考試験の結果じゃないかな。
大学で proxy の cache が効いていると、
Flash を使ったページが cache からウンロードされて更新されないというケースがあった。

NWSOSは、最近動きないねぇ。

>>661
水面下でいろいろやってるんです(^_^;)

API-DLLへの対応、インポート関数への対応、スタックの自動伸張、
ドライバの仕様化、予約だけして物理ページを割り当てないメモリへの
対応、ファイルバッファ容量の自動調整機能など。

さらにこれらのための下準備として、NWSLをインポート関数や特権レベル
セグメントへ対応させたり、今までALL-ASSEMBLERだったメモリ管理や
ファイル管理を全部Cに書き直したり、割り込み中でメモリの確保をやめて
固定バッファに直したりとか。

一応、DLLも扱えるようになり、ファイルシステムとメモリシステムは全部Cに
書き直せて、スタックの自動伸張にも基本的には対応できました。
アプリのファイルサイズが大分小さくなり、GUIの文字描画やエディタの
描画速度も速くなり、タスクスイッチも高速になっていますが、全て
内部構造の変化でしかなく、目に見えて分かるような機能向上がないので、
公開していないのです。

>>662
よっ。大統領〜。

>>662
すげ〜
素直に感動した。

>>662
アプリケーションプログラマから見れば十分機能向上してます。
もっとまめに更新してもいいんじゃないかと思いますが。

なぜLﾀﾝは、自作自演を続けるの?
そしてなぜ気づかれていないと思うのだろうか。
(自称）頭いいならば、そこにまず気づけと。

>>666
以下は、漏れが書いたんだが、本人ではないぞ。
>>645 >>646 >>663

>>558以降、ずっとLﾀﾝに噛み合わない突っ込み入れ続けてるが。
結構楽しい。

>>568 >>570 >>576 >>580 >>582 >>585 >>589 >>598 >>609 >>610
>>613 >>617 >>619 >>628 >>630 >>633 >>635 >>636