2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

OSを作ろうpart5

1 :(・∀・)yossy ◆FlasH.X1/s :03/01/12 21:44
独自に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

プロジェクトメンバーになりたい方は、
higepon@users.sourceforge.jp までメールをどうぞ。

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

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

2 :ひげぽん:03/01/12 21:47
ズサ━━━━⊂(゚Д゚⊂⌒`つ≡≡≡━━━━!!

3 :デフォルトの名無しさん:03/01/12 22:00
新スレおめ

4 :デフォルトの名無しさん:03/01/12 22:01
3GET、ごめんなさい・・・(確○犯

5 :デフォルトの名無しさん:03/01/12 22:01
あ・・・

6 :デフォルトの名無しさん:03/01/12 22:02
嗚呼・・・

7 :デフォルトの名無しさん:03/01/12 22:02
嗚呼…

8 :デフォルトの名無しさん:03/01/12 23:22



9 :山崎渉:03/01/13 18:29
(^^)

10 :デフォルトの名無しさん:03/01/13 22:18
読んでみた。
前半は難解だったけど最後まで読んだら
ネットについての理解が格段に深まった。
ありがとう。

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

11 :デフォルトの名無しさん:03/01/14 17:00
age

12 :デフォルトの名無しさん:03/01/14 20:33
>>10
何を読んだの?
>>1 のソース?

13 :デフォルトの名無しさん :03/01/14 20:48
俺も暇だからブートの部分だけ勉強してみよ


14 :デフォルトの名無しさん:03/01/15 03:01
前スレ落ちた?

15 :デフォルトの名無しさん:03/01/15 09:51
>>14
落ちたみたい

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

16 :山崎渉:03/01/15 17:46
(^^)

17 :デフォルトの名無しさん:03/01/15 19:19
http://pc.2ch.net/test/read.cgi/os/1031404041/904

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

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

18 :デフォルトの名無しさん:03/01/15 21:11
>>17
bochsの記事で、bochsのデバッグ機能が『mona』のブート部分の開発に役立った
というものでした。

19 :17:03/01/15 21:31
>>18

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

20 :デフォルトの名無しさん:03/01/15 22:10
>>18
なんかそれだけみると。bochsの何のために有るか分からん機能が
monaに役に立った。って書いてあるように見えるなぁ。

21 :デフォルトの名無しさん:03/01/15 22:27
>>18
ひげぽん「また落っこちました〜」
まわり「だからbochsのログだせやぁ」

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

22 :ひげぽん:03/01/15 22:50
>>21
>の流れを思い出しました。w
あの時も、今もたくさんの人のお世話になっているということですね(笑)

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

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

23 :デフォルトの名無しさん:03/01/15 23:26
マーはニーしる!
を思い出しました。

24 :デフォルトの名無しさん:03/01/16 00:11
>22
「タスク切り替え」なんてものは、定義が適当だし、今の段階では
実際的な「タスク切り替え」とは程遠いので、あんまり大したこと
ではない。

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

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

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

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

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

27 :ひげぽん:03/01/16 21:28

>何か最近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)その他

28 :ひげぽん:03/01/16 21:29
長くなってしまったので分けて。

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

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

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

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

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

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

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

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

29 :ひげぽん:03/01/16 21:29
>あと64bitの話が出てたがどう考えてるの?

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

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

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

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

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

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

31 :デフォルトの名無しさん:03/01/16 22:36
>1. STLがどうなったのか
こういう書き方だと、
2chブラウザとかで >>1 と混同される

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

32 :デフォルトの名無しさん:03/01/16 22:49
何でひげぽんさんはこっちではトリップ付けないの?
MonaBBSではこんなにはじけちゃってるのに(藁
> (´∇`)ヒゲポソ ◆Ngzcp/NZpA

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

33 :デフォルトの名無しさん:03/01/16 23:27
>>32
なんかあってからそのトリップつけりゃいんじゃない?


34 :デフォルトの名無しさん:03/01/16 23:38
おまい、しんでからシートベルトつけても遅いんだぞ

35 :デフォルトの名無しさん:03/01/16 23:54
つーか、書いてる内容でだいたいわかるだろ。
荒らすような偽者には、このスレは敷居高いと思う。

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

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

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

37 :デフォルトの名無しさん:03/01/17 00:37
>>36
一体全体、どこ探したの???
http://pc3monaos.hp.infoseek.co.jp/cgi-bin/2ch/test/read.cgi/entrance/1042291353/l50

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

