やっと一段落

こんな夜中に更新するのは珍しいので、頭がもう眠いのもあってか、
言葉が変になると思う。

やっとプリエンプティブなマルチタスクを実現する事が出来た。
パソコンのタイマー割り込みを利用して微小時間ごとに実行するタスクを変えることにより、
同時に複数のタスクが動いているように見せかける手法です。

かなりセグメントには苦しめられています。
ポインタのポインタがどうだらこうたら…みたいなのが普通になっちゃっています。
これは私のプログラミングの経験というかセグメントの扱いが下手なのだと思います。

とりあえずなにができるようになったのか。

FDから起動し、ELFファイルを読み込んでプロセスとして起動し、また複数起動する事が出来、
そしてそれらをマルチタスクで実行することが出来るようになったのです。

さて、ここまできたら一休みしようと思っていたので、とりあえず飽きそうだから
一時中断して、技術解説的なページを作ろうと思います。

特にELFの資料に関しては、日本語がほとんど無いので、
基本的な部分だけでも私が説明すればかなり助かる人が多いのではないかと思うので。

さて、寝ます。んでは

苦労しただけ喜びがある

2、3日悩んだLDTが動作するようになった。
これで完全にELF形式のファイルの読み込みが可能となったわけである。

これからプリエンプティブなマルチタスクを構築するために、
タスクの状態を作成し、そして状態ごとにリスト構造で数珠繋ぎにし、
そして順番に時分割で動作させる。
これによりマルチタスクは動作する。

とりあえずここまで出来たら、OSとアプリとの通信の確立方法を学び、
通信を行えるようにしないといけない。
いや、通信でなくても良いが、OSの機能をアプリが利用できるようにするわけだ。

これにはゲートという概念とソフトウェア割り込みという概念、あるいはメッセージと言う概念を利用できる。

ゲートはOS側の関数を呼び出す方法、ソフトウェア割り込みは実際に割り込み処理により、機能を実現する。
大抵はレジスタに行いたい機能を格納し、割り込みを掛ける。
MS-DOSやLinuxなどは、この方式である。

さて、メッセージはWindowsでやり取りされている事は
Windowsプログラミングをかじった方なら知っているであろう。

どっちにしろメッセージの送信・受信にはOS側の関数を利用する必要があるだろう。
ここら辺は、CMagazineもヒントにしようと思うが、どこまで参考になるか…。

私的校正（１）

CMagazine2004年7月号に「オリジナルOSを作ろう！」と言う記事があり、
私もこれを見て買った一人です。

今現在OSらしきものを作っていることはこのブログで書いている通り。
CMagazineも参考にさせてもらっていますが、
私が参考にしようしようと思うと、どんどんと間違いが見つかり、
結局パソコンを破壊するような致命的なものは無いようだが、
これ普通動かないんじゃないの？的間違いが多々見つかってしまいました。

これは本来ならばCMagazine側が責任を持って校正すべき、訂正すべきなのだが、
Webサイトを見ても全くその気配が無い。いや、ソフトバンクが面倒なのかは不明だが、
本来金を貰う立場として、あるいは買ってもらう立場として、
訂正をしないのは如何なものか、墨染さんの記事を載せた責任だってあるはずだから、
記事の著者かソフトバンク側がどうにかすべき。

しかし行動を起こさないので、私が校正するしかない。
いや、私だけでは100%は無理なので、出来るだけ多くの方がやるべきなのかもしれないが。

まず校正を始める前に、この文章（実は全部は読んでいないが）の問題点がある。
やたらとネットワーク対応を好む。まるで簡単であるかのように書いてあるが
現実はそうではない事が分かっていない証拠である。

P30	table7　位置6	6ビット	Dビット	セグメントの種類を決める。0で16ビットセグメント、1で32ビットセグメントのことである。
P30	table7　位置6	7ビット	Gビット	0でリミットは1倍、1でリミットは4096倍（要は記事中で言えば「リミットの単位」を決める）

（上の訂正は「はじめて読む486」を基にしている。）

参考にしている図書一覧

以下の図書を参考にしています。

まずCPUの動作の原理などに関してはこれ。

はじめて読む486―32ビットコンピュータをやさしく語る

