同書をmacOSにて開発した際のソースコード。
下のイメージはは30日目終了時の記念撮影。エミュレータ実行のため、vram(シート)に少し異常あり。(基本動作に問題はない)
8日目までの開発は、Qittaに投稿されている『30日でできる！OS自作入門』を macOS Catalina で実行するを参照。9日目以降は著者ソースコードを参照。
(余程のミスをしない限り)コードに問題があっても、コンパイラが親切にエラーを出力してくれる。Haribote OSが壊れる、開発PCがフリーズするということはない。
- あくまで私的利用目的
- 2セクション分を1つのプロジェクトとして一括作業している部分あり
- 該当セクション終了後にミスを発見・訂正している部分あり。該当セクション時点での簡単なOS動作確認上の不具合は確認されなかった。(下記除く)
- 多くのコメントを割愛。残したコメントは想定外の文字化けを避けるため英語
- コメントは
//を優先利用 - 途中で細かな記述方法の変更あり
- PC: MacBook Pro 13-inch 2017
- OS: macOS Catalina 10.15.7
- コンパイラ: GCC(i386-elf-gcc) 9.2.0, NASM 2.15.05
- イメージ作成: mformat 4.0.25, mcopy 4.0.25
- エミュレータ: QEMU 5.1.0
- エディタ: Visual Studio Code 1.51 (何でも良いと思うが、UTF-8標準設定のものが無難)
Homebrewから各ソフトウェアをインストールする際、最新のXcodeが必要。最新版Xcodeでは、ターミナルからXcode Command Line Toolのインストールができなくなっており、Apple開発者サイト経由ですることになる。
2020年11月時点で既にCatalinaのアップデートmacOS Big Sur 11が公開されており、加えてアップル独自開発CPUM1搭載のPCも流通している。Big Surでも、(Intel Core ix系搭載のPCであれば、)必要なソフトウェア(GCC, NASM, QEMU, etc.)のインストール・動作ができれば、開発を進められそうである。
問題memory 128MBと表示される。
対応
エミュレータが自動で割り当てるメモリー量だと解釈。プログラム・OS自体に問題はないと判断し、無視して開発を継続。
問題HariMain()内for(;;)直下にシートを更新するプログラムが無いと、動作が遅くなる。PIC/PITもしくはCPUクロック数に原因があると推測される。
対応
10秒後ではなく、カウンタ数を常に表示。動作上の意味は無いが10秒後にカウンタ数を表示するプログラムは残してある。尚、この問題はharib11fで高速カウンタを消去し、if文内のio_sti()をio_stihlt()に戻した段階で自然解決される。
void HariMain(void) {
…
for (;;) {
count++；
// このあたり
}
}問題asmhead.nasに指定の画面モードをするも、黒い画面が表示されるのみ。コンパイル時のエラーはなし。
対応
harib11eのVBE設定プログラム導入で自然解決される。特に意味はないが、解像度は0x101を利用して開発を進めた。
問題task_b_main内for(;;)直下にシートを更新するプログラムが無いと、動作が遅くなる。harib10c~harib11eと類似した問題。
対応
前回同様、カウンタを常に表示。(if (fifo32_status(&fifo) == 0))内のio_sti()をio_stihlt()としてもスムーズな動作はするが、前者と比べてカウントスピードは約1/50になる。
問題task_b_main内for(;;)直下にシートを更新するプログラムが無いと、動作が遅くなる。前項同様の問題。
対応
前項同様、カウンタを常に表示。この問題もharib14bでカウンタを削除した段階で自動解決される。
問題<string.h>がincludeできず、strcmpが使えない。
対応sprintfに倣い、関数を自作。新たにmyfunction.cを作成し、同ファイルに関数を記述。新規関数・ファイル追加に伴いbootpack.hとMakefileに追加記述を施す。strcmpのプログラムはAppleのオープンソースサイトで公開されている。
問題strncmpが使えない。
対応strcmp同様、myfunction.cに関数自作。bootpack.hに関数定義も追加。参照: Appleのオープンソースサイト。
問題asm_cons_putcharの番地が本記載のものと異なる。
対応Makefile内bootpack.hrbを生成するコマンドに-Xlinker -Map=bootpack.mapオプションを追加し、マップファイルを生成。bootpack.mapに記載されているasm_cons_putcharの番地を調べ、その値をhlt.nas内be3値と入れ替える。ちなみに自分が実行した際の番地は、c64であった。この値を使用してharib17cを実行した際、正常に「A」が表示された。よくわかない場合、harib17eまでスキップすれば、番地を調べることなく、プログラムを実行できるようになる。
問題a.hrbとhello3.hrbの生成。
対応
『30日でできる！OS自作入門』のメモを参照。「アプリケーション用リンカスクリプト」をapp.ldとして保存し、a.hrb、hello3.hrb生成時に、これをリンカスクリプトとして利用。リンカスクリプトについては自分も未理解。
問題Shift + F1を押しただけでは強制終了しない。(0x3dが入力されない。)
対応
Macのキーボード設計による問題。Shift + fn + F1で強制終了できる。
問題rand()が使えない。
対応stars.c内にStack Overflowを参照してrand()を実装。結果的に同書と同じ星が配置された。
問題F11はmacOSにより既にリザーブされている。
対応F11の代わりにF11(0x58)を使用する。
問題noodle.hrb生成時、以下のエラーが発生される。
/usr/local/Cellar/i386-elf-gcc/9.2.0/lib/gcc/i386-elf/9.2.0/../../../../i386-elf/bin/ld: section .data VMA [0000000000000400,000000000000040f] overlaps section .text VMA [0000000000000030,000000000000048f]
collect2: error: ld returned 1 exit status
make: *** [noodle.hrb] Error 1
対応
良くわからないが、.dataの一部が.textの番地に書き込みされようとしているのが原因。app.ldをapp2.ldとして複製し、0x0400を0x0500と書き換えるとコンパイルに成功した。(.textの終了番地が0x48fのためそれより大きい値を代入。)
尚、この時自身のソースコードtimer.c:72に不要なコード(if (t == 0) { break; })があることを発見し、この行を削除。この行を削除しないとタイマーのカウントは1秒で止まる。加えてこの行を削除することにより、アプリ実行後task_aのウィンドウに戻るとカーソルが点滅しなくなる不具合も解決された。
問題
キーボード入力の条件判定if (s[0] != 0)でBackspace、Enterの入力も&key_win->task->fifoへ送信くれるはずだが、うまく送信されない。(BackspaceおよびEnterが効かない)
対応harib22hまでのBackspace、Enter用条件判定を残し、その中でfifo32_put()を実行する。
問題
著者開発のobj2bimが使えないため、無駄なファイルとのリンクを解けない。
対応
結果的にharib24dよりもファイルサイズが大きくなるが、無視して継続。
問題
著者開発のライブラリアンgolib00が使えないため、ライブラリを作れない。
対応
GNUのアーカイブユーティリティarを使う。Haribote OSでは、macOS標準のarが使用できないため、elf用i386-elf-ar(386-elf-binutilsの一つ)を使う。harib24eと比較し、アプリのファイルサイズが大幅に小さくなった。ライブラリを含めてコンパイルした際、GCCが勝手に必要な関数のみを読み込んでくれたと推測している。
余談であるが、アプリファイル生成の際、GCC実行時
-fno-builtinと-gのオプションを外しても正常にコンパイルできた。
問題
使用ソフトウェアが(10年以上前の)Windowsでの開発と異なるため、Makefileが記述が異なる。
対応
詳しくは該当ディレクトリの各Makefileを参照。
問題haribote/mysprintfはアプリ(noodle.hrb, sosu.hrb, etc.)でも使われる。
対応
27日目の学習でライブラリに詳しくなったため、sprintf, strcmp, strncmpをライブラリとして書き出す。新規作成、修正したファイルは以下の通り。必要なくなったファイルは削除している。
# 新規
.
├── lib
│ └── Makefile, sprintf.c, strcmp.c, strncmp.c # `[sprintf.c] => libstdio.a`、`[strcmp.c, strncmp.c] => libstring.a`
└── include
└── stdio.h, string.h
# 修正
.
├── Makefile
├── app.ld # Change: 0x400 -> 0x500
├── app_make.txt
├── haribote
│ └── Makefile, bootpack.h
└── noodle
└── noodle.c問題__allocaが自動で呼び出されない。
対応
アプリ用リンカスクリプトにアプリ毎スタックサイズを指定できるようにapp_make.txtとapp.ldを変更。
…
ifndef STACK
STACK = 0x500
endif
…
$(APP).hrb : …
… -Wl,'--defsym=__stack=$(STACK)'
……
SECTIONS
{
.head 0x0 : {
…
LONG(__stack)
}
…
.data __stack : …
…
sosu2/MakefileにSTACK = 0x2800、winhelo/Makefile, winhelo/MakefileにSTACK = 0x2000を追加。(10000=0x2710, 150*50=0x1D4C。)このままでもプログラムは動作するが、指定スタックサイズが必要なメモリサイズより小さい場合にアプリを実行するとOSがフリーズし、強制終了(Shift+fn+F1)もできなくなる。原因は不明だがallocaを使用してバッファを確保すると、アプリプログラムは実行されないものの、強制終了はできるようになった。(apilib.hへのalloca関数定義を忘れずに。)
// sosu2.c
char *flag = alloca(MAX);
// winhelo.c, winhelo2
char *buf = alloca(150 * 50);問題
全てのファイルはShift JISではなくUTF-8でエンコードされているため、type ipl10.nasを実行しても文字化け表示される。
対応
無視。
問題chklang実行、本記載のバグ(右半分しか表示されない)が発生しない。
対応
無視。
問題
(1) memcmpが使えない。(2) setjmp.hが存在しない、setjmp、longjmpが読み出せない。
対応
(1)lib/memcmp.cを作成。内容は著者ソースファイルomake/tolsrc/go_0023s/golibc/memcmp.cを参照。この関数をlibstring.aとしてライブラリ化。include/string.hも併せて更新。
(2) include/setjmp.hを作成、typedef int jmp_buf[3];を記述し、tek.cから読み込む。tek.cでは、setjmp、longjmpの代わりに__builtin_setjmp、__builtin_longjmpを使う。
なおアプリ(.hrb)は著者作成のプログラムを使用してのtek圧縮ができないため、アプリは一切圧縮せず開発継続。
問題sprintf()で桁数指定(%08d)ができず、(画面表示上での)スコアの上昇がおかしい。
対応
無視。この問題はharib27eでsetdec8を導入することにより自動解決される。
問題
(1) strtolが使えない。 (2) |が入力できない。
対応
(1) 著者ソースコード(omake/tolsrc/go_0023s/golibc/strtol.c)を参照し、strtol.c、strtoul0.cを作成。libstdlib.aとして書き出し、コンパイル時にアプリとリンク。strtolに必要なerrno.h、limits.hも併せて作成。
(2) 無視。
問題
音がならない。
対応qemu-system-i386に-soundhw pcspkを加えてエミュレートした結果、正常に音がでた。しかし、warning: '-soundhw pcspk' is deprecated, please set a backend using '-machine pcspk-audiodev=<name>' insteadの警告を受ける。-machine pcspk-audiodevに渡すべき<name>がわからなかったため、そのまま-soundhw pcspkを使用することに。
音楽ファイルは圧縮したものを著者ソースコードより複製。圧縮前ファイルについては、UTF-8変更したものを保存。
問題bmp.nasmを流用できない。(jpeg.cはほぼそのままで利用できる。)
対応bmp.nasmを適当なディレクトリへ複製。ファイル内の文字化け部分を全削除。最初の方に文字化けを含む%if 0…%endifブロックも削除。iconv -f US-ASCII -t UTF-8 bmp.nasm > bmp.nasを実行してUTF-8形式に変換し、gview下へ移動。[BITS 32]、関数接頭字_を削除。.bpp4内の.do4.1ラベル宣言でコロンが抜けているので.do4.1:と修正。
jpeg.cはUTF-8形式としてファイルをした後、著者ソースコードをコピー&ペースト。文字化けは鬱陶しいので、その部分は削除。コンパイル時jpeg_decode_yuvがintを返さないと警告を受けるので、同関数のreturn;をコメントアウト。
問題
シリンダ読み込み数。
対応
各バイナリファイルは、本記載のものよりサイズが大きくなる傾向にあり、且アプリの圧縮も行えない。setdec8導入後、バイナリエディタ(Hex Fiend)を使ってharibote.imgの中身が何バイトまで使用されているか調べると0x02BAA0であった。結果、シリンダ数: 0x02BAA0 / 18432 = 178848 / 18432 = 9、余り: 0x02BAA0 % 18432 = 178848 % 18432 = 12960(13k)となる。圧縮なしで13kを節約するのは無理と判断。10シリンダを読み込む形でipl9.nas => ipl10.nasとした。