38 :デフォルトの名無しさん:03/01/17 00:42
> 荒らすような偽者には、このスレは敷居高いと思う。
ひげぽんさんが登場するのはこのスレだけではないと思われ
それこそOSASKとかNWSOSとかの絡みでしょっちゅう引き合いに出されてるし

39 :デフォルトの名無しさん:03/01/17 01:19
ていうか前はトリップ付けてたけど…

40 :33:03/01/17 02:10
ほんとだpart3みたらついてる、、、


41 :デフォルトの名無しさん:03/01/17 02:24
にしても、NWSOSの進行が速いな。さっき最新版ダウソしたら
いつのまにか、いろんなGUIアプリが動いてた。ってかメモ帳程度の
ものが当たり前に動いてるし、

なんなんだ、いったい

42 :デフォルトの名無しさん:03/01/17 05:00
MONAもNWSOSも自作組み立て機で動いた。わーい

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

43 :デフォルトの名無しさん:03/01/17 09:12
>>41-42

桜?
頑張れ。

44 :デフォルトの名無しさん:03/01/17 10:46
>>43 は友達がいないタイプだな

45 :ひげぽん:03/01/17 17:07
>>31
> 引用符と引用文の間はスペースを空ける慣習があるんだよ
了解しました。

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

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

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

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

46 :ひげぽん ◆Ngzcp/NZpA :03/01/17 17:39
トリップ失敗。。。

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

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

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

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

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

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

47 :ひげぽん ◆Ngzcp/NZpA :03/01/17 17:42
ただ起点となる(process1)の切り替えがうまくいかない
timerHandler
    schedule
        switchProcess
            ここで切り替え

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

48 :ひげぽん ◆Ngzcp/NZpA :03/01/17 17:44

スタックの内容が表示できるよう
#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?
かなあ。

49 :ひげぽん ◆Ngzcp/NZpA :03/01/17 18:19
表示が乱れてしまいました。
すいません。

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

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


50 :デフォルトの名無しさん:03/01/17 18:22
非プログラマブル部分があるからね>CS32BIT

51 :デフォルトの名無しさん:03/01/17 18:45
もうおそいけど、次スレ作る際に現行スレのコピーとっておいて、
どこかのWEBページで見れるように保存しておいてほしかったなぁ。
前スレがDAT落ちしまくって後から来たものにはなにがどうなってるのか
分からない罠。

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

52 :FreeDOS教徒:03/01/17 19:19
>>51さんがこう言ってるんだし、
とりあえず過去ログどっかに置いていいんじゃない?>ひげぽん

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

53 :デフォルトの名無しさん:03/01/17 23:34
>freedos教徒さん

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

54 :デフォルトの名無しさん:03/01/17 23:45
↑拝見させて、だね

55 :デフォルトの名無しさん:03/01/18 02:54
>>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");
}
とかするとよろし。


56 :デフォルトの名無しさん:03/01/18 02:55
しまった。タブ入れ欄内の忘れてた。スマソ


57 :デフォルトの名無しさん:03/01/18 02:56
漢字むちゃくちゃだ。モチツケ漏れ


58 :ひげぽん:03/01/18 03:05
まさに今スタックのぞきみを思案中です
インラインとprintfでやってますがうまくいかないです


59 :デフォルトの名無しさん:03/01/18 03:42
>>58
上の例を説明すると、

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

    push dword 0x1234
    call func

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

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

60 :デフォルトの名無しさん:03/01/18 06:34
>>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

61 :デフォルトの名無しさん:03/01/18 09:51
(昔の雰囲気が戻った)

62 :ひげぽん ◆Ngzcp/NZpA :03/01/18 12:52
#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);
}

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

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

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


64 :ひげぽん ◆Ngzcp/NZpA :03/01/18 13:04
>>52
FreeDOS教徒さん
フォローありがとうございます。
yossyさんと検討してみます。>過去ログ