486というのは昔のCPUですが、基本的な原理は
今現在でも大きく変わっておりません。
よって、この本が役に立ちます。
32bitにおけるセグメント方式やページング、タスク切り替えなど
OSのためにCPUに搭載されている機能などの説明があります。

周辺機器の制御に関してはこれ。

パソコンのレガシィI/O活用大全―割り込みとDMAからシリアル/パラレル・ポート、FDD/IDEインターフェースまで (ハードウェアデザインシリーズ)

基本的に周辺機器の制御はout命令とin命令、
そして取得したデータなどのビット演算が中心となります。
この本は各デバイスを制御するためのI/Oアドレスとその意味を中心としています。
よって具体的にこれをこうやればこう動くよ、という易しい解説ではありません。
しかしFDCの詳細などが記載されている本は今現在あまり無いのでとても貴重だと思います。

そして実際にはあまり役に立たなかったが、一応使用したということで、
紹介しておくのが、「C Magazine 2004年7月号」です。
特集記事に「オリジナルOSを作ろう！」とありますが、
残念ながら内容はいい加減で、私が発見しただけでも
明らかなプログラミングミスや、記載の間違いなどがありました。
この記事の著者はあまり理解しないまま、とりあえず記事を書いたと言う事が、
バレバレでさらにコンパイルすらしていないことが、あり得ない間違いで分かりました。
何のためにこんな中途半端な記事を出したのかは分かりません。

後は学校でオペレーティングシステムの基礎の勉強をしていたので、
そこでスケジューリングなどの勉強はしました。
これはこれからちょうど私が作成する部分でもありますし、参考になります。

他人のことはこれで最後にします

昨日の日記は書き直しましたが、
本当に言いたかったことを書いてみる。
今後は私の事や考えを中心に書く事にする。
そこに他人の発表物を引き合いに出さない。
今後はこのブログは、完全に「私のOS作りの発表場」になる。

昨日書いていた事の題名を考えるなら「川合さんの本が与える影響について考えた」ってな感じです。

川合さんの本が初心者に分かりやすい。これは事実だと分かりました。
これによって今までアセンブリすら触った事の無い人でも、
アセンブリに慣れ、そしてC言語との連携が出来るようになる。

最初はバイナリエディタで直に機械語を打つという
現代ではまずあり得ない方式を取る事で、コンピュータの基礎的な部分から教え込む。
これは発想が面白いと感心しました。

私が問題だと思った事は、本に書いてあることから一歩出るときのこと。
私自身が経験してみた事、例えばELF形式の理解があります。
ELF形式のファイルに関しては確か川合さんの本には書いていないはずです。
（もし万が一書いているのなら、PE形式でもとりあえず良いと考えます。）

ELFの仕様に関して私はネットで色々と検索を掛けてみましたが、
その根本的な原理を分かりやすく書いているページは無く、
仕様書は英語だったので、理解するのは大変でした。
日本語のWebページであっても、ダンプリストはこうなる程度だったと記憶しています。

さて公開されているKさん本を、改めて読んでみましたが、確かに読みやすい。
説明的に書いているから、そして一つ一つ丁寧に解説しているから。
（以前の私の主張とは違っているかもしれませんが、こちらが今の意見です。）

だから読者は書いてある事に関しては当然理解できるわけですよね。
そして一歩先へ出たいと思いますよね。

Kさんの本はアセンブリの何たるかから、分かりやすく解説をしてくれています。
アセンブリ言語の解説本でさえ、ここまで丁寧に解説している事は少ないのではないかと思います。
公開されているページを読めばそれは分かると思います。

さて逆に今までOSが盛んに作られなかった理由を考えて欲しいのです。
つまりKさんの本以外の本やネット上の資料などはかなり敷居が高かったことを意味しているはずです。
一つ一つ勉強していけば理解出来るものなはずですが。
（それは私がKさんの本無しで、今現在でも多少の問題がありながらも、一応OSの開発を続けられていることから、
不可能ではない事は分かって頂けるはずです。）

資料が乏しい、あっても言葉が難しい等それなりの理由がなければ、
OS作成という分野に進出する人はたくさん居たはずです。

