理科とコンピューターを好む。
ちなみに(理科>コンピューター)である。
しかしOSと理科のどちらをより好むかは未定義である(おい)。
ゆえに、制作中のOSの名前がCHNOSProjectになりました。
CHNOSProject (案)
実現までの道はまだまだ遠いですが、よろしくお願いします。
更新は、主にsourceforge.jpで行うので、たまに見に行ってもらえると嬉しいです。
エミュレーターは便利です。そして素晴らしいソフトウエアだと思います。
しかし、やはり実機や仕様と挙動が異なる場合が多々あるようです。
そして時にそれは、開発者達を惑わせます。
デバッグ例外は、CPUに用意された便利で強力な機能の一つです。
指定されたアドレスのコードを実行したり、またはデータとして読み書きを行ったり、はたまたIOポートとしてアクセスしたときに、例外を起こしてくれます。
これは、メモリがいつの間にか破壊されていた!という心霊現象のようなバグを解決するために非常に有効です。
#ええ、そうですとも。まさかメモリ管理システムがメモリを破壊していたなんて、思い至りませんでしたよ(涙)。
…ということで、その素晴らしい機能を使ってデバッグしようとしていたのですが…。
いきなりこの関門にぶち当たってしまいました。
どうやら検索したところ、QEMUはKQEMUという高速化モジュールをインストールしなければデバッグ例外が使えないようです。
Bochsに関しては、「エミュレーション速度は遅いけれど例外の報告は正確だから!」ということで重宝していたのですが、動きませんでした。
もしかすると、自分の設定ミスかと思い、VirtualPC2007で実行してみました。
すると…出ました。デバッグ例外。
これで一安心、と思いきや、次なる関門が待ち受けていました。
今回は、ある特定のアドレスにアクセスした命令をすべてリストアップしたかったので、ブレークポイント例外が発生しても、情報を確認後、実行を再開させたかったのです。
ということで、「紙に印刷したらきっと分厚い」IA-32 インテル® アーキテクチャソフトウェア・デベロッパーズ・マニュアルを参照して、例外ハンドラーを実装しました。
このマニュアルが言うには、私が今求めている、指定アドレスへの書き込みに対するブレークポイント例外が発生した時、
「プロセッサは、このアクセスを行った命令を実行した後に例外を発生する。したがって、これらのブレークポイント条件によってトラップクラスの例外が発生する。」
「トラップの場合-レジスタCSとEIP にセーブされている内容は、その例外を生成した命令の次の命令を指す。」
つまり、単純にIRETDすれば、実行を再開できるはずだったのです。
しかし…VirtualPC2007は
「例外を発生させた命令自体を指すEIP」
を保存していたのです…。
なるほど、だからあんなに繰り返しシリアル出力にデバッグ例外の発生が記録されていたのか。
これでやっと、メモリを破壊していた犯人が…え?Memory_Allocate関数?
ということで、結末は先にお話しした通りです。
…そもそもバグのあるコードを書いた私がいけないんですけどね…。
ということで、めでたし、めでたし。
hankaku.txtに、半角カタカナを追加しました。きっと作るのは面倒だし、はりぼて系のOSでは使えると思うので、ぜひ使ってください。
http://keihanna.dl.sourceforge.jp/chnosproject/45774/hankaku.txt
*右クリックして、「対象をファイルに保存」を選んでください。
適当に実装したので、文字が読みづらいですが…。
気に入らなかったら、改造しましょう。そのためのオープンソースです!(笑)
ライセンスは、KL-01とします。
ある日、かの緑の本を読み返していて、352ページのコラムに、
「左シフト+右シフト+ASDF」は入力できない!!!!とあったので、試してみました。すると…
QWER UIOPASDFGHJKL BNM(空白は、入力できなかった。)
つまり、TYZXCVが入力できませんでした!
なぜ、こんな中途半端なんだ…。
(使用したコンピューターは、SONYのVAIO、VGC-LJ91Sです。)
はりぼてwiki内のページ
http://hrb.osask.jp/wiki/?hikarupsp
sourceforge.jp内のページ
http://sourceforge.jp/projects/chnosproject/
sourceforge.jp内のプロジェクトWiki(技術文書などを書いてあったりします)
http://chnosproject.sourceforge.jp/wiki/