65 :超先生@OS板 ◆leaf/RYZgY :03/01/18 15:26
< `ー´>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]

66 :デフォルトの名無しさん:03/01/18 18:17
ちなみに、関数のプロローグは、標準的には、
push ebp
mov ebp,esp
sub esp,(AUTO変数のサイズ)

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

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

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

67 :LightCone ◆sSJBc30S5w :03/01/18 18:17
だって。

68 :ひげぽん ◆Ngzcp/NZpA :03/01/19 02:20
>>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));       \
}

69 :ひげぽん ◆Ngzcp/NZpA :03/01/19 02:36
スタック覗き見作戦ということで
やってみました。

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

70 :ひげぽん ◆Ngzcp/NZpA :03/01/19 02:39
ソースチェックアウトしてMakeしたけど
スタックダンプしてとまるぞと、怒られそうで・・・

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

71 :デフォルトの名無しさん:03/01/19 03:30
C++なんだから、マクロなんか使わないで、インライン関数にしては?>>ヒゲポソタソ

72 :デフォルトの名無しさん:03/01/19 03:32
>>69
そのためのブランチでしょ。
新しい実験を開始するたびにブランチすればいい。

73 :デフォルトの名無しさん:03/01/19 03:40
>>71
スタック扱うのに?

74 :デフォルトの名無しさん:03/01/19 05:39
>>73
インラインですが何か?

75 :デフォルトの名無しさん:03/01/19 06:23
>>74
保証ない

76 :デフォルトの名無しさん:03/01/19 06:35
>>75
逆汗してみ

77 :デフォルトの名無しさん:03/01/19 09:12
>>76
コンパイルオプションを変えただけで動かなくなるかもしれない方法を薦めないように


78 :デフォルトの名無しさん:03/01/19 11:05
>>78
だから逆汗してみっていってるでしょ
インラインアセンブラで書いた部分が最適化の影響を受けるとは初耳

79 :デフォルトの名無しさん:03/01/19 11:41
>>78
インライン関数がインライン展開される保証は無いのですが
VisualC++なら__forceinlineなんてものがありますが


80 :デフォルトの名無しさん:03/01/19 12:44
>>71
今回みたいにちょこっと実験してみるにはマクロが便利でつ
コンパイルオプションとかコンパイラとか、なるべく関係ないように書くには
アセンブリ言語が一番だけどナー


81 :デフォルトの名無しさん:03/01/19 13:00
で、実際に逆汗してみた香具師いるわけ?
-O付けなければ一切インライン展開されない。
-Oが付いていればレベルに関係なく100%インライン展開される。
よって>>77は正しいが、-Oさえあれば保証はある。

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

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

82 :ひげぽん ◆Ngzcp/NZpA :03/01/19 14:47
>>71
スタックを扱うので、ちょっとインライン関数は怖かったです。

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

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

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

83 :超先生@OS板 ◆leaf/RYZgY :03/01/19 18:10
< `ー´>y-~~ やっぱりinline展開されてない様子。 >switchProcess2
initProcessでtimerHandlerへの戻り先他を積んでおかないとダメか。

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

84 :デフォルトの名無しさん:03/01/19 18:30
>>83
CVSでCFLAGSを見る限り、-Oが付いてないですね。
これではインライン展開されないです。

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

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

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

86 :ひげぽん ◆Ngzcp/NZpA :03/01/19 18:35
>そもそもコンテキストスイッチをesp切り替えでやるのはあまりお勧めできないが・・・。

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

87 :ひげぽん ◆Ngzcp/NZpA :03/01/19 18:40
>>84さん
アドバイスありがとうございます。

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

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

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

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

88 :デフォルトの名無しさん:03/01/19 19:06
>>81
> -Oが付いていればレベルに関係なく100%インライン展開される。

この情報のソースある ?

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

89 :デフォルトの名無しさん:03/01/19 19:18
>>88
monaのソースを逆汗して確認。

90 :デフォルトの名無しさん:03/01/19 20:11
>>89
それってたまたまそうなってたってことじゃないのか ?

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

91 :デフォルトの名無しさん:03/01/19 20:49
>>90
とりあえず、確認もせずにえらそうなことを言うのはやめてくれ。
インラインにならない経験があるんだったら、
それと同じケースがmonaの開発に使っている環境で再現することを示せば
背理法で何も議論する必要ないんだから。

92 :デフォルトの名無しさん:03/01/19 20:58
>>91
要するに、100% インラインになることは、保証されてないわけね。

議論以前の問題だよ。

93 :デフォルトの名無しさん:03/01/19 21:00
と、とにかく、、コンパイルOPTIONによって動くとか
動かないとかいうのはシステム的になんか嫌だな・・・。
OS作る前にもっとコンパイラとかオブジェクトコードの勉強しないと。。。

94 :デフォルトの名無しさん:03/01/19 21:25
>>92
何一人で熱くなってんの?
とりあえず、Monaをダウンロードして、コンパイルしないと始まらないよ。
手を動かしましょうよ。そう思って逆汗逆汗って言ったのに。

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