Kさんの本を読むことでアセンブリから、簡単なOSの作成まで初心者でも理解しています。
これはKさんが深く考えた文章の書き方が実った事を意味するのでしょう。
しかし、そこから一歩出ようとしたときに、当然他の資料もKさんが書いていればいいわけですが、
現実的にそうはいきませんよね。

もしもELFの仕様をKさんが書き直せば、皆苦しまないで理解できるわけですよね。
でも現実はそんな理想郷ではなく、堅苦しい言葉、難しい言葉で塗り固められた世界ですよ。

Kさんの考えとしては、この本をキッカケにさらに勉強してくれる方、
当然この難しい言葉の壁を乗り越えてくれる方が数百人に一人でも居てくれたら嬉しいと思っているでしょう。

これは正しくて、Kさんの本が無ければそこまで到達できなかった人が、
成長できるわけですから、Kさんの本は役に立ったわけです。

ここまで到達できなくても、アセンブリの理解やコンピュータの原理を学べるはずですから、
（BIOSなんて知らなかった人でも知ることが出来る事なども含めます。）
この本は役に立ったと考える事が正しい。

めでたしめでたし…が一番理想なのですが、
このネット社会ですから、Kさんもネット上でサポートをしていらっしゃいますが、
そこで「あれこれはどうやる？」、「教えろよ、著者。」と言う話が出てくると、
Kさんが大変じゃないのだろうかと思ったわけですよ。

本でOS作りの基礎を学ばせて、後は自分で問題解決をしていくことで、
独自色の出る、そしてKさんが作っているOSを超えるものが生まれてくることを、
Kさんとしては望んでいたのではないかと考えたのです。
つまり上に書いた著者への解説要望はKさんが全く望まなかった事なのではないかと思いました。

Kさんが「数打てばいくらかは当たる」という考えで本を書いたというのであれば、私の心配はあまり意味が無いです。

もし皆乗り越えられると思っているのなら、「大丈夫だろうか？」という疑問があったのです。
本当にKさんの本以外の本は言葉が難しいから、
Kさんの甘い声(？)が無くなった環境へ対応できるのだろうかという疑問があったわけです。

ソフトウェア産業に悪影響的なことも書きましたが、
Kさんの本を読んである一定の領域まで達してさらにその殻を破る事が出来る人、
そして最初からいばらの道を進んでいき挫折せずに理解を進めていく人、
この二者を私の勝手な都合で比較してしまいました。

以上が言いたかったことです。前日の主張と変わっていますが、
前日のに記している「車輪の再発明」の
ブラックボックスと無理やり同列に扱い、結論付けてしまったことで、
結果的に変な主張となってしまいました。

ソフトウェア産業への悪影響に関しては、
比較対象自体が比較できるものではないのに比較してしまったので
結果的に訳が分からなくなってしまったと結論付けました。

環境への対応に関しては私自身で改めて考えて出した答えは、
「それまでならばそれまでの人なのだろうし、上で書いたように、
今まで知らなかった事柄を学べた事は4000円という価値があるのであろう。」

ということです。自分で書いている文章に自分で結論をつけるのは変ですが、
もともと変な人間なので、そこら辺はよろしくです。

この文章を書いたのは、これ以上他人の事柄について扱うのは止めるためです。
中途半端に書いておいて消したのはどうも頂けないと思い、
最後に本当の主張を書きたかったので、書きました。
個人攻撃ではなく、本当は心配という意味合いが大きかった訳です。
過激になりすぎた部分があったのは深く反省すべき事ですので、反省します。
「言葉は難しいなぁ」とまた一つ思いました。

「車輪の再発明」

プログラミングに関する用語では、車輪の再発明という言葉があります。

C++のお蔭でソースコードの再利用が進んでいますが、
ブラックボックスのまま利用しているわけで、実はこれは恐ろしいことだと気づいていないわけです。
ブラックボックスで塗り固められたソフトウェア、もしそのブラックボックスから煙が出てきたらどうしますか？
貴方は中身が何で動いているのか分かりません。
水を掛ける事が正しいとは言い切れません。消火器も普通の消火器でよいか分からないのです。
なぜなら中身は油が原料かもしれないし、電気かもしれない。
いや水素かもしれません。

