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

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

OSをつくろうpart3

1 :ひげぽん:02/07/19 21:10
独自にOSを作っているまたは、作ろうとしている人たちのための
スレッドになればと思います。

前スレッド
OSをつくろうpart2
http://pc3.2ch.net/test/read.cgi/tech/1024411711/

2 :ひげぽん:02/07/19 21:10

早速ですが、
現在のhigeposのステータスは、
firstboot ブート開始&secondboot以降をディスクからメモリに読み込んでjmp
secondboot プロテクトモードへ移行&third部にjmp
third Cでソースを書いてコンパイル&リンク return 'A';してaxレジスタに反映されることを確認

を試みているのだが
third部にjmpするとBochsが異常終了してしまう。

third部をアセンブラで書いた場合は通常に実行される(third.asm)
またうまくいかないCから作成されたバイナリファイルを
逆アセンブルすると出てくるものには、mox eax, ???以外の命令がある。
その命令のせいで不正終了しているのではと思っています。

なお現在の動かない最新のソースは↓にuploadしました。

http://oshigepon.tripod.co.jp/

どなたかお知恵を拝借させて下さい。

3 :デフォルトの名無しさん:02/07/19 21:36
>ひげぽん
kernel.cは16bitのコードを生成してるだろ?

4 :ひげぽん:02/07/19 21:38
>>3
${CC} -c -ffreestanding -Wall higepos_kernel.c -o ${BIN}/higepos_kernel.o
gccは32bitコンパイラだと思っていたのですが、16bitコードを吐くんですか?

5 :デフォルトの名無しさん:02/07/19 21:52
プロテクトモードに移行できてないのは気のせい?

6 :ひげぽん:02/07/19 21:57
多分出来ていると思います。↓
0153320000i[CPU  ] protected mode
0153320000i[CPU  ] CS.d_b = 32 bit
0153320000i[CPU  ] SS.d_b = 32 bit
0153320000i[CPU  ] | EAX=60000068  EBX=00000000  ECX=00150002  EDX=00000000
0153320000i[CPU  ] | ESP=00001000  EBP=00000000  ESI=000000ee  EDI=000b8006
0153320000i[CPU  ] | IOPL=0 NV UP DI PL NZ NA PE NC
0153320000i[CPU  ] | SEG selector     base    limit G D
0153320000i[CPU  ] | SEG sltr(index|ti|rpl)     base    limit G D
0153320000i[CPU  ] |  DS:0010( 0002| 0|  0) 00000000 000fffff 1 1
0153320000i[CPU  ] |  ES:0010( 0002| 0|  0) 00000000 000fffff 1 1
0153320000i[CPU  ] |  FS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
0153320000i[CPU  ] |  GS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
0153320000i[CPU  ] |  SS:0018( 0003| 0|  0) 00000000 00000000 1 1
0153320000i[CPU  ] |  CS:0008( 0001| 0|  0) 00000000 000fffff 1 1

7 :デフォルトの名無しさん:02/07/19 22:27
OSをつくろうpart1ってないの?

8 :デフォルトの名無しさん:02/07/19 22:31
俺も思た

9 :デフォルトの名無しさん:02/07/19 22:31
>>2
gccでコンパイルしてオブジェクトファイルにした物を
そのままcatしても起動できないのは当たり前。
-cでコンパイルした物は単なるcoff形式のオブジェクトファイルだから。

10 :デフォルトの名無しさん:02/07/19 22:34
>>4
kernel.o をそのままロードしてるの ? リンクは ? ヘッダーの除去は ?
できたらロードしてるバイナリもアップした方が助言しやすいと思う。

11 :9:02/07/19 22:36
gcc -c -ffreestanding -Wall kernel.c
strip --output-target=binary kernel.o
でどうかな?


12 :デフォルトの名無しさん:02/07/19 22:54
なぜに strip を使うのか。


13 :9:02/07/19 22:59
シンボルとセクションを除去して、生のバイナリを吐き出させるため。

14 :9:02/07/19 23:01
>gcc -c -ffreestanding -Wall higepos_kernel.c
>strip --output-format=binary higepos_kernel.o
>ndisasmw -u higepos_kernel.o
00000000 55 push ebp
00000001 89E5 mov ebp,esp
00000003 B861000000 mov eax,0x61
00000008 5D pop ebp
00000009 C3 ret
0000000A 90 nop
0000000B 90 nop

実行結果がこうなるんで、問題ないと思うが、いかが?

15 :ひげぽん:02/07/19 23:20
>>14(9)
bochsが↓というエラー出しながら異常終了してしまいます。
00000232034e[CPU ] prefetch: running in bogus memory

${CC} -c -ffreestanding -Wall higepos_kernel.c -o ${BIN}/higepos_kernel.o
#${LD} --oformat binary -Ttext 0x200 -o${THIRD} ${BIN}/higepos_kernel.o
${STRIP} --output-target=binary ${BIN}/higepos_kernel.o -o ${THIRD}
${NDISASM} -u $@ >${LIST}/third_disasm.asm

make と ndisasmの結果です。
00000000  55                push ebp
00000001  89E5              mov ebp,esp
00000003  B861000000        mov eax,0x61
00000008  5D                pop ebp
00000009  C3                ret
0000000A  8DB600000000      lea esi,[esi+0x0]

16 :ひげぽん:02/07/19 23:38
上のエラーと関係があるかは分かりませんが、
ひとつどうしても納得いかない点があるので質問させてください。

前提知識としてブート部のサイズは以下の通りです。
firstboot  512byte
secondboot 512byte

firstbootでは、2セクタ目から18セクタ分 0x100に読み込んでいます。
そのためsecondbootにjmpするときには
jmp 0x100:0000
のようにしています。

secondbootからthirdにjmpするときには、0x100+ 512 = 0x300
と指定していました。
しかしこれだとexceptionがあがるので
0x200を指定したところうまくいきました。
なんだか計算が合わない気がするのですが、どこで間違っているのでしょうか。


17 :デフォルトの名無しさん:02/07/19 23:47
一応貼っておこうよ。
http://oshigepon.tripod.co.jp/

18 :ひげぽん:02/07/19 23:48
>>17
ありがとう。忘れてました。

19 :17:02/07/19 23:50
っつうか、>>2で貼ってあるね。スマソ。

20 :デフォルトの名無しさん:02/07/20 00:02
すごい。いきおいだなこのスレッド。
がんばれひげぽん+名無しさん

21 :デフォルトの名無しさん:02/07/20 00:05
DJGPP
http://www.delorie.com/djgpp/

NASM
http://sourceforge.net/projects/nasm/

ひげぽんはこの2つを使ってるってことでOK?

22 :デフォルトの名無しさん:02/07/20 00:07
>16
何かがおかしい。

jmp 0x100:0000 はリニアアドレス 0x1000 のはず。
0x200 byte が second なら 0x1200 から third か?
なら jmp 0x200 であってる。
jmp 0x100:0000 で 0x1000 にセグメントを置きなおしてるから。
なぜに 0x100 + 512 なのか?


23 :ひげぽん:02/07/20 00:09
>>21
ありがとう。
Bochs
http://bochs.sourceforge.net
も追加しておきます。

24 :デフォルトの名無しさん:02/07/20 00:09
>>16
0x200で上手くいったのは [org 0x100]を指定していないからだろ。
orgを指定すれば 0x300で上手く行くだろうに。

25 :ひげぽん:02/07/20 00:11
>>22
jmp 0x100:0000 はリニアアドレス 0x1000 のはず。
>0x200 byte が second なら 0x1200 から third か?
>なら jmp 0x200 であってる。
>jmp 0x100:0000 で 0x1000 にセグメントを置きなおしてるから。
>なぜに 0x100 + 512 なのか?
すいません。
一瞬で自分の勘違いを理解しました。
かなり赤面の勘違いです。
ご指摘ありがとうございました。



26 :デフォルトの名無しさん:02/07/20 00:13
>>22をみて気づいたが、ひげぽんにつられて俺も間違えちまった。
>>24は、 [org 0x1000] で、 jmp 先は 0x1200 だな。
まあ org と jmp 先アドレスがちょうど 0x200ずれてれば上手く行っちゃうんだけど、、、。

27 :ひげぽん:02/07/20 00:14
お詫びに最近の私のお気に入りを提供します。

http://www.osdev.org/cgi-bin/projects.cgi
たくさんのOS開発プロジェクトへのリンク集です。
多くのプロジェクトはソースを公開していて大変勉強になります。
もちろん英語ですが・・・

28 :ひげぽん:02/07/20 00:16
ひとつ疑問が解決したのですっきりしました。
もうひとつのほうは、いまだ解決しておりません。
明日がんばってみます。

29 :デフォルトの名無しさん:02/07/20 00:18
#define VRAM ((char*)0xB8000)

void hige(void) {
VRAM[0] = '2';
VRAM[2] = 'c';
VRAM[4] = 'h';
for(;;);
}

ひげぽん、動いたよ。
エラーになったのは、returnで処理を返していたからだろ。
キッチリhangしないとダメポ


30 :デフォルトの名無しさん:02/07/20 00:19
>>28
もうひとつのほうとは?

31 :デフォルトの名無しさん:02/07/20 00:19
>22
相対じゃなかったか、とか言うのは?

↓のが良いと思う。

jmp _third
times 512-($-$$) db 0
_third:


32 :ひげぽん:02/07/20 00:20
まだ、だいぶ先の話だとは思うのですが、
OSの設計・開発を本気で始めるときに
共同開発者や、協力者ってどう集めればいいんでしょうか?
source forgeみたいなところで、まずはきちんとプロジェクトとして
始動しておいたほうが良いのでしょうか?

33 :ひげぽん:02/07/20 00:25
>>29
ありがとう!!!!
できましたよ。
今日は遅いので明日ちょっと改良してアップロードさせて
いただきます。

すごいやる気が出てきました。

>>30
↑解決しました。
>>31
ありがとう。それも試してみます。


34 :デフォルトの名無しさん:02/07/20 00:30
ちょとリフェガメつくてみた。
--------
typedef short word;
typedef char byte;

#define MAX_HEIGHT 24
#define MAX_WIDTH 80
#define VRAM ((byte *)0xb8000L)
#define BUFF ((word *)0x08000L)
#define AT(X,Y) ((X)+(Y)*80)

void copy_buff()
{
int i;
for(i=0;i<MAX_HEIGHT*MAX_WIDTH;i++){
VRAM[i*2]=BUFF[i];
}

}

void buff_clean()
{
int i;
for(i=0;i<MAX_HEIGHT*MAX_WIDTH;i++){
BUFF[i]=' ';
}
}

void init()
{
BUFF[AT(4,4)]='*';
BUFF[AT(4,5)]='*';
BUFF[AT(4,6)]='*';

BUFF[AT(41,10)]='*';
BUFF[AT(42,10)]='*';
BUFF[AT(40,11)]='*';
BUFF[AT(41,11)]='*';
BUFF[AT(41,12)]='*';
}



35 :デフォルトの名無しさん:02/07/20 00:30
つづき
------
int count(int p)
{
int i,c;

#if 0
int around[8]={-81,-80,-79,-1,1,79,80,81}; /* こうしたいところだが */
#else
int around[8]; /* こうしないと上手く行かない */
around[0]=-81;
around[1]=-80;
around[2]=-79;
around[3]=-1;
around[4]=1;
around[5]=79;
around[6]=80;
around[7]=81;
#endif

for(i=c=0;i<8;i++)
if(VRAM[(around[i]+p)*2]=='*')
c++;
return c;

}

void update()
{
int x,y;
for(y=1;y<MAX_HEIGHT-1;y++)
for(x=1;x<MAX_WIDTH-1;x++){
int c=count(AT(x,y));
if(c==3 || (c==2 && VRAM[AT(x,y)*2]=='*'))
BUFF[AT(x,y)]='*';
else
BUFF[AT(x,y)]=' ';
}
}

void c_main()
{
buff_clean();
init();
for(;;){
copy_buff();
update();
}
}


36 :29:02/07/20 00:33
ほんとはもっとCっぽくやりたかったんだけど、
stripでオブジェクトを作ると、
文字列リテラルとかが入っているオブジェクトが破損されるから出来なかった。

37 :デフォルトの名無しさん:02/07/20 00:38
>>36
strip しても文字列は消えないんじゃない?
ただリンクを上手くしないとdata領域に上手くアクセスできないってのはあるけど。

38 :ひげぽん:02/07/20 00:40
>>34
>リフェガメ
ってどんなものですか??

39 :29:02/07/20 00:43
>>37
たとえば、
#define VRAM ((char*)0xB8000)

void hige(void) {
VRAM[0] = '2';
VRAM[2] = 'c';
VRAM[4] = 'h';
for(;;);
}
char* text="2ch";

このソースのリスティングが下のようになっちゃう。
やっぱり、きちんとリンカを使わないとだめなようです。
MinGW標準だと-oformat binaryが使えないので、
どっちにしろダメポってかんじですか。

00000000 1A00  sbb al,[eax]
00000002 0000   add [eax],al
00000004 0500800B00  add eax,0xb8000
00000009 32C6  xor al,dh
0000000B 0502800B00  add eax,0xb8002
00000010 63C6  arpl si,ax
00000012 0504800B00  add eax,0xb8004
00000017 68EBFE3263  push dword 0x6332feeb
0000001C 68  db 0x68
0000001D 00  db 0x00
0000001E 90  nop
0000001F 90   nop


40 :デフォルトの名無しさん:02/07/20 00:47
>>38 英語で書くと life game

41 :デフォルトの名無しさん:02/07/20 00:48
>>15
> bochsが↓というエラー出しながら異常終了してしまいます。
> 00000232034e[CPU ] prefetch: running in bogus memory

bochs のソースを grep すると...

if ( new_phy_addr >= BX_CPU_THIS_PTR mem->len ) {
 // don't take this out if dynamic translation enabled,
 // otherwise you must make a check to see if bytesleft is 0 after
 // a call to prefetch() in the dynamic code.
 BX_ERROR(("prefetch: running in bogus memory"));
}

となってるから、どうもメモリー容量を越えたみたい。
higepos_kernel.c の hige() は、誰からも呼ばれてないから関数から戻ったら
即暴走してメモリーを使い尽くしたんだと思う。
とりあえず...

static char foo();

void hige()
{
 char a;
 a = foo();
 while(1){
 }
}

static char foo()
{
 return 'A';
}

とでもして試してみて。

42 :デフォルトの名無しさん:02/07/20 00:51
解決済みだったり

43 :デフォルトの名無しさん:02/07/20 00:52
>>41
つうか、return するならアセンブリではcallにしろよ。>ひげぽん

44 :41:02/07/20 01:01
>>42
ショボーン...。

45 :デフォルトの名無しさん:02/07/20 01:22
"OSを作ろう"と言うスレがありました。
散々叩かれて消えていったとさ。。。

46 :デフォルトの名無しさん:02/07/20 01:36
>>45
叩いたつもりになってるのは、このスレの雰囲気が読めてない君だけだよ。
ちょっと内容が高度になってきて内容が理解できないのはわかるが、おとなしく
他のスレに行きな。

47 :デフォルトの名無しさん:02/07/20 01:44
アドレスをいじったりするようにすると何かと面倒になってくるから、
今の内からオブジェクト配置のリロケータを書いた方が良いのかな、とか思タヨ

48 :デフォルトの名無しさん:02/07/20 01:44
>>7へのレスなんですけど。

49 :デフォルトの名無しさん:02/07/20 06:04
>>45
どのスレ?
http://pc.2ch.net/tech/kako/1006/10065/1006524791.html
http://pc.2ch.net/tech/kako/1022/10226/1022685075.html
http://piza2.2ch.net/tech/kako/998/998113110.html
http://piza2.2ch.net/tech/kako/998/998502881.html

50 :デフォルトの名無しさん:02/07/20 07:54
>>48
あ〜〜〜、そう言うことか。唐突にでてきたように見えたから、単なる嵐かとおも
たよ。スマソ。で、結局どのスレなの ?