95 :デフォルトの名無しさん:03/01/19 21:59
>>94
わかった、わかった。
貴方の環境では、100% インラインになるわけね。

これでいい ?

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

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



97 :デフォルトの名無しさん:03/01/19 22:07
>>95
はい、結構です。で、本題。
興味の方向から考えるに、貴殿は組み込み用のOSを手がけておられるとお見受けしますが、
タスクスイッチはどういう風に実装しておられましたか?

98 :デフォルトの名無しさん:03/01/19 22:10
けんか(・A・)イクナイ!

99 :デフォルトの名無しさん:03/01/19 22:19
>>96
と言うか、inline にする/しないなんて、コンパイラのバージョンで変わったりしそうでしょ ?
それに依存するのは、あまり良くないと思ってる。

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

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

100 :デフォルトの名無しさん:03/01/19 22:19
一人インライン信者がいるだけ

101 :デフォルトの名無しさん:03/01/19 22:22
インラインスケート信者?

102 :デフォルトの名無しさん:03/01/19 22:35
>>99
失礼しました。やはりそうでしたか。
gccは2.95の頃から-finline-limit-Nで決めていたので、
そんなに不安定なものだという感覚じゃなかったんです。
inline信者というより、gcc信者の厨房ですみません。

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

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

103 :デフォルトの名無しさん:03/01/19 22:57
>>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 だからスタックどうのこうのは書いてないよ。

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

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


105 :ひげぽん ◆Ngzcp/NZpA :03/01/20 17:44
仕事でだいぶ不規則な生活になって来ました。
早く持ちなおさないと

現状を整理してみようと思います。
(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どちらを基準にすべきか・・・

大混乱中です。


106 :ひげぽん ◆Ngzcp/NZpA :03/01/20 17:45
やっちゃった。スッタクゴメソ

107 :デフォルトの名無しさん:03/01/20 18:10
bochsdbg.exe等のデバッガ付きのもので追跡してみては?


108 :デフォルトの名無しさん:03/01/20 18:42
>>106
新手のタクシーですか

109 :デフォルトの名無しさん:03/01/20 23:45
スッタク(・∀・)カコイイ!!

110 :デフォルトの名無しさん:03/01/20 23:50
>>105
>・スタックマクロもebp,espどちらを基準にすべきか・・・

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

111 :110:03/01/20 23:51
32bit モードなので ebp + 4 の間違いですた。

112 :デフォルトの名無しさん:03/01/21 22:18
>>110
> ベースポインタって名前の通り ebp をベースにするのが便利でつ。

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

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

114 :デフォルトの名無しさん:03/01/22 01:50
楽しげだ。でも仕事忙しくて傍観してるしか能がないおれ。

115 :デフォルトの名無しさん:03/01/22 02:06
>>114
ここでレスするだけでもちょっとは助けになるんじゃない?
参加の仕方も色々。


116 :ひげぽん ◆Ngzcp/NZpA :03/01/22 22:34
>>110,112
ありがとうございます。
やはりespからたどるのがよさそうですね。

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

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

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

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

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

117 :ひげぽん ◆Ngzcp/NZpA :03/01/22 23:00
Bochs&GDBデバッグはもしかしてWindowsでは
できないのかな?
cygwinでMakeすれば出来そうだけどバイナリはないのだろうか・・・

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

118 :デフォルトの名無しさん:03/01/22 23:03
>>117
バイナリパッケージ入れたら bochsdbg.exe ってやつが入ってるからそれ使えばいい。


119 :ひげぽん ◆Ngzcp/NZpA :03/01/22 23:08
>>118
それを起動させて
cygwin gdbで
gdb
target remote localhost:1234
とやってみましたが
connection refusedとなりました。

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

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

./configure --enable-gdb-stub

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

120 :名無し@沢村:03/01/22 23:46
ヌヒ等よ、OSをつくために頑張っているヌヒ等よ。
ところで新しいOSができたというニュースはまだ聞かないが、ヌヒ等よ何をしている?
ヌヒ等よ、早くやれ!!

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


122 :名無し@沢村:03/01/23 00:29
>>119
ごたくはいいから早くつくれ!!

123 : :03/01/23 12:37
↑酷ぇなおい

124 :デフォルトの名無しさん:03/01/23 15:07
>>123
何か沢村の名を騙った偽者に見える。


125 :FreeDOS教徒:03/01/23 15:55
>>124
122はあきらかに偽物だろ。
違うのか?

126 :山崎渉:03/01/23 21:18
(^^)

127 :ひげぽん ◆Ngzcp/NZpA :03/01/23 23:19
こんなのを作ってみました。
ループはあえて使ってません。

#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)); \

128 :ひげぽん ◆Ngzcp/NZpA :03/01/23 23:20
これをタイマハンドラでこんな風に使ってみます。
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;
}