これをプログラミングに置きかえれば、ブラックボックスを信用したばかりに、
システムがダウンする可能性があるわけです。
エンジニアはその原因を探りますが、
その原因がブラックボックス内にあると分かったところで、
まずそのブラックボックスの理解という作業が必要になり、
結局ブラックボックスの理解に時間を費やす事になります。
その結果、得意先に多大なる迷惑、損害をこうむらせる可能性が高いわけです。

私は車輪の再発明はじゃんじゃんやるべきだと思います。
車輪を作れないと、つまり車輪の構造を知らないと、欠点も分からない。
欠点が分かれば、その欠点を踏まえた新しい車輪が作れるはずです。

車輪すら作れない人が車輪に文句を言う。これも現実社会では普通です。
「Mona」というOSを作っているひげぽん氏も最初はそう言われていましたね。
私は何を言われても趣味だし、車輪の再発明ほど楽しいものはないという考えですので、
全く痛くも痒くもありません。

（ここからは上とは完全に無関係ですよ。）

ELF形式のファイル、今までブラックボックスだったのが、
自分でメモリにロードして動いたときは、脳みそが「ブルブルブルブル」って震えましたよ。
久しぶりにプログラミングの楽しさを見つけました。
別に本に書いてあるモノをそのまま書いた訳ではなく、
英語のELF仕様が書かれたPDFファイルを読んで勉強しました。
だから凄く嬉しかったです。

ELF形式のファイル読み込みと実行に成功しますた

はい、タイトル通り成功しますたよ。
とは言っても、まだ完全な対応ではありません。
スタティックな変数のための領域に関しては未実装だからです。
とは言ってもプログラムヘッダーを見れば大体分かるわけで、すぐに実装できます。
とりあえず必要性が出てくるまで置いておこうと思いますが。

画像中で動いているのはベタバイナリなので、意味合いが違います。
ELF形式が動くということは、いちいちバイナリに変換する必要性がありませんから。
まぁあまり意味が無いと言えば意味がないのかも知れませんねぇ。

でも凄く嬉しいです。
とりあえずapp.elfとapp2.elfを読み込んでTSSで相互にやりとり。
これは画像中、つまりELF関係なしに出来ていたんだけど、
正直凄く嬉しいな。

ちなみに今現在のカーネルのメイン関数を晒してみる。
メインはたったこれだけです。まぁその他の関数が膨大にあるわけです。
今のところ書いたソースはアセンブリ含めて3000行ってところかなぁ。
1万行はまだまだ先ですなぁ。

ちなみにこの前の書きましたが、asm("")の中では、
セグメント間ジャンプ（セグメントをまたいだジャンプ）をするための命令を
機械語そのまま書いているわけです。

実はセグメント間ジャンプを行う命令がC言語には無く、
実際にはアセンブリ言語で書くべきですが、
今はテストと言う事で機械語そのまま書いているわけです。
farジャンプと言いますが、
いつまでも機械語では書かず、当然そのうち実装しますよ。

void os_main(){

	char *string = "Hello. This is a VIP OS.\n";
	unsigned char *dst[64];

	InitGDT();
	Cls();
	print(string);

	DisableInterrupt();
	InitPIC();
	InitIDT();
	EnableInterrupt();

	SetTSS( (TSS*)0x600000, 0x30, 0x38, (unsigned char*)0x000000, 0x200, 0xffff,0x40, 0, 0x18);
	SetGDT(0x100, 0x600000, sizeof(TSS), ( 0x80 | SObject | DPL0 | TSS32bit));
	SetTSS( (TSS*)0x600200, 0x48, 0x50, (unsigned char*)0x000000, 0x200, 0xffff,0x58, 0, 0x18);
	SetGDT(0x108, 0x600200, sizeof(TSS), ( 0x80 | SObject | DPL0 | TSS32bit));

	//テストタスクの読み込みとジャンプ
	strcpy(dst, "/app.elf");
	ELFRead(dst, (unsigned char*)0x400000);
	strcpy(dst, "/app2.elf");
	ELFRead(dst, (unsigned char*)0x800000);

	asm(".byte 0xea, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01");

	while(1){
	}

}