51 :デフォルトの名無しさん:02/07/20 12:11
>>50
( ´,_ゝ`)プッ ダセェ

52 :デフォルトの名無しさん:02/07/20 13:45
結局このスレの開始スレってどれ?

53 :デフォルトの名無しさん:02/07/20 13:49
>>ALL
まずはFDにおさまるOSをつくろうぜ


54 :デフォルトの名無しさん:02/07/20 15:45
誰かブートローダー作ってる?
漏れFATからロードするローダー今作ってるが、
誰かが作るならやめる。

55 :デフォルトの名無しさん:02/07/20 16:07
良スレの予感

56 :45:02/07/20 17:02
ごめんよ>>50
同じタイトルのスレ見覚えがあったんだけどOS板でした…
結局part1はどれかわからん。とにかくひげぽん頑張ってね〜
興味あるんだけど漏れじゃ何もできんよ。。。
初めて読む486読んで勉強してるところです。

57 :ひげぽん:02/07/20 20:18
>>53
>>ALL
>まずはFDにおさまるOSをつくろうぜ
そうですね。ひげぽんの当面の目標も↑と一緒です。

>>56=45
ありがとう。
>興味あるんだけど漏れじゃ何もできんよ。。。
>初めて読む486読んで勉強してるところです。
そんなことはないですよ、このスレッドの前スレから目を通してもらえれば
すくなくとも、フロッピーからブートするところまではいけると思いますよ。

OSを作ることに興味がある人はぜひご参加ください。







58 :デフォルトの名無しさん:02/07/20 21:02
>>54
俺も、ひげぽんのおかげでフロッピーからブートするところまではいける
ようになったよ。(つーか、ひげぽんのソースをちょっといじっただけと
も言えるが...。) で、次にカーネルのコアに相当するものを読み込む
ローダーを作ろうと考えてたんだけど、もう作っている人いるのか...。

そろそろファイルシステムとか実行ファイル形式とかメモリー管理とか
決めないといけない状況かな...。

59 :ひげぽん:02/07/20 21:09
>>58
>そろそろファイルシステムとか実行ファイル形式とかメモリー管理とか
>決めないといけない状況かな...。
そうですよね。
ファイルシステムってどの時点で決めざるを得なくなるんだろう。
OSブート部に含まれるシステム初期化部分に含まれるんですよね。
いまは、VGA部のライブラリを書こうと思っているのですが・・・

良いサンプルとかありますか?
higeposの方針として
一番ハードウェアよりのレイヤーは、システムライブラリ群として実装し
それをcppのクラスでラップしようと思っています。

たとえばVGA、FILEクラスとか・・・
もしx86以外に移植する場合はライブラリを
直すようにすればよいかな・・・
なんて考えております。




60 :54:02/07/20 21:27
>>58
フロッピーからブートだけど、
FAT12形式の方が何かと便利なので、
FAT上にファイルとしてhigeboot.bin(2nd boot program)を設置して
それに実行を移すプログラムを書いてるって事。

61 :54:02/07/20 21:28
>>59
フロッピーって時点でFAT12で決定じゃないんですか?
それとも、フロッピーもオリジナルのファイルシステムにする?

62 :ひげぽん:02/07/20 21:45
>>61
>フロッピーって時点でFAT12で決定じゃないんですか?
>それとも、フロッピーもオリジナルのファイルシステムにする?
ファイルシステム実は良く分かってないっす(笑)
ファイルシステムは、どの時点で決定するものなのでしょうか。



63 :デフォルトの名無しさん:02/07/20 22:10
bochs-1.4.1で、除数 <= edx
の時に除算命令(div)を発行すると、
除算命令で無限ループになるんだけど、
これってx86の仕様?


64 :58:02/07/20 22:16
>>61
> フロッピーって時点でFAT12で決定じゃないんですか?
> それとも、フロッピーもオリジナルのファイルシステムにする?
それ以外にも、EXT2 (Linux), NTFS (WindowsNT), BSD FFS (FreeBSD),
HFS (Mac) とかもあるからどうするものかと...。

>>62
> ファイルシステムは、どの時点で決定するものなのでしょうか。
普通、カーネル自体は普通のファイルの形式にすることが多い。そうすれ
ば、カーネルを再構築した時に単にそのファイルを置き換えるだけで済む
から。その為には、second_boot 当たりがファイルシステムを理解して
読み出すことが必要。と言うことで、そろそろかなぁと思った次第。
とりあえずは、開発システムのファイルシステムに合わせておくのがいい
かと思う。

65 :54:02/07/20 22:22
>>64
えーっと、いきなりハードディスクで動かすのを前提で進めるの?
まず、フロッピー運用でウインドウシステムなりコンソールなりまで出さないの?

EXT2もNTFSもフロッピーに作れるファイルシステムじゃないし、
今の時点では考えてなかったんだけど。


66 :ひげぽん:02/07/20 22:23
>>64==58
>普通、カーネル自体は普通のファイルの形式にすることが多い。そうすれ
>ば、カーネルを再構築した時に単にそのファイルを置き換えるだけで済む
>から。その為には、second_boot 当たりがファイルシステムを理解して
>読み出すことが必要。と言うことで、そろそろかなぁと思った次第。
なるほど、ありがとうございます。
まったく勉強不足で申し訳ないのですが、
ファイルシステムの実装はどのくらいのボリュームなのでしょうか。
またファイルシステム毎にやはり難易度は違うのでしょうか。




67 :デフォルトの名無しさん:02/07/20 22:30
>>63
> 除算命令で無限ループになるんだけど、これってx86の仕様?
命令が無限ループになるなんて言う仕様/バグがあるとは考えにくい。
(実プロセサはもとより、bochs にも。) 除算エラー例外のハンドラが
単純に IRET してるとかしてない ?

68 :58:02/07/20 22:52
>>65
> EXT2もNTFSもフロッピーに作れるファイルシステムじゃないし、
すまん、NTFS はダメだね。EXT2 もダメなのか...。
ところで、WindowsNT の FD は FAT12 だけど、Linux の FD ってどう
いうフォーマットなの ?

>>66
> ファイルシステムの実装はどのくらいのボリュームなのでしょうか。
とりあえず、FAT を実装したソースが...
http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/msdosfs/
からダウンロードできるみたい。これは、FAT12/16/32 を含んでいて、
更に書き込みをサポートしているから、ブートローダーとしてならこれ
の半分ぐらいにはなると思う。

> またファイルシステム毎にやはり難易度は違うのでしょうか。
これは、当然そう。同じサイトに、ntfs とか isofs とかもあるから
見比べてみればいいかも。

69 :デフォルトの名無しさん:02/07/20 22:55
LinuxもFAT12
つーか、PC互換機ではほとんどのOSで
フロッピーのファイルシステムはFAT12。

70 :デフォルトの名無しさん:02/07/20 23:00
FAT12の亜種で、紛れもなくFAT12なんだけど、
0x0b〜のBPBを潰してある形式もあったね。
たぶん、BPB決め撃ちなんだと思うけど、
ウインドウズからは読めなかったはず。

71 :ひげぽん:02/07/21 00:01
>>68
>>69
なるほどフロッピーならFAT12ということですね。
FAT12の規格・仕様がきちんと存在して、
それを実装するということですね。



72 :ひげぽん:02/07/21 00:10
リンク時に下記のエラーが出てしまい困っています。
ld.exe: warning: cannot find entry symbol startKernel; defaulting to 00000200
../bin/higepos_kernel.o(.eh_frame+0x11):higepos_kernel.cpp: undefined reference to `___gxx_personality_v0'

やろうとしていることは、
higepos_kernel.cppに実装していたVRAMアクセス文字列出力関数を
vga.cppで実装し、呼び出すことです。

vga.cppで実装している_sysPrint2ch関数をhigepos_kernel.cppで
呼び出しているのですが、リンク時に
higepos_kernel.cpp: undefined reference to `___gxx_personality_v0'

というエラーが出てしまいます。
もちろん`___gxx_personality_v0'というものには、
まったく覚えがありません。
リンカのオプションが悪いのでしょうか。

このエラーがエラーが出てしまうソースは、
http://oshigepon.tripod.co.jp/
におきました。



73 :ひげぽん:02/07/21 00:12
ソースのコメントはDoxygen用に記述することにしました。

ファイルシステム難しそうだなあ。

74 :デフォルトの名無しさん:02/07/21 00:20
>>72
リンク時にエントリーを指定しても意味がない。
リンク時先頭にあるコードから実行されるようになる。

2つ目のメッセージは、c++のランタイム関数かと。
例外処理とかその他で利用する奴(要するに必須)でない?


>>73
まだファイルシステムサポートは書く必要ないだろ
ルートからファイルを一つ読み出せればいい

理由:
 プロテクトモード移行前のファイルシステムドライバを書いても、
 結局2nd bootで利用するだけになり、意味がない。



75 :デフォルトの名無しさん:02/07/21 00:21
c++はいろいろあって面倒だから、やめた方が無難だと思うが、どうか。

76 :ひげぽん:02/07/21 00:24
>>74
>リンク時にエントリーを指定しても意味がない。
>リンク時先頭にあるコードから実行されるようになる。
やっぱりそうですよね。
私もそう思っていたのですが、自信が無くて・・・・

>2つ目のメッセージは、c++のランタイム関数かと。
>例外処理とかその他で利用する奴(要するに必須)ではない?
リンク時にこの必須でない関数をリンクしないオプションがあるのでしょうか。
それともライブラリを見つけてリンクしなければいけないのかな?


77 :ひげぽん:02/07/21 00:26
>>75
>c++はいろいろあって面倒だから、やめた方が無難だと思うが、どうか。
~~~~~~~~~~~~~~~~~~~~~~~~~
   ↑
  この辺詳しく聞きたいです。




78 :デフォルトの名無しさん:02/07/21 00:31
>>76
>リンク時にこの必須でない関数をリンクしないオプションがあるのでしょうか。
>それともライブラリを見つけてリンクしなければいけないのかな?

gccはよくしらんのだけど、RTTIと例外を無効にするオプションを使ってみたら?

>c++はいろいろあって面倒だから

たとえば、上に上げた例外や、他言語(アセンブラが主かな)とのシンボル名の整合
あとは、cだとランタイムを使わなければ良いだけでも、
c++ではnew演算子とか言語自体の機能なんで、
デフォルトでいらないコードがリンクされたり、それの準備のための初期化ルーチンが用意される。


79 :デフォルトの名無しさん:02/07/21 02:14
ファイルシステムまだ早いやろ。
Second で FAT12 からファイル読めるのは便利だが。
32bit モードでやるならディスクアクセス BIOS に頼るのもなんだし。
IDT 作ってキーボード割り込み捕まえる辺りのが先では?


80 :デフォルトの名無しさん:02/07/21 02:25
minix fs とかいってみるテスト

81 :デフォルトの名無しさん:02/07/21 10:15
>>72
> このエラーがエラーが出てしまうソースは、
> http://oshigepon.tripod.co.jp/
> におきました。
ちょっと話題がずれるんだけど、ソースコードアップルーチンにバグない ?
なんか、#include の後ろがなくなってるみたいなんだけど...。
HTML は、'<' や '>' は、特別扱いだからそこら当たりが怪しいかと。
あと、& 等も要注意だね。

82 :ひげぽん:02/07/21 11:09
>>81
不具合修正いたしました。
適当に作っていたのでまったくタグの事なんか気にしてなかった(鬱)

83 :ひげぽん:02/07/21 11:38
>>78
>ld.exe: warning: cannot find entry symbol startKernel; defaulting to 00000200
>../bin/higepos_kernel.o(.eh_frame+0x11):higepos_kernel.cpp: undefined reference to `___gxx_personality_v0'
のエラーが出てしまう件ですが

>gccはよくしらんのだけど、RTTIと例外を無効にするオプションを使ってみたら?
例外を無視するオプション  -fno-exceptions
を使ったらばっちりうまくいきました。
ありがとう。

84 :デフォルトの名無しさん:02/07/21 12:50
higepos
osask

85 :ひげぽん:02/07/21 19:10
vga.cppをちょこっと更新しました。
↓こんな感じで使えるようになりました。
    _sysInitVga();
    _sysClearScreen();
    _sysPrint(" Higepos Kernel start!!\n Powered by 2ch\0");

http://oshigepon.tripod.co.jp/

[問題点・課題]
文字列の終端を'\0'で捕まえようとしているが出来ない。
'\b', '\t'に対応する。
日本語の表示


86 :デフォルトの名無しさん:02/07/21 19:45
>>85
_sysPrintとか_sysPutCharacterっていわば低レベル文字出力でしょ?
\bとか\tはレイアウトを扱うもっと高レベルな関数でサポートするのが良いと思う

87 :デフォルトの名無しさん:02/07/21 19:57
>>85
> 文字列の終端を'\0'で捕まえようとしているが出来ない。
どうなっちゃうの ? ちょっと意味が良くわからない。

> '\b', '\t'に対応する。
'\b' は、
if(0 < curX){
 backwardCursor();
 _sysPutCharacter(' ');
 backwardCursor();
}

'\t' は、
while((curX % 8) != 0){
 _sysPutCharacters(' ');
}
あたりでどうか。(\t の 直後に \b されるとちょっとまずいけどね。)

> 日本語の表示
これは、ちょっと難しい。そもそもフォントをどのように扱うかが問題と
なる。とりあえず優先順位は落としたほうがいいと思う。

88 :ひげぽん:02/07/21 20:05
>>86
>_sysPrintとか_sysPutCharacterっていわば低レベル文字出力でしょ?
>\bとか\tはレイアウトを扱うもっと高レベルな関数でサポートするのが良いと思う
あったら便利なのかなと思ったのですが、後述するように\tはめんどくさいですよね。

>>87
> '\b', '\t'に対応する。
>'\b' は、・・・
\bはそんな感じですね。

\tは、\bされたときにどうするかというが非常に面倒くさいですね。
現時点でそこまでして実装するのか!!みたいな・・・










89 :ひげぽん:02/07/21 20:08
↑無駄な空白が出来てしまいましたごめんなさい。
>>87
>> 文字列の終端を'\0'で捕まえようとしているが出来ない。
>どうなっちゃうの ? ちょっと意味が良くわからない。
C言語では文字列の終端は'\0'ですよね?

そこで
vga.cppでは

void _sysPrint(char* str) {
     for (; *str != '\0'; str++) {
         _sysPutCharcter(*str);
     }
     return;
}
のように実装しています。

で呼び出し側で_sysPrint("higepon");とやると
無限ループになってしまうんです。
_sysPrint("higepo\0");だとOK




90 :デフォルトの名無しさん:02/07/21 20:35
>>89
bochsdbgは試してる?
指定アドレスにブレークポイント張れるから、
ステップ実行してみるといいかも

91 :87:02/07/21 20:38
>>89
> で呼び出し側で_sysPrint("higepon");とやると
> 無限ループになってしまうんです。
> _sysPrint("higepo\0");だとOK
う〜〜〜ん、わからん。_sysPrint("higepon"); とやった時のバイナリ
イメージアップできます ?

92 :ひげぽん:02/07/21 20:43
>>91
いま、試してみたら
_sysPrint("higepon");
でも正常動作しました。
何か違うところのバグっぽいので調べてみます。
お騒がせいたしました。

93 :デフォルトの名無しさん:02/07/21 20:52
質問いいっすか?
firstbootで18セクタ読んで、
1000h:0000h 2nd boot
1000h:0200h kernel
という配置ですよね?
2nd bootの最後でkernelのアドレスにジャンプしていると思うのですが、
kernelの先頭位置には文字列が来てるじゃないですか。
どうして実行できるんですか?

94 :ひげぽん:02/07/21 21:00
>kernelの先頭位置には文字列が来てるじゃないですか。
>どうして実行できるんですか?
kernelの先頭に文字列とはどういう意味でしょうか?
あれれ何か変なことやらかしてますか?→私




95 :デフォルトの名無しさん:02/07/21 21:04
ていうかひげぽんさあ。
あんたマジすごいよ。
なんですぐ、VGAとか書けちゃうの????

あー俺って、おちこぼれって感じ。

96 :93:02/07/21 21:14
逆アセンブルしてみました。

Kernel.binのダンプ
20 48 69 67 65 70 6f 73 20 4B 65 72 6e 65 6c 20 | Higepos Kernel |
73 74 61 72 74 21 21 0a 20 50 6f 77 65 72 65 64 |start!!. Powered|
20 62 79 20 32 63 68 00 00 90 55 89 e5 83 ec 08 | by 2ch...U.....|
〜(略)〜

0008:00001200 20 48 69     and [eax+0x69],cl ; " Hi"
0008:00001203 67 65 70 6f   gs a16 jo 0x76  ; "gepo"
0008:00001207 73 20      jnb +0x20     ; "s " *1
〜(略)〜
0008:00001229 90        nop
0008:0000122a 55        push ebp
〜(略)〜

2nd bootからメッセージの先頭に飛んで、
たまたま*1の時の"s "のオペコードが jnb +0x20で、
とんだ先が正常に実行できるコードだったというだけみたい。

で、'\0'の問題は、'\0'を入れたことによって、
「たまたま」とんだ先が正常なコードになっただけで、
cのソースが悪いわけじゃなかったみたい。


97 :93:02/07/21 21:15
2nd bootからとんだ先のアドレスが
0008:00001200なので、メッセージ(文字列)の中にjumpしてるって事。

98 :93:02/07/21 21:17
ついでに言うと、正常なエントリポイント(startKernel)のアドレスは
0008:00001261になっているはず

99 :デフォルトの名無しさん:02/07/21 21:21
もしかして、ひげぽんって動いたら逆アセンブルとかステップ実行とかやらないの?

100 :ひげぽん:02/07/21 21:23
>>93
この場合、文字列の中にjmpしてしまうことはどのように回避すれば
良いのでしょうか。

文字列部分がkernelの先頭に来てしまうということは、
文字列を変更した場合は、startKernelのエントリポイントが
変わってしまうんですよね。
混乱してきました。

101 :ひげぽん:02/07/21 21:26
>>99
>もしかして、ひげぽんって動いたら逆アセンブルとかステップ実行とかやらないの?
とりあえず、やってませんでした。<(_ _)>


102 :93:02/07/21 21:26
>>100
ほんとスマン、詳しくないんだけど。
リンカスクリプトで、配置をコントロールできるんじゃないの?

103 :デフォルトの名無しさん:02/07/21 21:28
てな感じでお手軽回避か?

void startKernel(void) {
body();
}

void body(void) {
_sysInitVga();
_sysClearScreen();
_sysPrint(" Higepos Kernel start!!\n Powered by 2ch\0");
while (true) {
}
}


104 :93:02/07/21 21:29
もしかすると、文字列を持ったり、静的変数を使う場合、
オブジェクト形式を規定して適切にリロケーションしないとダメなのかも知れない。
それから、今はstatic int curXとかは0008:00000000に配置されているはず。


105 :93:02/07/21 21:30
>>103
それでも回避は不可能。
デフォルトで、リテラルはまとめられて先頭に配置されているみたい。

106 :デフォルトの名無しさん:02/07/21 21:39
// kernel.c
void startKernel(void) {
body();
}

// body.c
void body(void) {
_sysInitVga();
_sysClearScreen();
_sysPrint(" Higepos Kernel start!!\n Powered by 2ch\0");
while (true) {
}
}

//
ld -T simple.ls kernel.obj body.obj -o a.exe
objcopy a a.bin -O binary

//
OUTPUT_FORMAT(pei-i386)
SECTIONS
{
. = 0x1200;
.text : { *(.text) }
.data : { *(.rodata) }
.data : { *(.data) }
.bss : { *(.bss) }
}

//
by MinGW
てな感じは?


107 :デフォルトの名無しさん:02/07/21 21:44
>>106
無理みたいですね

108 :デフォルトの名無しさん:02/07/21 21:55
無理というか、コードには反映されているね
やっぱり、実際のデータを動的に再配置するしか方法は無いみたいですが。

109 :デフォルトの名無しさん:02/07/21 22:07
解決法は、以下の二つだと思う...
1. リンカスクリプトで、コードセグメントを先頭に持っていく。
2. 実行ファイル形式に先頭アドレスの情報を埋め込んで、ローダーがそれを解
釈して指定された先頭アドレスにジャンプする。
組み込みなんかでは、1. の方が多い。通常の PC アプリケーションでは 2. の
方が多いと思う。私は、VC++ でやっていて標準の link.exe では、1. ができ
ないので、2. でやれないか、.exe ファイルフォーマット (PE 形式) を調査
中。

110 :106:02/07/21 22:18
む〜 MinGW で試してきた。
文字列は先頭に来なくなり main が先頭に来ている。
djpp とか linux版 gcc とかは無理なのかな?

いい加減だったので訂正。

// りんく手順
ld -T simple.ls kernel.obj body.obj vga.obj -o a.exe
objcopy a.exe a.bin -O binary

// simple.ls
OUTPUT_FORMAT(pei-i386)
SECTIONS
{
. = 0x1200;
.text : { *(.text) }
.data : { *(.data) }
.bss : { *(.bss) }
}

// 以下より参考
ttp://www.sra.co.jp/public/sra/product/wingnut/

ld マニュアル(binutils-2.11.2) の
3. リンカスクリプト の
3.3 簡単なリンカスクリプトの例 から


111 :デフォルトの名無しさん:02/07/21 22:27
>>110
startKernelからbodyを呼び出すのが重要だったんですね。
リンカスクリプトは要らないようです。
リンクすると、自然に以下の配置になるようです。

obj0::data
obj0::code
obj1::data
obj1::code

objn::data
obj0::code



112 :ひげぽん:02/07/21 23:18
上記有用な議論踏まえて(ありがとうございます)

ソース構成を変えたものをアップロードしました。
ばっちりうまく動いております。
http://oshigepon.tripod.co.jp/

ところで例のMinix本でファイルシステムの勉強をしてました。
実現したい機能等はMinixのものと同様かそれ以上なのですが
かけるコードは、絶対それ以下の自信があります(半分本気)





113 :デフォルトの名無しさん:02/07/21 23:34
http://www.afis.to/~mone/osask/osask_ml/200105/msg00002.html
パクリだけど、↑を実装してみるとか

114 :デフォルトの名無しさん:02/07/21 23:37
>>112
ていうか、ファイルシステムの議論って今して意味あるのか?
HDDで運用するfsを決めるより、FDDでの運用をどうするかを決めないといけないし、
カーネルの構造と、デバイスドライバとのインターフェイスを考えないといけない。
大体、fs非依存ではなく、fs依存型のOSを作るつもりですか?

115 :ひげぽん:02/07/21 23:50
>>113
>>114
>ていうか、ファイルシステムの議論って今して意味あるのか?
ファイルシステムに関して、自分の知識不足を感じたので
勉強しただけっす。

>カーネルの構造と、デバイスドライバとのインターフェイスを考えないといけない。
>大体、fs非依存ではなく、fs依存型のOSを作るつもりですか?
カーネルの構造は考えなければいけないですね。
まあその前にもっと基礎的な部分で足りないところがいろいろとありますが。


116 :デフォルトの名無しさん:02/07/22 00:31
ファイルシステムまだ早いって。(勉強するのはまた別で)
それより、IDT作って、キーボード、FDC、IDEインタフェース
この辺りの割り込み受け付けて通信できないと。
ディスクアクセスが出来なくてファイルシステムが意味ある訳ない。


117 :デフォルトの名無しさん:02/07/22 01:03
基本的なフロッピードライバやIDEドライバって、
マイクロカーネルのOSでもカーネルに内蔵するの?
そうでないなら、どうやってロードしてるんだろ。

カーネル自体はブートストラップからの一連の処理で起動するのは分かるけど、
カーネルが記憶装置からドライバをロードするには、
その記憶装置へのアクセスを提供するドライバが必要だし。


118 :デフォルトの名無しさん:02/07/22 01:17
キーボード割り込みどうすればいいのかわかんない

119 :過去ログ読んでないから外してたらごめん:02/07/22 03:25
DOSなんかだと確かブートシステムが最小限のFileSystemアクセスのドライバを持っていて
FDでもHDDでもルートディレクトリのファイルだけは読みこめるようになってる。
で、そのディスクアクセスはどうやるかっていうとBIOS(int13h)経由でしょ。

FAT12前提でやるなら、ルートディレクトリの位置は決まっているはず。
これもうろ覚え(というよりPC98の記憶)だけど、
同じDOSでも古いバージョンだとIO.SYSのディレクトリエントリの位置も
ファイル本体の開始位置も決まってたような気がする。
「IO.SYSはこのセクタから始まる」って決め打ちで読みこみね。

まあ、ブートセクタ(ミニマムローダ)読みこみ→ローダー読みこみ(bios経由)として、
この後のカーネルイメージとドライバの読みこみを
リアルモードでやるかプロテクトモードでやるか、どっちが良い(あるいは楽)かな。
リアルモード(Win9x式)だと、16bitでファイルシステムにアクセスするために
結局同じものをもう1つ作ることになるけど、
biosを使えば手軽だし、読みこんでから配置をいじったりできる。
プロテクトモード(WinNT式)だと、ローダーに制御が渡ったらすぐにモード遷移するから
ファイルシステムサポート部の他に、FDDやHDDにアクセスする(最小限の)ドライバも
ローダーに組みこむ事になる(ファイルシステムにアクセスできないと、
ドライバを読みこめないから)。
ただ、ドライバやファイルシステム自体は全て32bitモードで管理できる。

個人的には、(とりあえずの間は)ブートはブートと割りきって
ローダーの位置決め打ちでbiosを使って読みこんで
GDT,IDTのセットアップやカーネルイメージのロードまでリアルモードでやっちゃって
カーネル本体の動作を見える(楽しめる)ようにした方がいい気がする。

120 :デフォルトの名無しさん:02/07/22 18:35
>>119
NT系でもBIOSで読んでるだろ。
ブートローダ専用ドライバなんて話、DDKのドキュメントでも見た覚えないし、
手元のSCSIドライバディスクにも入ってない。

121 :デフォルトの名無しさん:02/07/22 18:43
>>120
NTでドライバを読んでいるのってプロテクトモード移行後でしょ
で、そのドライバを読み込むのにBIOS使ってるの?

122 :デフォルトの名無しさん:02/07/22 20:22
>>121
BIOS呼ぶときは当然、リアルモードなりV86モードなりになってるだろ。
各ベンダにブートローダ専用ドライバを作らせるよりよっぽど現実的。

123 :デフォルトの名無しさん:02/07/22 20:28
各ベンダ毎ってなんだよ。
FDDとIDEドライバ(相当のもの)をNDLDRに入れるだけじゃないか。

124 :デフォルトの名無しさん:02/07/22 20:31
リアルモードなりV86モードなりになってBIOS呼ぶよりよっぽど現実的。

125 :デフォルトの名無しさん:02/07/22 20:38
それだとカーネルやローダーを置くファイルシステムが、
ローダーやカーネルをコンパイルした時点で固定されちゃうじゃん。

126 :デフォルトの名無しさん:02/07/22 20:53
任意のファイルシステムからブート出来るOSってあまりないと思う

127 :デフォルトの名無しさん:02/07/22 21:01
>>123
ふーん、全てのIDEやSCSIコントローラはまったく同じ方法で制御できるのか。
それならMSが1つドライバ作れば済む話だね。

128 :デフォルトの名無しさん:02/07/22 21:13
実際にSCSIシステムでは
ブート時にntldrやntdetectの他にntbootdd.sysが必要らしいんだけど
これはSCSIドライバではないのかな

129 :128:02/07/22 21:14
あ、俺は知らないから、純粋に聞いてるだけだよ。

130 :120:02/07/22 21:25
http://www.google.co.jp/search?q=ntbootdd.sys&ie=UTF-8&oe=UTF-8&hl=ja&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja

フルバージョンのSCSIドライバらしい。
となると、nsoskrnl.exe、hal.dll、bootvid.sys、pci.sys、scsiport.sys、ntbootdd.sysあたりまでがBIOSでロードか?

131 :ひげぽん:02/07/23 00:48
次はIDTかな。
キーボート割り込み処理が目標・・・

132 :ろうひ男爵:02/07/23 01:25
FDDオンリーの簡易DOSなら作ったことあるけど、
MINIXみたいなのをつくるの?凄いですね。

133 :デフォルトの名無しさん:02/07/23 01:29
すみません。
このスレに触発されかかって、OSを作ってみたいと思いかけているのですが。
PowerPCをCPUに選びたいんです。
その場合でもIntel系と作る手順というのは変わらないのでしょうか?

134 :デフォルトの名無しさん:02/07/23 01:32
>>132
*nix系なのかぁ。
BeやBTRONみたいにRT系の方が面白そうだよなぁ

>>133
ブートはこんなに泥臭くないとおもうが。


135 :デフォルトの名無しさん:02/07/23 01:54
>>119
ドライバまで含めてブートローダで読み込みかぁ。

なら、リアルモードのうちに BIOS でメモリに配置で読み込みのみならできそうか。
ファイルシステム意味あるかも?

>>118
PIC(8259A)設定 > IDTに割り込みハンドラ設定 > in al, 60h する

ttp://www.cqpub.co.jp/column/books/2001a/34331PC_Legacy/default.htm
でなけりゃ EOTA の boot 以下参照で逝け。


136 :デフォルトの名無しさん:02/07/23 02:10
>>135
ポート60hにコマンドを送ると割り込み処理されるのに
キーボードを押してもなんにも反応ないのですが
そういうものなんでしょうか。


137 :135じゃないけど:02/07/23 03:33
ん、よく知らないないけど、IDTに処理アドレスを設定してあるとして、
・その処理ルーチン内でON/OFF(make/breakだっけ?)のどちらであるかを読み、
・リングバッファなりに記録(あるいはシフト状態フラグを変化させる)して、
・処理した事を8259Aに知らせる(どっかのポートを叩く)
じゃなかったかな?
で、他の方法(システムコール等)でそのバッファに記録された内容を読み出すことで
キーボードからの入力を受け取ると思うんだけど。

138 :デフォルトの名無しさん:02/07/23 03:37
とりあえず反応を確かめるなら、割りこみ処理時にVRAMに何か書きこんでみては?

139 :デフォルトの名無しさん:02/07/23 03:57
>>133
http://www.google.com/search?q=%E6%AD%BB%E3%81%AD%E3%81%B0%EF%BC%9F&sourceid=opera&num=0&ie=utf-8&oe=utf-8
これ見れ。

140 :45:02/07/23 05:55
>>133
>すみません。
> このスレに触発されかかって、OSを作ってみたいと思いかけているのですが。
> PowerPCをCPUに選びたいんです。
> その場合でもIntel系と作る手順というのは変わらないのでしょうか?

CPUの違いはあるけど基本は同じだべ。
そんな事もわからないんですか?

141 :デフォルトの名無しさん:02/07/23 09:13
>>137
他のソースをみると割り込み処理の基本的な部分は自分で用意したバッファに
コードを保存するということのように思ったのですけど、そのような作業を実は
してるんでしょうか。
>>138
作った処理はの内容は60番ポートからデータを読み込んで、そのコードを
画面に表示し、20hに20hを送るというものです。

bochsにキーボードのログをとるように指定すると、何回もKeyboard mouse disable
calledっていうのがあるのと、押したときにputting scancode * in internal buffer
ってなっているのが気になります。

142 :ひげぽん:02/07/23 13:53
[まじめ話です]
sourceforge.jp
sourceforge.net 使っている人いますか?

もしいたら、使い心地、メリット、デメリット等を
教えてください。

143 :デフォルトの名無しさん:02/07/23 18:47
http://www.os-omicron.org/~takano/doc/mksvc.html
参考になるかナー

144 :デフォルトの名無しさん:02/07/23 21:55
>>136
送るんでなく,キーボード押すて割り込まれたら 60h から in する。
それと PIC に EOI の発行も忘れずに。

137, 141 の書いてることはあってるような雰囲気。

割り込みハンドラではリングバッファなどに入れるだけに留めとく。
後で,キーコードを読み出したいルーチンがバッファから読む。


145 :デフォルトの名無しさん:02/07/23 22:10
higeposプロジェクト化?
応援するよ。微力ながら

146 : :02/07/23 23:15
ビクッ ∧ ∧ ∧ ∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  Σ(゚Д゚;≡;゚д゚) < うお!なんかすごいところに迷いこんじまったぞゴルァ!
     ./ つ つ    \_________________________
  〜(_⌒ヽ ドキドキ
     )ノ `Jззз

147 :デフォルトの名無しさん:02/07/23 23:59
2ch

148 :デフォルトの名無しさん:02/07/24 01:02
3Dを叩けるようになりますか?

149 :デフォルトの名無しさん:02/07/24 01:17
Higepos / 2ch Monax

150 :デフォルトの名無しさん:02/07/24 03:35
どうせならEROSで。

それはそうと、バイナリフォーマットはどうするん?>ひげぽん
COFFかELFを採用するのが妥当だと思うけど、もしかして独自にするつもり?
そうなると専用リンカを作るか、ldのパッチも作らないといけなくなるね。

151 :ろうひ男爵:02/07/24 12:29
eoiはスレーブに送る場合、マスターにも送らないとだめだからね。
キーボードはマスターだから、20hをたたけば良いだけだと思う。
8259_MS,8259_MSMSK,8259_SL,8259_SLMSKのうち、8259_MSでok。


152 :os4gd ◆PRisauvg :02/07/24 13:49
仮想3Dメモリー定義で処理を軽快にしてみました。
まだ取り入れられてない定義なのでもうしばらくしたら
完成できそうです。ただ問題もたくさんあるので
相談していこうかと思います。よろしく

153 :デフォルトの名無しさん:02/07/24 15:09
デムパ?

154 :デフォルトの名無しさん:02/07/24 21:52
>>153

ビクッ ∧ ∧ ∧ ∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
Σ(゚Д゚;≡;゚д゚) < うお!妄想厨が来ちまったぞゴルァ!
./ つ つ \_________________________
〜(_⌒ヽ ドキドキ
)ノ `Jззз

155 :デフォルトの名無しさん:02/07/24 22:33
age

156 :ひげぽん:02/07/24 23:01
idtあまり進まず
↓定義して終わってるていうか勉強中です。

typedef struct idtr_st {
    unsigned int limit;    /*! idtr limit           */
    unsigned int highbase; /*! base address of idtr */
    unsigned int lowbase;  /*! base address of idtr */
};

>>150
>それはそうと、バイナリフォーマットはどうするん?>ひげぽん
正直に言うと、バイナリフォーマットにどんな種類があって
どのような特性があるか、不勉強のため分からないので
勉強させてください。

IDT早く終わらせたい。

>どうせならEROSで
これって何ですか?


157 :ひげぽん:02/07/24 23:04
どこぞのサイト(英語)で読んだのですが、
OS開発の際にC++を使おうとするならば
new,delete演算子を自分で実装しなければならない
みたいな事が書かれていたのですが、
この辺を実装した例(ソース)とかないですかね。

158 :デフォルトの名無しさん:02/07/24 23:12
>>157
mallocだとしても自前で定義しないとダメでしょ
少なくとも、今のところは管理すらされてない生のアドレスが露出してるだけだから。

159 :ひげぽん:02/07/24 23:14
>>158
そうですよね。
そのへんて、メモリ管理をどうするか?
ということが、きちんと設計できた時点で実装するんですよね。

160 :デフォルトの名無しさん:02/07/24 23:25
>157
EOTA の memory.c に malloc と free があった。
あと K&R にも malloc と free が載ってる。


161 :ひげぽん:02/07/24 23:35
>>160
ありがとう!!

162 :デフォルトの名無しさん:02/07/24 23:37
>>160
だめだって。
それをサポートするための低レベルメモリ管理を書かないと。
MMUって言われている奴。

163 :ひげぽん:02/07/24 23:43
MMUってはじめて読む486で読んだんですけど・・・
486はハードウェアとしてMMUを持っているそうです。
それをソフトウェアとして実装するということですか?

164 :デフォルトの名無しさん:02/07/24 23:57
>>150
 EROSはOSの名前のことだと思うけど・・・先越されてる?
http://www.eros-os.org/


165 :デフォルトの名無しさん:02/07/25 01:04
だめか・・。なら仕方なく K&R か、この辺りで、というのは?
MMU は後回しで、まず、リニアアドレスでメモリ管理の練習ってのは悪くないと思う。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4797304952/ref%3Dlm%5Flb%5F11/249-4037071-2369146


166 :デフォルトの名無しさん:02/07/25 01:10
10年程前に作りかけた仮想EMSドライバのソース(コメント少なくて理解できん)を
眺めてたんだけど、プロテクトモードに移行する時に
ハードウェア割りこみ(IRQ)のベクタを変更してる。
というのは、186以降で定義された無効命令とかの例外とベクタ番号が重なり
処理が面倒くさくなるから。
だから、8259Aを再初期化して、例外と重ならないように変更するといいかも。
で、例外もエラーコードをスタックに残すのと残さないのがあるから、
何種類かにハンドラを分類してるな。
それと、一般保護例外は特別扱いで、逆アセンブルして
ソフトウェア割りこみやHLT,I/Oポートの違反かを検出しているようだ。
(ページングをONにしているので、DMAアクセスはアドレス変換が必要だから)
その他の割りこみ等はリアルモードの処理ルーチンをセットしてiretdしてた(V86だから)。

特別な処理が必要ない場合は、ハンドラの先頭で
 push imm ; ←割りこみ番号
 jmp short INTR_Handler
みたいな感じでまとめてしまってる。
ハンドラの最後は必ずiretdしなければいけないからアセンブラになるけど、
その中からCのルーチンを呼ぶようにしておいて
実際の処理はC/C++で書くのが楽なんじゃないのかな。

167 :デフォルトの名無しさん:02/07/25 01:23
>>166
ちょっとオーバーヘッドが気になるね。
x86はせっかく割り込みベクタテーブル式で提供してくれてるんだから、
俺は有効活用したいと思うな。

あと、割り込みハンドラであんまりスタック使いたくないしね。

168 :デフォルトの名無しさん:02/07/25 01:54
> x86はせっかく割り込みベクタテーブル式で提供してくれてるんだから、
うん、これはその通りだと思うけど、
実際、アセンブラソースに256個書いて保守するのはどうかと思ってさ。

でも
> ちょっとオーバーヘッドが気になるね。
はどうだろ。
そもそも、割りこみ処理は特権レベルの移行やらタスクの移行やらで
普通のjump/callとは比較にならないほど複雑な処理をしてるよ。
スタックもゲートに指定したパラメータサイズ分だけコピーされて
一般的にカーネルスタックが使われるし。
確かに、カーネル内部でのスタック使用量は僅かに増えるかもしれないけどさ、
それでも気にするほどのことかな。

まあ、俺はコード書かないで口を出してるだけなんで、
変だと思ったら聞き流してくださいな。

169 :デフォルトの名無しさん:02/07/25 02:06
直接スレの流れと関係なくてすんませんが、少し質問させてください。
ハードリアルタイムのOSを実装できたらいいなと思い、勉強しているのですが

・特定タスクのデッドラインを守れなかった場合はどうしたら良いんでしょうか。
・タイマーで厳密な意味で1msを計ることが出来ないのですが(n.nとなり、多少誤差が生じる)、
 この揺らぎってどうしたら良いんでしょうか。


170 :168:02/07/25 02:19
なんか適当なこと書いてた気がする。
割りこみでタスクが切り替わるのはタスクゲートだけだね、確か。
割りこみゲートやトラップゲートではコールゲート呼び出しと同じなので、
タスクは切り替わらない(当たり前)。
スタックの切替はゲートの特権レベルによって違うかも。
もしかしたらユーザーモード実行中に割り込みが発生した場合のみかも。

よく覚えてないや。ごめん、ホントいい加減で。

171 :超先生@OS板 ◆OS/dd1Xc :02/07/25 02:37
 ∧_∧
< `ー´>y-~~~ OS板より出張。

>>169
> ・特定タスクのデッドラインを守れなかった場合はどうしたら良いんでしょうか。

何があろうとdeadlineを死守する必要があるからhard-realtimeなのだが。。。

> ・タイマーで厳密な意味で1msを計ることが出来ないのですが(n.nとなり、多少誤差が生じる)、
>  この揺らぎってどうしたら良いんでしょうか。

そのプラットフォームは?
PC/ATの場合は1.19318MHzでドライブされてるから、
8254Aのカウント値を補正する必要があるけど。

>>170
スタックが切り替わるのは、non-conformingで上位のprivilaged-levelへ遷移する場合だったと思う。

172 :デフォルトの名無しさん:02/07/25 02:54
>>171
レスどうもです。

>何があろうとdeadlineを死守する必要があるからhard-realtimeなのだが。。。

勿論それは承知してますし、普通は起きそうもないケースなのですが、
動的タスク生成をサポートする非組み込みのRTOSって出来ないかなって思ってるので、
最高優先度のタスクが処理能力の上限を超えて作られた場合の心配をしてます。

>8254Aのカウント値を補正する必要があるけど。

やっぱり補正する必要があるんですね、適当なOSのソースを見るのがよさげですね。

173 :ろうひ男爵:02/07/25 06:18
バイナリーの形式だけど、
linkers&loadersっていうズバリの本がオーム社から出てるよ。
coffもomfも出てて3200円は安いっす。

386関連の本は、
80486の使い方 スルヤント オーム社
で、用語を覚える

はじめて読む486 アスキー
で、動かしてみる

386BSDカーネルソースの秘密 アスキー
で、大規模実装の例を見る

自分はといった感じで読み進めました。
それとは別に8259A,8251,8253,8255の各サンプルを読みました

174 :デフォルトの名無しさん:02/07/25 09:11
このスレって年齢層高い?

175 :デフォルトの名無しさん:02/07/25 09:22
正直、インテル・アーキテクチャソフトウェア・ディベロッパーズ・マニュアル
の下巻だけあれば事足りる感じなんだが。


176 :デフォルトの名無しさん:02/07/25 09:29
>>175
事足りるって?

177 :デフォルトの名無しさん:02/07/25 09:38
>>176
はじめて読む〜系の本は必要ないと思う

178 :ひげぽん:02/07/25 23:14
idtコーディング中。
突破口が開けたかも・・・

179 :デフォルトの名無しさん:02/07/25 23:54
前スレあげた馬鹿がいるからage

180 :デフォルトの名無しさん:02/07/26 01:03
ひげぽんがんばれ。


181 :ろうひ男爵:02/07/26 15:52
やっと読み終わった。
lodsでcsの時には、
lods byte ptr cs:[si]
ですよ>ひげぽん


182 :ひげぽん:02/07/26 20:18
>>ろうひ男爵
>odsでcsの時には、
>lods byte ptr cs:[si]
>ですよ>ひげぽん
すいませんもう少し詳しくお願いします。

だれか。
idtの8byteのうち先頭から
2byte
2byte
1byte
1byte →ここ。
2byte

の部分って0xf、0xeとかが入ると思うんですけど
値とその意味の詳細とか載っている資料とかWeb上でありましたら
教えてください。





183 :デフォルトの名無しさん:02/07/26 20:24
Intelの例の3部作の下巻
5.9.IDTディスクリプタ
に詳細が書いてある

184 :ひげぽん:02/07/26 20:36
>>183
ありがとう。
覚悟を決めて読むしかなくなくなってきた(笑)

185 :デフォルトの名無しさん:02/07/26 20:37
http://www.intel.co.jp/jp/developer/design/pentium/manuals/
http://www.intel.co.jp/jp/developer/design/pentium4/manuals/
ここからだね。
でも、どっちが良いんだろ。なんかサイズ違うし。
pen4向けのガイドが少し増えてるのかな。
(俺が昔落としたpen3向けのpdfは見当たらない)

186 :デフォルトの名無しさん:02/07/26 20:40
覚悟を決めてっていうか・・・
すごく丁寧に書いてあると思うんだけど。

187 :デフォルトの名無しさん:02/07/26 20:44
下の方で良いんじゃないの?
将来P4についても調べたくなったとき、差分を探して読む手間が省ける。

188 :ろうひ男爵:02/07/26 20:53
>>182
ごめん、ひげほんさんじゃなかったですね。
お詫びに、IDT
07bit P
06bit DPL
05bit DPL
04bit 0
03bit 1
02bit 1
01bit 1
00bit 0:割り込みゲート,1:トラップゲート
です。


189 :ひげぽん:02/07/26 21:22
>>188
ありがとう。
軽く読んでみたところでは
11101110=0x76
かなと思っています。


190 :超先生@OS板 ◆OS/dd1Xc :02/07/26 21:58
>>189
interrupt-requestを受け付ける用途には、
P=1,DPL=0,interrupt-gate
で10001110=0x8eが一般的だと思う。

191 :ひげぽん:02/07/26 22:19
>>190 OS板の方ですか。
>interrupt-requestを受け付ける用途には、
>P=1,DPL=0,interrupt-gate
>で10001110=0x8eが一般的だと思う。
最も大きい特権レベルとして安易に1としてはだめということですね。

load idtrを実行するところまで一応実装してみたのですが、
見事に3rd exceptionになりました。
load idtrまでは、一応何事もなく。動くのですが
割り込み許可(_sysUnlock=sti)すると例外があがります。

そもそも、いまWebにアップロードしている
ひとつ古いバージョンでも_sysUnlockすると例外があがる気がする。

なんでだ・・・・・





192 :超先生@OS板 ◆OS/dd1Xc :02/07/27 00:37
 ∧_∧
< `ー´>y-~~~
>>191
>3rd exception

IDTが正しく指されていないか、もしくは
GateのSegment-selector値が不正というところか。。。

>load idtrを実行するところまで一応実装してみたのですが、

PIC側でINTRを止めておかないと、
stiした瞬間に設定されていないベクタ(ゲート)へ飛び込んでしまうけど。
もしくはダミーでもよいのでIRQハンドラを立てておく必要あり。

193 :ひげぽん:02/07/27 00:43
>>192 超先生@OS板さん
ありがとうございます。

>IDTが正しく指されていないか、もしくは
>GateのSegment-selector値が不正というところか。。。
この辺からですかね。

>PIC側でINTRを止めておかないと、
>stiした瞬間に設定されていないベクタ(ゲート)へ飛び込んでしまうけど。
>もしくはダミーでもよいのでIRQハンドラを立てておく必要あり
ダミーでハンドラを立てる場合は0から255のうち必要ないものはすべて
ダミーにすればよいんですよね。

セレクタが違うのかなあ。





194 :デフォルトの名無しさん:02/07/27 00:58
なぜ超先生がム板にいるんだろ

195 :デフォルトの名無しさん:02/07/27 01:37
>>194
超先生プログラム書けるじゃない。
おまけゲーム作ってたような。


196 :デフォルトの名無しさん:02/07/27 01:48
シナリオよりソッチの才があるんだろ。スレ違いsage

197 :ひげぽん:02/07/27 10:47
うーん。動かず。
今週末の目標は何とかこいつを動かすことですね。

http://oshigepon.tripod.co.jp/

とりあえずダミーのハンドラを用意したので
またアドレス違いとかなのかな・・

ここがおかしいじゃないかなど、突っ込み募集です。

198 :超先生@OS板 ◆OS/dd1Xc :02/07/27 13:37
 ∧_∧
< `ー´>y-~~~
>_sysLoadIdtr((idtr_st*)IDT_BASE);

>void _sysLoadIdtr(idtr_st* idtr) {
>
> asm("lidt (%0) ": :"p" (idtr));
> return;
>}


IDTとIDTRの扱いがゴチャゴチャになってるような・・・。
_sysLoadIdtrにはIDTへのポインタを渡すのが正解。

void _sysLoadIdtr(idt_st* idt) {
  idtr_st idtr;

  idtr.limit = sizeof(idt_st)*HANDLER_NUM-1;
  idtr.highbase = hiword(idt);
  idtr.lowbase = loword(idt);
  .....

  asm("lidt (%0) ": :"p" (idtr));
  return;
}

199 :デフォルトの名無しさん:02/07/27 14:47
/*! struct for idtr */
typedef struct idtr_st {
unsigned int limit; /*! idtr limit */
unsigned int highbase; /*! base address of idtr */
unsigned int lowbase; /*! base address of idtr */
};

32ビットコンパイラならunsigned int = 32bitじゃ?
で、IDTRはlimit 16bit、base 32bitの48bit。

200 :デフォルトの名無しさん:02/07/27 14:57
構造体の詰め物も考慮してる?

201 :ひげぽん:02/07/27 18:05
>>198,>>199 超先生@OS板さん
ありがとうございます。
ご指摘のIDTR IDTの混同部分と、
IDTRのサイズ間違いを修正いたしました。
http://oshigepon.tripod.co.jp/

あいかわらず3rd exceptionが発生いたします。

>>200
構造体の詰め物とは何でしょうか。
構造体が自分の期待しているサイズと異なってしまうということでしょうか。



202 :デフォルトの名無しさん:02/07/27 18:15
「構造体 パディング」で検索して見ましょう。

203 :超先生@OS板 ◆OS/dd1Xc :02/07/27 18:44
IDT_LOWBASE・IDT_HIGHBASEというのは一体・・?
↓で十分だと思う。。

typedef struct idtr_st {
  unsigned short limit;  /*! idtr limit */
  unsigned int base;   /*! base address of idtr */
};

/* idtr set up */
idtr.limit = sizeof(idt_st) * HANDLER_NUM -1;
idtr.base = IDT_BASE;


204 :超先生@OS板 ◆OS/dd1Xc :02/07/27 18:55
もう一点。要点は、

/*! struct for interrupt handler */
typedef struct handler_st {
  int number; /* handler number */
  int (*handler)(); /* pointer to handler function */
};

>/* set idt */
>idt->offsetL = (int)(p->handler) & 0x0000FFFF;
>idt->offsetH = ((int)(p->handler) & 0xFFFF0000) >> 16;

・戻り値や引数を伴う関数は直接ゲートには置けない。
・外部割り込み要因からの復帰はiretd命令を使用する必要がある。
・なので、stack frameを破棄するコードは自分で実装する必要がある。(例えばenter,leave命令)

205 :ひげぽん:02/07/27 19:51
_sysPrintIntを作成して
構造体のサイズを調べました。
size of idtr_st = 6byte
size of idt_st = 8byte
となりました。

>>203, 204 超先生@OS板さん
ありがとうございます。

>・戻り値や引数を伴う関数は直接ゲートには置けない。
handlerの戻り値をvoidにしました。

とりあえず割り込みがあったら、ハンドラにジャンプし
そのなかで無限ループに入るというのを最初の第一歩として
やろうかと思っております。

3rd exception 発生中。
http://oshigepon.tripod.co.jp/




206 :デフォルトの名無しさん:02/07/27 19:57
>>201
ねえねえこれ間違ってない ? (外出だったらスマソ)

#define IDT_HIGHBASE 0x6800 /* idt low base address */

たぶん上の行をコピベしたと思うけど、0x0000 だと思うが...。
(ついでに、コメントも直しておいた方がいいと思う。)

というか、俺なら IDT_HIGHBASE と IDT_LOWBASE の定義を止めて
/* idtr set up */
idtr.limit = sizeof(idt_st) * HANDLER_NUM -1;
idtr.highbase = (IDT_BASE >> 16) & 0x0000FFFF;
idtr.lowbase = (IDT_BASE >> 0) & 0x0000FFFF;

と書くと思う。

あと、3rd Exception が発生した時のログ (レジスタの値) を見せて
あげると、わかる人ならバグの場所が特定しやすくなると思うよ。
(俺には、無理だけど...。) がんばってね。

207 :ひげぽん:02/07/27 20:04
>>206
間違っております。やらかしてました。
訂正いたしました。

3rd exceptionがおきたときのレジスタ内容です。
# In bx_gui_c::exit(void)!
00000309028i[CPU  ] protected mode
00000309028i[CPU  ] CS.d_b = 32 bit
00000309028i[CPU  ] SS.d_b = 32 bit
00000309028i[CPU  ] | EAX=00000fc4  EBX=00000000  ECX=0000a7c0  EDX=0000a7c0
00000309028i[CPU  ] | ESP=00000fd8  EBP=00000fec  ESI=000000ee  EDI=0000ffe4
00000309028i[CPU  ] | IOPL=0 NV UP EI PL NZ AC PE NC
00000309028i[CPU  ] | SEG selector     base    limit G D
00000309028i[CPU  ] | SEG sltr(index|ti|rpl)     base    limit G D
00000309028i[CPU  ] |  DS:0010( 0002| 0|  0) 00000000 000fffff 1 1
00000309028i[CPU  ] |  ES:0010( 0002| 0|  0) 00000000 000fffff 1 1
00000309028i[CPU  ] |  FS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
00000309028i[CPU  ] |  GS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
00000309028i[CPU  ] |  SS:0018( 0003| 0|  0) 00000000 00000000 1 1
00000309028i[CPU  ] |  CS:0008( 0001| 0|  0) 00000000 000fffff 1 1
00000309028i[CPU  ] | EIP=000012cf (000012cf)
========================================================================
Bochs is exiting with the following message:
[CPU  ] exception(): 3rd exception with no resolution
========================================================================


208 :ひげぽん:02/07/27 20:05
_sysPrintIntもっと早く作ればよかった。
結構重宝するかも。

209 :超先生@OS板 ◆OS/dd1Xc :02/07/27 20:48
>/* idt size = 64bit */
>idt_st* idt = (idt_st*) IDT_BASE + p->number * sizeof(idt_st);

演算が間違っているのでは。
↓こうだと思う。

idt_st* idt = ((idt_st*) IDT_BASE) + p->number;

210 :ひげぽん:02/07/27 21:18
>>209 超先生@OS板さん
たびたびありがとうございます。

>/* idt size = 64bit */
>idt_st* idt = (idt_st*) IDT_BASE + p->number * sizeof(idt_st);
この計算の意図は、IDTをnumber番目にセットする
ためのアドレス計算なのですが・・・
sizeof(idt)倍しなくて良いんですか???
うーーん、でもとりあえず直してみるです。
きっとおいらが間違えているんだろうな・・・

3rd exception 発生中。
http://oshigepon.tripod.co.jp/
rb2html.rbに感謝!



211 :デフォルトの名無しさん:02/07/27 21:40
hige age
ここが踏ん張りどころだ。がんばれ。

212 :超先生@OS板 ◆OS/dd1Xc :02/07/27 22:24
21| typedef struct idtr_st {
22| unsigned short limit; /*! idtr limit */
23| unsigned short highbase; /*! base address of idtr */
24| unsigned short lowbase; /*! base address of idtr */
25| };

little-endianなのでhighbaseとlowbaseは逆かな。

213 :ひげぽん:02/07/27 23:20
>>212 超先生@OS板さん
大変ありがとうございます。
3rd exception 回避できました。

たぶん自分ひとりでは絶対気づきませんでした。

とりあえず画面上にdummyと表示されたので
何らかの割り込みが発生を捕まえたようです。
ありがとうございます。

http://oshigepon.tripod.co.jp/
割り込みcatch成功版


214 :ひげぽん:02/07/27 23:22
>>212 超先生@OS板さん
大変お世話になっております。
超先生@OS板さんって、どんな人なんですか。
OSを作られたりしているのでしょうか?
今の私からすると、かなりすごい人です・・・・



215 :デフォルトの名無しさん:02/07/27 23:30
最近忙しくて、ひさしぶりに来れたんだけど。
なんか、偉い人召喚しちゃったの?

216 :デフォルトの名無しさん:02/07/27 23:47
割り込み成功???
おめでとう。

217 :デフォルトの名無しさん:02/07/28 00:34
 

218 :デフォルトの名無しさん:02/07/28 03:09
>>215
OS板で最も実力を持っていると思われるヤシ。
当地ではチョンのAAを使って話をするので時々チョン先生と呼ばれることもある。

219 :デフォルトの名無しさん:02/07/28 11:55
久しぶりに来たら、ひげぽんがまだがんばってる・・・
しかも、かなり進化してる・・・
ひげぽんお前さん本気だな。
source forgeでプロジェクト申請したら???

220 :デフォルトの名無しさん:02/07/28 14:29
そろそろOSの設計部分について語ろうぜ。
APIはどうするの?

221 :デフォルトの名無しさん:02/07/28 15:26
チョン先生!!

222 :ひげぽん:02/07/28 16:16
>>219
>source forgeでプロジェクト申請したら???
もうすこし成熟してからにしようかと・・・
後は賛同者がいればって感じです。

>>220
>APIはどうするの?
C++のクラスライブラリとして提供できればと思っているのですが、、、
まだ先ですね。





223 :デフォルトの名無しさん:02/07/28 16:43
>>222
C++のクラスはやめとけ。
どうしてもというのなら、低レベルAPIをC互換で作り、
WinのCOMのような形で提供するべき。

224 :ひげぽん:02/07/28 16:49
>>223
>C++のクラスはやめとけ。
>どうしてもというのなら、低レベルAPIをC互換で作り、
>WinのCOMのような形で提供するべき。
理由も教えていただけるとありがたいのですが、
何かの経験上でしょうか。

もちろん低レベルAPIはCの関数として実装するとは思いますが、
C++のクラスでメインの機能を提供しようと思っています。

OSの主要な機能は、そのインスタンスを介して利用する形にしたいです。
インスタンス間(OSのさまざまな機能間)の連携は
observerパターンなどを使おうと思っています。






225 :デフォルトの名無しさん:02/07/28 16:52
>>224
C++の名前修飾や呼び出し規約はコンパイラ間で互換性がまったくない。

226 :ひげぽん:02/07/28 16:58
>>225
ということは、C++でクラスライブラリを提供する場合は
特定コンパイラ向けになってしまうということでしょうか。
良く分からないのですが、C++の標準の機能を利用するだけでも
大きな影響があるのでしょうか。

227 :デフォルトの名無しさん:02/07/28 17:10
荒らしに来ました。
今からここをメチャクチャにします。
応援ヨロシク!

228 :デフォルトの名無しさん:02/07/28 17:11
>>226
シンボルをすべてextern "C"にするか、
OSのコンパイルに使ったコンパイラの呼び出し規約と修飾された名前を
理解してくれる処理系でないと、ネイティブの実行ファイルが作れなくなる。

229 :ひげぽん:02/07/28 17:22
>>228
ということは、
higeposはgccでコンパイルしているので
g++用クラスライブリになってしまうということですね。

ということは、higeposのアプリケーションを作るときに
C++コンパイラは、g++を使わなければいけなくなるということですね。

これってアプリ開発者側から見て大きなデメリットでしょうか。
この辺の切り分けが出来ればよいかと思っています。


230 :ひげぽん ◆zcp/NZpA :02/07/28 17:40
これからは↑でいきます。

231 :デフォルトの名無しさん:02/07/28 17:42
>>229 非常に制限が大きくなると思います
 将来GCCがバージョンアップされたらOS毎再コンパイルが必要だし

232 :ひげぽん ◆zcp/NZpA :02/07/28 17:45
>>231 うーんなるほど・・・・
gccが下位互換になるとは限らないということですね。
こまったなあ。

独自コンパイラ作るのきっとしんどいだろうし・・・
うーんどうしよう。
今頭の中にあるOSは、オブジェクト指向なんですよ・・・
Cでオブジェクト指向実装するのは面倒だな・・(不可能ではないが)


233 :デフォルトの名無しさん:02/07/28 17:52
>>232
C++からしか使うことが出来ないようになるから、
やっぱり言語に依存しないインターフェイスモデルを構築した方がいい。

234 :ひげぽん ◆zcp/NZpA :02/07/28 18:04
既存のOSはどういう、アプローチをとっているんだろう。
やっぱりCでAPIを提供しているんだろうか。


235 :デフォルトの名無しさん:02/07/28 18:07
c++で提供しているのはBeくらい


236 :デフォルトの名無しさん:02/07/28 18:10
便乗 Beはどのようなアプローチ?
C++でも提供してるの?それともC++ only?


237 :デフォルトの名無しさん:02/07/28 18:13
OS作った奴が近大の理工学部で教授やってるから
聞いてみれ。
アドバイスくれるかも。

238 :デフォルトの名無しさん:02/07/28 18:37
>>225
> C++の名前修飾や呼び出し規約はコンパイラ間で互換性がまったくない。
なんか誤解してない ? そんなこと言うと C だって互換性 100% じゃないよ。

もし、OS の保護機構なんて要らないと言うことで、ユーザープログラムも OS
も全て C++ 等で書いて直接 (あたかもサブルーチンコールのように) 呼び出す
と言うのならその通りなんだけど、普通そんなことはしない。

最近 OS では、API は最終的にはソフトウェア割込みで行っているのが普通。
大概のプロセッサは割込み以外の方法ではユーザーモードからシステムモード
への切替をできないようになってるから、保護機能等を使うのであれば、これ
はほぼ必須。

通常 read(fp, buff, size) とか言ってる API は、全部その言語用のラッ
パーだよ。だから、
>>231
> 将来GCCがバージョンアップされたらOS毎再コンパイルが必要だし
と言うことは無い。第一そんなことしたら、その時動作しているコマンドや
サービス等のプログラムも再コンパイルが必要になる。
ただし、コンパイラが変わったらライブラリの再コンパイルは必要。

239 :デフォルトの名無しさん:02/07/28 18:44
>>238
あんたも古いな。
最近は割り込み〜じゃなくて、割り込み自体は昔から使われていた。
それより一歩進んだ方法として、たとえばIA32ではコールゲートがある

240 :デフォルトの名無しさん:02/07/28 18:46
>と言うことは無い。第一そんなことしたら、その時動作しているコマンドや
>サービス等のプログラムも再コンパイルが必要になる。

名前修飾に互換性がある保証がないから、
存在しないシンボルを呼び出すことになる可能性があるって事だろ

241 :ひげぽん ◆zcp/NZpA :02/07/28 19:07
この辺はこれからの設計にもかかわる重要項目ですね。
ところで
OSのカーネルがC++で組まれている事と
OSの提供するAPIがC++のクラスライブラリであることは

ある程度別問題として考えることって出来ますか?
うーん日本語が変ですね・・・

242 :デフォルトの名無しさん:02/07/28 20:10
>>239
> それより一歩進んだ方法として、たとえばIA32ではコールゲートがある
コールゲートが一歩進んでいるかは別にして、コールゲートを使っても
話は一緒だよ。IA32 プロセッサは保護モードの時に far Call を割り込
みの様に扱うだけだよ。(スタックのコピーとか特権チェックとか色々プロ
セッサでやってくるけどね。) 普通のサブルーチン呼び出しと同じように
は呼べないよ。
コンパイラを改造して OS 呼び出しって言うのを認識する (例えば、関数
の属性として API 属性と言うのを定義できるようにして、その関数を呼び
出す時は far Call を生成する。) ようにすれば、呼び出すことはできる
ようになるとは思うけど、ポインタ経由で呼び出された時にも対応する
(=ポインタにそう言う属性をつける ?) とか考えると、あんまり実用的に
は思えない。

>>241
基本的には別問題。
ファイル操作 API を C++ 風に...
file f;
f->open("foo", ReadOnly);
f->read(buff, size);
f->close();
となるけど、これアセンブラレベルで見たら全て this ポインタを伴って
呼び出されている。結局今時の OS で、ファイルディスクリプタを使うの
と (OS から見れば) 大して変わらない。
今時の OS は、デバイスでもファイルでも同じ方法で、read/write でき
るけど、結局これも OS 内で C++ で言うところの仮想関数呼び出しをし
て実現している。そう言う意味で、カーネル (特にデバイスドライバ) を
C++ で書くとそれなりにきれいになるのではとちょっと期待している。

243 :デフォルトの名無しさん:02/07/28 20:29
>コンパイラを改造して OS 呼び出しって言うのを認識する (略)

windowsのdllのインポートライブラリのように、
スタブを用意すればいいんじゃないの?

244 :デフォルトの名無しさん:02/07/28 21:31
>>243
dll 作成した時にできるヘッダーファイル見たことありませんか ?
__declspec(dllimport) と言う思いっきり Microsoft 独自 (とは限らないけ
ど、ANSI 非互換の) 関数属性が定義されてますよ。

>>242 に書いたコンパイラの改造は、あくまでも一例です。他にも、OS の API
関数は例えば、0x00010000 以下に置くと決めといて、その領域はわざとユー
ザー空間にはマップしないでおく。API 関数が呼び出されたら、アクセスエラー
の例外が発生するので、これをトラップしておもむろに OS 側でどのように呼び
出されたかを調べて本物の関数を呼び出すようにすれば、コンパイラの改造はい
らない。

245 :デフォルトの名無しさん:02/07/28 21:33
>>241
> この辺はこれからの設計にもかかわる重要項目ですね。
そろそろ、作ろうとしている OS の特徴を決める時期かも...。

246 :ひげぽん ◆zcp/NZpA :02/07/28 21:57
>>242
>基本的には別問題。
>ファイル操作 API を C++ 風に...
>file f;
>f->open("foo", ReadOnly);
>f->read(buff, size);
>f->close();
OSのカーネルをC++で実装したとします。
例えばファイルシステムの一部を
構造体や連結リストで表現するのではなく
クラスで表現したとします。
しかし公開するAPIはCの関数で、その関数の中でクラスライブラリを操作
している場合も何か問題が発生するのでしょうか。
分かりづらい質問かもしれませんが・・・
よろしくお願いいたします。


247 :デフォルトの名無しさん:02/07/28 21:58
>>244 __declspec(dllimport) これは省略できますがなにか?

248 :デフォルトの名無しさん:02/07/28 22:01
>>246
問題ない。

249 :ひげぽん ◆zcp/NZpA :02/07/28 22:16
>>245
>そろそろ、作ろうとしている OS の特徴を決める時期かも...。
まさに、今その時期かも。
とりあえず開発側から見たつくりの特徴としては
・カーネルの機能をコンポーネント化して、そいつらの結びつき
 は疎結合(メッセージング?)
・当面は、CUIだけ。unixのようにGUIはサーバーを通す?
・入出力を何らかの方法で高度に抽象化したい。
・当然日本語OK(マルチバイト対応)
・ネットワーク機能はOSにくみこむ??
・出来れば分散環境を意識したつくりにしたい。
・とにかくつくりをすっきりしたい、設計・実装どちらもスマートに
 ある程度パフォーマンスを犠牲にしてもきれいなつくりを維持する。
・過去の遺産は引きずらない

いま思いつくのはこれくらいかな。

250 :ひげぽん ◆zcp/NZpA :02/07/28 22:24
>>248
ありがとう。
そういうことであれば、自分のやりたいことは
最低限実現できそうです。

251 :デフォルトの名無しさん:02/07/28 22:36
>・入出力を何らかの方法で高度に抽象化したい。

unixでもデバイスをファイルとして扱えるけど、
具体的にどう抽象的でないと思う?

>・当然日本語OK(マルチバイト対応)

これは何?
CES依存で作るの?

>・出来れば分散環境を意識したつくりにしたい。

分散カーネルなんて聞いたこともないけど、どうすんの?
DCOMのような分散システムをもっとアプリケーションよりの層に作るのなら、
他OSでも実現されているし、実現自体は特に問題ないと思うけど。


252 :デフォルトの名無しさん:02/07/28 22:59
>>247
そん時は、リンカがサンクコードとリンクするだけのこと。(一段階の間接参照
だけだけど) API のラップと概念的には変わらないよ。

253 :DQN:02/07/28 23:23
よくわからんがplan9に近いんでない?

254 :ひげぽん ◆zcp/NZpA :02/07/28 23:31
>>251
こんばんわ
>unixでもデバイスをファイルとして扱えるけど、
>具体的にどう抽象的でないと思う?
うーん。すいませんまだきっちりと固まってないので
表現しきれないのです。インターフェースとしては同じですが。
内側の仕組みをもっとすっきり出来ないかなと・・・

>>・当然日本語OK(マルチバイト対応)
>これは何?
>CES依存で作るの?
無知ですいません。CESってなんですか。
2byte文字もきちんと意識しようってことです。




255 :デフォルトの名無しさん:02/07/28 23:47
ruby内蔵


256 :ひげぽん ◆zcp/NZpA :02/07/28 23:51
>>255
>ruby内蔵
シェルとしてということですか?
可能と思いますがOSのカーネルの設計段階ではあまり
関係ないかなと思います。

257 :ひげぽん ◆zcp/NZpA :02/07/29 00:19
板を汚してすいません。
以下の募集を行います。
まじめです。
http://pc3.2ch.net/test/read.cgi/tech/1024411711/
[募集]
higepos(仮称)の開発PJの要員
higeposとは、2002/06/18から開発が始まった新しいOSです。
とりあえずひげぽんは本気でOSを作ろうと考えています。

[現在のメンバー]
プロジェクトリーダーのひげぽんだけです。

[これからの予定タスク]
(1)簡単なプロトタイプの実装。http://oshigepon.tripod.co.jp
(2)OSの設計。

(1)(2)を並行して行っていこうと思います。

[注]
ひげぽんは、仕事をしているため
higeposの開発ばかりに完全には専念できません。
ご了承ください。

興味がある方は、ひげぽん宛にメールをください。
Subjectを[higepos]としていただけるとありがたいです。

Webデザイナーさんとかも来てくれたらうれしいです。
ひげぽんはデザインセンスが0なので・・・


258 :ひげぽん ◆zcp/NZpA :02/07/29 00:23
すいません1点書き忘れました
現状の知識は問いません。
そのとき必要な知識を勉強すれば良いですし。
役割分担があると思うので。

メールはすぐに返事を出します。
もし2日たっても返事が来ない場合は、すいませんがここに書き込みしてくれると
ありがたいです。


259 :デフォルトの名無しさん:02/07/29 00:33
>>254

>内側の仕組みをもっとすっきり出来ないかなと・・・
内側の仕様ってドライバ依存では?

>無知ですいません。CESってなんですか。
検索しようよ。

>2byte文字もきちんと意識しようってことです。
2byte文字をOSが意識すると言うことは、2byte文字を特別視すると言うことでしょ?
要するに2byte文字に依存してる。
たとえば、UNICODEとか、もっと別のコードは想定しないって事?

260 :デフォルトの名無しさん:02/07/29 00:36
分散カーネル
ttp://korbit.sourceforge.net/

261 :デフォルトの名無しさん:02/07/29 00:46
>>260
どこまでをカーネルと呼ぶかによって変わってくるけど、
システムコールのリクエストを複数のサーバーへの分散要求に変換してくれるわけでもないし、
基本部分はやっぱり各マシン毎で動いているから、分散カーネルとは言えないと思うんだが。


262 :ひげぽん ◆zcp/NZpA :02/07/29 00:46
>>259
>>内側の仕組みをもっとすっきり出来ないかなと・・・
>内側の仕様ってドライバ依存では?
I/Oの下層レイヤー(ドライバレベル)を上位のレイヤーでラップして
抽象化するときにすっきりとしたいなと考えています。
でもこれは、現状のUNIXがどういうアプローチを採っているのか
正確には知らないので、車輪の再発明っぽくなるかも・・・

>>無知ですいません。CESってなんですか。
>検索しようよ。
そうですね。しばらく時間をください。

>>2byte文字もきちんと意識しようってことです。
>2byte文字をOSが意識すると言うことは、2byte文字を特別視すると言うことでしょ?
>要するに2byte文字に依存してる。
OS内部で採用する文字コードをマルチバイト(2byteとは限らない)
の文字コードにするという意味です。
なので、2byte文字を特別視するという意味ではないです。







263 :デフォルトの名無しさん:02/07/29 00:59
>カーネルの機能をコンポーネント化して、そいつらの結びつき
>は疎結合(メッセージング?)

マイクロカーネルとか調べてみては?

264 :sage:02/07/29 01:04
Hobby OS を目指してるぽん?
それならいっぱいあるぽん!
とりあえず↓あたりは有名だぽん・・
ttp://www.menuetos.org/
ttp://www.skyos.org/index2.html
ttp://www.atheos.cx/
ttp://cosmoe.com/
ttp://syllable.sourceforge.net/

265 :デフォルトの名無しさん:02/07/29 02:43
ぽんぽんぽんぽんぽんぽんぽんぽんぽんぽんぽんぽんぽんぽん

266 :デフォルトの名無しさん:02/07/29 04:13
もしトンデモだったら聞き流してくれ。
>>262
>OS内部で採用する文字コードをマルチバイト(2byteとは限らない)
>の文字コードにするという意味です。
>なので、2byte文字を特別視するという意味ではないです。
てことは、1byte、2byte、4byteとかいろんなバイトの文字コードを扱えるようにするって事?
結構処理きつくならないか?
それならいっそunicodeで統一(以下略

267 :ろうひ男爵:02/07/29 07:47
>>232
yaccとlexを使うのが良いのでは?
自分は使わずに手で実装しましたが、大変でしたよ。
特にスタック関連の再帰が面倒でした。
字句解析には、力業で文字列のコンペア取ってましたが、
ハッシュに変えたらスゲー早くなりました。

でも、c言語レベルの物を作るならならそんなに大変ではないと思いますよ。
といっても、フルにやって2ヶ月はかかるでしょうけど。

しかも、os側でmmuを使って0からのアドレスにマップすれば、
アロケータは必要ありませんし、セグメントの用途固定にすればokですしね。

コンパイラは、ネイティブコード出力だけでなく、
共通の中間コードも出力できたら楽しいかもしれませんね。


268 :デフォルトの名無しさん:02/07/29 07:53
FreePascalベースにしたら? あれは一応オブジェクト指向言語だし

269 :デフォルトの名無しさん:02/07/29 12:55
Pascalのオブジェクト指向はいまいち

270 :デフォルトの名無しさん:02/07/29 14:24
>>267
せっかくOS開発として形になろうとしてきたところに、
言語から作れなんて言う水を差すような発言はどうかと思うぞ

271 :ろうひ男爵:02/07/29 17:01
>>270
すまぬ。

272 :ひげぽん ◆zcp/NZpA :02/07/29 20:00
>>267
なるほど言語ごと作るとは・・・
フルにやって2ヶ月って、宝くじが当たったらやろうかな。
仕事がなけりゃ、やってみたら面白いと思うけど
生活できない・・・

>>270,>>271
いえいえ。
確かにそこまでやったらかなり面白い!!
とは思います。でも今は無理です。

募集したのに誰もメールくれないと言ってみるテスト。
当分一人やるしかないようです。
もっとレベルが上がってから再募集します。


273 :デフォルトの名無しさん:02/07/29 20:45
>>272
漏れはsourceforgeにプロジェクトが立ち上がったら参加したいです
少なくとも、今の段階ではひげぽん一人で楽しみながらやるのが良いと思う。
個人で把握しきれない規模でもないしね。

274 :ひげぽん ◆zcp/NZpA :02/07/29 20:49
ハードウェア割り込みをキャッチしようと試みています。
が、つまずいています。
キーボード割り込みハンドラを作成してIDTを登録しました。
Bochs上でキー入力をしてもハンドラが呼ばれた形跡はありませんが
裏のコンソールに「nternal keyboard buffer full, ignoring scancode.(a1)」
と出るのでbochs自体は、キー入力は受け付けていると思います。

ハンドラは以下のようなものです。キーボード割り込み以外のハンドラも
下記と同様の作りです。
void keyStrokeHandler() {
    _sysPrint("key stroke\n");
    asm("mov %ebp,%esp");
    asm("pop %ebp");
    asm("iret");

    return;
}


275 :ひげぽん ◆zcp/NZpA :02/07/29 20:52
>>273
おお!結構うれしいです。
ちなみに募集をしたのもそろそろsource forgeでプロジェクト化しようと
思ったからです。
誰もメールをくれないのでめげていたところです。
source forgeってオープンソースでなければいけないんでしたっけ?
のちのち面倒なことにならないようにその辺はしっかりと
調べなければと思いつつ後回しになっています。


276 :デフォルトの名無しさん:02/07/29 21:16
>>262
>>259
OS関連の用語としてのCESは下記のようなことでよろしい?
CES = Character Encoding Schemeの略。 文字符号化方式。

参考リンク(google で "CES 依存 文字" で検索してめぼしいものをピックアップ)
ttp://www.inac.co.jp/~maki/ruby/ruby-i18n.html
ttp://tsukuba.m17n.org/mule-ja-archive/2000-1/msg00033.html
ttp://tsukuba.m17n.org/mule-ja-archive/2000-1/msg00034.html
ttp://www.emaillab.org/mutt/linuxjapan/mutt200111.pdf

# この辺りの話は glibc のようなものを作るときに問題にすればよいのでは?


277 :デフォルトの名無しさん:02/07/29 21:26
>>274
とりあえず、不正なアドレスへのアクセスなどは捕まえられるのかな。
キー入力を捕らえるなら 8259A の初期化辺りはどうなった?
それと、キー入力ならマスターへのEOI撃たないとダメだけど。

>>272
いや、だって、ちゃんとしたページもなけりゃ解説もなし。
内容は「はじめての486」もカバーしきれず。
もし遊ぶならもう少し気合が見たいかも知れず。


278 :超先生@OS板 ◆OS/dd1Xc :02/07/29 21:34
>>274
 ∧_∧
< `ー´>y-~~~ それはおそらく

最もプライオリティの高いsystem timer割り込みがEOIされてないから
プライオリティの低いキーボード割り込みを拒否してるだけだと。

stiする前にkeyboard以外のIRQをmaskするなどPICを設定しておく必要がある。

279 :ひげぽん ◆zcp/NZpA :02/07/29 21:34
>>276
ありがとうございます。
こういう書き込みは大変助かります。
文字オブジェクトという考え方はなかなか新鮮でした。

>>277
>とりあえず、不正なアドレスへのアクセスなどは捕まえられるのかな。
>キー入力を捕らえるなら 8259A の初期化辺りはどうなった?
>それと、キー入力ならマスターへのEOI撃たないとダメだけど。
bochs起動時に08h(タイマー?)への割り込みが1回キャッチされてます。
8259A,マスターEOI、調べます。キーワードをありがとうございます。

>いや、だって、ちゃんとしたページもなけりゃ解説もなし。
>内容は「はじめての486」もカバーしきれず。
>もし遊ぶならもう少し気合が見たいかも知れず。
力不足は認めます。
まずはカーネルのプロトタイプの完成を第一優先に
考えているので暖かく見守っていただけたらありがたいです。





280 :ひげぽん ◆zcp/NZpA :02/07/29 21:39
超先生@OS板さんありがとうございます。
>最もプライオリティの高いsystem timer割り込みがEOIされてないから
>プライオリティの低いキーボード割り込みを拒否してるだけだと。
>stiする前にkeyboard以外のIRQをmaskするなどPICを設定しておく必要がある
勉強不足で申し訳ありません。
でも、超先生の予想が当たっている気がします。

281 :デフォルトの名無しさん:02/07/29 21:43
超先生顔はチョソなのに何か素敵・・・ポッ。

282 :デフォルトの名無しさん:02/07/29 21:51
しかし、面倒なところまで来たね。
IOとかになってくると、もう資料を集めるスキルも多大に要求される。

283 :ひげぽん ◆zcp/NZpA :02/07/29 22:44
>>282
そうですね。いままでははじめて読む・・ + アマチュアOSのソースを
いくつか眺めながら作っていたのですが
資料集めスキルは本当に重要だと痛感しています。
Minix本は、偏りがあるし・・・

284 :デフォルトの名無しさん:02/07/29 23:11
がんばれよ

285 :デフォルトの名無しさん:02/07/29 23:49
この本は必要不可欠です。
ttp://www.amazon.com/exec/obidos/ISBN%3D0201596164

286 :ひげぽん ◆zcp/NZpA :02/07/29 23:51
EOI(End Of Interrupt)をsystem timer割り込みに対して発行したところ
キーボード入力に対して、「一度だけ」ハンドラ呼び出しに成功しました。
その後キーボード入力をしても、何も反応しなくなります。
キーボードハンドラの中でも、EOIしているのですが、
次の割り込みを捕まえることが出来ません。

ところでsystem timerのハンドラってとりあえずは空回りさせとけば良いのでしょうか。


287 :ひげぽん ◆zcp/NZpA :02/07/29 23:54
>>286
日本語版とかないですかね。
割り込みの資料も英語のものしか見つからなかったので
がんばって読んだのですが、ちょっと疲れました。

288 :ろうひ男爵:02/07/30 04:40
タイマーは、

1)古いハンドラを呼ぶ
2)EOIを発行 port 20hに20hを出力

が普通だと思う。


289 :ろうひ男爵:02/07/30 05:04
ちなみに、タイマーは、ワンショットではなく、方形派のハズなので、
周期的に何回も割り込みがかかってきているかチェックしてくださいね。

290 :LightCone:02/07/30 07:33
 横から失礼しますが、上の方を読む限り話がIDTの方に移行した
ようですが、Cソースをコンパイルした結果の .data セグメントや
.bss セグメントを正しく扱う事の方が優先順位的には高いと思います。

 OBJファイル群をリンクした後に出来る実行形式のフォーマット(ELF等)
の資料を入手し、IPLに続く部分もしばらくはアセンブラで書いて、
その実行形式に対するローダーを書いておくか、自分でコンバータを
作って、予めロードしやすい形式にしておくといいです。

 それから、32 BIT のCコンパイラが吐き出すコードは、32BIT
プロテクトモードへ移行して、各種の環境を整えてやらないと、
そもそも全く正しく実行できません。
 初期時のしばらくの間、安定した32BITのアドレッシングモード
に移行するまではアセンブラで書くのが安全で楽だと思います。

 Cコンパイラの吐くコードを実行するのに重要なことは、DS,ES,SSの
セッティングです。そのコンパイラがFLATモデルのコードを吐いている
なら、DS,ES,SS を全て 4GB FLAT に設定する代わりに、ちゃんと
命令中の OFFSET アドレスを全てリロケートする必要があります。
逆に、セグメントモデルのコードを掃いているなら、DS,ES,SSを
正しく設定すれば、リロケート作業は必要有りませんが、ポインタ
を far ポインタで扱う必要が出てきます。お勧めはFLATモデルです。
 FLAT モデルの場合のリロケートする方法ですが、それは、実行形式
に埋め込んである「再配置情報」を利用します。そこからは、絶対
OFFSET アドレスが書かれているアドレスと、それに関係した
セグメントの情報が得られます。

291 :LightCone:02/07/30 07:59
 ちょっと、#93が指摘されているように、文字列の入っているセクション
(多分.data)が最初に来ていると言う状態や、#89,#92 で、文字列の
終端コードが読めないと思っていたら、読めることも有ったりするのは、
実は全てセクションの配置や、OFFSETの再配置問題が関係しているように
思えますので、そこをうまく乗り越えれば、ひとまず小安定した
環境がやってくると思います。

 この掲示板を読む限り、なんとなく勘で試したら、動く時も有った、
かのような感じを受けるのですが、そういう姿勢はやめて、もっと
精密に一歩一歩石橋を渡るように前に進んでいくことをお勧めします。
まず、ブートさせる前に、イメージファイルなどをバイナリエディタで
くまなく観察することがお勧めです。

 あたりまえのことですが、配置が1バイトでも狂っていれば、
プログラムの論理的なバグがもし一切無くても、全く動くこと
さえできません。
 OS作りとは、環境作りであって、カーネルを、Cソースでスイスイ
と書ける状態に持っていけたらば、既にかなり進展したと言っていいと
思いますので、まずはそこに一週間かけても問題は無いと思います。

 なお、少しまともなOSを作ろうとすれば、ページングを実装しなければ
なりませんが、アドレスを精密に決める癖がついていないと多分挫折する
ことになるでしょうから、ここで踏ん張りを効かせて、Cソースが完全に
正常に動く所まで持っていけるように、自分の腕を鍛え上げてください。

292 :デフォルトの名無しさん:02/07/30 08:36
>LightCone
なんか偉そうだね。

プロテクトモードへは移行しているが?
しかも、raw binaryを吐き出させているから、
DS=ES=SS前提の、offset 0ベースでアドレス情報もキッチリ出力されてます。

>終端コードが読めないと思っていたら、読めることも有ったりするのは、

>>96で原因調査をして、>>111で解決策が出ています。
スレをもっとよく読みましょう。

んで、あなたの云う安定したアドレッシングモードってなんですか?

293 :デフォルトの名無しさん:02/07/30 08:42
まぁ、なんだ。
俺がいいたいのは、たとえ行き当たりばったりだとしても、
今は好きな順番で好きなようにやらせるべきだと思うんだ。
第一にひげぽんの知識が全然無いこと。
今は何をやっても無駄ということはなく力になる段階であると思う。
そして、最も重要な事は、モチベーションを持続させる事であるため、
お仕着せで作業順を決定するのはどうかと。

294 :LightCone:02/07/30 10:26
>>292
そうだったんですか。
でも、raw binary と言う言葉も、offset 0 ベースでアドレス情報が
出ていると言うことも、このスレだけでは読み取れないと思います(gcc
に詳しくなければ。)。

ともかく、ひげぽんさん、頑張ってくださいね。
#293 さんが言う、モチベーションの維持は一番難しいと思います。
私だって、NWSOSが何を目的に作っているのかも分かっていませんし、
暫定版でもいいから公開しろという声が一部から上がったので、公開したく
無かったバージョンを無理やり公開したら、非難轟々を浴びたわけで、
もともとナケナシのモチベーションは下がりまくりです。

偉そうにしていると思う人もいるようですが、私もひげぽんさんも、立場
は何も変わらないんですよ。最初は何にも無い所から作り始めたんですか
ら、、、。今でもたいしたことは全然無いんですけれど。
まあ、そもそも、コンピュータソフト自体は、その中に使われている
純粋な理論以外の部分では、「簡単」と思われても仕方が無い部分を
持っていて、私自身も、他の分野に比べてかなり簡単だと思っている
わけで、いまさら、OSを作れたぐらいで偉そうにするなと言われても、
私自身が、OSを作ることなんて大したことが無いと自分で思っている
わけで、そういうことを言う人が、何がいいたいのかわからないで困っ
ています。

はっきり言いまして、OSなんてある種の人たちには簡単に作れるはずなん
です。しかし、全世界が、Windowsの呪縛からなかなか離れないでいるこ
ともまた事実で、それは技術的なものよりも、背景事情から来ていること
なんですが、かといって、万人にOSが簡単に作れてしまうと言うわけでも
無いのは事実だと思います。NWSOSごとき、OSと考えるなというのは
最もな意見ですが、それと同様なものさえも、日本ではあまり見かけない
という事実もまたあるんじゃないでしょうか、、、。

295 :デフォルトの名無しさん:02/07/30 10:29
この本読まなきゃ
ttp://www.linux.or.jp/bookreview/BR56.html

296 :デフォルトの名無しさん:02/07/30 11:14
>LightCone
なんか偉そうだね。

297 :デフォルトの名無しさん:02/07/30 12:22
この作者さん?
ttp://homepage2.nifty.com/nowsmart/nwsos.htm

ここまでがんばってるんだから多少エラソウに見えてもしょうがない

298 :デフォルトの名無しさん:02/07/30 12:24
でも、作って喜ばれるのは Windowsと互換性が大きいOSだろうな

299 :デフォルトの名無しさん:02/07/30 13:23
WindowsCE互換のほうが喜ばれる
またWindows互換でかつ下位互換なら狂喜する

300 :デフォルトの名無しさん:02/07/30 13:51
x86ベースのCEなんてあったか?
API互換でも動くソフトが存在しないんじゃ?

301 :デフォルトの名無しさん:02/07/30 14:03
>>297
>この作者さん?
> ttp://homepage2.nifty.com/nowsmart/nwsos.htm
>
> ここまでがんばってるんだから多少エラソウに見えてもしょうがない

だから偉そうにしていいのか?ノータリンですか?

302 :デフォルトの名無しさん:02/07/30 14:14
>>301
ご本人はそういうつもりじゃないと思うけどなあ・・・
それなりに情報もってるんだろから排斥しなくてもいいのにと思ったからさ

303 :ろうひ男爵:02/07/30 14:23
>x86ベースのCEなんてあったか?
MSのエミュレーターであるよ。
コンシューマ向けでも何度か企画されたことがある。

304 :デフォルトの名無しさん:02/07/30 16:49
>>303
企画つーか、高木産業から一機種発売になってます。

305 :デフォルトの名無しさん:02/07/30 20:23
>>296
>>301
 このスレを覗いている人たちや助言をしてくださっている方々のモチベ
ーションを下げる傾向にある(と自分には受け取れた)発言は慎むべきか
と思われ。。。
 だって、情報が集まらなくなるじゃないですか?そうなったらお互いに
損ですよね?;-)

>>293
 モチベーションの持続・・・大事ですね。最近切に感じます。
とりあえず、
「最初はみんな素人だ、失敗し、学び一人前になる」
「壁を意識できるやつは壁を乗り越える素質を持っている」
とか言ってみるテスト。

# 関係ないレスでスマソ。


306 :ひげぽん ◆zcp/NZpA :02/07/30 21:32
>>289 ろうひ男爵さん
>ちなみに、タイマーは、ワンショットではなく、方形派のハズなので、
>周期的に何回も割り込みがかかってきているかチェックしてくださいね。
これは確認できました。
確かに一定の間隔の割り込みで発生しています。

>>290,>>291 LightConeさん
まずは書き込みありがとうございます。
実際にOSを作っている方からの意見は大変貴重でありがたいです。

> この掲示板を読む限り、なんとなく勘で試したら、動く時も有った、
>かのような感じを受けるのですが、そういう姿勢はやめて、もっと
>精密に一歩一歩石橋を渡るように前に進んでいくことをお勧めします。
>まず、ブートさせる前に、イメージファイルなどをバイナリエディタで
>くまなく観察することがお勧めです。
そうですね。確かに、本来であればその姿勢が正しいと思います。
現状自分では、手探り状態でOSを作っている状態です。
本来であれば気を付けなければいけないところに、手が回らず
とりあえず動くものを・・・という姿勢でやっています。
もちろん不定な動きがあれば、原因追求すべきだと思います。

現状作っているものは、位置づけとしてプロトタイプと考えています。
出来がよければそのまま使い続けるかもしれません。

>ともかく、ひげぽんさん、頑張ってくださいね。
>#293 さんが言う、モチベーションの維持は一番難しいと思います
ありがとうございます。
これは最重要項目ですね(笑)
この掲示板に書き込みを下さる方もありがたいです。

307 :デフォルトの名無しさん:02/07/30 21:34
ひげぽんさん、頑張れ!!

308 :ひげぽん ◆zcp/NZpA :02/07/30 21:35
ありがとうございます。
さあがんばろう。

309 :ひげぽん ◆zcp/NZpA :02/07/30 22:54
おれは何も出来ない。
でもこのスレは好き。
だからage

310 :ひげぽん ◆zcp/NZpA :02/07/30 22:56
スレッドを間違えました。
恥ずかしい・・・
そもそもageてないし。
反省して今日はもう寝ます。

311 :デフォルトの名無しさん:02/07/31 00:12
>>309 ?

312 :デフォルトの名無しさん:02/07/31 01:56
>>309
ゴバク(・∀・)ニヤニヤ

313 :デフォルトの名無しさん:02/07/31 02:08
誤爆じゃなくて自演だろ。( ´_ゝ`)

314 :デフォルトの名無しさん:02/07/31 02:22
内容からして7行スレかメーラスレ?

315 :ひげぽん ◆zcp/NZpA :02/07/31 08:26
>>311,312,313,314
プログラム板の某スレッドと間違えました。
大変失礼しました。

こっそり報告です。
sourceforge.jpに昨晩申請し、今朝PJ登録されました。
プロジェクト名は、higeposです。


316 :ろうひ男爵:02/07/31 12:44
>>306
では、ちゃんと割り込みは入っているみたいですね。
では、キーボード割り込み単体の問題みたいですねぇ。
タイマーの方もEOIしてるでしょうし、
他の割り込みをmaskしてみてはどうでしょうか。

>>304
フォローありがとう。
そーいえば、高木産業からノーパソの筐体を使ったCEが出てたんですよね。

317 :デフォルトの名無しさん:02/07/31 13:04
>>309
ひげぽん・・・俺は気にしないぞ。がんばれ。
俺は自演でも気にしないぞ。
・・・ぁ〜あ。

318 :デフォルトの名無しさん:02/07/31 13:36
http://sourceforge.jp/projects/higepos/
http://higepos.sourceforge.jp/

319 :ひげぽん ◆zcp/NZpA :02/07/31 20:45
>>318
ありがとう。
引き続き協力者募集中です。

しばらくはsourceforge用の環境構築に時間が取られそうです。

>>316 ろうひ男爵さん
ありがとうございます。
他の割り込みをMASKする方針でちょっとやってみます。

ところで会社から2chを見ようと思うのですが←ダメ社員
どこかのサービスで、ページにアクセスしてURLを入力すると
CGIかなんだかが、URLのページ内容を代わりに表示するみたいなのって
ありませんでしたっけ?
どなたか知っていたら教えてください。

320 :デフォルトの名無しさん:02/07/31 21:03
CGIプロクシは
http://www.age.ne.jp/x/babya/download/#EseXy
これをどっかにおけばいいんでねの?

321 :ひげぽん ◆zcp/NZpA :02/07/31 21:05
>>320
おおありがとう。でもどこに置こう。
どこかに既存のものがあったら、さらにありがたいっす。

322 :ひげぽん ◆zcp/NZpA :02/07/31 21:58
Windowsでcygwin,Meadow,djgppをいれていて
なんちゃってunix環境なのでssh,scp,cvsの設定は楽かと思ってたけど
もう少し時間がかかりそうです。

323 :デフォルトの名無しさん:02/07/31 22:07
確かに最初は面倒かも。

324 :デフォルトの名無しさん:02/08/01 20:36
開発停止中?

325 :デフォルトの名無しさん:02/08/01 20:46
ひげぽんはフォーラムにも既に書き込んでいるが
質問やらなんやらはこのスレでした方が良くないか?
フォーラムの方はあれたときの非難用か何かの方が都合良いと思うぞ。

326 :デフォルトの名無しさん:02/08/02 00:36
>>325
そうね。
今のとこ、こちらのが気楽に書き込みできそうだし。
とりあえず、様子見。


327 :ひげぽん ◆zcp/NZpA :02/08/02 00:54
やっとSSHでシェルログインできました。

sourceforge.jpのドキュメントは一部古いものがあったり
.netのものだったりして苦労しました。
分かりづらかったのでメモ代わりに方法を書いておきます。

私の環境は
cygwinの
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
Bad escape character 'rsion'.

■キー作成
ssh-keygen -t rsa
パスフレーズの入力をすると
.ssh/id_rsa.pubというファイルが出来る。

■キー登録
sourceforge.jpにログインし、メニューのアカウント管理を選び
シェルアカウント 鍵の編集で
上記ファイルの内容をそのままペーストする。

数分待ってから

■ログイン
ssh -l username shell.sourceforge.jp

パスフレーズを入力するとめでたくログインできる。

ちなみにcvsは本を買ったので勉強中です。

>>325
了解です。

引き続き協力者募集中です。see >>257

328 :ひげぽん ◆zcp/NZpA :02/08/02 20:13
sourceforge.jpのhigeposプロジェクトに
現状のソースをCVS importをしました。
下記からたどっていただけたらと思います。
http://sourceforge.jp/projects/higepos/

本日より開発を開始いたします。


329 :デフォルトの名無しさん:02/08/02 21:24
再開したね。

330 :デフォルトの名無しさん:02/08/02 21:27
放置すると自演するもんな。

331 :デフォルトの名無しさん:02/08/02 21:46
とりあえず荒らすなよ


332 :ひげぽん ◆zcp/NZpA :02/08/02 23:10
キーボード割り込みが1回しか取れない現象で困っています。

割り込み許可の前に以下の作業をしています。
    /* Enable IRQ0 (timer) and IRQ1 (keyboard) at the
    8259 PIC chips, disable others: */
    outportb(0x21, ~0x03);
    outportb(0xA1, ~0x00);
キーボード割り込みハンドラでは
    /* EOI is below for IRQ 0-7 */
    outportb(0x20, 0x20);

    /* iret */
    asm("mov %ebp,%esp");
    asm("pop %ebp");
    asm("iret");
をしています。

timerイベントは、定期的取得できているのですが、
キーボードイベントは一度しかとれないです。

333 :FreeDOS教徒:02/08/02 23:41
SourceForge進出おめでとうございます。

一度しかキーボードイベントが取れないのでしたら、
出力バッファが満杯なフラグが立ったままなのでは?

これは私の勘なのですが、キーボードコントローラが
フラグを感知して割り込みを発行しないのかも。。
ハンドラでステータスレジスタを操作してやれば如何?

334 :ひげぽん ◆zcp/NZpA :02/08/03 00:10
>>SourceForge進出おめでとうございます。
ありがとうございます。
最近ちょっとモチベーションが下がり気味だったのですが回復しました。

>一度しかキーボードイベントが取れないのでしたら、
>出力バッファが満杯なフラグが立ったままなのでは?
おっしゃるとおりでした。
まずはキーボードハンドラが呼ばれることを実現するという方針で
進めていたのがあだとなったようです。

importb(0x60)でscan codeを取得するようにしたら
複数回のキーボードイベントを感知できるようになりました。

キーボードイベント取得成功版をcommitしました。

335 :ひげぽん ◆zcp/NZpA :02/08/03 01:17
キーボードイベントの取得のめどがたったので
ちょっと考えてみました。
以下私の思考の流れです。

キーボード処理を書いてるけどこれってドライバーだよなあ。
OSからみて、ハードウェア割り込みって受動的だ。
とりあえずキーイベント情報は、バッファにためるべきかな。
でもためたキーボードイベントって、アプリケーションはどうやって
受け取るんだろう。

1.アプリケーションに取りに来てもらう。
2.アプリケーションはキーハンドラを用意して、OSはそいつにキー情報
を与えてやる。

どっちにしろ、OSとドライバーの関係をきっちり決めなければ
いけない気がしてきた・・・・
でもその前にメモリをどう管理するかを決めたほうがよいかな。
そうすればmalloc,newもできるようになるし、幅が広がるかも。

ということで、当面の目標は、メモリ管理について調べて実装するという事に
なりそうなのですが、
間違った方向に行ってませんか?
上記よりも大事なことがあるだろ!みたいな突っ込みお待ちしています。

336 :デフォルトの名無しさん:02/08/03 01:31
メモリマネージャ->ABI->実行イメージの順でいいとおもうよ

337 :FreeDOS教徒:02/08/03 06:54
それが基本でしょう

338 :ひげぽん ◆zcp/NZpA :02/08/03 10:15
>>336, >>337
ありがとうございます。
メモリマネージャ作成を次の目標とさせていただきます。

339 :デフォルトの名無しさん:02/08/03 10:24
キタ━━━(゚∀゚)━━━!!

ひげぽんぽん(ハッカー)◆zcp/NZpA

の誕生だ!

340 :ひげぽん ◆zcp/NZpA :02/08/03 21:12
MemoryManagerという抽象クラスを継承したX86MemoryManagerクラスを
作るという設計方針でテストしていたのですが・・・・

リンク時に以下のエラーが出てしまうのですが、
これの解決方法をご存知の方がいたら教えてください。
なお、継承をしなければ以下のエラーは出ません。
ld.exe: warning: cannot find entry symbol start; defaulting to 00001200
../../bin/X86MemoryManager.o(.gnu.linkonce.d._ZTI16X86MemoryManager+0x0):X86MemoryManager.cpp: undefined reference to `__ZTVN10__cxxabiv120__si_class_type_infoE'
../../bin/X86MemoryManager.o(.gnu.linkonce.d._ZTI13MemoryManager+0x0):X86MemoryManager.cpp: undefined reference to `__ZTVN10__cxxabiv117__class_type_infoE'
make.exe: *** [../../bin/third.bin] Error 1



341 :デフォルトの名無しさん:02/08/04 00:40
>>340
RTTI関連じゃないか?

342 :ひげぽん ◆zcp/NZpA :02/08/04 11:49
>>341
ありがとうございます。
-fno-rtti オプションでコンパイル後
リンクすると
ld.exe: warning: cannot find entry symbol start; defaulting to 00001200
../../bin/MemoryManager.o(.gnu.linkonce.d._ZTV13MemoryManager+0x8):MemoryManager.cpp: undefined reference to `___cxa_pure_virtual'

というエラーが出てしまいます。
仮想関数を使っているのが怒られているのでしょうか。
でももう一息で解決しそうな・・・・

343 :超先生@OS板 ◆OS/dd1Xc :02/08/04 12:09
>>342
 ∧_∧
< `ー´>y-~~~ 典型的なC++コンパイラの実装に従えば、
___cxa_pure_virtualは純粋仮想関数の不正な呼び出しを受け止める関数かな。

ダミーでvoid ___cxa_pure_virtual() {}とかしておけばいいかと。

344 :ひげぽん ◆zcp/NZpA :02/08/04 13:54
>>343
ありがとうございます。
自分の実験でも純粋仮想関数を使うと上記のエラーが出ることが分かりました。
基底クラスのクラス宣言で
void MemoryManager::___cxa_pure_virtual() {}
としてみましたが、リンク時に同じエラーが出てしまいます。

純粋仮想関数が使えなくても、何とかなるといえばなるのですが、
のちのちクラスの設計・実装者の意図がうまく伝わらないことが起こりそうで心配です。

345 :ひげぽん ◆zcp/NZpA :02/08/04 13:55
ひとつ書き忘れました。
ただの仮想関数なら大丈夫でした。

346 :デフォルトの名無しさん:02/08/04 13:57
>>344
extern "C" void __cxa_pure_virtual();
void __cxa_pure_virtual() {}


347 :デフォルトの名無しさん:02/08/04 14:00
ttp://ponta.kit.to/doc/develop/
[libstdc++]
pure virtual な 関数を定義すると
undefined reference to `__cxa_pure_virtual'

undefined reference to `vtable for __cxxabiv1::__class_type_info'
が出る。

-lstdc++
ライブラリをリンクするのを忘れてた。
以上。



348 :ひげぽん ◆zcp/NZpA :02/08/04 14:10
>>346
>extern "C" void __cxa_pure_virtual();
>void __cxa_pure_virtual() {}
これは、別ファイルでこの関数を定義して
pure virtual関数宣言時にヘッダーをincludeして、リンクするということでしょうか?

それとも基底クラス内でのお話ですか。

>>347
OS開発時にライブラリをリンクしてしまってよいのでしょうか。


349 :超先生@OS板 ◆OS/dd1Xc :02/08/04 14:25
 ∧_∧
< `ー´>y-~~~

>>348
> これは、別ファイルでこの関数を定義して
> pure virtual関数宣言時にヘッダーをincludeして、リンクするということでしょうか?

ヘッダをincludeする必要すらなく、全く別のモジュールとして
__cxa_pure_virtual関数をlinkするだけでOK。

350 :デフォルトの名無しさん:02/08/04 14:27
>>348 そうじゃなくてC++の名前変換の仕掛けを止める為に extern "C" を付けろという意味です

351 :ひげぽん ◆zcp/NZpA :02/08/04 14:33
>>349
>>350
ありがとうございます。
出来ました。別モジュールとしてリンクしたらばっちりでした。
この関数はいずれ、OSレベルで何らかのエラー処理を実装したほうが
良いのでしょうか。


352 :デフォルトの名無しさん:02/08/04 14:33
> OS開発時にライブラリをリンクしてしまってよいのでしょうか。

好きにやったらいいと思うけど、こういうややこしい問題は暫く続くよ

だって、仮想関数テーブルはどこに配置されてるとか、そんなレベル
をコントロールしなくちゃいけないでしょ

このレベルだとまだ C で書いた方がいいんじゃないの?
仮想関数の代わりに 関数ポインタ構造体にしておけば?

353 :名無しさんだよもん:02/08/04 16:48
>>349
それもパクリですか?(藁

354 :デフォルトの名無しさん:02/08/04 17:00
え?
超先生がパクリ?

355 :赤紫超先生@OS板 ◆OS/dd1Xc :02/08/04 17:17
>>353
 ∧_∧
< `ー´>y-~~~ バイナリ〜

356 :デフォルトの名無しさん:02/08/04 17:20
なになに?

357 :ひげぽん ◆zcp/NZpA :02/08/04 21:21
http://sourceforge.jp/projects/higepos/

メモリ管理勉強中。
デマンドページング
セグメント
アドレス変換

難しいですね。
これはなかなか大きな壁だ。
でもやる気出てきた。最近あまり頭使ってないし・・・
たまにはじっくり考えよう。


358 :ひげぽん ◆zcp/NZpA :02/08/05 23:26
メモリマネージャの外部インターフェースは、
大雑把に言えば
  ・メモリを確保する(malloc,new系)
・メモリを開放・後処理(free,delete系)
ですよね。
この二つのインターフェースの実装はたくさんの選択肢があると
思います。
仮想メモリ、ページング等の技術を駆使して賢く作るのが
理想でしょう。

ですが、今の私の技術レベルからする一からそれを実装するのは
難しいと思います。

そこで最低限のメモリ管理機能を実装しようと思うのですが、
どのような管理機能を実装すると勉強になるでしょうか。
もし経験者の方がいたらアドバイス頂けたらうれしいです。

359 :デフォルトの名無しさん:02/08/06 15:42
Windowsとか、LinuxとかのメジャーなOSでは
どうやってるのかを調べることからはじめると
理解が進むと思いますよ。


360 :ひげぽん ◆zcp/NZpA :02/08/07 00:07
>>359
ありがとうございます。
メジャーなOSだときちんとした(実装するのは難しい)メモリ管理機能
を搭載していて、ちょっとボリュームありすぎます・・・

昨日今日とメモリ管理について勉強して気づいたのですが、
実験段階であればとりあえず要求されたメモリをただ割り当てて
後始末出来ればよいのではないでしょうか。

とりあえず勉強ばかりだとモチベーションが維持できなくなるので
そろそろ簡単な実装には入れればと思います。


361 :デフォルトの名無しさん:02/08/07 00:19
>>360
> 実験段階であればとりあえず要求されたメモリをただ割り当てて
> 後始末出来ればよいのではないでしょうか。
極論すれば、とりあえず割り当てだけして解放はほっとくというのでも
良いかも...

static void *Last = 0x10000; // 管理領域の最初

void *Malloc(size_t Size)
{
 void *OldLast = Last;
 Last += Size;
 return Last;
}

void Free(void *p)
{
}

みたいな...。

362 :ひげぽん ◆zcp/NZpA :02/08/07 00:30
>>361
ありがとうございます。
そうですね。
この方針で明日にでも実装してみます。
その後 new演算子も実装しようかなあ。

363 :デフォルトの名無しさん:02/08/07 01:00
OSもできていない段階で聞くのもなんですが。
higepos上で動作するアプリケーションなんてのは
どうやって作っていくんでしょう?
専用のコンパイラとか必要になるんですか?

364 :ひげぽん ◆zcp/NZpA :02/08/07 01:12
>>363
>higepos上で動作するアプリケーションなんてのは・・・
興味深い質問です。
今のところ未定ですが、
実行ファイルの形式を決定すればある程度形は決まると思います。

理想は、標準のCおよびC++クラスライブラリとAPI
を提供してフリーのコンパイラでコンパイルすればOK!という形です。

その辺にもし御興味があるなら
ぜひhigeposプロジェクトへご参加ください(笑)
http://sourceforge.jp/projects/higepos/

365 :デフォルトの名無しさん:02/08/07 01:53
>>360
確かMINIXは仮想メモリ実装してなかったと思う。参考になるかも。


366 :デフォルトの名無しさん:02/08/07 02:03
>>364
>を提供してフリーのコンパイラでコンパイルすればOK!という形です。
こういうことに突っ込むのもアレだがリンクはしないの?

367 :ひげぽん ◆zcp/NZpA :02/08/07 19:52
>>365
ありがとうございます。
Minix本は一応持っているのですが、ソースまでは追ってないです。

>>366
おっしゃるとおり、リンクしなければならないので
フリーのリンカでうまくいけば吉かと。

368 :ひげぽん ◆zcp/NZpA :02/08/08 00:21
X86MemoryManagerをsingltonパターンで実装していたらリンクエラーに
くじけるもんか・・・


369 :デフォルトの名無しさん:02/08/08 20:58
age

370 :デフォルトの名無しさん:02/08/08 21:21
シングルトンパターンなら C言語の領域(関数ポインタ)で書けばいいんじゃないの?
それが出来ないJAVAの為のパターンをわざわざ踏襲する必要ないだろうに

371 :ひげぽん ◆zcp/NZpA :02/08/08 21:36
>>370
>シングルトンパターンなら C言語の領域(関数ポインタ)で書けばいいんじゃないの?
それも選択肢のひとつだとは思います。

>それが出来ないJAVAの為のパターンをわざわざ踏襲する必要ないだろうに
今回のX86MemoryMangerは、メモリを管理するクラスで
インスタンスが2つ以上あることは許されません。
そのためシングルトンパターンが必要なのです。

また、MemoryMangerという抽象クラスを継承していて
いることにより、インターフェースが確定しているので
容易に他のMemoryManagerと入れ替えることが出来るはず・・・
という計画です。


372 :ひげぽん ◆zcp/NZpA :02/08/08 21:48
class X86MemoryManager:virtual MemoryManager {

  private:
    X86MemoryManager() {}
    ~X86MemoryManager();
    X86MemoryManager(const X86MemoryManager&);
    X86MemoryManager& operator = (const X86MemoryManager&);
  public:
    char* getMessage();
    char* getName();
    unsigned long allocateMemory(unsigned long);
    unsigned long freeMemory(unsigned long);
    static X86MemoryManager& instance() {
        static X86MemoryManager theInstance;
        return theInstance;
    }
};
のように実装したのですが、
link時に
ld.exe: warning: cannot find entry symbol start; defaulting to 00001200
../../bin/higepos_kernel.o(.gnu.linkonce.t._ZN16X86MemoryManager8instanceEv+0x2f):higepos_kernel.cpp: undefined reference to `_atexit'
というエラーが出てしまいます。

extern "C" int _atexit();
int _atexit() {}
としてもだめでした。
うーん。なぜだろう。

373 :超先生@OS板 ◆OS/dd1Xc :02/08/08 21:57
 ∧_∧
< `ー´>y-~~~ いよいよ夏の祭典が始まりか。。。

_atexitはANSIだと↓だと思うけど。

int _atexit( void (__cdecl *func)(void));

374 :超先生@OS板 ◆OS/dd1Xc :02/08/08 22:02
訂正: int _atexit( void (*func)(void));

375 :デフォルトの名無しさん:02/08/08 22:11
atexitが呼ばれないようにすればいいんじゃない?

static X86MemoryManager *theInstance;
if (!theInstance) theInstance = new X86MemoryManager;
return *theInstance;

あとさ、何で atexit にアンダーバー付けて定義してるの?


376 :ひげぽん ◆zcp/NZpA :02/08/08 23:13
>>373 374 375
>int _atexit( void (*func)(void));
ありがとうございます。この定義でも同じエラーが出てしまいました。

atexitが呼ばれないようにすればいいんじゃない?

>static X86MemoryManager *theInstance;
>if (!theInstance) theInstance = new X86MemoryManager;
>return *theInstance;
実はこのクラスに限っては上記の方法を使いたくんないんです。
このクラスのallocateMemory()が、newや、mallocの元となる関数なんです。
このクラスが完成したらnewや、mallocが
使えるようになって、幸せになる予定です。

>あとさ、何で atexit にアンダーバー付けて定義してるの?
_を除いて、コンパイルしてリンクしたら幸せになりました。
ありがとうございます


377 :ひげぽん ◆zcp/NZpA :02/08/08 23:27
ところで
>超先生@OS板
>いよいよ夏の祭典が始まりか?
夏の祭典てなんですか?

378 :デフォルトの名無しさん:02/08/08 23:48
甲子園!

違うか。。。

379 :ひげぽん ◆zcp/NZpA :02/08/08 23:50
甲子園か・・・
超先生@OS板さんは、謎多し



380 :ひげぽん ◆zcp/NZpA :02/08/09 00:18
higepos開発時に簡単な図を含んだドキュメントを作ろうと思っているのですが、
何かお勧めな、フリーのツールで一般的なファイル形式のものってないでしょうか。

複数人で開発するので少なくともWindowsおよびunix系のどちらでも編集閲覧
が可能でないとまずいのですが、今のところ候補は、
open office???とかしか思い浮かばないです・・・

UMLが描けたら最高ですが、簡単な図が描けるだけでも十分です。
メモリの図やら簡単なクラス図とか・・・


381 :デフォルトの名無しさん:02/08/09 00:23
ぉぉ、超先生!こんなところに出張してるとは(ワラ

382 :デフォルトの名無しさん:02/08/09 00:38
自分で超だの先生だの名乗る人間は碌な人間じゃない。

383 :デフォルトの名無しさん:02/08/09 10:29
>>380 一般的なファイル形式 と言うならHTMLでしょ 次は .pdf

384 :デフォルトの名無しさん:02/08/09 10:41
ちょっと違うかもしれんが…
http://pc3.2ch.net/test/read.cgi/tech/1008775775/l50

385 :デフォルトの名無しさん:02/08/09 12:43
>>382
10点

386 :ひげぽん ◆zcp/NZpA :02/08/09 22:12
>>383 384
ありがとうございます。
htmlは図形描画が厳しいですね。
pdfって、adobeのWriter以外の編集手段ってあるんでしょうか?

ところで
Gnu diaってどうなんでしょうか?

387 :デフォルトの名無しさん:02/08/09 22:30
TeXとかは? 一応図も書けるし.

388 :ひげぽん ◆zcp/NZpA :02/08/09 22:35
>>387
texいいですね。
学生のとき愛用してました。
でもtexの本、友達にあげちゃいました。
texかあ、すっかり忘れたなあ。卒論のときは重宝しました。
Wordで卒論かいてるやつが気の毒だった・・・

389 :387:02/08/09 22:40
>>Wordで卒論かいてるやつが気の毒だった・・・
禿同.

…とか言ってる俺がWordで仕様書書きながらこのスレを
見てるわけだ. もう見てらんない….

390 :ひげぽん ◆zcp/NZpA :02/08/09 22:46
>>389
卒論って、画像とか張りまくって
表とかが多いのでWordがすごい不安定になるんですよね。

とかいいながら、わたしもテスト仕様書をExcelでかいてたりする・・・

391 :デフォルトの名無しさん:02/08/09 23:02
馴れ合いはsageでいこうや

392 :ひげぽん ◆zcp/NZpA :02/08/09 23:04
りょうかい!!!

393 :ひげぽん ◆zcp/NZpA :02/08/09 23:12
機能は、X86MemoryManagerのSingleton化と
そいつのメソッドを使って
new,delete演算子を定義しました。
でも怖くてまだ使えてません。
土日にじっくりと実験してみようと思います。

394 :ひげぽん ◆zcp/NZpA :02/08/09 23:14
機能→昨日m(_ _)m

395 :デフォルトの名無しさん:02/08/10 11:02
sourceforge.jp に行ったら、Higeposプロジェクトが活発な
プロジェクト一覧に入ってたよ。
すごいじゃん。


396 :デフォルトの名無しさん:02/08/10 18:28
GNU Dia
http://www.lysator.liu.se/~alla/dia/

397 :デフォルトの名無しさん:02/08/10 18:49
>>395
俺も見た。すごいねー。

398 :デフォルトの名無しさん:02/08/10 19:25
自分もひげぽんさんに感化されてOS作ろうとしているんですが
http://pcmania.jp/~osdev/echo/first_boot.asm
これをNASMでコンパイルして実行するだけで3rd exceptionが出てしまいます。
どこらへんが悪いか誰か御教授お願いします…

399 :デフォルトの名無しさん:02/08/10 19:56
OS Developer's Siteの管理人さんですか

>これをNASMでコンパイルして実行するだけで3rd exceptionが出てしまいます。
画面には何か表示された?
関連ファイルはすべて提示したほうがきっと、玄人さんたちが
答えやすいと思うよ
OSを作りたいなら、higeposに参加するのもあり

400 :398:02/08/10 21:45
>>398
自己レス。
恥ずかしながら単にセグメントレジスタについて勘違いしておかしな設定をしてしまっていただけのようです。
それを直したらうまく動いてくれました。

>>399
>>OSを作りたいなら、higeposに参加するのもあり
自分ではペースが遅くてあまり貢献できなさそうなので1人マイペースで作っていく予定です。

401 :デフォルトの名無しさん:02/08/10 22:11
higeposはGPLなのか…。

402 :ひげぽん ◆zcp/NZpA :02/08/10 22:49
>>395 397
>sourceforge.jp に行ったら、Higeposプロジェクトが活発な
>プロジェクト一覧に入ってたよ。
>すごいじゃん
ありがとうございます。でもあれって、何が基準なんだろう。
75.555%みたいな表示があるけど・・・

>>401
>>higeposはGPLなのか…。
sourceforge.jpの申請時にライセンスを選ばなければいけなかったので
GPLにしました。
でもGPLの説明英語だったから多分3/4位しか理解してない。

GPLのデメリットとかあるんですかね。
ちょっと不安になってきた。
一応ライセンスは、変えられるらしいけど。

ただいま、new実験中。
2重インクルード防止を忘れてたので、でいろいろと書き換え中。


403 :デフォルトの名無しさん:02/08/10 23:01
オープンソフトのライセンスについて
ttp://icrouton.as.wakwak.ne.jp/pub/e-law/opensource.html

個人的にはBSDが好き。GPLは縛りがきついので使えない事が多い。
でも、ひげぽんがイイ!と思うライセンス形態にすればいいと思うよ。

404 :403:02/08/10 23:03
オープンソフト→オープンソースだ。

405 :ひげぽん ◆zcp/NZpA :02/08/10 23:42
>>403
大変有用なリンクをありがとうございます。
とりあえず、GPLのままで行こうかなと思います。
GPLに必要な、COPYINGを追加しました。

406 :ひげぽん ◆zcp/NZpA :02/08/11 00:19
メモリを割り当てる実験をしているのですが、
mallocやnew演算子の元となる関数で返す、割り当てられたメモリの
先頭アドレスって、CSのなかでのオフセットアドレスで良いんでしょうか。

bochsで以下のエラーが出てしまいます。
実装方法は、>>361のような感じです。

>0000311650e[CPU ] prefetch: running in bogus memory
>0000311652i[CPU ] write_virtual_checks(): write beyond limit, r/w
>0000311687p[CPU ] >>PANIC<< iret: return CS selector null


407 :超先生@OS板 ◆OS/dd1Xc :02/08/11 01:01
>>406
 ∧_∧
< `ー´>y-~~~ 念のため確認しておくと、
仮想関数の呼び出し(allocateMemory)自体は問題ないのかな?

仮想関数テーブルが初期化されていないため、
running in bogus memoryになってる気がする。

408 :デフォルトの名無しさん:02/08/11 01:06
ひげぽんも知ってると思うけど, GPLの和訳もネットに転がってるから, キチンと理解したいのなら探してみるのもいいかもしんない.

409 :ひげぽん ◆zcp/NZpA :02/08/11 09:32
>>407
超先生@OS板さん、いつもありがとうございます。

>仮想関数テーブルが初期化されていないため、
>running in bogus memoryになってる気がする。

X86MemoryManager& mm = X86MemoryManager::instance();
_sysPrintInt(mm.allocateMemory(500));

と実行すると意図どおりの動きをするので
仮想関数呼び出しは問題ないと思います。

>>408
>ひげぽんも知ってると思うけど, GPLの和訳もネットに転がってるから, キチンと理解したいのなら探してみるのもいいかもしんない
ありがとうございます。
そうですね。上であげていただいたリンクも結構詳しい解説が載っていましたよ。

410 :デフォルトの名無しさん:02/08/11 10:22
あのさー、そろそろ最小のCランタイム書いた方が良いんじゃない?
atexitだって存在しないと静的なクラスのデストラクタ呼び出しが出来なくなるだろうし。

411 :ひげぽん ◆zcp/NZpA :02/08/11 15:51
>>410
Cで書いた方がOS作りに集中でき、余計な面倒がかからないと
仰ってくれてるのは大変ありがたいのですが、
もう少しだけがんばってみます。m(__)m

>>409
メモリ割り当てのエラーに関して問題の切り分けをしてみたところ
どうやら超先生@OS板さんのご指摘の通りかもと思われます。

-- テスト用 --
int* num = (int*)malloc(sizeof(int));
*num = 8885;
_sysPrintInt(*num);


-- これは動きました --
void* malloc(unsigned long size) {
    return (void*)0x10000;
}

-- これはエラーでした --
void* malloc(unsigned long size) {
    X86MemoryManager& mm = X86MemoryManager::instance();
    return (void*)mm.allocateMemory(size);
}

unsigned long X86MemoryManager::allocateMemory(unsigned long size) {
    return 0x10000;
}

-- エラー内容 --
00000311654i[CPU  ] write_virtual_checks(): no write access to seg
00000311654p[CPU  ] >>PANIC<< exception(): 3rd exception with no resolution

超先生@OS板さんのご指摘の通り
仮想関数テーブルの初期化辺りが怪しいのかといろいろ調べたのですが
ちょっと行き詰っています。
WEBで調べたところ仮想関数テーブルは、GCCが作成してくれるみたいな
記述があったのですが、この認識は間違っているのでしょうか。


412 :ひげぽん ◆zcp/NZpA :02/08/11 15:52
>>409で書いたように
一部の関数はきちんと動いているので余計混乱しています。
うーん。

413 :デフォルトの名無しさん:02/08/11 16:42
>>405
gcc使っているなら絶対gplでなきゃだめジャン。

414 :デフォルトの名無しさん:02/08/11 16:43
>>413 ん? なぜ? まあいいか別のスレでやっておくれ

415 :デフォルトの名無しさん:02/08/11 17:39
>>411
>Cで書いた方がOS作りに集中でき、余計な面倒がかからないと
>仰ってくれてるのは大変ありがたいのですが、
>もう少しだけがんばってみます。m(__)m

ちゃうちゃう。
シングルトンにするとリンクエラーが出るんだろ?
つーことは、静的領域にあるインスタンスの解放(デストラクタ呼び出し)は
Cランタイムのatexitを利用して実装してるって事になる。
勝手にatexitを何もしない物で置き換えたら、メモリマネージャのデストラクタが呼ばれなくなるはず。

416 :デフォルトの名無しさん:02/08/11 17:40
>>413
gccを使っても問題ない。
古いバージョンのglibcを使うとGPLに縛られることになるけど、
このプロジェクトでは標準ライブラリも使ってないしね。

417 :デフォルトの名無しさん:02/08/11 17:43
>>413
(゚Д゚)ハァ?
http://www.gnu.org/licenses/gpl-faq.ja.html#CanIUseGPLToolsForNF

(´-`).。oO(なんでこういう誤解する香具師が減らないんだろう・・・)

418 :デフォルトの名無しさん:02/08/11 18:09
>>413
ライセンスも理解してないバカが発言するな。

419 :デフォルトの名無しさん:02/08/11 18:45
>>416
標準ライブラリを使ってもgplに引っかかるのか?

420 :デフォルトの名無しさん:02/08/11 19:46
>>419
新しいバージョンのglibcはLGPLだったはず。
昔はGPLだった。

421 :ひげぽん ◆zcp/NZpA :02/08/11 19:54
>>415
>シングルトンにするとリンクエラーが出るんだろ?
>つーことは、静的領域にあるインスタンスの解放(デストラクタ呼び出し)は
>Cランタイムのatexitを利用して実装してるって事になる。
>勝手にatexitを何もしない物で置き換えたら、メモリマネージャのデストラクタが呼ばれなくなるはず
すいません。大きな誤解をしていたようで・・・
つまり、リンクエラーの回避のためにatexitを実装するなら
静的領域にあるインスタンスのデストラクタが呼ばれるように
きちんと実装しないとだめということですね。
これであってますでしょうか。



422 :デフォルトの名無しさん:02/08/11 23:45
>>420
LGPLって、GPLよりゆるいんだよね。

423 :デフォルトの名無しさん:02/08/12 15:11
>つーことは、静的領域にあるインスタンスの解放(デストラクタ呼び出し)は
>Cランタイムのatexitを利用して実装してるって事になる。

やっぱりC++のソースから吐き出されるアセンブラソースが完璧に
想定できるようでないと、カーネル組むのは難しいね。
ひげぽんがC++でがんばってるの見るといろいろと参考になります。

ところで、oskitはMSのCOMを真似てC++でもOSが作れるようにしてる
みたいだけど、そのあたりの技術はかっぱらってこれないかしら?

424 :ひげぽん ◆zcp/NZpA :02/08/12 22:14
>>423
oskitダウンロードしてみました。
ソースはかなり参考になりますね。
ありがとうございます。

今も暴走中・・・


425 :ひげぽん ◆zcp/NZpA :02/08/12 23:11
AtheOSがC++で書かれているようですね。
あれくらいのOS作りたいなあと思う今日この頃

やっぱり仮想関数呼び出し辺りが非常に怪しい。
すごい怪しい・・・



426 :デフォルトの名無しさん:02/08/12 23:37
>ひげぽん
いまAtheOSを見てみたけどカーネルはCで書いてあるよ。
前に見たときの記憶だとeCosがC++だったような。。

それよりもC++の出すアセンブラをよく見た方が
良さそうだね。

427 :ひげぽん ◆zcp/NZpA :02/08/13 23:12
>>426
>前に見たときの記憶だとeCosがC++だったような
ありがとうございます。
時間のあるときにぜひ見てみます。

>それよりもC++の出すアセンブラをよく見た方が
>良さそうだね。
そうですね。
早く安定した、C++環境を構築することも大きな目標です。
今日は今帰ってきたのであまり進んでおりません。


428 :超先生@OS板 ◆OS/dd1Xc :02/08/13 23:29
gccが吐き出したバイナリをupしてもらえると、
何か手がかりがつかめるかも知れず。

429 :デフォルトの名無しさん:02/08/13 23:51
>428
そこまでしてあげますか。
ご苦労様です。

430 :ひげぽん ◆zcp/NZpA :02/08/14 00:36
>>428
超先生@OS板さんいつもありがとうございます。
下記URLにエラーの再現するソースとバイナリを置かせていただきました。
http://oshigepon.tripod.co.jp/

エラー内容
prefetch: running in bogus memory
write_virtual_checks(): write beyond limit, r/w
>>PANIC<< iret: return CS selector null

超先生@OS板さんのご好意によりアドバイスが頂けるかもしれないとの
ことですが、もしよろしければ今後のためにも
調査のポイント、こんなことを勉強しておけ、こいつを読めなどありましたら
ぜひ教えてください。
本来この部分は自分でどうにかしないといけないことだと思います・・・
大変申し訳ありませんがもし何か、お気づきの点がありましたら
教えてください。


431 :超先生@OS板 ◆OS/dd1Xc :02/08/14 01:20
ttp://www.skyfree.org/linux/references/ELF_Programmer.pdf
の 3.1 Global Constructors and destructors in C++
が参考になるかも。

コンストラクタのコードにバイナリ上での目印を埋め込んでもらえるかな。
asm("hlt") を10個程度。

432 :超先生@OS板 ◆OS/dd1Xc :02/08/14 02:03
というか、crt0のソースコードを見るのが手っ取り早いと思うけど。

433 :デフォルトの名無しさん:02/08/14 10:12
>>415
OSなんでしょ。atexitなんか何もしなくていいんじゃないの?

434 :デフォルトの名無しさん:02/08/14 10:18
>>433
あんたはOSのシャットダウンフェーズには何もやらないで
勝手に電源切っちゃうタイプですか?

435 :デフォルトの名無しさん:02/08/14 10:45
シャットダウン処理を静的変数のデストラクタで実装するの?
それ本気で言ってる?

436 :デフォルトの名無しさん:02/08/14 11:37
なんでcrt0なんてものをくっつけるの?
そんなもんリンクしたらだめじゃん

437 :デフォルトの名無しさん:02/08/14 18:22
age


438 :デフォルトの名無しさん:02/08/14 18:27
で、マジな話日本人で趣味でOS作ってる奴いるの?

いたとしたらうpして

439 :デフォルトの名無しさん:02/08/14 19:06
OSっいうよりはここでやろうとしてるのはカーネルだよな。
いや、分かっているのならいいんだけど。

440 :デフォルトの名無しさん:02/08/14 20:24
いきなりそんなしちめんどうそうなことせずこれくらいのやつでやったらどうなるよ?

class base {
public:
virtual int func(void) = 0;
};

class sub : virtual base {
public:
static sub& instance(void)
{
static sub inst;
return inst;
}

int func(void)
{
return 100;
}
};

void cstart(void)
{
sub &a = sub::instance();

// a.func() を表示
}


441 :ひげぽん ◆zcp/NZpA :02/08/14 21:13
>>431, 432 超先生@OS板さんありがとうございます。
>ttp://www.skyfree.org/linux/references/ELF_Programmer.pdf
>の 3.1 Global Constructors and destructors in C++
>が参考になるかも。
ありがとうございます、参考にさせていただきます。

>というか、crt0のソースコードを見るのが手っ取り早いと思うけど
>なんでcrt0なんてものをくっつけるの?
>そんなもんリンクしたらだめじゃん
crt0というものを知らなかったので調べてみたら
#一般の C プログラムをコンパイルすると, 全体の先頭に crt0.s
#(をコンパイルして得られる crt0.o) というファイルが自動的に付加される. このファイルには, main 関数を呼び出す前に行なう処理が記述されている.
とでていました。これって勝手にリンクされているのでしょうか。



442 :ひげぽん ◆zcp/NZpA :02/08/14 21:22
>>440さんのアドバイスに従い
-- Sub.cpp --
#include<Sub.h>

int Sub::getNumber(void) {
    return 777;
}

char* Sub::getName(void) {

    static char* name = "BASE\n";
    return name;
}

-- Sub.h --
#include<Base.h>

class Sub : virtual Base {
  public:
      static Sub& instance() {
          static Sub theInstance;
          return theInstance;
      }
      int   getNumber();
      char* getName();
};


443 :ひげぽん ◆zcp/NZpA :02/08/14 21:22

-- Base.h --
class Base {
  public:
    virtual int   getNumber(void) = 0;
    virtual char* getName(void)   = 0;
};


-- higeOperetor.cpp --
char* getName() {
    Sub& sub = Sub::instance();
    return sub.getName();
}

-- startKernel.cpp --
Sub& sub = Sub::instance();
_sysPrintInt(sub.getNumber()); /* 直接呼出しOK   */
_sysPrint(sub.getName());      /* 直接呼出しOK   */
_sysPrint(getName());          /* 間接呼び出しNG */

-- エラー内容 --
prefetch: running in bogus memory
write_virtual_checks(): write beyond limit, r/w
>>PANIC<< iret: return CS selector null



444 :ひげぽん ◆zcp/NZpA :02/08/14 21:24
上記のインスタンス取得後 sub.getNumbet();
のような呼び出しは大丈夫だが。

関数getName()を介してSub::getNameを呼び出すと
エラーになってしまいます。

445 :超先生@OS板 ◆OS/dd1Xc :02/08/15 02:22
Sub* sub = &Sub::instance();
_sysPrintInt(sub);

だとどうなるのかな?

446 :名無しの組込みプログラマ:02/08/15 12:56
>>441
> crt0というものを知らなかったので調べてみたら
> #一般の C プログラムをコンパイルすると, 全体の先頭に crt0.s
> #(をコンパイルして得られる crt0.o) というファイルが自動的に付加される. このファイルには, main 関数を呼び出す前に行なう処理が記述されている.
> とでていました。これって勝手にリンクされているのでしょうか。

「一般のCプログラムをコンパイルすると」じゃなくて、「一般の
Cプログラムをリンクすると」だね。

勝手にリンクされるかどうかはあなたがどーやってリンクして
るか次第。
モノを見ずに憶測で言えば、リンクされてはいないと思う。
逆に言えば、crt0.o相当の処理を追加する必要があるって
こった。
超先生がソースを見ろって言ってるのもそういう意味だろ
ね。

447 :ひげぽん ◆zcp/NZpA :02/08/15 22:31
>>445 超先生@OS板さん
    Sub* sub = &Sub::instance();
    _sysPrintInt((int)sub);
としてみたところ。
10288(0x2830)と表示されました。

>>446
>「一般のCプログラムをコンパイルすると」じゃなくて、「一般の
>Cプログラムをリンクすると」だね。
そうですね。

>逆に言えば、crt0.o相当の処理を追加する必要があるって
>こった。
>超先生がソースを見ろって言ってるのもそういう意味だろ
>ね。
crt0ってmainを呼び出す処理とかをしているように思われるのですが
フロッピーブートするOS(もどき)にも必要なのでしょうか。




448 :名無しの組込みプログラマ:02/08/15 23:18
>>447
> crt0ってmainを呼び出す処理とかをしているように思われるのですが
> フロッピーブートするOS(もどき)にも必要なのでしょうか。

「とか」の部分が重要なことがあるよ、ということです。
必要かどうかは、自分で判断ね。

449 :ひげぽん ◆zcp/NZpA :02/08/15 23:26
>>448
>「とか」の部分が重要なことがあるよ、ということです。
>必要かどうかは、自分で判断ね。
なるほど。
では、今回のエラーは、もしかしたらcrt0の部分でやるべき
作業をしていないことが原因かもしれないということですね。
勉強になります。ありがとうございます。


450 :デフォルトの名無しさん:02/08/16 19:29
今動かない原因とは直接関係ないと思うけど、注意すべき点を幾つか。

静的に初期化出来ないデータ(プリミティブ型ではないもの)や
指定する初期値が定数でない(関数の返り値など)に対して
関数内staticなインスタンスを用いる場合、一般的なコンパイラの生成コードは、
staticなフラグとインスタンス用の領域だけを用意して
最初に到達した時に初期化するという形式になると思われます。

具体的には、
Singleton& Singleton::instance() {
 static Singleton instancedata;
 return instancedata;
}
は、実際には下のようなコードが作られるということです。
Singleton& Singleton::instance() {
 static bool flag; // = false;
 static char instancedata[sizeof(Singleton)];
 if (!flag) {
  flag = true;
  new (instancedata) Singleton();
  add_destructor_list(data, Singleton::~Singleton); // 擬似コード
 }
 return *(Singleton *)&instancedata;
}

451 :デフォルトの名無しさん:02/08/16 19:30
このコードの中には、注意すべき点が3つほどあります。

まず、デストラクタを呼び出すために
thisとデストラクタ関数のアドレスをどこかに登録しています。
C++は、他の多くの言語と違い統一基底クラスがないため
インスタンスのポインタだけではデストラクタを呼び出せません。
ポインタと共に関数のアドレスも渡す必要があり、
これをどこかで管理しておいてプログラムが終了する前に呼び出すことになります。

次に、初期にstaticなフラグを使っていることです。
コンパイラの生成コードは、単独のコンテキストで実行される前提のため、
コストの増えるロック等は一般にはしていません。
このようなコードはマルチスレッド(あるいは非同期処理)において
支障をきたす可能性があります。
割りこみハンドラや複数の(ユーザー)プロセスから呼ばれる可能性があるのなら
flagをtrueにする前に排他制御を行い、再度flagを確認してから処理をすべきです。

最後に、非初期化データ領域が0で埋まっていることを前提としている事です。
flagやinstancedataに使う領域は、実行ファイルが無意味に大きくならないよう、
data領域ではなくbss領域に置かれ、スタートアップで0クリアされることが
期待されています。
別の言い方をすると、crt0をリンクしないのならば
非初期化データが0であることに依存してはならないのに、
コンパイラの生成するコードがそれに依存している(可能性が高い)ということです。

452 :ひげぽん ◆zcp/NZpA :02/08/17 09:37
>>450,451さん
ありがとうございます。

大変勉強になります。
もともとSingletonのコードを書くときに
flgを用いないようにしたのは、スレッドセーフにしようという意図だったのですが
見事にコンパイラが危険なコードを吐いてくれてるんですね。

>別の言い方をすると、crt0をリンクしないのならば
>非初期化データが0であることに依存してはならないのに、
>コンパイラの生成するコードがそれに依存している(可能性が高い)ということ
なるほど。
でもだからといって、crt0を安易にそのままリンクするというのも
問題がありそうですね。

今回の問題はいまだ解決せず、思うように進んでいないので
ちょっと逃避してクラス図を追加しました。


453 :デフォルトの名無しさん:02/08/17 09:54
ユーザーオブジェクト以外でObjectルートにする意味ってあるか?

454 :ひげぽん ◆zcp/NZpA :02/08/17 10:04
>>453
突っ込みありがとうございます。
MemoryManagerに関して言えばObjectをルートにする必要は多分ないと思います。
カーネル内のクラスでは、同一インターフェースを実装した
複数種類のオブジェクトがいる予定なので
デバッグ時にObjectのメソッドを活用しようかと・・・

455 :デフォルトの名無しさん:02/08/17 19:07
うまくいかない部分はとりあえず保留にして、
他の部分の実装に入るのもありかと思うよ。

456 :デフォルトの名無しさん:02/08/17 19:16
ダメダメ、本当はオブジェクト形式やリロケーションなどの知識は
制作に入る前に知っておかなければならないことだし、
これは解決しておかないといつも詰まってばかりで進行が滞るんでない?

457 :デフォルトの名無しさん:02/08/17 19:27
ここのところあまり進んでなさそうだよね。
モチベーションが下がると思ってさ。
今どの段階でつまってるんだっけ?

458 :デフォルトの名無しさん:02/08/17 19:46
ここを解決しないなら、CでやるかC++の危険そうな機能は使わないことかな。

>>442
じゃ、下みたいに継承を削ったらどうなる?
仮想関数が原因かどうか分かるんでない?

class Sub {
public:
static Sub& instance() {
static Sub theInstance;
return theInstance;
}
int getNumber();
char* getName();
};


459 : :02/08/17 19:50
>>443
アセンブラのコードは見てみた?手元のgccだと、
これどっちも同じコード吐くんだけど。

> _sysPrint(sub.getName()); /* 直接呼出しOK */
> _sysPrint(getName()); /* 間接呼び出しNG */

460 :ひげぽん ◆zcp/NZpA :02/08/17 20:18
>>455 456
そうですね。保留にして先に進みたいのですが、
メモリ管理が出来ないとnewすらできないので
非常に困るのですよね。


461 :デフォルトの名無しさん:02/08/17 20:21
オブジェクト指向スレでC++でOS書けるとか息巻いてた
先生方はどこへ行かれたのでしょうか?素朴な疑問です。

462 :ひげぽん ◆zcp/NZpA :02/08/17 20:36
>>458さん
継承を削ってみたところ、
別のエラーが出ました。エラー内容は

00000775036e[CPU  ] prefetch: running in bogus memory
です。

そのときのアセンブラコードは

[_sysPrintln(sub.getName());]
00000104  83EC0C            sub esp,byte +0xc
00000107  FF75FC            push dword [ebp-0x4]
0000010A  E8F1080000        call 0xa00
0000010F  83C404            add esp,byte +0x4
00000112  50                push eax
00000113  E8EC000000        call 0x204
00000118  83C410            add esp,byte +0x10

[_sysPrintln(getName());]
00000120  83EC0C            sub esp,byte +0xc
00000123  83EC04            sub esp,byte +0x4
00000126  E84F070000        call 0x87a
0000012B  83C404            add esp,byte +0x4
0000012E  50                push eax
0000012F  E8D0000000        call 0x204
00000134  83C410            add esp,byte +0x10

463 :ひげぽん ◆zcp/NZpA :02/08/17 20:37

>>459さん
継承をそのまま残した場合は

00000782814e[CPU  ] load_seg_reg: GDT: ES: index(1fd8) > limit(00001f)
00000782849p[CPU  ] >>PANIC<< fetch_raw_descriptor: LDTR.valid=0
というエラーで

[_sysPrintln(sub.getName());]
0000011D  83EC0C            sub esp,byte +0xc
00000120  8B45FC            mov eax,[ebp-0x4]
00000123  8B00              mov eax,[eax]
00000125  83E814            sub eax,byte +0x14
00000128  8B00              mov eax,[eax]
0000012A  0345FC            add eax,[ebp-0x4]
0000012D  8B10              mov edx,[eax]
0000012F  83C204            add edx,byte +0x4
00000132  8B45FC            mov eax,[ebp-0x4]
00000135  8B00              mov eax,[eax]
00000137  83E814            sub eax,byte +0x14
0000013A  8B00              mov eax,[eax]
0000013C  0345FC            add eax,[ebp-0x4]
0000013F  50                push eax
00000140  8B02              mov eax,[edx]
00000142  FFD0              call eax
00000144  83C404            add esp,byte +0x4
00000147  50                push eax
00000148  E8F7000000        call 0x244
0000014D  83C410            add esp,byte +0x10

[_sysPrintln(getName());]
00000155  83EC0C            sub esp,byte +0xc
00000158  83EC04            sub esp,byte +0x4
0000015B  E874070000        call 0x8d4
00000160  83C404            add esp,byte +0x4
00000163  50                push eax
00000164  E8DB000000        call 0x244
00000169  83C410            add esp,byte +0x10

464 :デフォルトの名無しさん:02/08/17 20:46
class X86MemoryManager:virtual MemoryManager;
virtual継承やめたら?
それから、vmmをprivate継承する必要はないでしょう。

465 :ひげぽん ◆zcp/NZpA :02/08/17 20:53
>>464さん
>class X86MemoryManager:virtual MemoryManager;
>virtual継承やめたら?
>それから、vmmをprivate継承する必要はないでしょう
アドバイスありがとうございます。
今現在出ているエラーが継承に起因するものかきちんと切り分けること
ができたら、継承関係の整理もきちんとさせていただきます。

466 :超先生@OS板 ◆OS/dd1Xc :02/08/17 21:25
やはりmain関数前に実行すべき処理があるはず。(おそらくcrt0相当)

third.binの0x14e8が恐らくはスタートアップ時の関数テーブルだと思う。

467 : :02/08/17 21:34
>>463
_sysPrintln(sub.getName()) の呼び出しも vtbl 経由に
なっているので、_sysPrintln(sub.getName()) が動いて
_sysPrintln(getName()) が動かないのは信じられないのだが。

468 :ひげぽん ◆zcp/NZpA :02/08/17 23:48
>>466
超先生@OS板さん いつもお世話になっております。

>やはりmain関数前に実行すべき処理があるはず。(おそらくcrt0相当)
>third.binの0x14e8が恐らくはスタートアップ時の関数テーブルだと思う。
なるほと。この間教えていただいた通りcrt0のソースをどこからか入手して
見るしかないのでしょうか。

>>467
>_sysPrintln(sub.getName()) の呼び出しも vtbl 経由に
>なっているので、_sysPrintln(sub.getName()) が動いて
>_sysPrintln(getName()) が動かないのは信じられないのだが。
vtblとは、仮想関数テーブルのことですよね。
でもgetName()だけだときちんと動くんですよね。
なせだろう。

469 :ひげぽん ◆zcp/NZpA :02/08/18 00:23
vtblの解説を見つけたので
ttp://www.semantics.org/gotchas/gotcha50.pdf

470 :デフォルトの名無しさん:02/08/18 01:46
>>458も書いてるけど、怪しげなC++機能は捨てたほうがいい。

たとえば、コンストラクタ/デストラクタが必要なクラスを静的持続時間を
持つオブジェクトに使わなければ、_atexit()は必要なくなる(はず)。

MemoryManagerをどうしてもsingletonにしたいなら、

inline void *operator new(size_t size, void *ptr) { return ptr; }

MemoryManager *mm;

void start()
{
 char x86mm[sizeof(X86MemoryManager)];
mm = new (x86mm) X86MemoryManager;
 mm.~X86MemoryManager;();
}

みたいにするとか。

純粋仮想関数呼び出しのハンドラは仕方ないね。
基本クラスのコンストラクタの実行時のvtblは基本クラスのものになるから、
純粋仮想関数を持つクラスでは必ず呼び出す可能性がありえる。
Visual C++のコンパイラみたいに、__declspec(novtable)があるなら平気だけど。

あと、仮想基本クラスは要らないと思うよ。多重継承が必要な場合は、Javaの
インタフェースみたいな使い方すればいいんだし。多分設計が間違ってる。

このあたりはコンパイラにアセンブリ言語のソース吐かせれば調べられるよ。

471 :ひげぽん ◆zcp/NZpA :02/08/18 12:23
>>470
>たとえば、コンストラクタ/デストラクタが必要なクラスを静的持続時間を
>持つオブジェクトに使わなければ、_atexit()は必要なくなる(はず)。
なるほど、このような手もあるんですね。

>あと、仮想基本クラスは要らないと思うよ。多重継承が必要な場合は、Javaの
>インタフェースみたいな使い方すればいいんだし。多分設計が間違ってる。
>このあたりはコンパイラにアセンブリ言語のソース吐かせれば調べられるよ
元々私は、Java屋なのでX86MemoryManagerは、
インターフェースMemoryManagerをimplmentsしているイメージで設計しました。
つまり、
メモリ管理のコードをjava風に書くのであれば

MemoryManger mm = new X86MemoryManger();
mm.allocateMemory(size);
mm.freeMemory(address);

となります。メモリマネージャを使う場合は、そのインスタンスを
X86MemoryManagerとしてではなく、MemoryManagerとして扱います。
もし他のCPU向けに移植する場合は、
MemoryManger mm = new XXXXMemoryManger();
と書き直して
XXXXMemoryMangerを新たに実装するようにすれば良いのかと。

C++では、インターフェース継承を実現するには、
純粋仮想関数を基底クラスで宣言することにより実現し、そのクラスを
継承することで実現するのではないのでしょうか。
(Effective C++より)
あと、多重継承ですがObjectクラスを継承のことでしょうか。
ttp://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/higepos/higepos/doc/MemoryManager.png?rev=1.3&content-type=text/vnd.viewcvs-markup
をごらんいただければお分かりいただけるかと。

>このあたりはコンパイラにアセンブリ言語のソース吐かせれば調べられるよ
このあたりの重要さは、昨日より痛感しております。


472 :デフォルトの名無しさん:02/08/18 13:00
>あと、多重継承ですがObjectクラスを継承のことでしょうか。

virtual継承してるから、多重継承(というか、菱形継承)を気にしてるんだろうけど、
少なくともこのケースでは菱形継承になるような設計は間違ってるって話だろ。

473 :デフォルトの名無しさん:02/08/18 17:48
継承削って別のエラーってのもイケてないねェ。
アセンブラコードを部分だけ載せるくらいなら、そのときのソース全部と
gcc の -S オプションしたのでUPした方が良いかも。


474 :デフォルトの名無しさん:02/08/19 15:26
>MemoryManger mm = new X86MemoryManger();
>もし他のCPU向けに移植する場合は、
>MemoryManger mm = new XXXXMemoryManger();
>と書き直して

こんなの条件コンパイルでいいじゃん
これだからJava屋って....


475 :デフォルトの名無しさん:02/08/19 21:42
>>474
Javaだと条件コンパイルできないからAbstractFactoryとか使うだろ。
アンタの回りのJava屋がヘボいだけ。

MemoryManager mm = MemoryManager.getInstance();
mm.allocateMemory(size);
mm.freeMemory(address);

# 関係ないのでsage

476 :ひげぽん ◆zcp/NZpA :02/08/20 23:38
>>475
フォローありがとうございます。

エラーに関していまだ解決できておりません。
逆アセンブラしたものを、↓に置かせていただきました。
http://oshigepon.tripod.co.jp/
主要部分にはasm("nop");などを埋めました。

ソースは
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/higepos/higepos/src/
でご覧いただけます。

もしお気づきの点がありましたら、アドバイス、ご指摘いただけると
ありがたいです。
よろしくお願いいたします。


477 :デフォルトの名無しさん:02/08/20 23:56
ひげぽんさん、古いソース、消しちゃいました?
できればフォルダ作って取っておいてもらえるとうれしいかも・・・

478 :デフォルトの名無しさん:02/08/21 00:10
ごめんなさい、ソース移動したんですね。ぼけてました。

479 :ひげぽん ◆zcp/NZpA :02/08/21 00:11
>>477
>ごめんなさい、ソース移動したんですね。ぼけてました。
いえいえこちらこそ、不案内で申し訳ありません。


480 :デフォルトの名無しさん:02/08/21 12:26
>>475
ハードアーキテクチャの違いを吸収するため抽象クラスを
使うってのが間違ってるんじゃないのと言いたいわけよ。
特にメモリアロケータのような低レベルクラスでね。
それが原因(かどうかわからんけど)でドツボにはまってるわけだし。
このケースでは条件コンパイルで十分でしょ。


481 :デフォルトの名無しさん:02/08/21 13:29
ちと遅れてきたので、また〜りと古い質問してもいいでしょうか?(不味かったら放置してください)
secondboot.asmの最後を
>; jmp 0x200    ← jump をコメントアウト&hangをコメントイン
>hang:
>  jmp hang
とすると、「disk reading ... done」を表示して止まるのですが、
0を表示させようと思って、hang:の前に、
> mov al, '0'    ; 0を表示してhang
> mov ah, 0Eh
> mov bx, 0h
> int 10h
を入れると、リブートしてしまいます。
プロテクトモードではもしかしてbiosを使った画面描写ってできないのでしょうか?
それとも基本的な間違いを犯しているのでしょうか?

あと、現在のファイル全てをmakeしてddでFloppyに書き込んでブートしても、
やはりリブートしてしまいます。(タイミング的には↑と一緒のあたり)
いずれも実機(自作機)でやっているのですが、もしよろしければヒントをいただけないでしょうか?
環境は、ひげぽんさんと同じく nasmw,djgpp です。(Windows2000)
#必要があればバイナリを逆アセンブルして出してみます。。


482 :デフォルトの名無しさん:02/08/21 14:14
もうちょっと状況書きます。
↑の後者についてですが、とりあえずはハングアップさせようと思い、cpstart.cppの

startKernel();

の直前に

while (true) {}

を挿入します。で、makeして出来たthird.listをみると、

00000000 55 push ebp
00000001 89E5 mov ebp,esp
00000003 83EC08 sub esp,byte +0x8
00000006 90 nop
00000007 EBFE jmp short 0x7  ←ここでループするはず?

となっています。そして、first second third を cat したバイナリを
バイナリエディタでのぞいてみると、

00000400: 55 89 E5 83 EC 08 ・・・・

となっていて、400番地から命令が正しく入っていると(自分には)思われるのですが、
ddで書き込んでブートすると、リブートしてしまいます・・・

おかしいと思った点は、
jmp short 0x7
のジャンプ先は 01207 であるべきのような気がします。
もしかして、このせいでしょうか?

板汚し、すみません。以上です。

483 :超先生@OS板 ◆OS/dd1Xc :02/08/21 17:13
>>481
> プロテクトモードではもしかしてbiosを使った画面描写ってできないのでしょうか?
> それとも基本的な間違いを犯しているのでしょうか?

そのとおりです。
自力でVRAMへ書き込む必要があります。

>jmp short 0x7
>のジャンプ先は 01207 であるべきのような気がします。

eb feは相対jmp -1という意味になので
絶対的なアドレス(0x120n)は関係ないです。

484 :481:02/08/21 17:28
>>483
ありがとうございます。VRAMに直書でないといけないのですね。

>eb feは相対jmp -1という意味になので
そうでしたか。ということは、直前のnopあたりに戻ってループできそうですよね?
でもなぜかリブートしてしまいます。
ちょっと変ですね。secondbootから正しくジャンプしてきていないのかな?
少し考えてみます・・・。

485 :481:02/08/21 17:32
>直前のnopあたりに戻って
すんません。jmp命令自身に戻るんですよね。(細かいことですが)

486 :デフォルトの名無しさん:02/08/22 03:26
〈 トウヒョウシテクダサイ   〈 オネガイシマス…   〈 コノトオリデス!
 ̄∨ ̄ ̄ ̄ ̄ ̄   ∨ ̄ ̄ ̄ ̄ ̄ ̄  ∨ ̄ ̄ ̄ ̄ ̄
 (´Д`;)ヾ      (;´Д`)             ヾ
   ∨)        (  人)         (´Д`;)、
   ((          〉 〉           ノノZ乙

http://www.gal-para.com/gal-channel/read.cgi?bbs=lounge&key=1028811476&ls=50


487 :デフォルトの名無しさん:02/08/23 00:19
>>476
ディスアセンブル結果を見たけど、::getName() からの sub.getInstance()
呼び出しのアドレスが間違っているように見えた。
sub::getInstance() は0a70h からなのに、::getName()からは0a50hをコール。
わけわからん。
1)開発ホスト用にコンパイル&リンクしたら正常に実行できるの?
2)-S とかつけてコンパイルしたアセンブリリストが見たいなあ。

昔、オレもOSを作ろうとしたことあったよ。
同人ソフトを作るのに、MSDOSを添付したくなかったから。
といっても、BOOT+ファイルシステム+極小DPMIみたいなのだけど。
シェル無しのヘボDOSだな。
ゲーム用のシングルタスクだから、メモリ管理もプロセス管理も無いヤツね。
仕事が忙しくなって中断したが楽しかったなあ(仕事が落ちついたら、HDD
あたりまえの時代になっていて無用になった)。

CPU、コンパイラ(アセンブラ含む)、リンカ(実行時含む)あたりの知識は
どんな分野のプログラムでも役に立つと思うから、なるべくアセンブリと額
つつき合わせてがんばれ!


488 :ひげぽん ◆zcp/NZpA :02/08/23 00:36
>>487さん
こんばんわ。
ありがとうございます。
OS作りの先輩ですね。

>ディスアセンブル結果を見たけど、::getName() からの sub.getInstance()
>呼び出しのアドレスが間違っているように見えた。
>sub::getInstance() は0a70h からなのに、::getName()からは0a50hをコール。
>わけわからん。
コンパイル・リンクのどちらかでおかしくなっているのですが、
いったいどういう理由なのかがつかめていません。

>1)開発ホスト用にコンパイル&リンクしたら正常に実行できるの?
>2)-S とかつけてコンパイルしたアセンブリリストが見たいなあ。

週末にいろいろ実験してご報告させていただきます。
アドバイスありがとうございます。


489 :ひげぽん ◆zcp/NZpA :02/08/23 20:51
>>487さん
gcc -Sオプションで吐かれたアセンブラソースを以下のURLに置かせて
頂きました。
http://oshigepon.tripod.co.jp/

引き続き調査中です。
もし何かお気づきの点がございましたらご指摘くださいm(__)m

490 :ひげぽん ◆zcp/NZpA :02/08/25 15:50
仮想関数使用時に動きが怪しくなる問題が長い間解決できないので
とりあえず継承を一切やめて見たところ正常に動作しております。
(メモリをただ割り当てるだけバージョンのnew,malloc)

これから本格的にメモリ管理について実装する予定です。
メモリ割り当てのときにプロセスIDのようなものを引数で受け取ろうかどうしようか。
仮想メモリは、ファイルシステムができてからだろうか。
ファイルシステムと、プロセス管理も考えなくてはいけないことに気づいてきました。

以下ボヤキ
簡易版vectorをtemplate機能を使って作ってみたら、
リンク時にエラーが出た・・・
C++の機能が全然使えてない・・・・



491 :デフォルトの名無しさん:02/08/25 17:57
C++って、OSみたいな下位層のプログラムを書くには
複雑すぎるんじゃないの?

492 :ひげぽん ◆zcp/NZpA :02/08/25 18:08
>>491
そうかもしれませんね。
C++でやるには、コンパイラ・リンカの知識が
Cで作る場合に比べてさらに必要ということではないでしょうか。

知識がないうちは(今の私)、害が出ない程度に
C++の機能を使うしかないのではと思っています。

493 :デフォルトの名無しさん:02/08/25 20:19
ムム、面白いスレだ。

漏れはCとアセンブラは7年前くらいに学んだが最近はC++
に移行しちまってほとんど忘れてるなぁ。Cは覚えてるが。
C++は、確かに複雑だが、やれない事はないと思うよ。
まぁ、漏れが慣れてしまってるからかもしれないが。



494 :ひげぽん ◆zcp/NZpA :02/08/25 20:23
>>493
もしに何かご存知でしたらぜひご教授ください。
特にリンクcrt0関係やgccの吐くコード・リンクなどについて
困っています。

495 :デフォルトの名無しさん:02/08/25 20:34
少し上の方から読んでたから、話が見えないのでちょい始めから
目を通して見るね。

でも、Winアプリ屋の漏れの知識は役に立たないかも(w






496 :kso:02/08/25 21:07
過去ログなにも見ないで適当なこと言うけど、結局Linuxの二番煎じ?

497 :デフォルトの名無しさん:02/08/25 21:20
>>496
基礎の基礎を作ってるとこだよ。
これからの仕様、設計によってどんなOSになるか決まる。

498 :デフォルトの名無しさん:02/08/26 19:58
http://www.mega-tokyo.com/os/os-faq-cpp.html#start

499 :ひげぽん ◆zcp/NZpA :02/08/27 01:52
>>498さん
有用なリンクありがとうございます。
参考にさせていただきます。

500 :ひげぽん ◆zcp/NZpA :02/08/27 01:54
g++ -nostdlib -nostdinc -fno-builtin -fno-exceptions
あたりを参考にさせていただきます。
またbuiltin_のあたりも必須ですよね。


501 :kso:02/08/27 02:05
フリーか商用か、
LinuxのようなOSか、WindowsのようなOSか
どっちを目指す?


502 :ひげぽん ◆zcp/NZpA :02/08/27 02:22
>>501さん。
フリーですね。
宝くじが当たったら、仕事やめて開発に専念します(笑)
儲ける気はありませんが、自分の生活くらいは保障されるとうれしいかも

獲らぬ狸の・・・・でした。

503 :デフォルトの名無しさん:02/08/27 08:39
GUI部分に入ったら標準で2chブラウザをつけてくれい。

504 :デフォルトの名無しさん:02/08/28 03:32
gccとqtかgtk+を移植すればGeckoコンポ使ったブラウザが簡単に作れるカモ

505 :デフォルトの名無しさん:02/08/28 06:02
ま, そういう話しは別スレで.

506 :デフォルトの名無しさん:02/08/29 20:54
メンテ

507 :ひげぽん ◆zcp/NZpA :02/08/30 22:51
>>498
を参考にbuiltin_new,deleteも追加しました。
http://ime.nu/www.mega-tokyo.com/os/os-faq-cpp.html#start

ところで
__builtin_vec_new
って引数・戻り値ってどこで調べれば分かるでしょうか。
googleで調べたら、変なバイナリばかり引っかかってしまいます。

508 :487:02/08/31 06:05
まじ、すっかり忘れてた。
しかし、-S で出力したファイルの拡張子が .o ってのはあまりに以外であったが、
Unix 方面では一般的なのか? 必死に .s .src .asm を探し回ったよ。

で、アセンブリリストを見てみたわけだが、特に問題はない。
おそらく、オブジェクトファイルの段階では問題ないのだろう。
すると、リンク時のアドレス解決時の問題ということになる。
俺に思いつく可能性は、
1)リンカスクリプトのミス
2)ld のバグ(ホントかよ!)
だが、考えにくい・・・。
マップファイルが欲しい・・・。他にもズレてるシンポルがあるだろうから、
そこから原因が推測できるかも知れんし・・・。


ま、今日のところは何も分からないことが分かったというところか。

ところで、intelのサイトの資料は読んでる?
日本語でもまあまあ色々あるし、英語ならそれなりに面白いのもある。
資料不足なら逝ってみるのもいいんじゃない?

あと、ちょと前に出てた crt0 だけど、djgpp のソースから持ってきたんなら、
どっかに crt0.s (アセンブリソース)があるから見てみたらいいんじゃない
かな。
俺が見たことあるのは、拍子抜けするくらい単純なヤツだけど。
ま、ある意味、組み込み系の仕事だし、当然なんだけど。

# あの Makefile は多少切ない・・・


509 :487:02/08/31 06:07
長くて申し訳ないが、本日の成果

000000E1 E88A090000 call 0xa70=__ZN3Sub8instanceEv; Sub::instance()
000000E6 8945FC mov [ebp-0x4],eax
000000E9 83EC0C sub esp,byte +0xc
000000EC 8B45FC mov eax,[ebp-0x4]
000000EF 8B00 mov eax,[eax]
000000F1 FF75FC push dword [ebp-0x4]
000000F4 8B00 mov eax,[eax]
000000F6 FFD0 call eax; ->getNumber() ?
000000F8 83C404 add esp,byte +0x4
000000FB 50 push eax
000000FC E827010000 call 0x228=__Z14_sysPrintlnInti; _sysPrintlnInt()

call__ZN3Sub8instanceEv
movl%eax, -4(%ebp)
subl$12, %esp
movl-4(%ebp), %eax
movl(%eax), %eax
pushl-4(%ebp)
movl(%eax), %eax
call*%eax
addl$4, %esp
pushl%eax
call__Z14_sysPrintlnInti


_sysPrintln(getName());
0000012F 83EC0C sub esp,byte +0xc
00000132 83EC04 sub esp,byte +0x4
00000135 E844070000 call 0x87e=__Z7getNamev; getName()


510 :487:02/08/31 06:07
__Z9getNumberv:
pushl%ebp
movl%esp, %ebp
subl$8, %esp
call__ZN3Sub8instanceEv

0000085C 55 push ebp
0000085D 89E5 mov ebp,esp
0000085F 83EC08 sub esp,byte +0x8
00000862 E8E9010000 call 0xa50


__Z7getNamev:
pushl%ebp
movl%esp, %ebp
subl$8, %esp
call__ZN3Sub8instanceEv

0000087E 55 push ebp
0000087F 89E5 mov ebp,esp
00000881 83EC08 sub esp,byte +0x8
00000884 E8C7010000 call 0xa50=__ZN3Sub8instanceEv


__ZN3Sub8instanceEv:
pushl%ebp
movl%esp, %ebp
subl$8, %esp

__ZN3Sub8instanceEv:
00000A70 55 push ebp
00000A71 89E5 mov ebp,esp
00000A73 83EC08 sub esp,byte +0x8


511 :487:02/08/31 06:11
>>507
__builtin_vec_new prototype
でググったら普通にでてきたぞ。
どんぐらい普遍的なのかは知らんけど。

void* __builtin_new(size_t sz)
{
return kmalloc(sz, GFP_KERNEL);
}

void* __builtin_vec_new(size_t sz)
{
return __builtin_new (sz);
}

void __builtin_delete(void* ptr)
{
// if (ptr) //kfree checks against NULL pointer
kfree(ptr);
}

void __builtin_vec_delete(void* ptr)
{
__builtin_delete (ptr);
}


512 ::02/08/31 10:00
よーし、Higepon OSができたらパパなんか手伝っちゃうぞ〜。

513 :ひげぽん ◆zcp/NZpA :02/08/31 12:19
>>487さん
ありがとうございます。
>まじ、すっかり忘れてた。
>しかし、-S で出力したファイルの拡張子が .o ってのはあまりに以外であったが、
>Unix 方面では一般的なのか? 必死に .s .src .asm を探し回ったよ。

いや私がサボったため起きた現象です。-o *.oにしてたの忘れてしました。

>1)リンカスクリプトのミス
>2)ld のバグ(ホントかよ!)
>だが、考えにくい・・・。
なるほどオブジェクトファイルの時点では問題ないということですね。

>ところで、intelのサイトの資料は読んでる?
>日本語でもまあまあ色々あるし、英語ならそれなりに面白いのもある。
>資料不足なら逝ってみるのもいいんじゃない?
そうですね。存在は知っているのですが、なかなか読まないですね。
読んでみようと思います。

># あの Makefile は多少切ない・
どの辺が切ないのでしょうか。確かに我流だし、汎用性0ですね。
せめてunixのかたがたもすぐ使えるようにしたほうがいいのかも。






514 :ひげぽん ◆zcp/NZpA :02/08/31 12:29
>>511
builtin_vec_newもサイズだけ受け取ればよいんですね。
ありがとうございます。
配列用なので配列のサイズも必要なのかと思っていたのですが・・・

>>487さん
これからも、アドバイスいただけたらうれしいです。
OSを作ったことのある人の経験は大変貴重です。



515 :ひげぽん ◆zcp/NZpA :02/08/31 19:42
仕事もひと段落
やる気復活してきました。

Vectorがあるといろいろ便利なのだが・・・

516 :FreeDOS教徒:02/09/01 21:24
最近やっと資料を読んでから作業したほうが効率的だと気付きました。
理解しきれてないと、どうしてもどこかで行き詰まるもんです。

地味な作業みたいですが、地道にがんばってください。応援してます。

517 :ひげぽん ◆zcp/NZpA :02/09/01 21:34
>>516さん
そうですね。資料を読んで勉強して、それからですよね。
どうも行き当たりばったりで、行き詰ってたりします。

518 :ろうひ男爵:02/09/04 12:27
ひげぽんさんがんばってますね〜。
自分もアセンブラでですが作っています〜。
コンソールまで出来て、コマンド起動まで出来ました〜。
以前、DOSもどき+XMSの物は作ったことがあったので、
ここまではすんなりいきました。
次はint21hのエミュレーションです〜。

519 :ただの通行人G:02/09/04 14:53
>>502
>宝くじが当たったら、仕事やめて開発に専念します(笑)
そんなに、Pentiumでオナニーしたいのか?
用途不明のOS作りとは(笑)

520 :デフォルトの名無しさん:02/09/04 16:26
まあ386でオナったらLinuxができるんだから
IComp比の分いいものができる・・・かもな

521 :デフォルトの名無しさん:02/09/04 16:27
みんなでワッショイ
それひけオーエス

522 :ただの通行人G:02/09/04 18:42
確かに、386でオナったらLinuxができた。
でもそれは10年前の話、今それをやって何を作ろうとしているのか?
そこが疑問なんですよ

523 :デフォルトの名無しさん:02/09/04 18:45
>>522
作ることが楽しいっていうのはないですか?
just for fan。これは何年経っても変わらないと思われ。

524 :デフォルトの名無しさん:02/09/04 18:47
実用性は後付けでいいじゃん. 自分の力でどこまでできるか, 何ができるか.
プログラマはクリエイティブな仕事. 何らかの形にしたいと思った中でOSっていう
選択肢があるのも悪くない…と俺は思うぞ.


525 :デフォルトの名無しさん:02/09/04 18:53
>>522
それは、
「いまさら富士山に登って何の意味があるの?」
と聞いてるのと同じだと思うが。

526 :ただの通行人G:02/09/04 19:27
今、OSを作る理由が作るのが楽しいから
これを否定するつもりはありません。
疑問に思うのは、2002年に開発を始めたOSの目指す姿が不明な点です。

527 :デフォルトの名無しさん:02/09/04 19:56
ただの荒らしだね、これじゃ。

528 :デフォルトの名無しさん:02/09/04 20:00
今、富士山に登る理由が作るのが楽しいから
これを否定するつもりはありません。
疑問に思うのは、2002年に富士山に登り始めた登山者の目指す姿が不明な点です。

529 :デフォルトの名無しさん:02/09/04 20:22
>>526
おれも趣味でごにょごにょやってるわけだが、正直、どんなのを作ろう
かってのはわかんないけどな。OSの専門家じゃないし、理想の OSを作ろ
うという目標があるわけでもない。作っていくうちにいろいろわかって
くるとは思うけどね。で、作りたい OSがわかってくればそこでもう一度
作り直せばいいし。

今はどんなものが作りたいのか模索している段階だね。
プログラムで言えば、とりあえずHello, World作って、いろんなアルゴリ
ズムとか勉強してる段階。

ひげぽんの考えは知らないけど。

530 :ただの通行人G:02/09/04 20:22
疑問に対する答えはなしか、その程度だな。

531 :デフォルトの名無しさん:02/09/04 20:25
批判しかできない通りすがりははやく消えてほしいなぁ。

〜〜〜〜〜〜〜〜〜〜〜〜◯〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
                 Ο
                 o
              _____________
             /  ∧_∧        )
            / ( ̄(´Д` ; ) ̄0   /
         /~ ̄ ̄ ̄⌒⌒⌒⌒ ̄ ̄ ̄)
          / ※※※※※※※※  /
        / ※※※※※※※※  /
     / ※※※※※※※※   /
    (____________ノ

532 :デフォルトの名無しさん:02/09/04 20:26
そこまで話が言ってないのをログから読めないとは
読解力に致命的な問題があるのでは?

533 :デフォルトの名無しさん:02/09/04 21:42
だから荒らしは無視しなよ。
こんな奴に使って欲しいなんて思って作ってる人はいないんだから。

534 :ろうひ男爵:02/09/05 01:28
自分は、第一弾として、DOS-EXTENDER程度のOSを作ろうと思ってますよ。
目的としては学習用です。
第二弾、第三弾を作るときには目的は変わるかもしれませんが。

535 :デフォルトの名無しさん:02/09/05 01:51
>>534
釣り師か?
DOSEXTENDERはOSじゃないぞ.

536 :ろうひ男爵:02/09/05 02:26
>>535
ちとことばか足りなかったのですが、
INT21の拡張って意味です。
ところで、使用側から見ると、
win3.1と同じでextenderもosと見なして良いのでは?

537 :ろうひ男爵:02/09/05 02:33
また言葉が足りなかったので、つっこまれる前に。
int21hの拡張とは、32bit化への拡張です。
run386のファンクション程度を実装できたらと思っています。
機能的に、dos+extenderの機能を実装した簡易OSを作ろうと思っています。
dpmi機能よりは使用側がシームレスに使えると思っています。

次には、オリジナルの言語を作ろうと思っています。
c言語のプリプロセッサ機能+アセンブラのマクロ機能、
ここまでがプリプロセッサで実装しました。
その後、BASIC+PASCALの構造化言語を作っていますが、
プリプロセッサの実装までで力尽きました。
BASICインタープリターなら作ったことがあるので簡単ですが、
386コードへの変換が難しそう。


538 :ろうひ男爵:02/09/05 02:35
長々とスレ違いごみんね。

ところで、ひげぽんさんはDISKアクセスにはBIOSのリアルモードへ戻しますか?
あと、それとも関係しますが第一弾からマルチタスクにしますか?

539 :ただの通行人G:02/09/05 07:14
528,531,532
答えられないなら黙ってろ

540 :デフォルトの名無しさん:02/09/05 07:49
荒れてるね、( ̄ー ̄)ニヤリッ
当然と言えば当然だけどね。

ひげぽんも前半ははじめての486レベルの話が多かったし、
今も資料をあさればイイ話が多いからね。
そんなレベルなのに色々大きいこと言ってるからただの通行人Gに
かみつかれたんじゃない?

オレは理由は必要ないんじゃないって思ってるけど、
ひげぽんの甘え具合見てるとただの通行人Gの何のためにやってるのって気持ちも分かるよ。

でも、こには超先生や487やろうひ男爵みたいに優しい奴らが多いから、
ただの通行人Gは口を出さずに無視してれば良いんじゃない?

ひげぽんは今までみたいにマターリやって、
作れても失敗してもイイから作るってなかなか出来ないけど、
ここの雰囲気は凄くイイから、
見ててムカつくのも分かるけど黙って無視してれば>G

541 :540:02/09/05 07:56
>>522
勝手にやってればって無視してあげてよ。
でも、オナニーって言い方は言い得て妙だけど、
いちいち理由をつけてソフトを作ってる奴ってそんなにいないと思うよ。

>>535
いんや、Extenderはosの一部かもしくは微妙な部分だろ?
そんなのにいちいち反応するおまえが釣り師。
言葉尻に反応するのやめれ。

542 :デフォルトの名無しさん:02/09/06 01:29
単純でもいいからOSを作る事が目的なんじゃないの?

富士山に登るのも、まずは登り始めなければ始まらないし。
登り始めた登山者は最終的に富士山に登るのが目的。

ひげぽんが最終的にどんなOSのイメージを持っているかは
本人に聞かないと分からないが。。

まぁ、面白いスレだからマターリしましょう。

543 :ひげぽん ◆zcp/NZpA :02/09/06 01:52
お休みをとって、旅行に行っていました。

>>518 ろうひ男爵さん
>自分もアセンブラでですが作っています〜。
>コンソールまで出来て、コマンド起動まで出来ました〜。
すごいですね。
自分の勉強・力不足を感じます。


>ところで、ひげぽんさんはDISKアクセスにはBIOSのリアルモードへ戻しますか?
えーと私がソースをある程度読んだあるOSはリアルモードへ移行していました。
一応それを参考にしようかと思っています。

>あと、それとも関係しますが第一弾からマルチタスクにしますか?
まだ未定です。
もし自分の技術的に可能であればぜひマルチタスクにしたいです。
シングルタスクから入ったほうがメモリ管理等がシンプルそうなので
その辺の兼ね合いで考えようかと思っています。


544 :ひげぽん ◆zcp/NZpA :02/09/06 01:53
>>522 ただの通行人G
>そんなに、Pentiumでオナニーしたいのか?
>用途不明のOS作りとは(笑)
>今、OSを作る理由が作るのが楽しいから
>これを否定するつもりはありません。
>疑問に思うのは、2002年に開発を始めたOSの目指す姿が不明な点です。
>疑問に対する答えはなしか、その程度だな。
まずはお返事が遅れてしまって申し訳ありません。
OSを作ってみたい、作る過程が楽しそうだというのが
プロトタイプOSの開発開始の動機のひとつです。
そのため、明確なビジョン・進もうとしている方向は
私自身の中でもあいまいです。
そろそろそういったことを意識しなくてはいけないのかもしれませんね。

>>529さん
>OSの専門家じゃないし、理想の OSを作ろ
>うという目標があるわけでもない。作っていくうちにいろいろわかって
>くるとは思うけどね。で、作りたい OSがわかってくればそこでもう一度
>作り直せばいいし。
私もそんな感じです。すでに作り直したい・こうすればよかったという箇所があります。

>>540
>今も資料をあさればイイ話が多いからね。
>そんなレベルなのに色々大きいこと言ってるからただの通行人Gに
>かみつかれたんじゃない?
大きい事言ってますよね。
以後なるべく気をつけます。

今まで通りマターリとやらせていただきます。
よろしくおねがいします。

545 :デフォルトの名無しさん:02/09/06 02:09
>大きい事言ってますよね。
これも含めてひげぽんなので、今までのままでイイ!!と思うよ。


546 :デフォルトの名無しさん:02/09/06 04:09
いいと思うよ。何でも最初は叩かれ煽られる。
案外、先でひげぽんのOSが世の中に広まるかもしれない。


547 :ただの通行人G:02/09/06 07:31
>>540
これからは黙っていることにするよ。
ろうひ男爵のDOS-EXTENDER程度のOSは、わかりやすい言い方だと思う。
これぐらいの答えを期待していただけだし。


548 :あぼーん:あぼーん
あぼーん

549 :ひげぽん ◆zcp/NZpA :02/09/08 15:17
メモリ管理をゆっくりと実装中です。
簡易的なものですが、なかなか難しいですね。

550 :LightCone:02/09/08 17:10
>>549
 アプリプログラムの経験があっても、メモリ管理は普段やらないこと
ですからね。

 物理メモリの利用マップを管理するだけでも、なかなか難しいはず
です。最初、管理用のワークエリアを取る場所さえも自分で探す
必要がありますし。

 物理メモリマップの壁をクリアしても、論理的なメモリ管理用の
管理領域自体を動的に伸張していくことも以外に難しいと
思います。

 ページ単位でメモリを用意するためには、メモリブロックのヘッダ
を、メモリブロックの先頭にくっつける方法は取れないので、
別領域にまとめておかないといけなかったり。



 ページテーブルへアクセスするために、自己参照的なページ
エントリを作っておかないといけなかったり、システム共通領域
に対するエントリは、全てのタスクのページテーブルに書き換えを
反映させないといけなかったり。


 頑張ってください。

551 :ひげぽん ◆zcp/NZpA :02/09/08 17:47
>>550 LightConeさん
どうもお久しぶりです。

>アプリプログラムの経験があっても、メモリ管理は普段やらないことですからね。
そうですね。メモリ管理の勉強をしていて連想したのは、
HDDの断片化(デフラグしますよね) やデータベースのブロックでした。

>物理メモリの利用マップを管理するだけでも、なかなか難しいはず
>です。最初、管理用のワークエリアを取る場所さえも自分で探す必要がありますし。
最初、この部分で混乱しました。
空き領域をあらわすようなクラスを最初考えていたのですが、
そのクラスはどうやって自分自身のメモリを確保するんだろう?
newしたら無限ループに入るって事に途中で気づきました(笑)
実装前に気づいてよかったです。
結局、今回はあまり欲張りすぎず連結リストを用いた
メモリ管理をすることにしました。

上記実装が落ち着いてきて、他の部分も成熟してきたら
ページング等にも挑戦しようと思っています。

>ページテーブルへアクセスするために、自己参照的なページ
>エントリを作っておかないといけなかったり、システム共通領域
>に対するエントリは、全てのタスクのページテーブルに書き換えを
>反映させないといけなかったり。
>頑張ってください
ありがとうございます。

メモリ管理を実装中に、debugのために printfがほしくなったので
簡易版printfを実装中です。
ちょっと横道にそれてきました。

552 :デフォルトの名無しさん:02/09/08 17:57
>>551
printf…でなくてassertとかではダメかい?

553 :ひげぽん ◆zcp/NZpA :02/09/08 18:01
>>552
assertって自分で実装する必要ないのでしょうか。

554 :552:02/09/08 18:07
いや、printf実装するよりも簡単に使えるassertの方を先に実装したら?と思ったんだ。
でもデータのdumpとるのならprintfの方がいいかもね。

555 :ひげぽん ◆zcp/NZpA :02/09/08 18:12
>>552さん
簡易版printfができたら、assertは簡単に実装できると思うので
ご意見採用させていただきます。


556 :ひげぽん ◆zcp/NZpA :02/09/08 19:09
簡易版printfがやっと出来ました。
%s,%dしか使えませんが、かなり便利です。
もっと最初から作っておけばよかった・・・

557 :デフォルトの名無しさん:02/09/08 20:25
OSを一から作ろうとする情熱がすごいと思う。
俺はそこまでできない。


558 :デフォルトの名無しさん:02/09/08 22:39
このスレとは

ひげぽんに取って:たんにOSを作るうえでの技術相談所

厨房に取って:ひげぽんが何か大きなプロジェクトを立てようとしている
俺のが偉いんだ阻止するぞ阻止するぞ阻止するぞ阻止するぞ

559 : ◆k/Ubp.Kg :02/09/08 22:44
>>558
ワラタ。本当にそういう奴(厨房)いるからねぇ。

俺にとっては何やろうね。実はひそかにpart1から読んでたりするんだけど(藁。

560 :ひげぽん ◆zcp/NZpA :02/09/08 22:52
>>558
モチベーション維持にも活用させていただいております。
OSを作っている他の方々との交流もできたらよいなあ。

561 : ◆k/Ubp.Kg :02/09/08 22:53
っていうか、このスレの常連さんでOffとかやったら楽しいのではないだろうか、と言ってみるテスト。

562 :デフォルトの名無しさん:02/09/08 23:18
>>556
細かいことだけど、_sys_printf("xxx%"); とかやられると、ちょっとうれしく
ないことが起こる。また、現状の版では "%" を出力したい時は
_sys_printf("%s", "%"); とやるしかないので...

 for (int i = 0; format[i] != '\0'; i++) {
  if (format[i] == '%') {
   i++;
   switch (format[i]) {
   case 's':
    _sysPrint((char *)*list);
    ((char**)list) += 1;
    break;
   case 'd':
    _sysPrintInt((int)*list);
    ((int*)list) += 1;
    break;
>   case '%':
>    _sysPutCharacter('%');
>    break;
>   case '\0':
>    i--;
>    break;
  }
 } else {
  _sysPutCharcter(format[i]);
 }
}

とかすれば、どうでしょうか ?

563 :ひげぽん ◆zcp/NZpA :02/09/08 23:52
>>561さん
どうなんでしょうか?
コテハンの人以外にどのくらいの人数の方がいるんでしょう。

>>562さん
採用させていただきます。ありがとうございます。
ついでにtypoを直しました。charcterって・・・(鬱)
ソースを見てくれている人がいるんですね。
ちょっとびっくりしました。


564 :ひげぽん ◆zcp/NZpA :02/09/09 00:22
起動画面にちょっとお遊びを入れてみました。
ただいま逃避中。

565 :age:02/09/09 21:36
age

566 :デフォルトの名無しさん:02/09/10 14:51
みんなフロッピーブートセクタに書き込むには何を使ってるんでしょう。
win2000系では何があるんでしょうか。
rawriteではエラー、dksimgも何故かダメ。
質問だけでスンマソン。

567 :デフォルトの名無しさん:02/09/10 16:36
俺はWriteFileする自作の奴


568 :ろうひ男爵:02/09/10 21:54
>>566
自分はwin98seなのでint13hです。
以下の感じ。

; ipl の書き込み
movax,0301h; ah=03h,al=書き込みsec数
movcx,0001h; ch=シリンダ番号,cl=セクタ番号
xordx,dx; dh=ヘッド番号,dl=ドライブ番号
movbx,seg ipl_top; es:bx=書き込み先頭アドレス
moves,bx
movbx,offset ipl_top
int13h


569 :556:02/09/11 01:57
>>568
目からうろこが・・。

>>567,568
ありがとうございます!

570 :ろうひ男爵:02/09/11 02:55
>>569
たいしたものではないんですが、
アセンブラでよければIPLのプログラムをupしませうか?
tasmとtlinkでコンパイル出来る奴で、多分masmでもokだとおいます。

571 :デフォルトの名無しさん:02/09/11 03:13
IPLのプログラムじゃなくて、ディスクライターがほしいんじゃないのか

572 :ろうひ男爵:02/09/11 03:18
>>571
あ、ごめん。
自分は一本のプログラムに、IPL自体とIPLの書き込みルーチンをまとめてるので、
そういう意味でサンプルになるかなって思って書きました。

573 :デフォルトの名無しさん:02/09/11 08:17
>>572
上げてほしいっす

574 :ろうひ男爵:02/09/12 11:47
http://ime.nu/www.42ch.net/UploaderSmall/source/1031798613.lzh
iplプログラムです。
ご自分のお作りになった、2nd ipl 以降を読み込むための物です。

>ipl1.exe 1000 1000:0000 2 1
で、iplにプログラムを書き込みます。
この例の場合、iplはブートアップの後、セクタ2から1セクタ分seg1000へ読み込みます。
そして、seg1000:offset0000へジャンプします。

dosフォーマット済みのブランクfdをドライブに入れて、
window95/98/meなどのコマンドプロンプトで
>ipl1.exe 1000 1000:0000 2 1[ret]
と入力して下さい。
その後、マシンをリブートしてfdから起動させて下さい。
起動したら、メッセージが表示されます。

サンプルとして、2nd ipl のサンプルの ipl2.exe をつけますので、
先ほどのfdをドライブに入れれて、
window95/98/meなどのコマンドプロンプトで
>ipl2.exe[ret]
と実行して下さい。
なお、dosフォーマットのdiskはipl2.exeを実行したとたんデーターが壊れます。
その後、マシンをリブートしてfdから起動させて下さい。
起動したら、メッセージが表示されますが、
今度は"2ndIPL BOOT OK"というメッセージも表示されます



575 :ろうひ男爵:02/09/12 13:32
>>574
と思ったら、削除されてました。トホホ
どっかにプログラムをupするイイ所ってないっすか?

576 :デフォルトの名無しさん:02/09/12 13:37
ddでいいじゃん。あ、Windowsか。。。
Windowsはそういうのに不向きだと思うけどなあ。

577 :デフォルトの名無しさん:02/09/12 13:58
最近のWindowsにはdebugコマンド標準で付いてくるんだけどなぁ。。。


578 :デフォルトの名無しさん:02/09/12 14:27
>>575
http://www36.tok2.com/home/tok/cgi-bin/upboard/upboard.cgi

579 :ろうひ男爵:02/09/12 14:57
ういっす、再度upします。
http://www36.tok2.com/home/tok/cgi-bin/upboard/updir/ipl.lzh
iplプログラムです。

580 :デフォルトの名無しさん:02/09/12 15:05
win2000ならMINIX用のfdvol.exe 使え。
http://www.cs.vu.nl/pub/minix/dosutil/fdvol.exe
fdvol 1440 A: boot1st.bin
みたいに。

581 :デフォルトの名無しさん:02/09/12 16:37
と、C++の継承がどうの辺りからぶりに来てみたけど。
停滞中?


582 :ひげぽん ◆zcp/NZpA :02/09/12 22:23
>>581
継承問題は棚上げにして
メモリ管理クラスの実装に入りました。
現在デバッグ中なのでここにあまり書き込む情報(質問???)がありません。

フロッピィへの書き込みは、サブマシンのlinuxのddを使ってます。
もっとも最近はbochsでしかテストしてませんです。
>>580みたいなのもあるんですね。


583 :ろうひ男爵:02/09/12 22:59
>>ひげぽんさん
メモリ管理ですが、連結リストってことは
DOSみたいなメモリブロック構造ってことですよね。
メモリーブロックの前に、管理ヘッダーを置くって形ですね。
出来上がったら、結構前進しますね。がんばって下さいね。

584 :ひげぽん ◆zcp/NZpA :02/09/12 23:08
>>583 ろうひ男爵さん
>メモリ管理ですが、連結リストってことは
>DOSみたいなメモリブロック構造ってことですよね。
>メモリーブロックの前に、管理ヘッダーを置くって形ですね。
DOSのメモリブロックはちょっと知らないのですが、
そんな感じです。

>出来上がったら、結構前進しますね。がんばって下さいね。
ありがとうございます。
余裕があったら他のメモリ管理の方法も試したいなとは
思っているのですが、当分は無理でしょうね。。。


585 :デフォルトの名無しさん:02/09/12 23:42
ひげぽん仕事は大丈夫?

586 :デフォルトの名無しさん:02/09/12 23:48
連結リストってカーネル内の管理方法だろ?
ページング使うんだから、タスクからはリニアに見えるんじゃないの?
もしかして、マジでMCBと同じにするつもり?

587 :ひげぽん ◆zcp/NZpA :02/09/12 23:57
>>585さん
>ひげぽん仕事は大丈夫?
ちょっと忙しいですが、忙しいほうが
なぜか家に帰ってから30分でも集中してhigeposに時間をまわして
結果的には、開発状況は自分的には、アクティブです。

>連結リストってカーネル内の管理方法だろ?
そのとおりです。

>ページング使うんだから、タスクからはリニアに見えるんじゃないの?
>もしかして、マジでMCBと同じにするつもり?
いえいえ全然そんな意図はありません。
MCBというものも知りませんでしたし(それはそれで問題ですが)
例のMINIX本と、他のOSのソースを見て
とりあえず連結リストによるメモリ管理の実装を試みている状況です。

>>Memory Control Block(MCB) メモリー制御ブロック
>>DOS が管理するメモリーブロックの先頭に置かれた管理情報領域。


588 :デフォルトの名無しさん:02/09/13 00:17
>>587
そうだよな、583を見ておいおいって思ったので。

589 :デフォルトの名無しさん:02/09/13 22:43
>582
そか。じゃしばらくしたらまた来てみよう。


590 :デフォルトの名無しさん:02/09/14 12:35
しかしこのスレッド、ム板でよかったよね。
OS板はKとLの対決で荒れてる荒れてる。


591 :896:02/09/14 18:44
 

592 :デフォルトの名無しさん:02/09/18 00:57
ゲーム製作に特化したOSを造ろうというスレはここですか?

593 :デフォルトの名無しさん:02/09/18 02:54
作れば?

594 :ひげぽん ◆zcp/NZpA :02/09/18 23:12
カーネル内メモリ管理が大体まとまってきました。

メモリ開放時の隣り合う空き領域の連結処理が実装できていませんが
一応順調に進んでおります。
最近仕事がまた忙しいのでちょっと進みが遅いですが、
何とかやっております。

595 :デフォルトの名無しさん:02/09/20 11:53
がんば!

596 :ひげぽん ◇zcp/NZpA:02/09/20 13:08
FreeのPC UNIXからソースコード盗んでるだけですけどね。

597 :デフォルトの名無しさん:02/09/20 20:10
隣り合う領域の連結ってファーストフィット?
もしそうならK&R読んできた方が・・とか。


598 :デフォルトの名無しさん:02/09/20 20:41
>隣り合う領域の連結ってファーストフィット?
それは割り当てアルゴリズムだね。
隣り合う領域の連結はベストフィットでも同じ筈。
K&Rのはシンプルでいいですね。

599 :ひげぽん ◆zcp/NZpA :02/09/21 01:08
偽者が・・・

>>597,598
>隣り合う領域の連結ってファーストフィット?
>もしそうならK&R読んできた方が・・とか。
ええ。ファーストフィットです。
いちばんシンプルですし。タネンバウムの本で知りました。
連結処理、今週末に出来れば良いなあって感じです。




600 :ろうひ男爵:02/09/21 11:28
>>599
進んでるみたいですね〜。
自分の方は、本当にMCBライクな物を使っています。
ところで、バイナリのサイズはどれくらいですか?
自分はまだFDDが満タンになるにはほど遠いのですが、
バイナリの圧縮をlzssでやりました。
ファイルシステムをどうしようかと悩み中です。

601 :ひげぽん ◆zcp/NZpA :02/09/21 11:45
>>600
>ところで、バイナリのサイズはどれくらいですか?
8KBくらいですね。
フロッピーを満タンにするには、あと何ヶ月かかるか・・・

>バイナリの圧縮をlzssでやりました。
初めて聞く、キーワードですあとで調べて見ます。

>ファイルシステムをどうしようかと悩み中です。
やはり、FAT12でしょうか。


602 :デフォルトの名無しさん:02/09/22 18:51
>>601
何言ってんの、ファイルシステムはhgpfsに決まってるでしょうが。
ジャーナリングしてね(はーと)

603 :名無しさん:02/09/22 22:04
ひげっぷage
ひげっぷひげっぷ

604 :名無しさん:02/09/22 22:04
ひげっぷ

605 :ひげぽん ◆zcp/NZpA :02/09/22 23:28
調べました
■lzss
 http://www.ingnet.or.jp/~kojif/mu/comp/lz77.htm
■hgpfs
見つからないと思ってたら、

>>603
>>604
やっと意味が分かった(笑)


606 :デフォルトの名無しさん:02/09/22 23:32
>>605
> ■hgpfs

 HiGh Performance File System. FD 上では FAT12 互換らしい...。

607 :デフォルトの名無しさん:02/09/22 23:57
ちょっと苦しいな

608 :デフォルトの名無しさん:02/09/23 08:36
hgepfsとVFSどちらが先かそれが問題だ。
ジャーナリングもLFSみたいな使い方ならFDに使ってもおもしろそうだ。

609 :デフォルトの名無しさん:02/09/23 08:37
でも今のhigeposだと1セクタ目潰してるからDPB書けないっしょ
FATは不可能

610 :デフォルトの名無しさん:02/09/23 09:31
>>609
> でも今のhigeposだと1セクタ目潰してるからDPB書けないっしょ
> FATは不可能

別に、JMP 命令入れてその後に DPB 書くだけだろ。そんなに難しいことじゃないと思うけど。

611 :ひげぽん ◆zcp/NZpA :02/09/23 18:57
やっとカーネル内部メモリ管理(暫定版・ベータ)の実装が落ち着きました。
今のところ大体、意図どおりに動いている模様です。

次は、ファイルシステムでしょうか。
ちょっと勉強せねばと思っております。

■ジャーナリング
http://www-6.ibm.com/jp/developerworks/linux/010928/j_l-fs.html

ところで、どなたかhigeposをmakeして試してみた事ある人って
いるんでしょうか。
さすがにまだいないですよね。

612 :デフォルトの名無しさん:02/09/23 22:50
Bochsに流せるディスクイメージがあれば
試すよ

613 :ひげぽん ◆zcp/NZpA :02/09/24 00:00
>Bochsに流せるディスクイメージがあれば
>試すよ
ありがとうございます。
何が起きても責任はもてませんが、もし良かったら試してみてください。

http://higepos.sourceforge.jp/higeboot.bin

614 :612:02/09/24 00:03
>>613
動いた。key stroke..って出て、終わり。
よくできてるよー。すげえよ。

615 :ひげぽん ◆zcp/NZpA :02/09/24 00:14
>>612さん
ありがとうございます。
はやいですねぇ。
現在は、全くインタラクティブではないので
張り合いがないかもしれません。
キーが押されても、key strokeってでるだけだし・・・

ちなみに、[U16-65536]とかはメモリーの情報です。
SIZE=16 ADDRESS=65536 Uは使用中。 Fはフリー

タネンバウム本でファイルシステム勉強中です。


616 :デフォルトの名無しさん:02/09/25 23:45
key strokeって出ますなぁ。。。

617 :デフォルトの名無しさん:02/09/26 01:39
漏れも入れてみた。すげー、ただkey storokeって出るだけなんだけど、なんか感動したよ。

618 :617:02/09/26 01:40
おっとtypo。
s/storoke/stroke/でよろ。

higeposって、どういうOSにするつもり…とか構想はあるのかな?

619 :デフォルトの名無しさん:02/09/26 07:29
>>618
過去ログ全部読んできてください。

620 :ひげぽん ◆zcp/NZpA :02/09/27 20:11
少なくとも3人の方に試していただけたようでありがとうございます。
最近平日はなかなか更新できませんが、何とか続けていこうと
思っています。
メモリ管理はリストでやったので
ファイルシステムはビットマップでやろうかな・・・


621 :ひげぽん ◆zcp/NZpA :02/09/29 17:26
今日はタネンバウム本でファイルシステムの部分を勉強してました。
FDのREAD,WRITE部分を先に実現しないとどうにもならないので
資料を探している途中です。

カーネル内メモリ管理→ファイルシステムの順にこなして行こうと思うのですが、
その前にやっておいたほうが良いことってありますでしょうか。
→経験者の方

PJメンバー募集です。
OS作りに興味がある方で、開発に協力しくれる方を募集します。
ひげぽん宛にご連絡ください。
ttp://sourceforge.jp/developer/sendmessage.php?touser=2006

622 :デフォルトの名無しさん:02/09/29 23:53
>>621
FDに関してはCQの『パソコンのレガシィI/O活用大全』(↓)を
http://www.amazon.co.jp/exec/obidos/ASIN/4789834336/
を参考にしますた(他にいい資料があるかもしれないけど、とりあえず)。

623 :デフォルトの名無しさん:02/09/29 23:59
すげぇ・・。まじでOS作ってたのか・・。

624 :ひげぽん ◆zcp/NZpA :02/09/30 00:00
>>622
ありがとうございます。
参考にさせていただきます、今度アキバに行ったときでも
探してみます。

625 :デフォルトの名無しさん:02/09/30 00:04
>>621
技術無いんですけど、興味あるんでいいですか?

626 :ひげぽん ◆zcp/NZpA :02/09/30 00:15
>>625
全然大丈夫です。
やる気があれば何とかなります(おそらく)
上記のURLからお願いします。


627 :625:02/09/30 23:36
>>626
すみません。
大型プロジェクトに組み込まれてしまい、参加できそうもなくなってしまいますた。。
このスレ見ながらハァハァすることにします。

628 :デフォルトの名無しさん:02/10/01 14:28
協力したいけど、レベル足りない…時間もない…

629 :ひげぽん ◆zcp/NZpA :02/10/02 00:42
おかげさまで、数名の方から協力したいとの連絡をいただきました。
ありがとうございます。
引き続け募集中ですので、よろしくお願いいたします。

>>627
いえいえ、もし機会がありましたらまたお願いします。
>>628
やる気があれば大丈夫かと思いますが
気が変わったら是非よろしくお願いいたします。

最近仕事が忙しくて、本当に週末しかあまり更新できていませんが
モチベーションは維持できているのでとりあえずは大丈夫です。

Meadowのsetup.exeを試しに使ってみたところ
今の開発環境(Meadow1.14)がおかしくなってしまったので
現在復旧作業中です。emacs-lispもそのうち勉強しよう・・・

630 ::02/10/02 03:24
Bochsの各デバイス用のソースに、
例えばFDDならFDコントローラのデータシート等へのリンクが書かれていました
日本語のはなかったけど・・・。
参考になるかと・・


631 ::02/10/02 03:27
例えば ./iodev/floppy.c に
http://mudlist.eorbit.net/~adam/pickey/ports.html
こんなリンクが、 英語が読めればかなり参考になりそう

632 ::02/10/02 03:42
よくみたらFD以外のソースにはリンクついてなかった

633 :デフォルトの名無しさん:02/10/02 08:26
ROMしかできませんが

皆さん頑張ってください。

MSに一泡ふかせてやってくらさい。おながいします。


634 :デフォルトの名無しさん:02/10/02 16:30
Inside AS/400という本を読み始めました。
なかなか秀悦です。
OS製作を目指す方は、ぜひ一読をお勧めします。
とはいえ、私はIB*社員でも何でもありません。
AS/400の実物は触ったこともありません。
それどころか、I*Mとはライバル社の・・・・・・

635 :デフォルトの名無しさん:02/10/04 00:01
>>634
ICMか。なつかしいな。(違う

636 :デフォルトの名無しさん:02/10/04 21:01
最近、AS/400アレルギーが…

637 :ひげぽん:02/10/04 21:06
レスが遅くて申し訳ありません。
>>630,631
ありがとうございます、参考にさせていただきます。

>>633
ありがとうございます。
M$か・・・


638 :デフォルトの名無しさん:02/10/05 01:48
age

639 :ひげぽん@Meadow:02/10/05 18:54
開発環境が復活しました。

画面スクロールの部分が未実装だったので
実装中です。
考えだすと欲が出ますね。
上下にスクロールさせたいとか・・・

ところでLinuxでmakeに成功した方
いらっしゃいませんか。



640 :デフォルトの名無しさん:02/10/05 20:33
Makefile覗いてみて、.exeが指定されていたので試したこと無いです。


641 :ひげぽん:02/10/05 21:25
>Makefile覗いてみて、.exeが指定されていたので試したこと無いです。
そうですよね。
失礼しました。


642 :ひげぽん:02/10/06 15:59
画面スクロール機能を実装しました。
理想は高かったのですが、結局簡易版となりました。

画面の一番下で改行するとスクロールします。

643 :デフォルトの名無しさん:02/10/06 16:38
>>642
> 画面スクロール機能を実装しました。

スクロール時に、最下行はクリアしなくていいの ?

644 :640:02/10/06 18:03
Makefile.linuxを作ってくれたので試してみましたが、エラーと警告が出まくっ
ています。$ gcc --version 2.96 ですが、エラーは `operator new' takes
type `size_t' as first parameter が原因みたいです。
include/higeOperator.hとhigeOperator.cppです。私はC++分からないので、
このエラーに関してはコメント不能です。前もって $ mkdir ../bin ../list
が必要でした。# 改行数制限のため、エラーメッセージは割愛です。


645 :Makeflle.linux 作者:02/10/06 19:11
>>644
すみません、その辺りの変更を今CVSにコミットしました。
bin と listディレクトリについてはどうしようか考え中です。
#Makefileの中で mkdirする?

が、現在 Linux上で makeしたバイナリはブートできない状態ですので
もうしばらくお待ちください(リンカの問題?)。

もちろん、こうしたらいいよというような意見は歓迎です。

646 :ひげぽん:02/10/06 19:12
>>643
最下行クリアは必要です。
クリアしていないのになぜかうまくいっていて気づいていませんでした。
あまり考えもせずに実装して、反省中です。

>>644
おっと、もう試していただけたんですね。
こういう報告は大変助かります。

>ています。$ gcc --version 2.96 ですが、エラーは `operator new' takes
>type `size_t' as first parameter が原因みたいです。
私の環境はWindows djgpp gcc.exe (GCC) 3.1です。

higepos PJにもlinux環境の人がいるのですが、
そこでもこの現象が起こっています。

前提として
(1)operator newの引数は size_tでなければならない。
(2)higeposではとりあえずunsigned longにしておいた。
  (size_tは処理系で定義するため??)
(3)linux gccはどうやら size_t = unsinged intとして
 上記のエラーを出してくるらしい。

すいません、現在調査中ですのでしばらくお待ちください。






647 :640:02/10/06 19:28
>>646
> すいません、現在調査中ですのでしばらくお待ちください。
このエラーは海外のMLで検索で引っかかりました。フォローアップが無いもの
がほとんどですが、GCCのバグとして処理されているものもあります。パッチ
はいくつかありますが、i386系のアーキテクチャのものは発見できてません。
GCC 3.2 の環境でも作って、試してみないと駄目かな?


648 :ひげぽん:02/10/06 19:41
>>640さん
すいません調べていただいてありがとうございます。

#ifdef等でこのエラーを回避することは出来ると思うのですが
その前に何が正しいのかを調べないといけないですね。

operator new の引数は size_t? unsigned int? unsigned long?


649 :ひげぽん:02/10/06 20:25
gcc3.0からどこぞの団体が決めたC++の仕様にさらに準拠するようになった
との記述を見つけたのですが、関係あるのでしょうか。

C++の仕様を探してたら、17$と書いてあったんだけど
C++の仕様書を本で買ったら17$という意味なのかな?

650 :645:02/10/06 21:20
size_t の問題は
typedef __SIZE_TYPE__ size_t;
と型定義することで解決しました。

ということで、現在 DJGPPとLinux(gcc2.96)で buildできる状態です。
#Linux版は bootせずですが。。

651 :ひげぽん:02/10/06 21:30
見当違いな調査をしていたひげぽんです。
ひとまず解決してホッとしていますが、Linux版で
ブートしないのはいずれきちんと調査しないとまずいですね。



652 :デフォルトの名無しさん:02/10/06 22:32
//g++-2.95の場合
g++-2.95 -I include -nostdlib -fno-exceptions -fno-rtti -ffreestanding -fno-builtin -Wall -c -DBUILD_ON_LINUX io.cpp -o ../bin/io.o
io.cpp: In function `void outportb(unsigned int, unsigned char)':
io.cpp:61: parse error before `::'

//g++-2.0の場合
ld: warning: cannot find entry symbol _start; defaulting to 00001200
../bin/higepos_kernel.o: In function `startKernel()':
../bin/higepos_kernel.o(.text+0xb6): undefined reference to `operator new(unsigned)'
../bin/higepos_kernel.o(.text+0xd4): undefined reference to `operator new(unsigned)'
../bin/higepos_kernel.o(.text+0xf6): undefined reference to `operator new(unsigned)'
../bin/higepos_kernel.o(.text+0x133): undefined reference to `operator delete(void*)'
../bin/higepos_kernel.o(.text+0x17e): undefined reference to `operator new(unsigned)'
../bin/higeOperator.o: In function `X86MemoryManager::instance()':
../bin/higeOperator.o(.gnu.linkonce.t._ZN16X86MemoryManager8instanceEv+0x2b): undefined reference to `__dso_handle'
../bin/higeOperator.o(.gnu.linkonce.t._ZN16X86MemoryManager8instanceEv+0x37): undefined reference to `__cxa_atexit'


653 :デフォルトの名無しさん:02/10/06 22:34
ミスた。
g++-2.0じゃなくてg++-3.0ね。

654 :Linuxたんとー:02/10/07 00:34
>>652
情報ありがとうございます。
gcc2.95 に関しては該当行を
asm volatile ("outb %%al,%%dx": :"d" (port), "a" (value));
にする(「::」の間にスペースを入れる)ことでコンパイルできますか?
(コンパイルファームの gcc 2.95.4で試したところ、上記でOKでした)

gcc-3.0 は今、手元にコンパイラが無いため確認できません。。

655 :ひげぽん:02/10/07 00:57
>>652さん
早速の情報ありがとうございます。

g++ 2.95のほうはなんとなく解決しそうですが
g++ 3.0のほうは、完全にリンカエラーですね。

>../bin/higeOperator.o(.gnu.linkonce.t._ZN16X86MemoryManager8instanceEv+0x2b): undefined reference to `__dso_handle'
>../bin/higeOperator.o(.gnu.linkonce.t._ZN16X86MemoryManager8instanceEv+0x37): undefined reference to `__cxa_atexit'
この辺は_pure_virtualの仲間かな。

要調査ですね。

656 :デフォルトの名無しさん:02/10/07 17:37
>>649
それANSIのHPで買えるPDF版じゃないかな

657 :652:02/10/07 21:36
>>654
g++2.95は解決。

3.x系は色々探ってるわかんねぇ。
力なれなくてスマソ。

658 :654:02/10/07 23:11
>>657 さん
確認ありがとうございます。

> 力なれなくてスマソ。
とんでもないです。ありがとうございます。
3.x系に関しては、gcc-3.0を見付けたのでこれからこちらでも調べてみます。

659 :ひげぽん:02/10/08 17:39
風邪で寝込んでいたため返事が遅くなり申し訳ありません。
>>656さん
>それANSIのHPで買えるPDF版じゃないかな
そういうことですね。
ありがとうございます。

>>652さん
いろいろとありがとうございました。


660 :デフォルトの名無しさん:02/10/09 21:00
ためしにmakeしてみたらエラーが出ました。
:が一個多いということでしょうか?

io.cpp: In function `void outportb(unsigned int, unsigned char)':
io.cpp:61: parse error before `::'

661 :デフォルトの名無しさん:02/10/09 21:34
)660 
じゃなっくて,間にスペースを入れないと駄目なみたい。

662 :デフォルトの名無しさん:02/10/09 22:38
cygwinにてmakeしたのですがmake出来ませんでした。
エラーはこんなのが出ました。

ld: PE operations on non PE file.

663 :640:02/10/10 21:07
ld --version GNU ld version 2.13
g++ --version g++ (GCC) 3.2
nasm -r NASM version 0.98
な環境作成してみました。結果は、
ld: warning: cannot find entry symbol _start; defaulting to 00001200
../bin/higepos_kernel.o: In function `startKernel()':
../bin/higepos_kernel.o(.text+0xb6): undefined reference to `operator new(unsigned)' 以下略
でした。何もできませんが、頑張ってください。


664 :ひげぽん:02/10/10 23:08
>>662,640さん
情報ありがとうございます。

こういう情報は、大変貴重でありがたいです。
これからもよろしくお願いいたしますm(__)m

665 :デフォルトの名無しさん:02/10/10 23:09
いくらOS作ろうがドライバが無いから動かないよ。

666 :デフォルトの名無しさん:02/10/10 23:17
>>665
おこちゃまは何を動かしたいのかな〜

667 :640:02/10/10 23:49
$ file higepos_kernel.o
higepos_kernel.o: ELF 32-bit LSB relocatable, Intel 80386,(略)
なんだけどOSってELF32をそのままリンクして作るものなのでしょうか?
もしかしてクロスコンパイル環境が必要ですか? 無知ですまんです。
$ readelf -a higepos_kernel.o
の結果から、
R_386_PC32 00000000 _Znwj
R_386_PC32 00000000 _ZdlPv
がundefined referenceみたいですが結局分からんです。意味無しm(__)m

668 :デフォルトの名無しさん:02/10/13 21:40
cygwinで構築できないか色々やっていますが,djgppとは環境がまるっきり違いますね。
いま,gccをクロスコンパイルできるように構築中。
ターゲットのしていは --target=i686-pc-msdosdjgpp

669 :640:02/10/13 22:50
>>668
> --target=i686-pc-msdosdjgpp
情報Tnx。Linux上でbinutils-2.13とgcc-2.95.2でクロス環境構築中です。
うまくいけば報告します。

670 :デフォルトの名無しさん:02/10/14 16:12
Linux上で、ld: supported targets: coff-go32 coff-go32-exe a.out-i386
はできたけど、gcc-2.95.3はうまく構築できなかった。gcc-3.2は無事クロス
環境だけど、
../bin/higepos_kernel.o(.text+0x278):higepos_kernel.cpp: undefined reference to `__Znwm'
こんな感じ。higepos_kernel.oは、
$ file ../bin/higepos_kernel.o
../bin/higepos_kernel.o: 80386 COFF executable not stripped - version 30821
だから、一応クロス環境にはなっているみたい。
gcc-2.95.3の環境作りに励みます。
>>668さんはどんな状況でしょうか?

671 :デフォルトの名無しさん:02/10/14 16:50
gcc-2.95.3環境できました。
結果、
../bin/KeyBoardManager.o(.text+0x11):KeyBoardManager.cpp: undefined reference to `__$_15KeyBoardManager'
になりました。最新のCVS版です。
io.cpp: asm volatile ("outb %%al,%%dx": :"d" (port), "a" (value));
は修正済みです。

672 :ひげぽん:02/10/14 17:04
>>671さん
>../bin/KeyBoardManager.o(.text+0x11):KeyBoardManager.cpp: undefined reference to `__$_15KeyBoardManager'
最新版CVS updateしました。
KeyBoardManager周りを微妙に変えてみたので
試していただけないでしょうか。


673 :デフォルトの名無しさん:02/10/14 18:19
>>672
> 最新版CVS updateしました。
コンパイルは無事通りました。これから起動テストに入ります。bochsがうま
く動かないので、再起動テストになるので、しばらくお待ちください。


674 :673:02/10/14 18:56
起動できませんでした。しかし、sourcefogeから落したhigeboot.binでも起動
しなかったので、私のマシンの問題のようです。(Intel入ってないです) ディ
スカッションフォーラム: Open Discussionにthird.binをおいておきました。



675 :ひげぽん:02/10/14 19:03
>>673さん
確認ありがとうございます。
現在、bochsでは起動できるが、
ネイティブブートが出来ないという問題があがっています。

現在現象の原因究明中ですので、解決後に
もし良かったらご確認いただけたらとおもいます。

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

676 :デフォルトの名無しさん:02/10/14 23:31
>670
構築できていません。(>_<)
だけどcygwinでもCOFFだし本当にクロス環境はいらないかも・・・
問題はリンカスクリプトあたりかも知れない。


677 :デフォルトの名無しさん:02/10/15 00:39
>>c++はいろいろあって面倒だから
>
>たとえば、上に上げた例外や、他言語(アセンブラが主かな)とのシンボル名の整合
>あとは、cだとランタイムを使わなければ良いだけでも、
>c++ではnew演算子とか言語自体の機能なんで、
>デフォルトでいらないコードがリンクされたり、それの準備のための初期化ルーチンが用意される。

C++もライブラリなんか必要無いんだけどな…
gcc使ったこと無いのかな…

678 :673:02/10/15 18:41
>>676
> 問題はリンカスクリプトあたりかも知れない。
リンカスクリプトはdjgpp.djlを拾ってきてクロス環境のlibに配置しました。
また、stub.h stubify.cからstubifyを作成し、クロス環境のbinに配置しまし
た。Linuxとは違うかもしれませんが参考まで。


679 :デフォルトの名無しさん:02/10/15 19:52
Windows98にBochsをインストールしてLinuxで作成したhigeboot.binが
無事に起動することを確認しました。最初からWinで試せばよかった(^^;
binutils-2.13とgcc-2.95.3を--target=i686-pc-msdosdjgpp
でconfigureしたクロス開発環境です。

680 :デフォルトの名無しさん:02/10/15 20:17
disk reading.... と永遠に出続けるが、いったいどうしたものか...

681 :デフォルトの名無しさん:02/10/15 20:27
>678
higeposを構築するのに,gccの構築はいらなくてldだけでいいんじゃないだろうか。
と言うつもりでした。(cygwinでは)

でもこの情報は役に立つと思います。
ありがとう

682 :デフォルトの名無しさん:02/10/15 20:36
>>681
確かにGNU BFDを利用すれば、LinuxでもELFからCOFFへの変換はldがやってく
れそうですね。--enable-targets=allでbinutilsを構築するだけで良かったの
かな?

683 :682:02/10/15 20:42
嘘ついてました。LFLAGS = -Ttext 0x200 --oformat binaryなので、Linuxで
は、前もってobjcopyとかで変換しておかなければ駄目かもしれませんね。

684 :デフォルトの名無しさん:02/10/16 18:12
http://www.osdev.org/
http://my.execpc.com/~geezer/osd/
http://nondot.org/sabre/os/articles
http://www.mega-tokyo.com/os/os-faq.html
http://www.acm.uiuc.edu/sigops/roll_your_own/

written in C++
http://www.cs.washington.edu/homes/tom/nachos/

まぁ知ってるだろう一応。

685 :ひげぽん:02/10/16 20:20
複数人の方々にmake、boot確認をしていただいているようで
ありがとうございます。
皆様より寄せられた情報を元にMakeFile等改善していけたらと
思います。

>>684さん
ありがとうございます。
http://ime.nu/www.osdev.org/
のMessage Boardはなかなか有用な情報が多いですね。



686 :デフォルトの名無しさん:02/10/17 18:49
firstboot.asmとsecondboot.asmの最後にそれぞれ
times 510-($-$$)
times 512-($-$$)
となってるけど
逆にしたほうがいいんじゃないかな?

687 :ひげぽん:02/10/18 21:16
higeposPJの私以外の優秀なメンバーの調査・修正により
higeposがネイティブートできるようになりました。

higepos最新版をmake後、dd or rawriteでフロッピーに
書き込むと、私の環境ではネイティブブートできました。


688 :デフォルトの名無しさん:02/10/18 21:18
cygwinで構築することができました!!!
ld でbinaryの指定が出来ないので色々やってましたが
結局,stripかobjcopyでbinaryに変換するのがベストでしょう。
指定の仕方は -O binary になります。


689 :デフォルトの名無しさん:02/10/18 22:28
結局ネイティブブートできなかった理由はなんだった?

690 :ひげぽん:02/10/18 22:31
>>686
>firstboot.asmとsecondboot.asmの最後にそれぞれ
>times 510-($-$$)
>times 512-($-$$)
>となってるけど
>逆にしたほうがいいんじゃないかな?
なぜでしょうか。
firstbootは510byte目までは0埋めで2byteのマジックナンバー
をつけるのではなかったでしたっけ?(記憶があいまいです。)

691 :ひげぽん:02/10/18 22:36
>>689
変更点は以下の通りです。
secondboot.asm

>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 (was mov sp, 0x1000)
>    jmp 0x200



692 :デフォルトの名無しさん:02/10/18 22:39
>690
単にずれてると思ったのだけです(^^;)


693 :FreeDOS教徒:02/10/18 22:56
>>684
osdev以外全部知らなかったョ‥‥

>>686
ホワ!何を云っているですか?
それやったらfirstbootすら動かないのですよ?

694 :デフォルトの名無しさん:02/10/19 00:04
Linux 2.4.4, gcc-2.95.3, binutils-2.13のクロス環境で作成した
higeboot.binをddで書き込んだフロッピーで起動することを確認しました。お
めでとうございます。さらなる発展を期待しています。頑張ってください。


695 :デフォルトの名無しさん:02/10/19 00:55
bochsだと3thException吐いて止まるな。

higepos_kernel.cpp50行目の_sys_Unlock()つまりasm("sti")で止まっている。
コメントアウトしたらちゃんと動いたから。
しかし指摘されてないってことは俺の環境だけなのかな。

linux
gcc2.95.4
binutils-2.13
bochs1.4.1

696 :デフォルトの名無しさん:02/10/19 09:10
VMWareで動かせるんだったら漏れも参加しようかなあ。

697 :ひげぽん:02/10/19 13:23
>>694
>さらなる発展を期待しています。頑張ってください
動作確認情報ありがとうございます。
これからもよろしくお願いいたします。

>>695
>bochsだと3thException吐いて止まるな。
私の環境ではでないですね。
うーん。なぜだろう。


698 :695:02/10/19 15:48
make時こんなメッセージが出てる。
sourceforgeに落ちてるbinary(higeboot.bin)ならいけたのでやっぱmake時の問題かねぇ。

ld: warning: cannot find entry symbol _start; defaulting to 00001200

699 :ひげぽん:02/10/19 17:03
>>698
>ld: warning: cannot find entry symbol _start; defaulting to 00001200
これは私のところでも出ていますね。
今現在のCVS最新でもなりますか?


700 :ひげぽん:02/10/19 17:10
募集です。
higepos PJのプロジェクトホームページを作っていただける人。
皆様にhigeposの動作確認等をしていただいた情報を
そこで公開しようと思っています。

ひげぽんは、はげしくデザインセンスがないので
カッコイイのを作ってくださる方お願いいたしますm(__)m

http://sourceforge.jpでアカウントを取得後
http://sourceforge.jp/users/higepon/より
ひげぽんまでご連絡ください。


701 :デフォルトの名無しさん:02/10/19 18:02
>>695
クロスコンパイル環境がうまくできていない可能性はないですか?GCCがELF
フォーマットを吐く時は同じエラーでしたが、COFFを吐くようにすると起動で
きます。
# bochs-1.4.1 on Linux では"Key hit!"がまだみれていない。(泣


702 :701:02/10/19 19:33
bochs-1.4.1 on Linux では"key stroke"が見れました。bochsコンパイル時の
問題でした。higeposは無罪です。


703 :695:02/10/19 22:12
こちらに非があったようで。すいません。

>>701
具体的にはCOFF形式で吐かせるためにはgccの./configureの時点でサポートして、
-gcoffオプションをつけてコンパイルってことで良いですか?
調べてみるとそんな感じだったのですが。。。

gccもbochsもdebで適当にぶちこんだ物なので。。。

704 :デフォルトの名無しさん:02/10/19 22:19
ジサクジエンご苦労さん

705 :ひげぽん:02/10/20 14:08
>>688さん
>cygwinで構築することができました!!!
>ld でbinaryの指定が出来ないので色々やってましたが
>結局,stripかobjcopyでbinaryに変換するのがベストでしょう。

もし良かったらcygwinでのmake方法を詳しく教えていただけないでしょうか。
cygwinでmake出来るのであれば、あえてdjgppを使う理由はあまりないので・・・


706 :デフォルトの名無しさん:02/10/20 16:48
>>703
>>679



707 :デフォルトの名無しさん:02/10/20 17:04
>705
リンカのオプションの--oformat binaryを消して,
リンク後にstripなどで-O binaryのオプションで変換します。
特に環境を替える必要はないはずですが,色々やった後なのでそのあたりは自信がありません。

708 :ひげぽん:02/10/20 17:30
【お知らせ】
sourceforge.jpの cvs のディレクトリ構成に変更がありました。

 CVSROOT/                 CVSROOT/  
 higepos/     →          higepos/  
                          higepos_v1.1/  

higepos/旧開発ディレクトリ
higepos_v1.1/新開発ディレクトリ

MakeFile、ファイル名等に変更がありますが
中身は同一です。

今日以降は新開発ディレクトリで、開発が進みますのでご注意下さい。

709 :ひげぽん:02/10/20 17:33
MakeFile.cygwinを追加しました。
bochs,ネイティブブートが確認できましたのでcvs addしました。

>>707さん
ありがとうございました。

710 :695:02/10/20 18:29
>>706
情報thanks.
やっと回避できたよ。。。

>>708
LinuxのMakefileの記述にミス発見(tarball)
20行目のXが小文字になってる。

しかし1.1だと普通にMakeしても大丈夫なんだよなぁ。

711 :ひげぽん:02/10/20 18:44
>>695
>LinuxのMakefileの記述にミス発見(tarball)
>20行目のXが小文字になってる。
修正しました。ご指摘ありがとうございます。
以前からあった記述ミスのようです。

しかしMakeFileが3つもあるとメンテが面倒ですね。
うまくまとめられないだろうか。

712 :デフォルトの名無しさん:02/10/20 20:24
>>710
> しかし1.1だと普通にMakeしても大丈夫なんだよなぁ。
クロス環境なんていらなくなりましたね。なんでだろう?
# 開発者の方で把握していたら教えてください。

713 :712:02/10/20 20:58
>>712
> クロス環境なんていらなくなりましたね。なんでだろう?
すみません。bochsrcファイルが以前のhigeboot.binを指定していただけでし
た。新たにhigepos_v1.1/bin/higeboot.binを指定し直したところ、3rd
exception with no resolutionで停止しました。
クロス環境で作成するとだと無事に起動しました。
# リターン入力でのハートがラブリー ♥



714 :デフォルトの名無しさん:02/10/20 21:08
>711
LunxとCygwinでは同じmakeファイルでokなはずです。
djgpp方ではツールの入ったフォルダにパスを通すとかして環境をmakeファイルに合わせればいいです。

715 :ひげぽん:02/10/20 22:50
>>712
>クロス環境で作成するとだと無事に起動しました。
確認ありがとうございます。

># リターン入力でのハートがラブリー ♥
デバッグ中なので対応する文字コードが存在しないキーは
変な文字が表示されます。あまり気にしないでください・・・

>>714
>LunxとCygwinでは同じmakeファイルでokなはずです。
そうですよね。MakeFile.cygwinがLinuxでも普通に使えることが
確認できたら統一したいです。

djgppとの統合は うーん といった感じです。
これからはcygwinに移行する気がします・・・



716 :LightCone ◆sSJBc30S5w :02/10/21 09:52
>>715
 ソース見てみましたが、アセンブラ部は僅かでほとんどC++で書いていらっ
しゃる点には驚きました。今後が楽しみです。

 ところで、割り込みディスクリプタテーブルについてですが、本来は、
ハードウェア割り込みのベース番号を再プログラムする必要があります。
そうしないと、一般保護例外(13)などと、ハードウェア割り込みの区別が
付きません。

 しかし、gccでも簡単に32BIT-OSが作れるようになっているのですね。
4、5年前は、ジャジャ馬のようでしたが(個人的には)。

717 :LightCone ◆sSJBc30S5w :02/10/21 10:07
 ちなみに、NWSOSでは、初期化がかなり複雑で好ましくないのですが、
higeposはシンプルで良いですね。

 NWSOSの場合、16BIT BIOS を走行させるための16BITエミュレータ
を持っていることや、メモリ空間確保のため、カーネルを高位アドレスへ
転送しているからも有るでしょうけど。

 最初に物理メモリの空きマップを調べてから、仮想アドレス空間へ
マップし、カーネルを転送しています。

 GDTの位置(テーブルの位置)も上位へ転送するので、再構築
したりしてます。こんな複雑なことをする必要は無いんじゃないか
と思ったりするのですが。

 話が厄介なのは、「ページテーブル管理ルーチン」が、カーネル
転送前と、転送後の両方で必要になることなんです。

 ページング ON の状態でカーネルを転送するために、転送前の
アドレスにも管理ルーチンが存在している必要がありますが、
一方で、転送後にも当然必要です。しかし、転送後は、転送前の
メモリはゴミと化すので、どうしても二つ必要な気がします。
同じソースを流用できるかもしれませんが。

718 :LightCone ◆sSJBc30S5w :02/10/21 10:24
 16BIT エミュレータを持つと複雑になるんですよね。

 割り込んだ時に、最低でも一回はシステムが用意したハンドラに
入ってから、必要に応じて、16BITハンドラと、32BITハンドラを
呼び出す、という仕組みになりますから。
 16BITモードから、32BITモードへ「戻る」のもIA32では難しかった
ですね。

 higeposでは、DISK周囲はどうされますか? 個別にドライバを
用意しますか? 画面モードの切り替えにも、BIOS呼び出しが必要
になると思いますが。
 ちなみに、VESA の プロテクトモードインターフェースはNWSOSでは
使わず、16BITモードインターフェースをエミュレーション実行
しています。

719 :デフォルトの名無しさん:02/10/21 11:55
LIghtConeたんが生きてた…ホゥ…



720 :デフォルトの名無しさん:02/10/21 19:19
>>715
> そうですよね。MakeFile.cygwinがLinuxでも普通に使えることが
> 確認できたら統一したいです。
CC, LD, STRIP, NASM, NDISASMとかの変数を別途用意した定義ファイルに書く
ようにすると大丈夫ではないでしょうか?djgpp, cygwin, Linuxではすべて
GNU makeだと思うので、includeが利用できると思います。クロスコンパイル
では、CC = prefix/bin/i686-pc-msdosdjgpp-g++,
LD = prefix/i686-pc-msdosdjgpp/bin/ld のようにする必要があるので、
修正は必須になります。


721 :ひげぽん:02/10/21 21:23
LightConeさん

>ソース見てみましたが、アセンブラ部は僅かでほとんどC++で書いていらっ
>しゃる点には驚きました。今後が楽しみです。

ありがとうございます。
ご期待に沿えるかどうかは分かりませんが、気長にやっていくつもりです。

> ところで、割り込みディスクリプタテーブルについてですが、本来は、
>ハードウェア割り込みのベース番号を再プログラムする必要があります。
>そうしないと、一般保護例外(13)などと、ハードウェア割り込みの区別が
>付きません。

はい、上記はhigepos PJメンバーの指摘により認識しています。
現在の課題のひとつです。

> しかし、gccでも簡単に32BIT-OSが作れるようになっているのですね。
>4、5年前は、ジャジャ馬のようでしたが(個人的には)。

そうですね。
確かに現在では、海外のOS Devサイトでかなりの情報が
取得出来るのが大きいですね。
また、2chのような情報交換の場があるのもありがたい話です。

>ちなみに、NWSOSでは、初期化がかなり複雑で好ましくないのですが、
>higeposはシンプルで良いですね。

シンプルというよりは、むしろ必要な初期化が足りていないと
いうのが現状です。

722 :ひげぽん:02/10/21 21:23
> NWSOSの場合、16BIT BIOS を走行させるための16BITエミュレータ
>                   ・
>                   ・
>                   ・
>16BITモードから、32BITモードへ「戻る」のもIA32では難しかった
>ですね。

現在の私の力量ではとても手を付けられそうなところですね。
さすがですね。
私も精進せねば・・・

> higeposでは、DISK周囲はどうされますか? 個別にドライバを
>用意しますか? 画面モードの切り替えにも、BIOS呼び出しが必要
>になると思いますが。

higeposは、現時点ではFDD動くことを目標としているので
FDDドライバを用意する予定です。

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

723 :ひげぽん:02/10/21 21:28
>>720
>CC, LD, STRIP, NASM, NDISASMとかの変数を別途用意した定義ファイルに書く
>ようにすると大丈夫ではないでしょうか?
はい、現在DJGPPの私の環境ではBATファイルを用意して対応しています。


>djgpp, cygwin, Linuxではすべて
>GNU makeだと思うので、includeが利用できると思います。クロスコンパイル
>では、CC = prefix/bin/i686-pc-msdosdjgpp-g++,
>LD = prefix/i686-pc-msdosdjgpp/bin/ld のようにする必要があるので、
>修正は必須になります。

なるほど貴重なご意見ありがとうございます。
higeposの一課題として取り組んでいきます。

724 :LightCone ◆sSJBc30S5w :02/10/21 22:02
>>721
>>ちなみに、NWSOSでは、初期化がかなり複雑で好ましくないのですが、
>>higeposはシンプルで良いですね。
>シンプルというよりは、むしろ必要な初期化が足りていないと
>いうのが現状です。

シンプルなことは素晴らしいことです。
アセンブラ部とC言語部を「リンク」せずに、単にcatするアイデアなど
は面白いと思いました。リンクしたほうが恐らく複雑になるので、
少なくとも現状の規模では、catの方がいいと思います。

また、OSを作り始めるときに、アセンブラでなく、ほぼいきなり
C/C++からやってしまうのは凄いことなんじゃないかと思いました。
C/C++だとセグメント配置などが厄介なはずなので。
ld がOSを作りやすいように出来ているのかもしれませんが。



タスクを制御しだすと、スタックを細かく扱う必要がありますが、
そこもC++でどこまで出来るか興味があります。


話は変わりますが、個人的に一番労力を割いたのは、IA32の複雑な
アーキテクチャの理解だったかもしれません。
初期化やモード遷移には物凄く悩まされました。
どのゲートを使うべきか等も、しばらく検討していたように
思います。

そうこうしているうちに、4GB では足りなくなって、物理メモリと、
仮想メモリが、順に拡張されましたね。SSE/SSE2まで理解し様と
するとほどんどパニック状態になりそうです。SSE/SSE2命令を
使えるようにするためにはOS側のサポートも欠かせないのですが。

725 :LightCone ◆sSJBc30S5w :02/10/21 22:23
>>722
 多分、今後の higepos に必要なのは、ページング関係と割り込み
関係だと思います。

 各種例外ハンドラを整備するのはOSとしては必須ですので避け
られませんが、例外が起きた時の処理は以外に面倒でした。IA32
の膨大な資料とにらめっこしながらコーディングしていたのですが、
当時詳しいドキュメントが無くて、実験しながら正しい理解を得ていか
ざるを得ませんでした。今でもこの辺はやってみながら薦めていかないと
正しく理解するのが難しいのではないでしょうか。

 ページング関係は早い段階で実装してしまう必要が有ると思います。
後になってページングをサポートし様としても修正が大規模になり、
デバッグが大変になるかもしれませんので。


 最近まで、実験機と開発機が共通でしたが、
OS開発ではまると、ブートさせても「停止」すらしてくれないん
ですよね。止まってくれただけで一安心みたいな境地でした。
なんらのメッセージすら見えずに一瞬にして再リセットなんて事の
方が普通だった時期もありましたね。こんなことを話しても、飲み屋
の愚痴みたいで何の参考にもならないと思いますが、すみません。

726 :ひげぽん:02/10/21 23:11
LightConeさん

>また、OSを作り始めるときに、アセンブラでなく、ほぼいきなり
>C/C++からやってしまうのは凄いことなんじゃないかと思いました。

ここは、私の技術的背景もあると思います。
端的に言うならばアセンブラ初心者であったので
なるべくアセンブラ部分を少なくしようという意図が
働いたのだと思います。(C++も初心者ですが・・・)

>タスクを制御しだすと、スタックを細かく扱う必要がありますが、
>そこもC++でどこまで出来るか興味があります。

なるほど。
私がhigeposをC++で書こうといろいろと調べてたり、
2chの方にアドバイスを頂いたときに感じたのですが。


727 :ひげぽん:02/10/21 23:12

実際にソースを公開している
いわゆる売り物ではないOSで
C++で実装している物があまり見つからないのです。

これはC++でやってやろうという人が少ないのか
それともC++で通すと、いずれ壁にぶつかるのか・・・
いずれ答えは出ると思いますが。

ただhigeposはC++を使っているものの
私が当初想定したより、かなりの制限を受けています。

・例外処理が使えない
・継承が使えない
・テンプレートが使えない

上記はおそらく、私の技術レベルが低いために
OSを作る際に、該当機能を使う環境が整えられない
のが原因なので、いずれは解決したいです。


728 :ひげぽん:02/10/21 23:12

> 多分、今後の higepos に必要なのは、ページング関係と割り込み
>関係だと思います

現在のhigeposは、いろいろと手を入れるべきところがあります。
プライオリティづけが必要であると感じています。
特にページングは、LightConeさんのおっしゃるとおり
早いところ手を付けたいところですね。

>こんなことを話しても、飲み屋
>の愚痴みたいで何の参考にもならないと思いますが、すみません。

いえいえ大変参考になります。
OSを作っているかたで、しかも大先輩の
お話を聞ける機会はなかなかないので・・・

少しでもNWSOSに追いつけるようにがんばります。

729 :デフォルトの名無しさん:02/10/22 01:30
Objective-Cに移行しる

730 :デフォルトの名無しさん:02/10/22 01:44
Mac の System 1はPascalだ
がんがれ。情報無しでsage

731 :LightCone ◆sSJBc30S5w :02/10/22 01:52
>>727
>ただhigeposはC++を使っているものの
>私が当初想定したより、かなりの制限を受けています。
>・例外処理が使えない
>・継承が使えない
>・テンプレートが使えない

テンプレートはマクロなので使えない方がむしろ不思議ですね。
継承も多分少し工夫すると使えるようになると思います(思うだけ
ですが)。
例外処理だけは、容易には使えないかもしれません。
一年位前まで、C++の例外処理は単に言語レベルで解決されていて、
OSに依存せずに処理されているのかと思っていたのですが、
コンパイラによっては、OSの機構にモロに依存しているようなのです。
極端な話、ページ例外や、一般保護例外といった CPU 例外と、
throw,catch などの機構を統合して処理できるOSもあるみたいです
(実はWindowsがそうらしい)。

 Windowsの catch機構は、throw したものだけでなく、他人が作
ったライブラリのバグなども拾うことが出来るようになっているよう
です。これは非常に興味深い機構で異常に強力なのですが、当然
OS側からの前面的なサポートが必要なので、新しいOSを作る際には
基本的に使えません。ただし、純粋に言語レベルでソフト的に処理
する方法もあると思います。「スタックの逆戻し」とか中々、乙な
仕組みをやってるみたいですが。

732 :LightCone ◆sSJBc30S5w :02/10/22 02:06
>>731
いずれにせよ、例外処理はかなりスタックを複雑に走査する必要がある
ので、作りたてのOSの、しかも、カーネルを記述する際に使用するとな
ると、難しい問題を招き入れてしまうことになりそうです。

カーネルのスタックの容量を自動伸張したりするのは、技術的に
高度で、新規のOSでは避けて通るに越したことは無いと思います。
例外処理を使うとスタック消費量も予想しづらくなりそうなので、
個人的には避けたほうがいいように思います。ただでさえ、
カーネル内の「スタック」の利用は伸張になる必要があります
から。
実は、NWSOSでは、カーネルも、ユーザープログラムも、
タスク毎に独立したスタック(つまり、タスク数*2本の
スタック)を持っています。このようにすると、カーネル
が使うスタックが不足することは考えなくて済むかも
しれません。ただ、それでも、ファイル名格納用のメモリは、
スタックに取らずに SysMalloc() というメモリ確保関数
から取得した領域を使うようにしています。スタックでも
問題ないかもしれませんが、、、。
同一タスクに、複数のスレッドを起動する場合は、
カーネルスタックはやはりスレッドの数だけ用意するべき
なのかもしれませんね。何が良いかは良く分かりませんが。、

733 :LightCone ◆sSJBc30S5w :02/10/22 02:23
>>728
優先順位付けは、腕の見せ所でも有るかもしれませんね。
何が必要で、何がそれほどでもないか。または、何を先にやれば、
うまくいくか、を決めていくのは、一番大事なところかもしれませ
んし、、、。OS作りでは、細かいロジックも重要みたいですが。
僅かでも間違いがあるとどこかで露呈しますし、いくら大局的に
立派な思想に基づいていても、細かいロジックが「解け」なければ
「もの」として出来てきませんからね。OSを作っていると、
つくづく、そういうところで自分の愚かさ加減がいやになりますが。

話は変わりますが、マルチタスクOSを作っていると、よく
ロック、アンロックを使う必要がありますよね。ご存知かもしれま
せんが、
 「デッドロックを起こさない絶対的な基準」
を知っていると得ですね。
これを知っていると楽ですね。
「入れ子のロックの順序を統一せよ」
ってだけなんですが、、、。

734 :LightCone ◆sSJBc30S5w :02/10/22 08:43
>>727
何度も連続投稿してすみませんが、
>これはC++でやってやろうという人が少ないのか
>それともC++で通すと、いずれ壁にぶつかるのか・・・
>いずれ答えは出ると思いますが。

特に壁は無いとは思いますが、低レベル言語の方が楽な場合も多いから
じゃ無いでしょうか。
保守性や拡張性や可読性は、高級言語のほうが遥かにいいのですが、
フラグ操作や、スタック操作、iret命令、例外ハンドラ書き、などは、
一部にはどうしてもアセンブラの助けが必要になるのですが、
そういう部分で高級言語と連携させようとすると通常一手間増えてしま
います。

ただし、C++の本領発揮できる部分も沢山有ると思います。
リストを多用しやすいことや、自動的なコンストラクタ、デストラクタ
挿入によるでミスの無い記述ができること、などは非常に有利では
ないでしょうか。

ただし、大まかに言って、カーネルは必要最低限のものの集合体で、
いわば、互いに素というか、各部分の共通部分がすくないため、
似たもの同士を結びつける時に威力を発揮する「継承機能」は余り使う場面
が無いかもしれませんね。



735 :LightCone ◆sSJBc30S5w :02/10/22 08:43
[#734の続き]

単純に考えても、ファイルシステムの各APIは、そんなに共通の性質が
有るとは思えません。オープンとクローズは関連の仕方が、恐らく継承で
解決できるものではありませんよね。ReadとWriteは似ているので、「継承」
が使える余地は有ると思いますが。
ディレクトリ作成とファイル作成は内部処理は似た部分が多いので、
「継承」で簡単化できる可能性もあることはありますが、別の方法で
共通部分を上手く処理する方法もあると思いますので、C++が有利
になるかどうかは個人的には良く分かりません。


例外処理なども、各ハンドラに似た部分も多そうなので、C++が有利そう
ではあります。しかし、もしかすると、
「どんな、割り込みハンドラを登録しても、矛盾無く調停される」
ということが出来る方が、オブジェクト指向で矛盾を減らすことよりも、
安定性や汎用性が高くなるため、理想的では有ると思います。


736 :デフォルトの名無しさん:02/10/22 10:24
所詮習作なので、作ってて気に入らなくなったらまたゼロから作るぐらいの
つもりで、ひげぽんの独断で方針決めて、がんがん作っちまえばよいと思われ。

んで、ひととおり動いたら、また新しく目標立ててプロジェクトおこせばいい。

最終的にはQNXを凌ぐオープンなOSを個人的には希望(笑

737 :ひげぽん:02/10/22 20:42
LightConeさん

>テンプレートはマクロなので使えない方がむしろ不思議ですね。
>継承も多分少し工夫すると使えるようになると思います(思うだけ
>ですが)。

LightConeさんのご意見を受けて、テンプレートを試したところ
うまくいきそうです。どうやら私知識不足でリンクエラーになっていたみたいです。
これから簡易版Vectorでも実装してみます。

>優先順位付けは、腕の見せ所でも有るかもしれませんね。
>何が必要で、何がそれほどでもないか。または、何を先にやれば、
>うまくいくか、を決めていくのは、一番大事なところかもしれませ
>んし、、、。

全くその通りですね。しかもご指摘の通りOSを作成する場合には
細かいところにも気を配らないといけませんね。


738 :ひげぽん:02/10/22 20:42

>いわば、互いに素というか、各部分の共通部分がすくないため、
>似たもの同士を結びつける時に威力を発揮する「継承機能」は余り使う場面
>が無いかもしれませんね。

そうですね。私が想定しているのは
完全にインターフェースとしての継承機能を用いることです。

例が悪いかもしれませんが、

外部記憶装置のドライバーの機能は外から見た場合
大雑把に言って
init:初期化
read:読み込み
write:書き込み
close:終了処理
となると思います。


739 :ひげぽん:02/10/22 20:42

ですので上記のようなインターフェースを持つ基底クラスとして
抽象クラスBaseDiskDirverを作成します。

具体的なハードウェアのドライバー担当者は
こいつを継承した具象クラスを実装する形になります。

OS側では

BaseDiskDrier* p = new FloppyDiskDriver1();

BaseDiskDrier* p = new FloppyDiskDriver2();

BaseDiskDrier* p = new HardDiskDriver();

としてドライバーインスタンスを生成しますが
どのドライバーを用いているかを気にするのは
インスタンスの生成のところだけで

それ以降は、pが一体どのドライバーオブジェクトなのか
を気にせずに処理が出来るようになります。

p->write(・・・・);

ドライバーの例はあまり適切ではありませんで
分かりづらいかとは思いますが
このような使い方が出来たらと思っています。

740 :ひげぽん:02/10/22 20:45
>>736
>所詮習作なので、作ってて気に入らなくなったらまたゼロから作るぐらいの
>つもりで、ひげぽんの独断で方針決めて、がんがん作っちまえばよいと思われ。
>んで、ひととおり動いたら、また新しく目標立ててプロジェクトおこせばいい。

ありがとうございます。
「動けばいいや」精神が弊害になってきているので
そこだけ注意して、これからもやっていきます。



741 :デフォルトの名無しさん:02/10/22 22:11
>>738
> 例が悪いかもしれませんが、

全然適切。

現在のモダンな OS では、基本的にひげぽんさんが考えているようになっている。
例えば FreeBSD 2.x では...

struct cdevsw {
 d_open_t *d_open;
 d_close_t *d_close;
 d_read_t *d_read;
 d_write_t *d_write;
 d_ioctl_t *d_ioctl;
 ...
};

と言うような、デバイス処理ルーチンの関数テーブルがあって、OS はデバイスから読みたい時は、device->d_read(...); と間接コールをする。
これらのテーブルは、デバイスの初期化ルーチンが呼ばれる時にセットされる。

要するに、C++ の仮想関数と同じことを手でやってると言うこと。
だから、ここら辺を C++ で書くと結構きれいにかけるかもしれないと思っているので、ひげぽんさん頑張ってください。

742 :デフォルトの名無しさん:02/10/22 22:25
まあ、最初なのでioctl()まかせになりまくっても突き進む。

743 :LightCone ◆sSJBc30S5w :02/10/22 23:22
>>738,739,741

基本的には、面白そうなのですが、一つ注意することがあると思います。


それは、カーネル自体を C++ で書いていたとしても、
ユーザーレベルに公開するインターフェースとは別の話ではあることです。

例の様にドライバの機能を仮想関数で呼び出せるようにするには、
「ドライバの公開仕様」として、「仮想関数テーブル」を出す必要がある
ことになると思います。

しかし、通常仮想関数テーブルは、コンパイラ依存になりますが、
正式なドライバの仕様は、もっと固定的で無ければならないわけで、
単純なコンパイラの吐くコードで直接カーネルから、ドライバの
仮想関数を呼び出せるわけではないと思うのですが、どうですか。



744 :LightCone ◆sSJBc30S5w :02/10/22 23:23
[#743の続き]

それと、ドライバであってもある程度の保護下で動かすのが普通ですので、
ドライバを呼び出す際には「特権レベルの遷移」が必要です。
仮想関数呼び出しは、当然ならが、単純な near call が生成される
だけですので、そのままでは使えないと思います。

具体的には、スーパーバイザレベルに近いものへのコールは、
コールゲートやトラップゲートなどを利用できるのですが、逆向きレベル
への遷移は、IA32 では iret 命令を使う方法しかないため、ドライバを
非特権レベルで走行させるためには、通常のコンパイラで自動生成される
コードは使えないと思います。その辺はどうしても、インラインアセンブ
ラか、純粋なアセンブラで書く必要があると思います。

仮にドライバをカーネルと同一の保護レベルで動かすことにするとしても、
メモリ空間などで、「断絶」がある可能性が高く、少なくとも、gcc など
が吐くコードを魔法の様に、ドライバとカーネルの垣根を越えて利用する
ことは出来ないと思います。

ただし、カーネルを、C++ で記述するのは面白い試みだとは思いますので、
どうなっていくか楽しみです。

745 :ひげぽん:02/10/22 23:31
>>741さん
FreeBSD 2.x ではそのような仕組みが使われているのですね。
私のやりたい事に近いと感じました。
勉強になりましたありがとうございます。

LightConeさん

懸念事項までご指摘・アドバイスいただきありがとうございます。
確かに、ドライバーの場合、いろいろ問題がありそうですね。
ドライバー作成者にどのような環境を用意するかというのも
大きな問題だということが分かりました。
ありがとうございます。




746 :LightCone ◆sSJBc30S5w :02/10/22 23:35
>>741 さん、こんばんは。

そうでしょうね。Linux などでもそんな感じだったと思いますし、
MS-DOS や CP/M でも似たようなものでしたし。

ドライバに限らず、システム側からユーザーが作ったソフトウェアを
呼び出すときには、似たり寄ったりになるのがある意味当然なのですね。

N 個の公開関数があるときに、N 個の関数アドレスを出すか、
「関数アドレス取得関数のアドレス」を一つだけ出して、その
関数で N 個の関数のアドレスを間接的に貰う方法等があると思います。

後者では、
void (*EnumFuncAddr(int k))();
みたいな関数を公開するわけですね。一つで N 個分を網羅できる
わけです。


ioctl などは、一つの関数で、可変種類で、可変長パラメータ
の関数を公開しているようなものだと考えられると思いますが、
これも、後者に近い方法ですね。


いくらでも仕様のバリエーションあっても、根本的な部分
では、何も変わらないわけですね。

747 :デフォルトの名無しさん:02/10/23 00:05
>>743-744
> それは、カーネル自体を C++ で書いていたとしても、
> ユーザーレベルに公開するインターフェースとは別の話ではあることです。

ユーザーと言うのがちょっと不明確。
ドライバを書く人のことを言っているのか ?

> 例の様にドライバの機能を仮想関数で呼び出せるようにするには、
> 「ドライバの公開仕様」として、「仮想関数テーブル」を出す必要がある
> ことになると思います。
> しかし、通常仮想関数テーブルは、コンパイラ依存になりますが、
> 正式なドライバの仕様は、もっと固定的で無ければならないわけで、
> 単純なコンパイラの吐くコードで直接カーネルから、ドライバの
> 仮想関数を呼び出せるわけではないと思うのですが、どうですか。

ここは考え方次第。ドライバを書く人は、必ずこのコンパイラを使えというのもありだと思う。
もちろん、各種の処理系でドライバを書きたいとなると、インターフェースは関数テーブル等のように処理系にできるだけよらないものにする必要はある。
その場合でも、ドライバ用のライブラリを作ってドライバ自体は C++ で書けるようにするのがいいと思う。

> それと、ドライバであってもある程度の保護下で動かすのが普通ですので、

の場合も基本的に同じ。これをやりたいなら、そこはインラインアセンブラ等で作成する必要はある。

748 :デフォルトの名無しさん:02/10/23 00:06
ドライバ
http://homepage2.nifty.com/rohizuka/ka/pa_003_a.htm

749 :LightCone ◆sSJBc30S5w :02/10/23 00:34
>>747
>ユーザーと言うのがちょっと不明確。
>ドライバを書く人のことを言っているのか ?

そうです。

保護なし、同一セグメント、であるなら、可能でしょうね。

750 :LightCone ◆sSJBc30S5w :02/10/23 00:36
>>748
グロ画像(というか幽霊?)

751 :デフォルトの名無しさん:02/10/24 02:37
lightタン、こんばんは。
lightタン、ちゃんと足は生えてますか?

752 :デフォルトの名無しさん:02/10/24 07:16
>>750
グロではないかな。気持ち悪い人形。
NWSOSの方、頑張ってくれい。

753 :デフォルトの名無しさん:02/10/24 15:15
nwsosもひげぽんも頑張れ。いつかゲイツを倒すのだ。

754 :ひげぽん:02/10/25 00:18
>>753さん
ありがとうございます。がんばります。
Templateが使えるようになったので簡易版Vectorを追加しました。
これでいろいろと楽になるかも・・・

今までで追加して便利だったのは簡易版printfの_sys_printfかな。
debug時にすごい重宝します。
でも16進表示機能が未実装なのが不満。
やろうと思えばできるんだろうけど、
どうしてもほかの事を優先してしまいますね。
うーん。

755 :デフォルトの名無しさん:02/10/25 00:21
gcc3.xで構築できないという件ですが。
コンパイラに渡すオプションの-DBUILD_ON_LINUXを外せば構築できました。
動作することも確認しました。

756 :デフォルトの名無しさん:02/10/25 08:49
>>754
いそがばまわれ。

757 :ひげぽん:02/10/25 21:09
>>756
そのとおりですね。数年計画で進行中です。

>>700
募集していた。プロジェクトホームページを作ってくれる人が
見つかりました。
うれしい限りです。

758 :デフォルトの名無しさん:02/10/26 02:34
disk reading.... と永遠に出続けるが、いったいどうしたものか...

759 :デフォルトの名無しさん:02/10/26 04:43
HPの前に、そろそろ名前考えた方がよさげ。

#いくらカコ(・∀・)イイ!!HPでも、名前で(´・ω・`)ショボーン

760 :デフォルトの名無しさん:02/10/26 08:05
OSの名前は「ひげぽん」でいいんでないの?


761 :ひげぽん:02/10/26 11:20
>>759
>HPの前に、そろそろ名前考えた方がよさげ。
前スレを読んでいただくと分かりますが
higepos(仮称)です。

確かに、そろそろ本気でいい名前を付けないといけませんね。
ということで、

higepos(仮称)の正式名称は何が良いかご意見をお聞かせください。

ちなみに過去に挙がっていた名前は、

・GATES FREE
・2chOS
・2chdows
・超ひげぽん 

カコ(・∀・)イイ!!のをお願いします

762 :名無しさん:02/10/26 14:39
ゲイツクライシス

763 :ひげぽん:02/10/26 16:22
>>754
>今までで追加して便利だったのは簡易版printfの_sys_printfかな。
>debug時にすごい重宝します。
>でも16進表示機能が未実装なのが不満。
実装しました。
便利っす。

>>762
なんか強そうな名前・・・


764 : :02/10/26 20:44
ゲイツバスター

765 :ひげぽん:02/10/26 23:41
>>764
やっぱり強そう。
2chos(ニコス)なーんて案もあります。

今日はキーボードドライバーを書いてました。
なかなか難しいですね。

766 :デフォルトの名無しさん:02/10/27 00:02
OS mou 3
お相撲さん

767 :デフォルトの名無しさん:02/10/27 00:14
CHAOS is Higepon's Another Operating System

768 :デフォルトの名無しさん:02/10/27 00:21
explosion

769 :ひげぽん:02/10/27 00:22
>>766
しゃれ系も良いですが、英語圏の人は面白さが分からないかも。
2004年バージョンは、OS mou 3 2004
ここまで来ると暗号です。

>>767
Gnuっぽいですね。かっちょいい。
でもなんだか、OSが安定していないイメージを受けますね。


770 :ひげぽん:02/10/27 00:36
・GATES FREE
・2chOS
・2chdows
・超ひげぽん
・ゲイツクライシス
・ゲイツバスター
・2chos
・OS mou 3
・CHAOS
・explosion

皆さんの一押しはどれでしょう。
2chに関連する名前たちは捨てがたいですね。

771 :デフォルトの名無しさん:02/10/27 00:43
cha-OS だなぁ
yaccみたい

772 :デフォルトの名無しさん:02/10/27 00:45
ヒゲポソはどういうOSめざしてるんですか?
それによって以下略
過去ログ読むの面倒以下略

773 :超先生@OS板 ◆mz/OS/KoRM :02/10/27 00:58
OS/RealReality ・・・どうすれバインダ。

774 :ひげぽん:02/10/27 01:02
>>772
・多くの人に使ってもらえるOS
・フリーのOS
・日本発信のOS
・いい意味で過去の遺産を引き継がないOS
・使いやすくて、センスのあるインターフェースを持つOS
・内部の実装が出来るだけシンプルなOS
・もちろんマルチタスク

うわー、現段階ではほとんどさっぱり実現できていない。
大きな事ばかり言っていますが、あまり突っ込まないでください・・・


775 :ひげぽん:02/10/27 01:04
>>773 :超先生@OS板さん

お久しぶりです。
いつぞやアドバイスいただきありがとうございました。

>>OS/RealReality ・・・どうすれバインダ。
解説をお願いいたします


776 :デフォルトの名無しさん:02/10/27 01:23
・GikOS
ギコ猫のAAをフラッシュに使用。

      ∧ ∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
〜′ ̄ ̄( ゚Д゚)< 逝ってよし!
 UU ̄ ̄ U U  \_____________


・AssOS
アッソーのAAをフラッシュに使用。
|   。
|⌒ヾ
|冫、)
|` / ジー
| /
|/
|


・はシラネーヨ

   ∧ ∧    ┌─────────
  ( ´ー`)   < はシラネーヨ
   \ <     └───/|────
    \.\______//
      \       /
       ∪∪ ̄∪∪


777 :デフォルトの名無しさん:02/10/27 01:30
・Zonux
    / ̄ ̄ ̄ ̄\
  /     ●  ●、      _____
  |Y  Y        \   /
  | |   |        ▼ | < ぞぬっす
  | \/      _人.|  \_____
  |       ___ノ
  \    ./
   | | |
   (__)_)

・DomOSumimasen
 ________
〈 ドウモスミマセン
 ∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 (´Д`;)ヾ
   ∨)
   ((

・UmaibOS
うまい棒っす

778 :デフォルトの名無しさん:02/10/27 01:32
最初のアプリはやっぱ2chブラウザっすね。

779 :デフォルトの名無しさん:02/10/27 01:39
コードが出てこないとすぐ>>778みたいなのが出てくるんだよな

780 :デフォルトの名無しさん:02/10/27 02:11
>>770
その中でというのならCHAOS。

781 :デフォルトの名無しさん:02/10/27 02:30
漏れもCHAOSかな。
CHAOSで真っ先に浮かんだイメージは『無限の可能性を秘めてる』だった。漏れはね。

782 :デフォルトの名無しさん:02/10/27 03:22
Zonux

イイ━━━━━(゚∀゚)━━━━━!!!!

783 :デフォルトの名無しさん:02/10/27 03:52
「Swodniw」 ってのはどう?


784 :FreeDOS教徒:02/10/27 10:48
>>758
たぶん一度に読むセクタ数が問題かと‥‥

>>ひげぽ
ChaOSはすでにLEGO MINDSTORMS用OSとして存在してます。

>>783
なんて読むんですか?

785 :デフォルトの名無しさん:02/10/27 10:53
ひげだけに「Whiskers」。

786 :ひげぽん:02/10/27 11:56
・GATES FREE
・2chOS
・2chdows
・超ひげぽん
・ゲイツクライシス
・ゲイツバスター
・2chos
・OS mou 3
・CHAOS --すでに使われている名前なので却下
・explosion
・GikOS
・AssOS
・はシラネーヨ
・Zonux
・DomOSumimasen
・Swodniw
・Whiskers

今のところ上記のものが候補に上がっています。
ただ、日本語表記のもは難しいかも。
ひげぽん的には、2chos,2chOS,GikOS,Zonux,Whiskersかな。


787 :デフォルトの名無しさん:02/10/27 12:03
Zonuxに一票!

788 :戸塚ヨット:02/10/27 12:36
つーかassOSって・・・。assかよ
GikoOSに一票

789 :デフォルトの名無しさん:02/10/27 13:51
higeposがいいと思うなあ

790 :デフォルトの名無しさん:02/10/27 15:08
>>789
俺も〜〜〜。

791 :デフォルトの名無しさん:02/10/27 16:39
知らない間にELF32用でも起動するようになっていた。もうクロスは不要ですな。

792 :デフォルトの名無しさん:02/10/27 18:26
>>788
糞OS

イイ━━━━━(゚∀゚)━━━━━!!!!


793 :デフォルトの名無しさん:02/10/27 18:53
おまいら・・・名前を決めるより先にまだやるべきことイパーイあるだろ(w
せめてkernelに相当する部分だけでも完成してから議論しる。
まだメモリ管理がやっとこできたかどうかで笑わせんな。(w


794 :デフォルトの名無しさん:02/10/27 19:46
>>793
ヤレヤレ

795 :FreeDOS教徒:02/10/27 21:32
Gikos
なんとなく複数形。もちろん起動画面は大量のギコで(w

796 :ひげぽん:02/10/27 21:54
GikoのAAで純粋に、半角英数記号Onlyでかっこいいやつあるのかな?

Gikoに限定しないけど、起動画面に表示するなら
使える文字がかなり限られる。

797 :デフォルトの名無しさん:02/10/27 22:13
>>796
最初から2バイト文字前提で作っちゃダメなんか?


798 :ひげぽん:02/10/27 22:19
>>797
現在のhigeposでは表示出来ぬのです。
申し訳ありませんが、できれば2byte文字は避けていただきたい。

799 :デフォルトの名無しさん:02/10/27 23:11
ネイティブでUnicodeサポートだ。ガンガレ!

800 :デフォルトの名無しさん:02/10/27 23:25
>>「Swodniw」 ってのはどう?
なるほど、逆読みか。


801 :デフォルトの名無しさん:02/10/27 23:37
>>799の機能を実装して、nortにしてくだちい。

802 :デフォルトの名無しさん:02/10/28 03:51
Unicodeはアプリケーションレイヤの話しじゃないの?

803 :デフォルトの名無しさん:02/10/28 03:54
>>802
それをKernelレベルでやれと言っておる

804 :デフォルトの名無しさん:02/10/28 04:08
コードを扱うのはロケールを管理するドライバかナニカに任せて
OSはなんもしない方がいいと思うけどね。


805 :デフォルトの名無しさん:02/10/28 04:34
起動時にBMPを表示させる。と言ってみるテスト

806 :デフォルトの名無しさん:02/10/28 11:46
ここはシンプルに"Higex"

Higex(・∀・)イイ!!

807 :デフォルトの名無しさん:02/10/28 12:39
何に盛り上がってんのかと思えば名前か。
SPATRA〜スパトラ

808 :ひげぽん:02/10/28 20:50
>>709,802,803,804,805
higeposにおいて、国際化をどう扱うかは一切決めていません。
まだまだ先にやらなければいけないことが山ほどあるので・・・
という事で現時点では半角英数字記号しか出力できません。

国際化の資料といえばInterface12月号は、なかなか勉強になりました。

OSの名前ですが
・ひげは出来るだけ卒業 ex)higepos,higex
・商標問題がありそうなのは避ける ex)Giko,モナー
という方針でいくと何が残るんだろう・・・



809 :ひげぽん:02/10/28 21:35
http://higepos.sourceforge.jp/
現在の最新のhigeboot.binをuploadしました。
自環境でmake出来ない場合にお使いいただけたらと思います。

810 :デフォルトの名無しさん:02/10/28 21:46
マイクロカーネルの方向っすか?

811 :ひげぽん:02/10/28 21:51
>>810
一応予定ではですが・・・

812 :デフォルトの名無しさん:02/10/28 21:56
一つ言ってイイ?
今作っているの?

813 :ひげぽん:02/10/28 22:01
>>812
OSを現在作っているのかというご質問であれば
はい、作っています。


814 : ◆kXn47FN4zU :02/10/28 22:34
レスがほしい807です。
Spicy
P?
A?
Try
Revolution
A?
これだけしか思いつかないでつ、カフっ。

815 :デフォルトの名無しさん:02/10/28 22:42
>>809
ひげぼんさん
これは、どうやってインストールすればいいのかな?

816 :ひげぽん:02/10/28 22:42
>>807,814
申し訳ありません。
>SPATRA〜スパトラ
Spicy
Portable
A?
Try
Revolution
Architecture
思いつきません。

817 :ひげぽん:02/10/28 22:47
>>815
x86エミュレータbochsを使う場合、
higeboot.binをフロッピーイメージに指定すればよいです。
vmwareでもほぼ同様です。

フロッピーにインストールしたい場合
unix系
 ddコマンドでhigeboot.binを書き込む。
Windows
 rawrite.exeというアプリケーションでhigeboot.binをかきこむ。
書き込んだら、フロッピーを起動させたいマシンに挿入して
リブートでいけるはずです。
ただし何が起きても一切責任はもてませんのでご了承ください。


818 : ◆kXn47FN4zU :02/10/28 22:57
レスを強要するような庫とを書いてすみませんでした。
Portable思いつかなかったです。安易にいくとこんな感じに
Spicy
Portable
And
Try
Revolution
Architecture

819 :ひげぽん:02/10/28 23:09
>>818
いえいえ、基本的にレスを返そうと思っているのですが
見落としていました。
SPATRAは、chaos系ですね。

820 :名無しさん:02/10/29 07:07
Zonuxに一票。

821 :デフォルトの名無しさん:02/10/29 07:08
adidos

822 : ◆kXn47FN4zU :02/10/29 07:42
>>819
いえ、スパトラは語感のみです。
アルファベットは1byte指定に合わせて適当に振りました。
意味の方は、レス欲しさに付けたおまけです。フルネームは
SPATRA Operating System

823 :デフォルトの名無しさん:02/10/29 08:19
Microkernel
Operating system
Named
After
eXcitement

祭りにちなんで名づけられたマイクロカーネルOS
MONAX

824 :LightCone ◆sSJBc30S5w :02/10/29 08:28
ひげぽんさん、こんにちは。

#809 のイメージから、
Win2000 の、cygwin で、dd if=higeboot.bin of=/dev/fd0

としてブートディスクを作ってみたところ、起動画面にはなりますが、
disk reading ... が表示されつづけたままになりました。
起動を試した機種は、ノート型の、FUJITSU FMV-5233 NA/X (BIBLO) です。

825 :LightCone ◆sSJBc30S5w :02/10/29 08:36

http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/higepos/higepos_v1.1/src/firstboot.asm?rev=1.2&content-type=text/vnd.viewcvs-markup

このソースを見て気付くのは、ss=cs に設定しているのに、
sp の初期化がされていないことです。

mov ax,cs
mov ss,ax ;自動的に直後の命令実行中はcli
mov sp,7c00h

としてみてください。

826 :LightCone ◆sSJBc30S5w :02/10/29 09:20
'disk reading ...' を繰り返す理由が恐らく判明しました。

#825 のソースで、mov ah,02h, int 13h で、cf=1 のときそのまま
繰り返していることに原因がありそうです。

PC/AT の BIOS では、int 13h で失敗した時は、必ず
mov ah,00h, int 13h を実行して、disk reset しなければ
なりません。そうしないと何度でも失敗します。

私も PC-98x1 から移行したとき、ここではまりました。
これで、この現象はfixされると思います。

827 :デフォルトの名無しさん:02/10/29 09:43
higepos は doxygen 準拠のソースっぽいですが、
どこかに doxygen の吐き出したドキュメントがあったりするのでしょうか?

828 :デフォルトの名無しさん:02/10/30 00:34
とりあえずマイルストーン決めて、目標バージョン番号とコードネーム決めよう

829 :デフォルトの名無しさん:02/10/30 16:28
(´-`).。oO(>>828みたいな奴どうにかしてほしいな)

830 :デフォルトの名無しさん:02/10/30 18:28
ひげぽす

831 :デフォルトの名無しさん:02/10/30 19:25
オミクロン萌え。

832 :デフォルトの名無しさん:02/10/30 20:38
ひげぽすやってみたくてBOCHSをDLしたまでいいけど
詳しい起動法がわからない・・・

bochs.exe -> メインメニューで1を選択 -> higeboot.binで開く
じゃ違うのか?

833 :デフォルトの名無しさん:02/10/30 22:43
>>832
> じゃ違うのか?
OSが分からんけど違う。higepos.binがあるディレクトリにbochsrc.txtを作成
した方が楽だと思う。bochsrc-sample.txtみたいなファイルがどこかにあれば
それを修正するのが吉。

834 :ひげぽん:02/10/30 23:26
レスが遅くなりすいません。
平日はなかなか忙しい・・・

>>823
MONAXいいかも。Monax・・・
ところでLinux,Monax みたいに最後にxつくと
unixクローンて誤解されるのかな?

>>LightConeさん
返事が遅くなりまして申し訳ありません。
バイナリを試していただいたようで
ありがとうございます。しかもBugおよび
修正箇所まで指摘していただいてありがとうございます。
週末にでも確認・修正して、反映させていただきます。


835 :ひげぽん:02/10/30 23:33
>>827
>higepos は doxygen 準拠のソースっぽいですが、
>どこかに doxygen の吐き出したドキュメントがあったりするのでしょうか?
今はどこにおいていません。
もし、higeposをMake出来る環境があり、doxygenがインストールされていれば
Make時に生成されます。
ご希望であればどこかに置きますよ。

>とりあえずマイルストーン決めて、目標バージョン番号とコードネーム決めよう
今のところOS名が決まればいいかなと考えています。
マイルストーンを決めても気分次第でふらふらしそうですし(笑)


836 :ひげぽん:02/10/30 23:37
>>832さんのbochsの使用方法について
>>833さんフォローありがとうございます。

.bochsrcの関係ありそうな部分抜粋
vgaromimage: ./VGABIOS-elpin-2.40
boot: a
floppya: 1_44=../../higepos_v1.1/bin/higeboot.bin, status=inserted

837 :832:02/10/31 07:35
>>833 , >>ひげぽん
サンクスです。
早速試してみます
ちなみにOSはWinMeです。

838 :デフォルトの名無しさん:02/10/31 09:48
>>834
POSIXになんとなく準拠していく予定ってことにしとけば最後にXついててもいいんじゃない?

EXCITEMENT(騒動、騒ぎ)のXでそれ以上深く考えなくてもいいと思うけど。(笑)
祭りってのは若干意訳な気もするけど、まあ、いわゆる2chの「祭り」と考えれば意味はあってる。

839 :832:02/10/31 16:08
00000000000i[ ] using log file bochsout.txt
って出るのはどう対処すればいいんでしょうか…
これが出たあとちょっとしてからBochsが終了します。

840 :832:02/10/31 16:29
解決

841 :がんばれひげぽん:02/11/01 00:04
ひげぽんに影響されて、

オペレーティングシステム<第二版> 設計と理論およびMINIXによる実装」
著:A.S.タネンバウム + A.S.ウッドハル
訳:千輝 順子
監修:今泉 貴史
プレンティスホール出版 ¥8,800

かって読んだんだけど・・・・・・
何を書いてあるのか全くわかりません。
こんなの読んでわかる人いるの?

というか、わかる人は今までどんな人生送ってきたのよ?

842 :デフォルトの名無しさん:02/11/01 01:29
理学部数学科とか工学部情報工学科とかで暗い人生では?

843 :デフォルトの名無しさん:02/11/01 01:31
普通に文系だけどなんとなくなら分ったよ。
実際にコードいじるとなると全然次元が違うけど。

844 :電波5号:02/11/01 04:05
今日このスレッドをみつけて面白かったので
全部よみました。
前スレは読んでいません。
僕はプログラミングは得意じゃないですが
Monaxに一票・・・とかだ投稿させて頂きます。

845 :デフォルトの名無しさん:02/11/01 06:05
>>841
それはOS関係では古典的かつ易しい部類の本だぞ
いわば基本

846 :戸塚ヨット:02/11/01 17:10
>>841
>何を書いてあるのか全くわかりません。
どんなことがわからないの?

847 :デフォルトの名無しさん:02/11/01 17:32
>>846
多分日本語が読めてない。
多分ちょn

848 :デフォルトの名無しさん:02/11/01 19:14
大変幸運なことに、Monolithicの頭文字もMである。

849 :デフォルトの名無しさん:02/11/01 19:20
マナマナの頭文字もMという罠。ガクガク(゚Д゚;)ブルブル

850 :デフォルトの名無しさん:02/11/01 21:25
>>849
エロゲ板へ(・∀・)カエレ!

851 :ひげぽん:02/11/01 23:25
>>841
>かって読んだんだけど・・・・・・
>何を書いてあるのか全くわかりません。
>こんなの読んでわかる人いるの?
>というか、わかる人は今までどんな人生送ってきたのよ?

>>845
>それはOS関係では古典的かつ易しい部類の本だぞ
>いわば基本

まじめにレスします。
ひげぽんはかなり理解力がないので、1回目に軽く目を通したとき
5%位しか理解できませんでした。
その後読んでみた感想は、
1章オペレーティングシステム概論→まあ言っていることは分かるかな?
2章プロセス→プロセスの競合等の理論はなんとなく分かったが、実際実装してみないと分からないかな・・
3章入出力→つまみ食い程度・・・まだちゃんと読んでない。
4章メモリ管理→カーネル内メモリ管理の実装の前に熟読しました。でも理解したのは40%位かな。
5章ファイルシステム→面白かったです。iノードとか勉強になります。一番理解したかも・・

852 :ひげぽん:02/11/01 23:27
>>848
Monaxいいかも。

853 :デフォルトの名無しさん:02/11/01 23:58
おい、おまいら!
Woodchuck(ウッドチャック)っつー北米産のリスの学名が
Marmota monax だぞ!!!!

http://museum.nhm.uga.edu/gawildlife/mammals/rodentia/sciuridae/mmonax.jpg

早くもマスコットが決定w

オライリーの表紙に使ってもらえ。

854 :ブー:02/11/02 00:03
ひげぽんさん、先ほどは私が立てたスレにお越しいただきありがとうございます。
私もOSを作ってみたいと思っていたのですが、その力がないのと、
なかなか行動に移せないでいました。
ですが、このひげぽんさんのスレをみて、私もOSを作成する決心がつきました。

私は、ひげぽんさんのずっと後ろのほうにいますが、早く追いつくように、
がんばって行きます。
先を行っているひげぽんさんに、質問させていただくときがあると思いますが、
そのときは、なにとぞよろしくお願いします。

855 :デフォルトの名無しさん:02/11/02 00:05
>>852
ひげぽん殿、
そういえばファイルシステムどーいう形式にすんの?
あと、プロセス管理とかは?マルチスレッド対応するんでつか?
プロセス管理わかんねならシングルタスクOSにするのもありかも。(w


856 :ひげぽん ◆Ngzcp/NZpA :02/11/02 00:08
>>854さん
お互いプログラム版@2chで成長して行けると良いですね。
是非いろいろ情報交換させてください。

857 :ひげぽん ◆Ngzcp/NZpA :02/11/02 00:13
>>855
>ひげぽん殿、
>そういえばファイルシステムどーいう形式にすんの
FDDの間は、FAT12にするのが有力ですが、勉強のため
ヘボファイルシステムを実装するかもしれません。

プロセス管理は、マルチタスクにするのが目標です。
分かるまで勉強するつもりです。
マルチスレッドに対応するかどうかは、まだ考えていません。

858 :FreeDOS教徒:02/11/02 00:55
こんなのつくりますた。
http://guriponn.tripod.co.jp/guri/2chos.lzh
日本語表示できなくても、起動時はこれで大丈夫?

859 :デフォルトの名無しさん:02/11/02 02:16
最高!、ワラタよ。

860 :デフォルトの名無しさん:02/11/02 03:06
レベル高いな

861 :デフォルトの名無しさん:02/11/02 03:08
この程度でか?

862 :デフォルトの名無しさん:02/11/02 03:13
>>861
あんたは、何か作ったのか?
その言葉は実際に作ってからいえ。

863 :FreeDOS教徒:02/11/02 11:05
>>859
そう言われるとネタ準備してよかったなと思いまス。

>>860
実はたくさん手抜きしてます。まあ動いたからよかったな、と。
まともなAAに書き換えたりしたやつを上げときました。

864 :ひげぽん:02/11/02 12:50
>>FreeDOS教徒殿
おもしろいっす。最高です。
こいつをhigeposで実現するのは難しいでせうか?
どういう技術を使っているのかいまいちピンときません。

865 :デフォルトの名無しさん:02/11/02 13:14
ブートさせたあとに、メモリ内のイメージを表示させてるんじゃないの?
ダンプしてみたら"FF FD FD FF FF"ってな具合に出てきたから、
で、キーボードを押したらリセットすると、

逆アセンブラとか使ってみたらいいじゃん?>ひげぽん


866 :デフォルトの名無しさん:02/11/02 16:51
まさかx86で走らせるのですか?

867 :デフォルトの名無しさん:02/11/02 17:03
いいえ、8080です。

868 :超先生@OS板 ◆mz/OS/KoRM :02/11/02 17:11
この手のプラットフォームとしてはP/ECEが最強!
ttp://www.piece-me.com/

869 :デフォルトの名無しさん:02/11/02 17:18
>>868
いや、それならWSの方が遙かに良いと思うんだが…

870 :デフォルトの名無しさん:02/11/02 17:39
WSではOSレベルでいじれませんよ。
P/ECEはカーネルからなにから全部いじれる。

871 :デフォルトの名無しさん:02/11/02 17:50
WSってBIOSじゃなくてOSなの?
ぜんぜん知らんかった…というより、モッテナイ。

872 :デフォルトの名無しさん:02/11/02 17:54
WSっていうか、うぃっち?

873 :デフォルトの名無しさん:02/11/02 20:42
Linux (not closs)で
[CPU ] exception(): 3rd exception with no resolution
になりました。FDCDriver.cppの変更後です。
# 昨日までは大丈夫だったんだけどなー

874 :832:02/11/02 21:23
>>858
これがひげぽすの起動画面になったら(・∀・)イイ!な・・・

875 :デフォルトの名無しさん:02/11/02 21:26
ketype は普通のキーと重複しないように256あたりからはじめないと,
いけないんじゃないかな。

876 :デフォルトの名無しさん:02/11/02 21:32
)873

higeKenel.cppのvectorのテストの辺りじゃないかな。

877 :デフォルトの名無しさん:02/11/02 21:42
isShift_ = (modifiers & KEY_MODIFIER_UP) ? false : true;
これって,
isShift_ = !(modifiers & KEY_MODIFIER_UP)
と同じじゃない?

878 :ひげぽん:02/11/02 21:45
>>873,876
申し訳ありません。現在調査中です。

>>877
仰るとおりです。あとで直しときます。
ソースを公開するとバカコードが発見されて品質が上がります(涙)
ご指摘ありがとうございます。へこみますた。


879 :デフォルトの名無しさん:02/11/02 21:55
>>876
> higeKenel.cppのvectorのテストの辺りじゃないかな。
Bochs上に "idt set done\n" が出力されないので、その前かもしれません。
よく分からんです。ちょっと調べてみます。
# 報告無かったら分からんかったと言うことでスマソ


880 :デフォルトの名無しさん:02/11/02 22:16
>879
テストの部分をコメントアウトしてみれば,すぐにわかります。

881 :デフォルトの名無しさん:02/11/02 22:20
OS上でOSと同様に動かせるOSもどきなら作れるんだけどなぁ。。。(藁
みなさん凄いです。

882 :デフォルトの名無しさん:02/11/02 22:29
>>880
> テストの部分をコメントアウトしてみれば,すぐにわかります。
_sysUnlock();
をコメントアウトしたら
[CPU ] exception(): 3rd exception with no resolution
が無くなりました。当然動きませんが ;-)

883 :PJメンバ:02/11/03 00:45
原因はバイナリの大きさがfirstboot.asmで読み込んでる大きさを超えたた
めのようです。
が、読み込む量を増やそうとしても今度は一定量以上読み込ませようとする
とそこで止まってしまう現象が起きるようです。

ということで差し戻しを行いました。お騒がせしました。

884 :デフォルトの名無しさん :02/11/03 02:19
>> FDDの間は、FAT12...
役に立つかどうかわかりませんが、Interface誌2001年7月号に、
FATの概要があります。

885 :ひげぽん:02/11/03 15:02
>>884さん
情報ありがとうございます。バックナンバーあるかな・・・
>>883
ということでhigeposPJメンバーが改善に努めております。
今しばらくお待ちください。
悪いのはひげぽんの書いたfirstboot.asmです。
ご迷惑をおかけいたします。

886 :ひげぽん:02/11/04 00:48
今日はつくづくハードウェアの知識が足りないと痛感。
勉強せねば。
しかもあほなコード書くし・・・
バグよりも性質が悪い・・・
と、ぼやきでした。

887 :デフォルトの名無しさん:02/11/04 01:15
>>886
自分が馬鹿だと気づいただけでも上出来です。
あなたには向上する余地が残っているということです。
安心めされい。

888 :デフォルトの名無しさん:02/11/04 01:16
ひげぽんは♀ですか?

889 :デフォルトの名無しさん:02/11/04 02:34
♂→♀を♀と認められるなら、そうです。

890 :デフォルトの名無しさん:02/11/04 05:12
なにやら、NWSOSが着々とVerUPしてますな・・・

891 :ひげぽん:02/11/04 13:04
>>888,889
♂です。

892 :謎の探偵X:02/11/04 17:40
陰乍ら、応援してるけど・・・・
俺も勉強してみようかな・・・・
ひげぽんさん、ファイd!

893 :デフォルトの名無しさん:02/11/04 17:47
ひげぽーん
IntelのPDF読んだ?
俺やっとフォーマット理解できたよ写し

894 :ひげぽん:02/11/04 17:49
>>892
ありがとうございます。
一緒に勉強しましょう(巻き添え)
>>893
>ひげぽーん
>IntelのPDF読んだ?
>俺やっとフォーマット理解できたよ写し
どの部分ですか。まだ1/4も読んでいないです。
ごめんなさい。

895 :デフォルトの名無しさん:02/11/04 17:52
>>893
何のPDF?

896 :デフォルトの名無しさん:02/11/04 18:38
IA32

897 :デフォルトの名無しさん:02/11/04 22:47
ひょっとして、げーはなさん?

898 :デフォルトの名無しさん:02/11/05 01:23
http://www.intel.co.jp/jp/developer/design/litcentr/index.htm
Intelプロセッサーマニュアル

のことだよね?

899 :デフォルトの名無しさん:02/11/05 21:58
根本的で初歩的なこと聞きますが
開発環境はどんなもんですか?
Win+VisualCではなさげだけど・・・

900 :デフォルトの名無しさん:02/11/05 22:00
>>899
過去ログ読め

901 :ひげぽん:02/11/06 00:17
>>899
開発環境
Windows + gnu_tool@cygwin + nasm
または
Linux + gnu_tool + nasm
です。

902 :デフォルトの名無しさん:02/11/06 16:07
>901
windwowsではwin用のnasmwを使ったほうがいいです。
nasmだと動きがチョット変じゃないですか?

903 :デフォルトの名無しさん:02/11/06 19:18
>>902
そんなこと無いと思います

windowsね!

904 :デフォルトの名無しさん:02/11/06 20:19
動きが変というのは、多分NTでコマンドプロンプトを使っていると
一度エミュレーションが走って過去のコンソールバッファが消えるとかじゃない?

905 :ひげぽん:02/11/07 00:29
>>902,903,904
言葉足らずでした。Windows環境ではnasmwを使っています。
すいませんm(__)m

ちょっと仕事が忙しくてあまり進展していないhigeposですが
週末にはブートストラップ問題を片付けられればとおもいます。
新名称は Mona はどうでしょうか。
読み方は もなー または、 もな 。

906 :デフォルトの名無しさん:02/11/07 00:53
ひげぽんが良いと思う名前で良いと思います。
個人的には『x』を付けると響きが良いなぁと思うけど、LinuxとかUnixとは違いますもんね。
MOna is Not unix. it is new operAting system かなり苦しいです。w

907 :デフォルトの名無しさん:02/11/07 01:29
もなー(or もな) :MOna is moNA

こんであかんのか?
gnuだってそんなもんだろ?

マスコットのリス、いいなぁと思いました。

908 :デフォルトの名無しさん:02/11/07 01:45
Mona Operating system is Not Atari

…古!!

909 :デフォルトの名無しさん:02/11/07 01:49
MONAPONがいい!

910 :デフォルトの名無しさん:02/11/07 02:03
Mona is Operating-system, Not Application!

911 :デフォルトの名無しさん:02/11/07 03:10
> Not Application!
滅茶苦茶必死臭いな(藁

912 :FreeDOS教徒:02/11/07 08:21
>>909
イイ!!

913 :デフォルトの名無しさん:02/11/07 14:40
a Microkernel Operating system for the Next Age.

次世代のマイクロカーネルオペレーティングシステム。

914 :デフォルトの名無しさん:02/11/07 14:41
>>907
リスの名前はmonaではなくmonax

915 :デフォルトの名無しさん:02/11/07 15:03
Mona is Operating-system, Not ASCII-Art!

916 :デフォルトの名無しさん:02/11/07 17:29
んじゃNeXT信者な折れは
HiGESTEPかMoNASTEPで

917 :デフォルトの名無しさん:02/11/07 20:29
Net/2みたいな感じで、Channel/2なんてどうよ?

918 :FreeDOS教徒:02/11/07 20:59
ひげぽんごめん。

原因わかった。ディスク読み込みでブートコード破壊してた。
ブートコードをいったん上位のアドレスに移したらふつーに動いた。

・・・吊ってくるぽ(汗

919 :ひげぽん:02/11/07 21:52
>909
MONAPONって英語圏の人にはなじむ語感なのかな?
ぽんぽんぽん
>>913
いいっすね。でもちょっとまじめすぎ?

920 :デフォルトの名無しさん:02/11/07 22:53
普通にmonaxでいいじゃん

921 :デフォルトの名無しさん:02/11/07 22:57
>>920
unixクローンと誤解されるのがいやなんじゃ?

922 :ひげぽん:02/11/07 23:39
>>FreeDOS教徒
>原因わかった。ディスク読み込みでブートコード破壊してた。
>ートコードをいったん上位のアドレスに移したらふつーに動いた。
直します。詳細を是非教えてください。

>>920
>>921
>unixクローンと誤解されるのがいやなんじゃ?
POSIX準拠だと思われたらかなわない・・・という意図はあります。


923 :デフォルトの名無しさん:02/11/08 00:14
名前よりまずは中身w

924 :デフォルトの名無しさん:02/11/08 00:17
まじでOS造ろうって言うのいんの?

925 :デフォルトの名無しさん:02/11/08 00:33
>>924
現に>>1はそう申しておりますが

漏れも言うだけなら言えるぞ

926 :FreeDOS教徒:02/11/08 05:03
org 0

start:
xor ax,ax
mov ds,ax
mov si,0x7c00
mov ax,0x9e00
mov es,ax
xor di,di
mov cx,0x0200

rep movsb

jmp 0x9e00:next

next:
mov ds,ax
mov ax,0x8e00
mov ss,ax
mov sp,0xfffe

以下略(ぉ
まさか携帯でニーモニック打つとは思わなんだ。。

927 :デフォルトの名無しさん:02/11/08 05:56
>>926
ん?それをFDのブートセクトに書き込むと、起動するの?

928 :FreeDOS教徒:02/11/08 06:48
>>927
このままでも一応動くけど・・・

>>ひげぽん
これを適切な位置に置き換えて使ってぽ。
firstboot.asmが手元にないけど、ちょっと書き替えたら動くはず。

929 :デフォルトの名無しさん:02/11/08 18:53
MIPSマンセー!!
x86なんて糞ですよ(マジで)。

930 :デフォルトの名無しさん:02/11/08 19:11
ARMマンセー!!
MIPSなんて糞ですよ(マジで)。

931 :デフォルトの名無しさん:02/11/08 19:33
x86マンセー!!
ARMなんて糞ですよ(マジで)。

932 :ひげぽん:02/11/09 00:41
>>928 :FreeDOS教徒さん
携帯からの入力thanx!!

ところで
>原因わかった。ディスク読み込みでブートコード破壊してた
これは、
最初の512byteだけですか、それとも???
ブートコードを破壊してる場所が明確で、修正が簡単に可能ならば
そちらを修正しようと思っています。

>start:
>xor ax,ax
>mov ds,ax
>mov si,0x7c00
>mov ax,0x9e00
>mov es,ax
>xor di,di
>mov cx,0x0200
>rep movsb

0x7c00:0000→0x9e00:0000へ1024byte分コピー

933 :ひげぽん:02/11/09 00:43
mp 0x9e00:next

>next:
>mov ds,ax
>mov ax,0x8e00
>mov ss,ax
>mov sp,0xfffe
上位アドレス0x9e00:nextにて実行を続行???

ちょっと今日は、特に頭が回らない・・・
明日考えます。

934 : :02/11/09 06:54
show-mona...

935 :FreeDOS教徒:02/11/09 07:45
>>ひげぽん
54セクタ読もうとすると
0x1000+(0x200*0x36)=0x7c00
でブートコードを破壊するのは分かりますよね。

だからブートコードを上位の空きメモリに移してそこで実行を続けています。
こうすることで最大640KB程度のカーネルまで読み込めるはずです。

936 :FreeDOS教徒:02/11/09 08:04
ちょっとつっこみ。

×0x7c00:0000
○0x07c0:0000(0x0000:7c00)
×1024バイト読み込み
○512バイト読み込み

937 :929:02/11/09 22:34
はじめて読む486っていう本読みました?>ひげぽそ

938 :デフォルトの名無しさん:02/11/10 02:05
>>937
まぁ、過去ログでも読めや

939 :ひげぽん:02/11/10 15:30
FreeDOS教徒さん

ひげぽんの遅い理解を以下にまとめて見ます。
間違い等ありましたら、突っ込みをお願いいたします。


512byteのブートコードは 0x07C0:0000(0000:0x7C00) に読み込まれます。

そのブートコード中では 0x0100:0000(0000:0x1000) をバッファの先頭として
後続のコードをFDより読み込みます。

ところが54セクタ読み込むと

読み込まれるサイズは 512byte * 54 = 0x6C00 となり
0x0100:0000(0000:0x1000) から読み込んだ場合
0x07C0:0000(0000:0x7C00) にあるブートコードを上書きしてしまいます。

これが問題となるのは
secondboot.bin + third.binのコードサイズが
54セクタ(512 * 54 = 27Kbyte)を超えたときです。

これを回避するためにFreeDOS教徒さんは

ブートコードが 0x07C0:0000(0000:0x7C00) が読み込まれて実行されている
途中でブートコードを
まるごと 0x9E00:0000(0000:0x9E000) へコピーしてそちらで実行を続けるという策を
とられています。

この方法を使えば理論上
(0x9E000 - 0x1000) = 628kbyte まで読み込むことが可能になります。

940 :ひげぽん:02/11/10 15:31
>>937
いぜんhigeposのブートコードを書くときに
エイッと読んでいたのですが、すっかり忘れていました。
もう一度読み返しているところです。

941 :デフォルトの名無しさん:02/11/10 20:58
ブーに注意

942 :FreeDOS教徒:02/11/10 23:16
>>ひげぽんさん
それで正解です。ただ実際に示したコードや移すアドレスは詰めが甘いので、適宜書き換えて使われてください。

943 :デフォルトの名無しさん:02/11/10 23:29
>>942 FreeDOS教徒 さん

>それで正解です。
ありがとうございます。

>ただ実際に示したコードや移すアドレスは詰めが甘いので、適宜書き換えて使われてください。
                                 ~~~~~~~~~~~~~~~
                               ↑
                          この辺が重要なんでしょうね。
ちょっとうまくいっていないのですが、もう少しがんばってみます。

944 :ひげぽん:02/11/11 21:15
>>943の書き込みは私です。

ブートコード問題多分解決しますた。
今現在higepos PJメンバーに動作確認してもらっています。

945 :デフォルトの名無しさん:02/11/11 22:17
Linux(not cross)で動作確認OKでした。

946 :ひげぽん:02/11/11 22:25
>>945
ありがとうございます。
原因は後ほど、報告いたします。

947 :ひげぽん:02/11/11 22:57
確認が取れましたので

■現象
最新版マルチセクタ読み込みfirstboot.asmで正しく
読み込まれているはずなのに、

int_trap_gate(): selector nullのエラーがでる。

■原因

idtrのアドレスがhigeIdt.hで0x6800に設定されていました。
これじゃあ上書きされてしまいます。

■対処

higeIdt.h:0x6800→0x0500(ここなら安全か??)

948 :LightCone ◆sSJBc30S5w :02/11/12 10:33
>>947
ひげぽんさん。お久しぶりです。

お忙しいならご返答は適当でいいのですが、DISK BIOSでセクタを
読むとき、複数回のBIOS呼び出しで、1セクタずつ読むより、
連続セクタを一回のBIOS呼び出しで読んだ方がやはり速いんでしょうか?

949 :超先生@OS板 ◆mz/OS/KoRM :02/11/12 12:21
 ∧_∧
< `ー´>-~~~
PC/AT機のBIOSだと、readコール発行する毎に
シリンダをシークしてるような機械的挙動ですね。
1セクタ毎だと倍程度の読み込み時間がかかってしまう。

950 :デフォルトの名無しさん:02/11/12 15:37
>947 ひげぽんさん
>■原因
>
>idtrのアドレスがhigeIdt.hで0x6800に設定されていました。
>これじゃあ上書きされてしまいます。
>
>■対処
>
>higeIdt.h:0x6800→0x0500(ここなら安全か??)

配列を使えば,そんなもんだいは解決します。

ソースはこんな感じで
idt_st idt[HANDLER_NUM];

for (int i=0;i < HANDLER_NUM; i++)
{
void* p = handlers[i].handler;
idt[i].offsetL = (int)(p) & 0xFFFF;
idt[i].offsetH = ((int)(p) >> 16 & 0xFFFF ;
idt[i].selector = 0x08;
idt[i].type = 0x8E;
idt[i].unused = IDT_UNUSED;
}

idtr.limit = sizeof(idt_st) * HANDLER_NUM -1;
idtr.highbase = (int)(&idt) >> 16 & 0xffff;
idtr.lowbase = (int)(&idt) & 0xffff;


951 :ひげぽん:02/11/12 18:06
LightConeさん、超先生@OS板さんおひさしぶりです。

LightConeさんwrote
>お忙しいならご返答は適当でいいのですが、DISK BIOSでセクタを
>読むとき、複数回のBIOS呼び出しで、1セクタずつ読むより、
>連続セクタを一回のBIOS呼び出しで読んだ方がやはり速いんでしょうか?
超先生@OS板さん wrote
>PC/AT機のBIOSだと、readコール発行する毎に
>シリンダをシークしてるような機械的挙動ですね。
>1セクタ毎だと倍程度の読み込み時間がかかってしまう。

数値で具体的に示せないのが申し訳ないのですが
1セクタ毎だと60セクタ程度でもちょっと遅いと体感できます。
1秒にも満たない時間ですが・・・


952 :ひげぽん:02/11/12 18:24
>>950
ありがとうございます。
なるほどそんな方法があるのですね。
ちょっと良く考えてみます。

953 :FreeDOS教徒:02/11/12 19:14
そろそろ次スレ立てねぇ?>ひげぽん

954 :ひげぽん:02/11/12 19:22
>>953
次スレたてますた。
こちらへ移行をお願いします。
http://pc3.2ch.net/test/read.cgi/tech/1037096449/

955 :LightCone ◆sSJBc30S5w :02/11/13 07:41
>>951
お忙しい所、返答有難うございます。

>数値で具体的に示せないのが申し訳ないのですが
>1セクタ毎だと60セクタ程度でもちょっと遅いと体感できます。
>1秒にも満たない時間ですが・・・

これは、60セクタ程度を、1セクタずつBIOSコールで読み込むのが、
トータル1秒未満で行える、ということですか。

間違っていたらすみません。

956 :LightCone ◆sSJBc30S5w :02/11/13 07:50
>>955
higeposのソースを見てみると、最大1トラック(18セクタ)をちゃんと
一度に読むようになってるみたいですね。

957 :デフォルトの名無しさん:02/12/08 02:28


958 :デフォルトの名無しさん:02/12/09 23:32
うめてよいよね?



だめ?

959 :デフォルトの名無しさん:02/12/10 16:02
>>958
協力しましょう。

960 :デフォルトの名無しさん:02/12/10 22:44
>>958
いいと思うよ。

961 :デフォルトの名無しさん:02/12/11 00:56
また〜りと うめたて

962 :ひげぽん:02/12/11 00:57
気づいてしまいました(笑)

963 :デフォルトの名無しさん:02/12/11 12:50
まったり埋め立て作業中

964 :sage:02/12/11 14:24
うめ

965 :デフォルトの名無しさん:02/12/11 19:11
本当にまったりだね。ひげぽんの人徳ですな。

966 :デフォルトの名無しさん:02/12/12 00:25
だよねー。ひげぽんちゃんと頑張ってたし、適度に高度な話題だから、厨房が寄り付かなかったしね。

967 :デフォルトの名無しさん:02/12/12 20:34
上げないでね

968 :sage:02/12/12 22:23
sageつつ、埋め!

969 :デフォルトの名無しさん:02/12/12 23:34
本擦れ上げた方がいいんじゃない?とかいいつつ埋め!

970 :みとこ ◆AEqcy/sQU6 :02/12/13 21:14
ヽ(`ー´)ノ

971 :超先生@OS板 ◆leaf/RYZgY :02/12/13 21:16
|[Aqua+]|ー´>埋め立てるならイマノウチ

972 :超先生@OS板 ◆leaf/RYZgY :02/12/13 21:16
|[Aqua+]|ー´>埋め立てるならイマノウチ

973 :ひげぽん:02/12/13 21:24
( ゚д゚)

974 :デフォルトの名無しさん:02/12/13 23:24
ひげぽんさんだ!がんばって!! 埋め埋め埋め

975 :偽ひげぽん:02/12/14 07:04
埋めまくり(・∀・)

976 :うふぅ:02/12/15 01:29
ドキドキ・・・

977 :うふぅ:02/12/15 01:30
ドッキンキン

978 :うめ:02/12/15 03:15
うめまするぅ〜

979 :ひげぽん:02/12/15 11:12
┐(´∇`)┌本物

980 :デフォルトの名無しさん:02/12/15 21:04
うめ

981 :デフォルトの名無しさん:02/12/15 21:06
うっめ〜〜〜〜っ。

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

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

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)