129 :ひげぽん ◆Ngzcp/NZpA :03/01/23 23:23
その結果
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


130 :ひげぽん ◆Ngzcp/NZpA :03/01/23 23:25
表示ロジックでスタックが上書きされたりするのでしょうか。
大混乱です。
観測しようとすると状態が変わるのか
もともと状態がおかしいのか
正常なのか。
・・・・・・・

131 :超先生@OS板 ◆leaf/RYZgY :03/01/23 23:26
>>127
ebpを基準にしないとダメポ・・・。

132 :ひげぽん ◆Ngzcp/NZpA :03/01/23 23:29
>>131
あ、もしかして他の関数をcallしてしまうとおかしくなるかも。。。
ってことでしょうか。

133 :ひげぽん ◆Ngzcp/NZpA :03/01/23 23:31
ということは
その関数に入ってからスタックには積まれた者はebpからするとマイナス
ということですよね。あれちょっと自信ないです。

134 :デフォルトの名無しさん:03/01/23 23:32
mov dword [esp],0x1dbf
mov [esp+0x4],eax
でスタックの内容を書き換えているので正常です


135 :ひげぽん ◆Ngzcp/NZpA :03/01/23 23:34
>>134
ありがとうございます。
書き換えが起こっているのは、関数callのせいなのでしょうか。

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

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

136 :デフォルトの名無しさん:03/01/23 23:35
>>130
> 観測しようとすると状態が変わるのか
量子力学の不確定性みたい...

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

137 :超先生@OS板 ◆leaf/RYZgY :03/01/23 23:38
こんな感じか。

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

138 :ひげぽん ◆Ngzcp/NZpA :03/01/23 23:42
>>>132
>> あ、もしかして他の関数をcallしてしまうとおかしくなるかも。。。
>先日のinline論議真面目に読んでないんだね...

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


139 :デフォルトの名無しさん:03/01/23 23:47
_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]);
...

でやったらどうですか?




140 :デフォルトの名無しさん:03/01/23 23:47
>>138
いい人 (*^_^*)

141 :ひげぽん ◆Ngzcp/NZpA :03/01/23 23:56
>>139
0x87654321  0x87654321  0x87654321  0x87654321  0x34353536  0x00000034  0x000000
と表示されました。
ありがとうございます。

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

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



143 :デフォルトの名無しさん:03/01/24 00:05
↓泣けてきます。 (TдT)
>>103
> ただ、このスレ見てる奴は、スタックがどうのこうのぐらいはだいたいわかってると思う。

144 :デフォルトの名無しさん:03/01/24 00:11
あ、スタック仕様はエクスパンドアップ、それともダウン?どっち?

145 :デフォルトの名無しさん:03/01/24 00:12
>>141
とりあえずここは一旦Monaのカーネルから離れて、
簡単な関数を書いてアセンブリ出力と睨めっこすることをお勧めします。

146 :デフォルトの名無しさん:03/01/24 00:14
コンパイラまでお作りになってるL様の偉大さを思い知る……か

147 :ひげぽん ◆Ngzcp/NZpA :03/01/24 00:14
>>142
なるほど。
ということは、インラインアセンブラなどを使わなければ
一番最初の_sysdumpStack4()は普通にスタック内を表示
できているのでしょうか。

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

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

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


148 :超先生@OS板 ◆leaf/RYZgY :03/01/24 00:15
こんな感じ。

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

149 :ひげぽん ◆Ngzcp/NZpA :03/01/24 00:16
>>145
実は最近それはやってみました。
引数がどのように格納されるか戻り値がどこに格納されるか。
AUTO変数の確保のされ方等
基本は学んだつもりなのですが
応用が利きません・・・

150 :デフォルトの名無しさん:03/01/24 00:25
146
またあらわれたLタン。
キャリアが違うと思うんだけど

151 :LightCone ◆sSJBc30S5w :03/01/24 00:34
>>150
#146は、わてちゃいますよーー

152 :デフォルトの名無しさん:03/01/24 00:38
Lタンが実際に登場した。
ではなくて、またLタンの話が引き合いに出された。
という意味だと思ふ。

