起動するまでの長い道のり メモリ管理編(2) メモリ・マップ取得の巻 - Outlandish Watch
ページングのことを書こうかと思ったが、まずマシンに何MBのメモリが搭載されているのか分からないと始まらない。それに、実はメモリ領域にも使えるところと使えないところがある。そういった情報も必要だ。 今回は、ACPIのファンクションを使ってメモリの領域情報を得る方法について解説する。 今回のソース setup.s memorymap.d startup.d メモリ量を得るには メモリがいくつ搭載されているか調べるには、またまたBIOSファンクションを使わなければならない。BIOSファンクションを使わないで調べる方法もあるらしいけど私は良く知らない。 メモリ量を調べるBIOSファンクションにも何種類かある。まずint 12hというファンクションがある。これを使うとKB単位でメモリ量が分かる。ただ、16ビットの数値で返ってくるので最大で64K*1K=64Mバイトまでしか分からない。いまどき64MB
起動するまでの長い道のり メモリ管理編(1) ページング概要の巻 - Outlandish Watch
またしても再開……。 さて、D言語が普通に動かせるようになった。scope指定をすればクラス・オブジェクトも作れるようになった。 が、まだ動的なメモリ確保やオブジェクト作成ができない。もっと言えば、実行時にサイズが初めて確定するようなデータのメモリ領域を確保できない。 動的なメモリ確保を行うためには、メモリ領域を色々と管理しなければならない。どの領域がどのくらい空いているのか、あるいは使われているのか、常に把握しておく必要がある。 これから、とりあえずカーネル・モードでのメモリ管理について解説する。 ページングについて ページングとは、メモリ管理の方法の一つだ。 少し前にセグメンテーションというメモリを分割する機能のことを説明した。ページングも同じようにメモリを分割する。ただ、ページングではメモリを固定サイズのページに区切る。具体的に言うと4KBで区切る(実は4MBでも区切れたりするが割愛
起動するまでの長い道のり D言語編(4) 標準ライブラリ格闘の巻(2) - Outlandish Watch
色々あったがようやく再開……。 さて前回で大量のリンク・エラーという壁にぶち当たった。そして、標準ライブラリを移植する必要があると分かった。 今回は、ビルドを通すためにどこをどう移植したかを説明する。はっきりいって不毛なので、読み飛ばしてソースコードだけ取得した方がいいかもしれない……。 標準ライブラリのソースはどこにあるか。 まずは移植元のソースがないと始まらない。CygwinでGDCをインストールした人の場合は、include/d/X.X.Xの配下にあるだろう(Xは数字)。私のようにちゃんとGCCも含めてソースコードからビルドした偉い人なら、GCCのソースディレクトリのgcc/d/phobos内にもある。 必要なソースを見極める。 前回で、標準ライブラリのうち動的型情報を含む最小限の部分だけ実装すると決めた。ではその最小限の部分って具体的にどこなのか。リンク・エラーが発生した関数を調べ
渋滞情報 - Outlandish Watch
実は先の方が詰まっていて更新が滞っています……。 標準ライブラリ移植は実際ソースもあるし、さらに言えばコピペばっかりで特に書くようなことをしてないし（爆）、どうでもいいのですが、実はこの先にページング・メモリ管理・割り込み処理が待ち受けていて、そちらの実装に手間取っているのです……。 ひみつプロジェクトの〆切もあるし、しばらく更新が滞るかもしれません。まあまっさらな状態でD言語を動かすだけならもうソースもあるし、今の状態でもきっと遊べます。私なんかよりうまい実装をしてもらえるかもしれない（笑）。 さらに問題なのがD言語のバージョン2.0が出てしまったことだったりします（滝汗）。
起動するまでの長い道のり D言語編(3) 標準ライブラリ格闘の巻(1) - Outlandish Watch
D言語を使って(あれを「使って」と言って良いなら……)、シリアル・ポートを叩くことに成功した。 しかし今のコードはカッコ悪い。IOを直に叩いているだけで、printfでHello,World!するのとあまり変わらない。これから先シリアル・ポートを叩く機会もたくさんあるだろうから、シリアル・ポート操作用の処理をまとめておきたい。今回はそれにチャレンジし、壁にぶちあたる(笑)。 今回のソース startup.d serial.d シリアル・ポート・クラスの作成 さて、シリアル・ポートの処理をまとめる。しかもオブジェクト指向らしくクラスでラップする。ポート番号をメンバ変数に持ち、初期化はコンストラクタ・入出力や待機処理はメンバ関数で行わせる。定数は全部enumで定義する。 で、大体以下のようになった。 module outlandish.os.serial; import std.stdint;
起動するまでの長い道のり D言語編(2) それとなくシリアル・ポートの巻 - Outlandish Watch
D言語の関数を呼び出すことに成功した。これからどんどんD言語で機能を追加していく。 OSを作っている以上、外部デバイスをいじれないとつまらない。画面表示や何かに動いているという証が欲しい。今回は、割合制御が簡単なシリアル・ポートに文字列を出力させてみる。シリアル・ポートの出力ならqemuからも簡単に見られたりする。 今回のソース startup.d io.d IO関数の用意 シリアル・ポートはIOポートを叩くことによって制御する。IOポートはアセンブラの命令で叩くことができる。が、D言語の世界に既に移行してしまったので、できればD言語の関数でIOポートを叩けるようにしたい。今後もIOを操作する機会は多いだろうから、アセンブラ命令を単純にラップした関数を用意しておく。 実はD言語の標準ライブラリ(Phobos)には、IOポートを叩くための関数が用意されている。しかし、OSを作るに当たって標準
起動するまでの長い道のり D言語編(1) 関数呼び出しの巻 - Outlandish Watch
不完全ながらプロテクト・モードに移行し、通常の32ビットコードを使う準備ができた。ここでいよいよD言語を導入していくことにする。 モジュール階層の準備 D言語のソース・ファイルをこれから追加していくわけだが、そのためにモジュール階層をまず用意することにする。モジュールとは、Javaで言うパッケージとほとんど同じものだ。ファイルパスでx/y/z.dというソースファイルは、モジュールで言うとx.y.zに属することになる。1ソースファイルが1モジュールとなる。で、x.y.zというモジュール階層を作る場合はxとyディレクトリを掘らなければならない。 ここではoutlandish.os以下に各ソース・ファイルを置くことにした。つまり各ソースファイルはoutlandish.os.XXXというモジュールを作ることになる。というわけで、outlandish/osディレクトリを掘る。 ソースコードの追加 と
起動するまでの長い道のり プロテクト・モード移行編(1) セグメンテーション薀蓄の巻 - Outlandish Watch
プロテクト・モードへの移行は起動処理の山場の一つだ。リアル・モードからプロテクト・モードに移って初めて32ビットのコードが動き、64KBの壁を破って4GBまでの全メモリにアクセスできるようになる。 x86系CPUでプロテクト・モードに移行するには、最低限セグメンテーションと割り込みディスクリプタテーブルを初期化する必要がある。だが、割り込みを禁止した状態ならばとりあえずセグメンテーションさえ設定すれば大丈夫だ。 今回は、プロテクト・モードにおけるセグメンテーションについて解説しようと思う。 プロテクト・モードにおけるセグメンテーション プロテクト・モードのセグメンテーションは、リアル・モードのそれと何が違うか。本当に違う。まったく違う。別物なんじゃないかと思うくらい違う。実際に別物だ。 リアル・モード時にはぶっちゃけ64KBの壁をどうにか超えるためのオフセットに過ぎなかった。ある意味後ろ向
帰還 - Outlandish Watch
というわけで明日から更新再開します。 ソースコードとかをsourceforgeプロジェクトにアップするかもしれません。きっとライセンスはNYSLでD言語で普通のOSを実装していくと思います。D言語ってOS書くための言語なんだね！ という誤解を広めたいです（爆）。 実は普通でないOSの構想も別にあるのです。フフフフフフ……。
起動するまでの長い道のり IPL編(9) ビルド環境makeの巻 - Outlandish Watch
512バイトの制限を超えてカーネルの読み込みができるところまでをやった。これからソースファイルがどんどん増えていくと、ビルドがかなりめんどくさくなる。そこで今回は、makeを使った一括ビルドの方法を解説しようと思う。 makeについて makeとは、UNIX系OSのプログラミング環境で使われる一括ビルドのためのツールだ。一般にMakefileと呼ばれる設定ファイルにビルド方法を書いておくと、後はそのMakefileがあるディレクトリでmakeを実行するだけで自動的にビルドが行われる。あるソースコードが変更された場合、そのソースだけがコンパイルされ直して後は再リンクされるだけ、といったスマートなこともやってくれたりする。 makeは、うまく使うとプログラムのビルド以外にもWebの更新や日常のバックアップやファイアーウォールのルール変更やその他色々なことに活用できる。IDE全盛の昨今ではいささ
起動するまでの長い道のり IPL編(8) カーネル読み込み実装の巻 - Outlandish Watch
前回でディスクからのデータ読み込み方法と、その時にぶつかる壁について解説した。今回はいよいよデータの読み込み処理を実装していく。 ソースファイルを追加する さて、読み込み処理を書くに当たって読み込むデータ(プログラム)が何か無いと始まらない。今までコードは全てipl.sという1つのソースファイルに書いていた。これに加えて、setup.sというソースファイルを別に用意する。この後機能拡張をしていくときは、ipl.sではなくsetup.sの方にコードを追加していく。因みに、わざわざsetupなんて名前にしたのは、今後ここに色々な初期化処理を書くよという布石だ。 とりあえず最初は無限ループで止まるようにしておけばいいだろう。 # setup.s .code16 begin: jmp begin リンカスクリプトを書く setup.oは、今まで書いたIPLのすぐ後ろに追加したい。そのためには、リン
起動するまでの長い道のり IPL編(7) カーネル読み込みの巻 - Outlandish Watch
実は、今まで黙っていたが、起動時のIPLはディスク先頭の512バイト＝1セクタしか読み込まれない。1セクタだけだからブートセクタなんて言うのだ。 言うのだ、なんて威張っても仕方ない。OSのカーネルがまさか512バイトに納まるわけはないので、残りの部分をディスクから読み込まなければならない。そのためにはまずカーネルのサイズを知り、そしてディスクからメモリの適切なアドレスへ読み込む必要がある。 カーネルをどこに置くか考える リアルモードの制限により、メモリは下位1MBまでしか使えない。しかも、連続してアクセスできるのは64KBまでだ。しかもその1MBの中には、いくつも予約されている領域が存在する。前回に出てきた割り込みハンドラテーブルもその一つだし、BIOSファンクションのコードがある場所やBIOS作業領域、VRAMにマップされている領域などなどがある。それらをかいくぐってカーネルが置ける場所
起動するまでの長い道のり IPL編(5) CPU解説の巻 - Outlandish Watch
前回まで実際のソースコードを元に不器用に説明したけど、いい加減CPUの説明抜きで話を進めるのが非常に辛いと分かったので、必要最低限解説しておこうと思う。 メモリ・レジスタ関連 メモリ・レジスタ 一般的なCPUには全てメモリとレジスタがある。メモリは言うまでもなくデータやプログラムを置く記憶領域で、レジスタは以前説明したとおり作業用の「手」だ。メモリから取り出した値を持ったり、値を加工するために持ったりする。非常に小さく、ほとんど1〜4バイトしかない。また、計算や処理には使わない実行制御用の特殊なレジスタもたくさん存在する。 プログラムカウンタ CPUはメモリに置かれたプログラムのコードを順次実行していく。そのために、メモリ上のどの命令を現在実行しているのかを覚えていなければならない。CPUにはそのための専用のレジスタがあり、プログラムカウンタと呼ばれる。486やPentiumなどのいわゆる
起動するまでの長い道のり IPL編(3) アセンブラ解説の巻 - Outlandish Watch
ひたすら打つべし！ 打つべし！ だったアセンブラのソースについていい加減解説する。 ディレクティブ・コメント ここについて説明する。 # ipl.s # generate real mode code .code16 「#」で始まる行はコメントだ。「#」から行の終りまでがコメントと見なされる。 「.code16」は、16ビットの実行コードを生成するよう指示するためのディレクティブ(指示語)だ。前に解説したとおり、起動直後のマシンは16ビットのリアルモードで動いている。その状態で実行できるコードを生成させるために、このディレクティブは必要となる。 ジャンプ・空の命令 ここについて説明する。 jmp begin nop # 中略 # boot begin begin: マシン起動時、最初にこのjmp命令が実行される。(先述の.code16はアセンブラに指示を与えるディレクティブなので実行コード
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