153 :超先生@OS板 ◆leaf/RYZgY :03/01/24 00:38
<後ろ頭>y-~~~ 参考URL
Linking C++ and Assembly
ttp://www.cs.uakron.edu/~margush/306/LinkingWithCplusplus.html

154 :デフォルトの名無しさん:03/01/24 00:58
>>113
-fno-omit-frame-pointerで、出来ない?


155 :113:03/01/24 04:42
>>154
ガーン(゚д゚|||) 知らなかった。 no- つけると逆になるんだ、、、
info 見直したら書いてあるし、、、


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

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




157 :ひげぽん ◆Ngzcp/NZpA :03/01/25 17:34
>>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が発生します。
これはただいま調査中です。




158 :ひげぽん ◆Ngzcp/NZpA :03/01/25 17:45
すごく悩んでいろいろ考えた結果の実装が
なんとなく動いたのはうれしいのですが
漏れがありそうで怖いですね。

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

159 :ひげぽん ◆Ngzcp/NZpA :03/01/25 22:37
リリースのお知らせです。
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

160 :デフォルトの名無しさん:03/01/26 00:40
>割り込みハンドラでいきなりCコードに飛ばずに、asm glue codeを一回経由するけど。
激しく同意。

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

161 :デフォルトの名無しさん:03/01/26 00:41
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のコードを軽く眺めてみるのも良いと思う。

162 :デフォルトの名無しさん:03/01/26 08:37
>>・STLの導入。std::swapは実際にタスクスイッチで使用しています。
をー!
OSカーネルにSTLを採用した例としては、世界初では?

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



163 :ひげぽん ◆Ngzcp/NZpA :03/01/26 19:47
>>160
>>161
なるほどありがとうございます。
上記のメリットはスタックをきちんと
自分でコントロールできることでしょうか。

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

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

164 :ひげぽん ◆Ngzcp/NZpA :03/01/26 20:25
クラス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を表示してしまう。
なんでだろう。。
調査中です。
でもだいぶ楽しいです。

165 :デフォルトの名無しさん:03/01/26 20:42
プログラムの勉強しようと思うんだけど、
何から始めれば良いの?
Visual BasicとかC言語とかあるけど、
最初はどれ?
Visual Basic?

166 :デフォルトの名無しさん:03/01/26 21:43
>>165 は誤爆です。すいません。

167 :デフォルトの名無しさん:03/01/26 22:30
>165
アセンブラとC言語。
アセンブラのみでもいいのだけど、アセンブラだとJMPしまくりで、
スパゲッティに慣れるとよくないから、Cのような構造化言語と併用
していくといいよ。

168 :デフォルトの名無しさん:03/01/26 23:41
>>167
誤爆にマジレス...

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


169 :デフォルトの名無しさん:03/01/27 02:51
>キーボードドライバにstd::queueを使ってみて遊んでいます。
キーボードドライバは std::deque のほうが向いてるよ。
historyたぐるときなどは、queueよりも高機能実装できるのだ!

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

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

170 :henoheno@OS板:03/01/27 13:51
Mona上にSTLportを移植された件、ベースになっているバージョンは
4.5.3という事でよろしいでしょうか。( ´∀`)ネソノタメ


171 :ひげぽん ◆Ngzcp/NZpA :03/01/27 22:25
>>169
>キーボードドライバは std::deque のほうが向いてるよ。
>historyたぐるときなどは、queueよりも高機能実装できるのだ!

なるほど。

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

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

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

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




172 :ひげぽん ◆Ngzcp/NZpA :03/01/28 00:34
キーボード入力を二つのタスクを走らせた状態で
片方のタスクで取得する実験をしてみました。

キー入力取得タスクの肝
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)
とやっても
この現象は起きます。

173 :ひげぽん ◆Ngzcp/NZpA :03/01/28 00:34
(2)
while ((ch = km.getCharacter()) == -1)

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

(3)
while ((ch = km.getCharacter()) == -1)

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

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

174 :デフォルトの名無しさん:03/01/28 01:01
>>172-173
MutexやWaitForSingleObjectみたいなの実装しないと
その手のことは安定して使えないと思われ

175 :デフォルトの名無しさん:03/01/28 01:07
↑すまん、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に絞り
あとは配布次第ってことで。


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


177 :デフォルトの名無しさん:03/01/28 03:28
>>172
キューに何も入ってないタイミングで、取り出そうとしたら駄目だろうね。
最初はスピンロックからでもやると良いかと。

65 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)