て日々

2009年5月


2009年5月31日(日)はれ

子供たちを教会の日曜学校に連れて行き、コミセンの図書館に本を返却に行き、企画展示ホールの『ためしてガス展』という妙ちきりんな名前の展示会で,、料理ショーを見たり【娘】にパン焼き体験をさせたり、いろいろ楽しんで帰ってきた。このイベント自体はお金をかけずに楽しめてまことに結構だったのだけど、ついでのことに、先日ガラス天板を割ってしまったうちのガステーブルの修理について聞いてみた。うちにプロパンを納入しているガス店で修理を請けてくれるらしいが、材料費だけでもさささ三万六千円くらいするという。なにせ天板の素材はドイツ製の高級品なのだ。自分で買うなら決してそんなオソロシゲなコンロは選ばないが、建売のいまの家を買ったときにはすでに据え付けてあったし、なにより割ってしまったのは自分だから仕方ない。


2009年5月30日(土)くもり

夕方から妻が大学に授業を受けに行っている。きょうは【息子】が長めの昼寝をしていたこともあり、子供の世話は前回ほどきつくはなかった。

サーバ入れ替え工事は無事に終わったようだ。サーバのカーネルが Linux 2.2 から 2.6 になったし、パフォーマンスも向上している。しかし、ユーザレベルのソフトウェアの更新まではされていないようで、Perl は 5.005003、NKF は 1.9 にとどまっている。Perl が 5.8 以降になるかあるいは NKF が 2.x になってくれると、Unicode が使えていろいろ助かるのだけど。

そして FreeDOS の話。一昨日と昨日の実験でわかったとおり、EMSを使うと DOS が保護モードで動くことになる、保護モードの動作の勉強をするためには、これはちょっと邪魔になる。Windows なり Mac OS なり Linux なりの成熟した高度なOSのほうがよほど快適に作業できるところを、わざわざ時代遅れの DOS を使う理由は、CPUの高い特権レベルの動作まで自由にプログラムできるからだ。きちんとI/O管理やメモリ管理のなされたOSではI/Oやメモリ管理そのものを実験することはできない。オペレーティングシステムが DOS でも、EMSドライバが特権レベルを支配しているような環境では、保護モードの実験はできない。だから、実験用 FreeDOS パソコンにはEMSドライバ EMM386.EXE を組み込まないことにする。いっぽう、XMSドライバの HIMEM.EXE あるいは FDXXMS.SYS を組み込んでも、CPUはリアルモードにとどまるようだ。こちらは RAM ディスクを使うのに必要だから入れておこう。あとは、保護モードに入らずに UMB を使わせてくれる機構があればメモリが節約できて助かるんだけど。


2009年5月29日(金)はれ

いまはまだ朝で、今日は始まったばかりなのですけど、とりいそぎ業務連絡。明日30日の日中に、当 tenasaku.com が間借りしているレンタルサーバ (WebARENA Suite) のハードウェア入れ替え作業があります。そのため、明日は tenasaku.com のすべてのサービスが停止します。実際ダウンする時間は3時間程度になる予定だと連絡を受けていますが、その前後はサーバの動作が不安定になる可能性があります。あしからずご了承ください。30日夜になってもまだなにか妙なことになっているようなら、Gmailのアドレス <tenasaku(あっと)gmail(どっと)com> までお知らせください。

やる気やる気やる気

で、いま午後10時ちょっと前。昨日の話の続きというか訂正というか。昨日の日記にアセンブリ言語のプログラムのリストを載せたのだけど、そこで (SP レジスタをコピーすべき BP レジスタに SS レジスタをコピーするという) アホなマチガイをしていた。そのうえ、そのプログラムを実行した結果についていい加減な解釈を書いていた。あまりに恥ずかしいのでその部分をばっさり削除して、ここに修正した内容を書くことにする。

昨日書いたとおり、CR0 レジスタの最下位ビットが立っていることがプロテクトモードのあかしである。インテルのマニュアルによると、プロセスの特権レベルに関係なくコントロールレジスタの読み出しは許可されているというので、CR0CR4という5つのレジスタのうち CR1 をのぞく4つの内容を読み出し画面に表示するプログラムを作ってみた。(→showcreg.asm)

これを FreeDOS で実行した結果は次のとおり。まずEMSドライバ EMM386.EXE を組み込んだ状態では、

A:\>nasm -f bin -o showcreg.com showcreg.asm[Enter] A:\>showcreg[Enter] CR0 = 0x80000011 CR2 = 0x00000000 CR3 = 0x00125000 CR4 = 0x00000000 A:\>

そして EMM386.EXEを組み込まない状態では、

A:\>nasm -f bin -o showcreg.com showcreg.asm[Enter] A:\>showcreg[Enter] CR0 = 0x00000010 CR2 = 0x00000000 CR3 = 0x00000000 CR4 = 0x00000000 A:\>

また、Windows Vistaのコマンドプロンプトで実行した結果は次のとおり:

A:\>nasm -f bin -o showcreg.com showcreg.asm[Enter] A:\>showcreg[Enter] CR0 = 0x80010031 CR2 = 0x00000000 CR3 = 0x00000000 CR4 = 0x00000000 A:\>

ここで CR1 レジスタが結果に表示されていないのは、このレジスタがIA32アーキテクチャで使用されない予約済みレジスタで、Pentium プロセッサではこのレジスタの読み出しすら禁止されている (例外が発生する) から。やむを得ず CR1 を読み出し表示するルーチンはプログラムから削除した。

実行してみた結果をみると、EMSドライバを組み込んだ FreeDOS では、CR0 レジスタの最上位ビット (PGフラグ) と最下位ビット (PEフラグ) が立っている。このことは、FreeDOS が DOSのくせにプロテクトモード(PE=1)でメモリのページングを有効(PG=1)にして動作しているということを意味する。EMM386.EXE を組み込まずに起動した FreeDOS では、CR0 レジスタの最下位ビットが寝ているので、リアルモードで動作していることがわかる。Windows Vistaのコマンドプロンプトでは、さらに CR0 の ビット 5 (NEフラグ) と ビット 16 (WPフラグ) も立っている。NEフラグは浮動小数点演算コプロセッサのエラー処理のされ方に関連するもの。また、WPフラグが立っていることは、ユーザ・レベルの読み取り専用メモリに上位のスーパバイザ・レベルのプロセスが書き込みアクセスすることを許さない (Write Protected) ということを意味する。WindowsのDOS窓が実際にはプロテクトモードで動作していることは驚くには当たらない。しかしEMSドライバを組み込んだ FreeDOS がコマンドを起動した時点ですでにプロテクトモードで動作しているのは、考えてみれば当たり前なのかもしれないけどちょっと意外だった。

参考文献として、昨日書いた『はじめて読む486』と『作りながら学ぶOSカーネル』のほか、本家インテルの出している『IA-32 インテル® アーキテクチャー・ソフトウェア・デベロッパーズ・マニュアル 下巻 システム・プログラミングガイド』を 日本語技術資料のダウンロード ページからダウンロードして、その第2章「システム・アーキテクチャの概要」を参照している。決してわかりやすくはないが、やはり正確な情報はインテルの技術資料を読むに限る。(この話題は当分続くと思われ。)

やる気やる気やる気

さて、話は変わる。ピアノのレッスンでは、ショパンの曲のテンポの取り方などを注意された。というのも、あまりに遅いテンポで安全運転しているとメロディーが歌にならないので、適度に速いテンポで演奏するよう先生に指示されたんだけど、せっかくそのテンポで演奏を始めても、ニュアンスをつけるためにリタルダンドしたあとのア・テンポでは元のテンポに戻らずいままで慣れ親しんだ安全運転テンポになってしまうのだ。演奏中はテンポやダイナミクスなどいろいろなことにつねに気を配らないといけないので集中力が必要だが、かといって緊張してしまうとすべてがブチコワシになってしまう。ううむ。

けさ【娘】が学校へ行くとき、別れ際に「なんか美味しいもの買ってきてね」とかなんとか言っていたのをピアノレッスンの帰りに思い出して、ミスドに立ち寄った。さいわいきょうはドーナツ一個100円の日だ。おかげで《店内でお召し上がりのお客さま》でほぼ満席状態だった。ちょっと奮発して8個も買って帰ったけど、子供たちは気づかずに寝てしまったので、ドーナツは明日の朝食になる予定。

歩数計カウント10,952歩。


2009年5月28日(木)くもり

蒲地輝尚『はじめて読む486』(アスキー)と金凡峻『作りながら学ぶOSカーネル』(秀和システム)を参照しながら、x86系列のCPUのプロテクトモードがらみのことをいろいろ試している。『作りながら学ぶOSカーネル』のリスト3.1の“カーネル”がうまく起動できないので、自分なりに調べてみて気がついたことを書く。

後日追記:「うまく起動できない」理由がわかった。詳細は6月2日の日記で。

CPUをプロテクトモードに切り替えるには、CR0 レジスタの最下位ビットを立てればいいだけのことらしい。もちろんそれだけではプロテクトモードのプログラムがきちんと動くというわけにはいかない (そのためにはメモリ配置を計画しセグメントディスクリプタテーブルを設定する必要がある) が、それはともかく、386以後のインテルCPUでは CR0 レジスタの最下位ビットを立ててプロテクトモードに入り、寝かせてリアルモードに戻るという要領で、プロテクトモードとリアルモードを行き来できるのだ。しかしながら、FreeDOS の debug コマンドで次のコードを実行させると、うまく動くときと動かないときがある。コードの内容は、いったんプロテクトモードに入り、なにもせずにすぐにまたリアルモードに戻る、というもの。

mov eax, cr0 or eax, 1 ; 最下位ビットを立てて mov cr0, eax ; プロテクトモードに入る jmp _flush0 ; パイプラインにキャッシュされた命令を破棄 _flush0: nop nop mov eax, cr0 and eax, 0xfffffffe ; 最下位ビットを寝かせて mov cr0, eax ; リアルモードに戻る jmp _flush1 ; パイプラインにキャッシュされた命令を破棄 _flush1: nop nop

といっても、debug コマンドではラベルやコメントは使えないから、本当にこのとおりに入力することはできない。ジャンプ先は適宜アドレスに書き換えてくださいな。

さて、EMS関連のドライバを何も組み込まずにDOSを起動した場合には、このコードの実行は正常終了するが、 HIMEM.EXEEMM386.EXE を組み込んでDOSを起動した場合、どういうわけかマシンにリセットがかかってしまう。なんでじゃろうと思って調べてみると、EMM386.EXE を組み込んで起動したFreeDOSでは、debug コマンド実行中に CR0 レジスタの最下位ビットが立っているようなのだ。つまり debug の管理下で走るプログラムはプロテクトモードあるいは仮想8086モードで動いていることになる。だから、そのプログラム内で CR0 レジスタの最下位ビットを寝かせようとすると、特権のないインストラクションを実行したことにより、例外が発生するというわけだ。

ためしに、debug コマンドで次の要領でコードを入力し、実行してみよう。これは、CR0 レジスタの内容をアドレス CS:0000 からのメモリ4バイトに格納しなさい、というコード。

-a 100[Enter] 0100 mov ax, cs[Enter] 0102 mov ds, ax[Enter] 0104 mov eax, cr0[Enter] 0107 mov dword [0], eax[Enter] 010B [Enter] -g=100 10b[Enter]

結果として0番地に入るDWord値は 0x80000011 である。つまりこのとき CR0 レジスタの最下位ビットは立っている。ところが HIMEM.EXE と EMM386.EXE を組み込まずにDOSを起動した場合、同じコードの実行結果が 0x80000010 となって最下位ビットが寝ている。面白いものだ。

翌日追記: 当日ここに書いた内容の、続きの部分にひどいマチガイがありました。あまりに恥ずかしいので削除して、翌日のページに書き直します。

後日追記:この最後の 0x80000010 というのはちょっと奇妙な現象で、最上位ビットは「ページング有効」のフラグであるから、最下位ビット(「保護モード」のフラグ)が寝ているときに立てることはできない。いったんプロセッサが保護モードに入ってページングが有効になってから実アドレスモードに戻ったのでなければ、俺のコードのバグで間違った結果が表示されているのだろう。おそらく後者だ。恥ずかしい。(6月2日)

後日追記:ここで書いた debug コマンドの使用例は FreeDOS に標準添付の DEBUG.COM を想定して書いたものだ。Windows のDOS窓で標準添付の DEBUG.COM を使うと、EAX など32ビットレジスタをいじるアセンブリ言語コードを入力することはできない。Windows 環境では、デフォルトの DEBUG.COM を使う限り、機械語コード 0F 20 C0 66 A3 00 00 を入力するしかない。それよりは、Japheth さんDEBUGX.COM をダウンロードして使うといい。これなら、32ビットレジスタは言うに及ばず、FPU レジスタや MMX レジスタの表示もしてくれるし、アセンブリ言語も386以降向けだし、DPMI を使うプログラムにも対応しているという。(6月2日)


2009年5月27日(水)くもり

コンピュータは、人間が手を焼くためではなく、人間が手を抜くために存在する。だもんで、「て日々」の最新のページを表示するようにディレクトリを走査するCGIスクリプトを書いた。これからは URL http://www.tenasaku.com/tenasaku/tepipi/latest.shtml を開けば常に最新ページだ。これで「てなさく世界」トップのリンクから最新のページに直行でき、しかも毎月の更新作業の時はトップのリンクは変更しないですむ。歩数計カウント6,749歩。


2009年5月26日(火)くもり

西田亙さんがブログで勝間和代さんの本について語っていた。西田亙さんは愛媛大学の講師で基礎医学の研究に従事している研究者だけど、ネット上ではむしろ、ソフト・ハード両面の高度な技術をもったプログラマーという本来の意味でのハッカーとして知られている。ゲームボーイアドバンスをターゲットとしたLinux上の開発手順を詳説した往年のUNIX USER誌の連載は話題を呼んだ。俺はこの人の本業を知らずに、その著書『Linuxから目覚めるぼくらのゲームボーイ』を買い、あとから自分と同じ大学に勤める先生だと知って驚いたのだ。

いっぽうの勝間和代さんについては、俺ごときがいまさら紹介するまでもあるまい。

おそらく本業とはほとんど関連のないGCCをもちいた開発手法についての本を書いて自費出版する西田さんと、何を言ってもメディアが競って取り上げてくれる「時の人」勝間さんでは、本を読んで物を知る目的も違うだろうし、《知識人としての成功》の定義も違うだろう。私見だけど、勝間さんは《輝かしい成功者の物語》の担い手であるからこそ、各種メディアが「成功者は何を為したか」という興味からとりあげてくれているわけだ。「トミタ電子システムパーツで部品選びをする至福の時」について語る西田さんは、おそらくその対極にある。そして、俺が西田さんと勝間さんのどちらにより強く共感するか。まあ、言わなくてもわかるだろう。

実は俺がきょう西田さんのブログを見たのは、昨日のtenasaku.comのアクセスログに「トミタ電子システムパーツ」というキーワードでGoogle検索して俺の旧「て日」にたどり着いた足跡があったからで、このログの Referer フィールド (つまりGoogleの検索結果のページ) を表示させたら、その筆頭が西田さんのブログだったというわけ。この話の教訓は、「日記にはいろんなことを書いておくに越したことはない」そして「人が何を求めてやって来るかはまったく予想がつかない」ということだ。あと、教訓ではないが、トミタ電子には長らく行ってないな。

参考:西田さんのブログ Wataru's memo

明日は【娘】の小学校の遠足だ。おやつを買わないといけない。山越のハトマートで自分で選ばせた。300円くらいまでというルールだ。ピンク色の小さな子供用バスケットに4品を上手に選んで285円。子供なりに「チョコレートは溶けるからだめ」とか「オマケつきより、小分けできておともだちと交換できるもの」とか、ちゃんと考えて選んでいるようだ。俺の財布にあった500円玉を持たせ、一人でレジに並ばせた。【娘】しゃん始まって以来はじめての、スーパーでお買い物だ。

歩数計カウント10,373歩。


2009年5月25日(月)はれ

いつものように歩いて出勤し、帰りには小学校へ【娘】を迎えに行ってお絵かき教室に連れて行ったり、そのあとBOOK・OFFに寄り道したり、なんだかんだよく歩いて、歩数計カウント16,191歩。

大学生協の書店で、金凡峻(キム ボムジュン)『作りながら学ぶOSカーネル -- 保護モードプログラミングの基本と実践』(秀和システム, ISBN978-4-7980-2254-3)という本を手に入れた。x86CPUの保護モードを実際にコーディングしながら理解しようという趣旨の本で、著者のキムさんは1974年生まれの韓国人。アセンブリ言語をフル活用してパソコンのブートプロセスから実験していこうというのもいまどき珍しいし、なにより、そういうテクニカルな本が外国語としての日本語で書かれたということに、ある種の心地よい驚きを感じる。なんだったかの文芸の新人賞にイラン人女性の書いた小説が選ばれたのも記憶に新しい。時代は変わりつつあるなあと感じる。

俺たちはついつい、日本語は日本人以外には習得不可能だと思い込みがちだが、それは事実ではない。たしかに、ネイティブな話者と同じレベルで外国語を使いこなすことは並大抵のことではないだろう。しかし、人間の話す言語には必ず、音を連ねて語を作り、語を組み合わせて文を作る論理的な規則性 (つまり文法) がある。音韻に慣れ、ある程度の語彙を覚え、文法を体得すれば、言葉は使えるはずなのだ。日本語も例外ではない。日本語は他の言語との類似性が乏しく比較言語学の観点から系統がたどれないという意味では特別な言語なのかもしれないが、決して外国語として習得不可能なものではない。現に、俺の職場のロシア人教授も、大学院で妻と机を並べて勉強しているジャマイカからの留学生も、ちゃんと日本語を身につけている。《ニホンゴはムズカシからガイジンさんにはムリでぇすねぃ》とは、たぶん、俺たちの心の中の江戸時代が長い鎖国政策の名残りで言わせているのだろう。あるいは度重なる黒船ショックの心理的反動で《日本語は世界一難しい言語であり、それを操る日本人は頭がいいのだ》と信じ込もうとしている人もいるだろう。

この話をしだすと、インフルエンザの水際作戦からかつてのBSE騒ぎ、公共事業談合から果ては便器のフタの話にまで及んで終わらなくなるので、いったん打ち切り。言語の話はともかく、この『作りながら学ぶOSカーネル』を読めば (おつむの程度が低いという意味ではなくハードウェアに近い層にかかわるという意味での) 低レベルのパソコンいじりが、ますます楽しくなりそうだ。

後日追記:本の扉裏をよく見ると、この本の原著というべき本が昨年のうちに韓国で出版されているようだ。とすると、韓国語から日本語への翻訳者が著者以外にいた可能性もある。このあたりの事情はよくわからないが、翻訳者のことは一切クレジットされていないので、ひとまず著者自身が日本語訳したと考えておこう。(5月28日)

さて、今日は10回目の結婚記念日だ。なんだかあっという間の10年だったようにも思うが、そのわりに、びっくりするほどいろいろの変化があった。なにしろいつのまにか子供が二人いるし、家も買っちまったし、妻の仕事も変わった。そんな日々のなかで、夫婦関係だって多少デコボコしたりギクシャクしたりもするが、それでも妻は俺という割れ鍋に最もふさわしい綴じ蓋である。これまでいろいろしてもらったことへの感謝と、これからもよろしくという気持ちを込めて、夕食にはパアッと飲み食い・・・したかったけど、贅沢はできないので、近所の回転寿司へ行ってチューハイで地味に乾杯した。


2009年5月24日(日)はれ

今日は朝食と昼食を俺が担当。朝食は昨晩のスープの残りでオジヤ。昼食は万長中華めんで味噌ラーメンだ。俺はこんな調子で大雑把な料理しか作らないが、子供たちがそれなりに喜んで食ってくれるのでありがたい。

午後のわりと早い時刻に妻が空港近くのキッズルームのある美容院を電話予約している。俺はキッズではないが、だからとって一人で家にいても面白くない。美容院前までついていってそこからしばし別行動で歩いてパルティ垣生 (これは「カキナマ」と書いて「はぶ」と読む) まで行った。ヴェスタで缶ビール (キリンクラシックラガー350ml) を買って外のベンチで飲み、県立図書館で金曜日に借りた『TCP/IPの絵本』(翔泳社)を少し読んだ。なるほどTCPはパケットを順不同で受け取ってソートするわけではないのだな、などと思っているところで、妻から「美容院すんだよ」と連絡。とはいえ、キッズルームから子供を引き離すのに時間がかかるはず。すぐには来るまいと思ったのでバッハ書店をのぞいたら、上橋菜穂子『獣の奏者』I&II (講談社) があったので購入。これはちょうどいまNHK教育テレビで毎週土曜日夜に放映していアニメ 《獣の奏者エリン》 の原作だ。読んでみると、闘蛇を死なせた罪を着せられてソヨンが処刑されるところが「序章」である。テレビアニメには、それより前の話をいくつか挿入してあるようだ。状況の説明のためかと思ったが、番組のWebサイトに原作者が寄せたメッセージによると、主人公エリンの視点から物語世界を描こうと考えた結果であるらしい。それに、アニメと小説では時間軸の扱いが違うということもあるだろうしな。まあそれはともかく、妻子と合流後またすこしヴェスタで買い物をし、子供らにソフトクリームを食わせて帰宅。歩数計カウント6,516歩。夕食時には久々にヱビスビール。


2009年5月23日(土)はれ

新入生歓迎会である。レインボーハイランド (松山市野外活動センター) でバーベキュー。新入生といえば今年19歳、ってことは何人かはまだ18歳だ。キャッチボールやらなにやらで元気に遊ぶ姿には邪気というものがない。俺にもそういう年齢の時期はもちろんあったが、こういうイベントに参加して無邪気に遊ぶ若々しさは、その頃の俺にあったかどうか。まあ、過ぎたことだし、その頃がダメだったならダメだったで、いま気持ちを切り替えればいいことなのだけど。

それにしてもひさしぶりに肉を腹いっぱい食った。そしてこういう場合の常として野菜がたくさん余ったのでもらって帰った。肉も余ったが、それは手伝いに来てくれた大学院生くんたちが山分けしてもって帰ったらしい。帰宅後、もって帰った野菜(のごく一部)を刻んでトマトと一緒に炊いてスープにし、それとサワラの切り身のバター焼きで夕食。歩数計カウント14,505歩。


2009年5月22日(金)くもりはれ

先ごろ改装された県立図書館に行った。三階の閲覧室は壁を取り払って広くなった。二階の自習コーナーも席数が増えたようだ。書架の配置も変わり見やすくなった。だけど、全体に落ち着いた静かなムードは以前と変わらない。まことに結構。TCP/IP関連の書物をいくつか借り出し、図書館を出てピアノ教室に向かうとき、松山市駅から堀之内へ向かうたくさんの人の流れとすれ違った。市民会館に誰ぞ有名な人が来ているに違いないが、いまどきのロックやポップスにしては、お客さんの年齢層が広い。帰宅後妻に聞いたら、きっとアンジェラ・アキのリサイタルだろうということだった。なるほど。歩数計カウント14,391歩。


2009年5月21日(木)くもりあめ

朝には《二万円のクラリネットを吹いたら案外楽に音が出た》という夢を見たが、これはきっと前の晩に観たTVアニメ『スポンジボブ』の影響だ。『スポンジボブ』にはジャズ好きで気難しいイカルドという軟体動物男が登場して、能天気なカイメンのボブとヒトデのパトリックにいつも酷い目に合わされているのだ。きょうは一日どんよりした天気で、夕方から雨。夕方には少しM教授のMacintoshの面倒をみて、妻の車で帰宅。歩数計カウント9,533歩。

帰宅後、DOSパソコンでアセンブラの短いプログラムを書き、パケットドライバのインストールチェックの方法とドライバ情報の読み出しの方法を実習。しかし、その先に進もうとすると、どうしてもネットに飛ばすパケットの作り方を覚えないといけない。手元にネットワーク関連の参考書がどういうわけか全然ないので、今夜のところはここまで。参考までに、DOS 版パケットドライバの API の説明は Crynwr Software のウェブサイトで公開されている PC/TCP Packet Driver Specification という文書で読めます。


2009年5月20日(水)くもり

歩数計カウント8,832歩。たとえ往復歩いても、職場で自室周辺にじっとしていると歩数が伸びない。疲れをためるとよくないので、帰宅後早めに風呂に入り、パソコンいじりも今日はちょっとひと休み。代わりに、レヴァインの『Linkers & Loaders』(オーム社)とかファンデアリンデンの『エキスパートCプログラミング』(アスキー出版局)とかの本を開いてみる。どちらも、難しいが面白い。どちらも決して新しい本ではないが、そんなことかまうものか。そもそも俺のやっているのは道楽のパソコンいじりで、新しい技術を追求する必要になど迫られているわけではないのだ。どーだわはは。


2009年5月19日(火)くもり

半袖で出勤したら、朝のうち少々肌寒かった。昼は妻とふたり、ロープウェイ街の「一心」で定食を食った。夕方から市民コンサートの機関誌づくりの作業。歩数計カウント12,557歩。センサが敏感すぎるのではないかと心配していたがそれほどでもないようだ。

DOSプログラムといえども、インストールパッケージがそう具合よくフロッピーディスク一枚に収まるとは限らない。DJGPP や Free Pascal のような大きなソフトウェアをインストールするには、ダウンロードしてきた大きな ZIP ファイルを Windows マシンで解凍してから CD-ROM に焼き、それを DOS マシンにマウントする。CD-R のメディアは今ではとても安価ではあるが、毎日のように使っては捨てるなんてことをしていると、いいかげん消費量がバカにならなくなってくる。方針を転換して CD-RW を使うようにするのもひとつの方法だけど、DOSマシンをネットワークにつないで必要なファイルを直接ダウンロードできるようにできれば、そのほうが面倒な手順がひとつ減ってよい。

使っていないネットワークインターフェイスカード (NIC) が、うちに二枚あった。ひとつは VIA の VT6105 チップ、もうひとつは Realtek の RTL8139D チップを使っている。VIA のドライバをダウンロードしたが使い方がさっぱりわからない。そこで次に Realtek のドライバの OEM ディスクというのをダウンロードし、ZIP ファイルの中をいろいろ探してみたら、パケットドライバ RTSPKT.COM というのがあった。カニさんの RTL8139D を使った NIC をパソコンに挿して DOS を起動し、その後にコマンドラインからこのパケットドライバを起動すればよいらしい。説明書き (英文) がちゃんとついていて、わかりやすくていい。これで NIC は動作したとして、それはネットワーク層 (Ethernet) がつながったというだけである。その上に TCP/IP がきちんと乗ってはじめて、われわれが常日頃いう「パソコンがネットにつながった状態」になる。DOS はもともとがインターネットなんてものが影も形もない頃に設計されたシステムだということもあり、このあたりが大変めんどくさい。どうやらパケットドライバをインストールしたあとは、その上に乗っかるデータリンク層からアプリケーション層までを、個々のアプリケーションソフトウェアが各自で用意しているらしい。まずは DHCP クライアントがほしいところだが、今日のところは IP アドレスを手入力だ。さしあたり必要なのは FTP クライアント。だが、フリーな単体の FTP クライアントには、ネット上でなかなかめぐり合えない。今回は、MINUET という統合ソフトを使ってみた。電子メール、News、Gopher、FTP、それにWWWまでをひとつの統合環境にまとめたもので、ノートパッド的なエディタが付属しており、開いたノートウィンドウに書いたURLを選択して接続することができる。これは実に便利なのだけど、このマシンではそもそも電子メールを使わないし、いまさら Gopher でもない。そしてWebブラウザとしてはどうもHTTPのリクエスト形式が古い (HTTPのバージョンを知らせていないかなにか) ことが災いして思うほどは使えない。なにしろ 1995年リリースのソフトだから仕方がない。とはいえ、この MINUET のおかげで、DOSパソコンもネットにつなぐことができるとわかった。だから安心して、「単なるFTPクライアント」と「シンプルなDHCPクライアント」を探そう。

MINUET は Minnesota INternet User's Essential Tool の略だそうです。自分でも試してみたいって人は、FDISK.COM の DOS Internet Info ページにあるリンクから入手してくださいな。今回は IP アドレスその他のデータを MINUET の設定画面で手入力した。DHCP サーバ側の設定で IP アドレスをこの NIC のために予約したから競合の心配はないが、毎回これでは面倒なのでなんとかしたい。DHCPクライアントを起動して、いろいろの設定をサーバに教えてもらうようにすればいいのだ。

後日追記: VIA の NIC も Realtekのと同様にパケットドライバー GETPKT.COM あるいは GETPKT.SYS をインストールすればいいようだ。このさいだから FreeDOSマシンに二枚とも挿して使ってみようかなと考え中。(5月25日)


2009年5月18日(月)くもり

神永正博『学力低下は錯覚である』(森北出版)という論争的なタイトルの本を読んだ。著者は地方私立大学の工学部所属の数学者・情報科学者(情報セキュリティ分野)だ。工学部における数学の基礎教育を通じて、学生の学力のかなり厳しい現状を実際に目の当たりにしつつも、著者はゆとり教育に学力低下の原因を求める通念に、数値データの丁寧な分析を手がかりにして疑問を呈する。いわく、大学における学力の低下の主な原因は18歳人口の減少すなわち少子化傾向にある。子供の数が減っているのに大学の定員は減っていない(むしろ増えている)ので、どこの大学でもいままでは入ってこれなかったレベルの学生が入ってくるようになった。その意味ではそれぞれの現場での学力の低下は事実である。いっぽう、こども全体という集団における学力の分布をみれば、必ずしも大きくレベルが下がっているわけではない。

いちばん面白かったのは、世界各国のTIMSS(国際数学・理科教育動向調査)平均得点と数学や理科を楽しいと感じている生徒の割合を二次元的にプロットしたグラフで、これにはかなり明瞭な負の相関がある。つまり、数学や理科のテストの平均得点が高い国 (数学や理科の得意な生徒が多い国で、多くは先進工業国) では、それらの科目を面白いと思う生徒の割合が少ないのだ。その理由について、経済発展や開発の途上にある国のほうが科学技術を学ぶ動機づけがより強いからであろうと著者は分析している。著者はそのうえで「国家の科学力、技術力を決めるのは、平均的な子供たちが数学・理科を好きかどうかではない」と結論づけるのだ。その分析の当否はともかくとしても、このグラフは、文化的成熟が好奇心を萎えさせる傾向にあることを薄々感じていた俺にとってさえ、たいそう意外であった。

著者は決して学力低下の問題がないと言っているのではない。大学教育が危機的な状況にあるということが錯覚だなんてことも言っていない。この本で他の何事にもまして告発されているのは、実際には言われてもいないそのような主張を、『学力低下は錯覚である』というタイトルに読み込むような、悪い意味でジャーナリスティックなものの見方なのである。

もちろんこの著者の主張を鵜呑みにしてもいけないのだろうが、なかなか面白いし、いろいろ考えさせられる本だ。というあたりで話は変わる。

点点点

新しい歩数計を買った。今度はピップフジモト製。さっそく明日から試してみるが、どうも以前のとセンサ部分の感度が違いそう (敏感すぎるような) で少々不安。

DOS パソコンに Free Pascal 2.2.4 を再インストール。以前にインストールに失敗したのはやっぱり ZIP ファイルが壊れていたからのようだ。そのほかに Japheth's Site なるサイトで配布されている JWASM という x86 アセンブラをインストール。こいつは MASM 互換なので、いろいろのサイトで公開されているコードをアセンブルするのに使えそうなのだ。なぜか、DOS や Windows で NASM を使っている情報源はあまり多くないように思う。これはおそらく、MASM が Microsoft 純正の開発環境 (Visual C++ など) のオプションパッケージとして配布されていたからだろう。


2009年5月17日(日)あめ

昼間からビールを飲み、かつ、長々と昼寝。天気が悪くて子供が外遊びできずエネルギーを余らせているので、ぼやぼやしていると、あっという間に家の中がカオス状態になる。

さて、昨日「強気の解決」と書いたけれど、まず、その逆の「弱気の解決」を試してみた。

  1. コマンドライン版コンパイラで -s オプションをつけて、アセンブル段階の手前で実行中断する
  2. テキストエディタで hello.s を開き, SECTION .rodata という行をすべて SECTION .data に書き換える
  3. バッチファイル PPAS.BAT を実行してコンパイラの処理を再開する

C:\TENASAKU>fpc -Anasmcoff -s hello.pas[Enter] C:\TENASAKU>edit hello.s[Enter] ... (アセンブルリストを編集) ... C:\TENASAKU>.\ppas.bat[Enter]

これだけで、Hello World にせよ何にせよ、ちゃんと表示されるようになる。あるいは ppas.bat の手順記述のアセンブル段階とリンク段階の間に sed コマンドを挿入して処理することも考えられる(え? DOS版 Free Pascal には sed が含まれてないの?)。いずれにせよ、コンパイルするたびに何らかの手作業を必要とすることに変わりはない。だから統合開発環境 (FP.EXE) を使っているときにはこの方法は使えない。仕様どおりに動いてくれないコンパイラにユーザが手作業で対応するという点から言っても、これは弱気の解決策である。

そりゃまあ、そもそも NASM を使うのを避ける、という、もっと弱気の解決策もあるが、それは論外。アセンブリ言語のプログラムを書くときには俺は NASM を使う。MS-DOS全盛期に Microsoft の MASM や Borland の TASM を使っていた経験から、いまでも AT&T 書式のアセンブリ言語を見ると頭が混乱しそうになるから、GNU as を使う気がしないのだ。だから、Pascal言語のコンパイラが中間段階で使うアセンブラとしても、使えるものなら NASM を使いたい。

この問題、そもそもの初めにコンパイラがスタティックなデータを .rodata セクションではなく .data セクションに置いたアセンブルリストを出力してくれれば、それでいいことなのだし、あるいは、アセンブルリストではあくまで NASMの作法 (なのかGCCの作法なのかわからんけど、それ) に従って .rodata セクションを使い、そのかわり、しかるべく変更されたスクリプトをコンパイラがリンカに渡してくれればいいことなのである。デフォルトのアセンブラを使った場合、前者の選択肢を採っている。俺としては、後者の対処法を採りたいが、もしも後者の選択肢を採らせない理由がリンカ側にあるのならば、前者で対処すればいい。

Win32版の Free Pascal では、デフォルトのアセンブラに食わせるアセンブルリストでも文字列など定数データを .rodata セクションに置いているようであるから、DOS版の Free Pascal のデフォルト動作のほうが、なんらかの理由で .rodata セクションを使わぬように変更されている可能性はある。

いずれにせよ、DOS版 Free Pascal と NASM の不仲の原因は、Pascal言語のコードをアセンブリ言語のコードに変換する狭義のコンパイラ、あるいはその上位にあってコンパイル・アセンブル・リンクの過程全体を制御するプログラム (GCCの各言語のコンパイラに対して gcc コマンドが占めている位置を Free Pascal システムにおいて占めているコンポーネント) にありそうだ。この件に関してはアセンブラが悪いわけではない。

そこで、もう一歩突っ込んで原因を究明し、とくに COFF オブジェクトファイルの形式や ld コマンドの動作を理解して (リンカに渡すスクリプトを改善するという) 後者の対処法をきちんと検証したうえ、コンパイラの開発者にそのように進言するというのが、俺の考えている「強気の解決策」である。COFF オブジェクトファイルの知識は Windows の機械語プログラム (PE ファイル) の書式を理解するために必要でもあるからな。

Free Pascal のソースツリーに入り込むだけの能力は、いまの俺にはまだない。しかし、こういう形で開発に貢献することくらいはできそうだ。

参考情報源としては、COFF については DJGPP COFF Specification が、そして PE については Iczelion's Win32 Assembly HomepageTutorial が役に立ちそうだ。


2009年5月16日(土)くもり

妻が大学に授業を受けにいっている間、俺が子供の面倒をみる。コミセンの図書館に行ったら、コミセン文化ホールのピロティで恒例の気まぐれ土曜市をやっていた。若い女の子がカラオケをバックにサックスを吹いていた。決して芸達者という感じの演奏ではなかったが、なかなかいい音だった。図書館では除籍本の放出をやっていて、前田利鎌『宗教的人間』を手に入れることができた。これは岩波文庫の『臨済・荘子』の元本であり、岩波文庫版に含まれないいくつかの章を含む。しかも、この版では秋月龍珉師があとがきを書いている。子供の世話に追われて自分の読む本を借りることはできなかったが、この本が手に入っただけでも大きな収穫だ。

引き続き、DOS版 Free Pascal と NASM の相性問題。アセンブラを NASM にしたものと デフォルトの内蔵アセンブラにしたものでは、出力される COFF オブジェクトファイルのセクション区分が違っていることが、 objdump コマンドでファイルを解析してみてわかった。

参考までに、ソースファイルは次のとおり (ファイル名: hello.pas)

program Hello; begin writeln('Hello Free Pascal.') end.

このソースをコンパイルし NASM でアセンブルした場合 (コマンドライン: fpc -Anasmcoff hello.pas) に出力されたオブジェクトファイル (名前を hello.o から nasm.o に変更) の、セクション別の内容を objdump -s コマンドで表示させた結果は次のとおり

nasm.o: file format coff-go32 Contents of section .text: 0000 5589e581 ec040000 00895dfc e8efffff U.........]..... 0010 ffe8eaff ffff89c3 b9000000 0089dab8 ................ 0020 00000000 e8d7ffff ffe8d2ff ffff89d8 ................ 0030 e8cbffff ffe8c6ff ffffe8c1 ffffff8b ................ 0040 5dfcc9c3 ]... Contents of section .data: 0000 00000000 01000000 00000000 00000000 ................ 0010 00000000 02000000 00000000 00000000 ................ 0020 00000000 00000400 00000000 00 ............. Contents of section .fpc: 0000 46504320 322e322e 32205b32 3030382f FPC 2.2.2 [2008/ 0010 30372f33 315d2066 6f722069 33383620 07/31] for i386 0020 2d20476f 33327632 - Go32v2 Contents of section .rodata: 0000 1248656c 6c6f2046 72656520 50617363 .Hello Free Pasc 0010 616c2e00 al..

そして、次のが デフォルトのアセンブラ (GNU as) でアセンブルした場合 (コマンドライン: fpc -Acoff hello.pas. これも hello.o から default.o にファイル名変更)

default.o: file format coff-go32 Contents of section .text: 0000 5589e583 ec04895d fce8f2ff ffffe8ed U......]........ 0010 ffffff89 c3b93000 000089da b8000000 ......0......... 0020 00e8daff ffffe8d5 ffffff89 d8e8ceff ................ 0030 ffffe8c9 ffffffe8 c4ffffff 8b5dfcc9 .............].. 0040 c3000000 00000000 00000000 00000000 ................ Contents of section .data: 0000 00000000 01000000 00000000 00000000 ................ 0010 00000000 02000000 00000000 00000000 ................ 0020 00000000 00000400 00000000 008d7600 ..............v. 0030 1248656c 6c6f2046 72656520 50617363 .Hello Free Pasc 0040 616c2e00 00000000 00000000 00000000 al.............. Contents of section .fpc: 0000 46504320 322e322e 32205b32 3030382f FPC 2.2.2 [2008/ 0010 30372f33 315d2066 6f722069 33383620 07/31] for i386 0020 2d20476f 33327632 - Go32v2

特に問題の文字列データの格納されているセクションの違いは気になる。それに、objdump -d で逆アセンブルしたとき、NASM版オブジェクトの場合に .text セクション以外に .fpc セクションと .rodata セクションまで逆アセンブルされてしまうのも奇妙だ。

とはいえ、.text セクションの逆アセンブル結果自体にはほとんど違いは見出せない。それぞれの出力結果は次のとおりだ。

C:\TENASAKU>objdump -d -mi386:intel nasm.o[Enter] 00000000 <PASCALMAIN>: 0: 55 push ebp 1: 89 e5 mov ebp,esp 3: 81 ec 04 00 00 00 sub esp,0x4 9: 89 5d fc mov DWORD PTR [ebp-4],ebx c: e8 ef ff ff ff call 0 <PASCALMAIN> 11: e8 ea ff ff ff call 0 <PASCALMAIN> 16: 89 c3 mov ebx,eax 18: b9 00 00 00 00 mov ecx,0x0 1d: 89 da mov edx,ebx 1f: b8 00 00 00 00 mov eax,0x0 24: e8 d7 ff ff ff call 0 <PASCALMAIN> 29: e8 d2 ff ff ff call 0 <PASCALMAIN> 2e: 89 d8 mov eax,ebx 30: e8 cb ff ff ff call 0 <PASCALMAIN> 35: e8 c6 ff ff ff call 0 <PASCALMAIN> 3a: e8 c1 ff ff ff call 0 <PASCALMAIN> 3f: 8b 5d fc mov ebx,DWORD PTR [ebp-4] 42: c9 leave 43: c3 ret ... C:\TENASAKU>objdump -d -mi386:intel default.o[Enter] 00000000 <PASCALMAIN>: 0: 55 push ebp 1: 89 e5 mov ebp,esp 3: 83 ec 04 sub esp,0x4 6: 89 5d fc mov DWORD PTR [ebp-4],ebx 9: e8 f2 ff ff ff call 0 <PASCALMAIN> e: e8 ed ff ff ff call 0 <PASCALMAIN> 13: 89 c3 mov ebx,eax 15: b9 30 00 00 00 mov ecx,0x30 1a: 89 da mov edx,ebx 1c: b8 00 00 00 00 mov eax,0x0 21: e8 da ff ff ff call 0 <PASCALMAIN> 26: e8 d5 ff ff ff call 0 <PASCALMAIN> 2b: 89 d8 mov eax,ebx 2d: e8 ce ff ff ff call 0 <PASCALMAIN> 32: e8 c9 ff ff ff call 0 <PASCALMAIN> 37: e8 c4 ff ff ff call 0 <PASCALMAIN> 3c: 8b 5d fc mov ebx,DWORD PTR [ebp-4] 3f: c9 leave 40: c3 ret

見てのとおり、違いは2点だけ。まず、スタックポインタ esp から 4 を引いて一時変数の領域を確保するさいに、定数 4 が 8 ビットで表現されているか 32 ビットで表現されているかの違い。それと、8個目のインストラクションでおそらく文字列データへのポインタと思われるアドレスを ecx に代入する、その値の違い。(コンパイラの吐き出すアセンブルリストによると、11個目のインストラクション call 0 は、組み込みルーチン fpc_write_text_shortstr の呼び出しである)。NASM版では0を代入し、GNU as 版では0x30を代入している。

おそらくこれは、NASM版オブジェクトファイルで文字列データが .rodata セクションの0バイト目から始まっており、GNU as版オブジェクトファイルでは同じ文字列データが .data セクションの 0x30 (=48) バイト目から始まっていることに対応する。

もしも NASM版オブジェクトをリンクするさいに fpc_write_text_shortstr ルーチンが .rodata セクションでなく .data セクションの 0 バイト目からのデータを出力するようにリンクされてしまっていると仮定すれば、Hello World が表示されない理由は説明がつく。というのも、.data セクションの先頭には NULL バイトが埋まっており、その結果 fpc_write_text_shortstr ルーチンは 空文字列を表示せよとの指示を受け取ることになるからだ。

ところで、アセンブラを変えるとオブジェクトファイルの内容が変わるというのは DOS版に限らず Win32版でも同じことなのに、Win32版では Hello World が表示されないなんて不具合は見られない。上でやったように objdump コマンドを利用して NASMでアセンブルした Win32版オブジェクトファイルを解析してみた。逆アセンブルリストの8行目はDOS版同様 mov ecx,0x0 だ。文字列データもやはり .rodata セクションの0バイト目から始まっている。そして、.data セクションの先頭には数十バイトにわたって NULL バイトが詰まっている。早い話が、オブジェクトファイルの内容は DOS版と Win32版のあいだで本質的な違いは見出せない。NASM/DOS版 と GNU as/DOS版の違いのほうが NASM/DOS版と NASM/Win32版の違いのほうがはるかに大きいのだ。

もちろんここで GNU as/Win32版オブジェクトファイルの解析もすべきなのだろうけど、困ったことに objdump コマンドがこのオブジェクトファイルを逆アセンブルしてくれないのだ。なぜか .text セクションが存在せず、それに相当する内容が .text.n_main という長い名前のセクションに置かれている。少なくとも DJGPP のサイトで紹介されている COFF オブジェクトファイル形式の説明では セクション名が8文字を越えることは許されていなかったのに…

NASM アセンブラが DOS版と Win32版で同等のオブジェクトファイルを吐き出している以上、悪さをしているのはアセンブラではないと言ってよさそうだ。

このように考えると、この問題の原因は リンク段階にあると考えられる。おそらく、リンカが文字列データ参照の解決をするさいに .rodata セクションではなく .data セクションを参照してしまっているのだ。ひとつの可能性として、リンカを呼び出す側 (gccコマンドに相当する、コンパイラの上位プログラム) が自分が呼び出すアセンブラが出力するオブジェクトファイルの形式の違いに無頓着であるとか。

ただし、以上はあくまで、若干の状況証拠からの推測にすぎない。オブジェクトファイルの内容が違うというだけでは決定的な説明にはならない。そこで、もっと詳しいことを知るためにも、コンパイラがリンカを呼び出す手続き (GNU ld コマンドのコマンドライン書式など) と、オブジェクトファイルが実行可能形式にリンクされるプロセスを知らないといけない。勉強のためにも objdump のように COFF 形式オブジェクトファイルを分析するプログラムを自作してみるといいかもしれない。

だいぶ問題が絞り込めてきたように思う。こうなりゃあ、強気の解決をめざすぞ。


2009年5月15日(金)くもり

昨日もそうだったけど、仕事がいろいろ充実していたので気分がいい。この両日が時間的にタイトだとあらかじめ予想していたので、水曜日までに前もっていろいろ準備していたのがよかったようだ。たしかにタイトではあったけど、心配していたほどハードではなかった。ピアノレッスン後、給料日だったので子供たちのためにドーナツを買って帰宅。

歩数計を紛失。歩く気を喪失。それでも、職場からピアノ教室までは「歩く張り合いがないなあ」と思いながらも歩いたし、二コマの授業そのほかで動き回ったので、1万7千から1万8千歩は行ってると思う。新しい歩数計買わなくちゃ。

DOS版 Free Pascal と NASM の相性問題。アセンブルリストに怪しいところがなく、Free Pascal IDE の内蔵デバッガでわからないとなると、次は吐き出されたオブジェクトファイルを調べないといけない。しかし今夜はもう寝る。


2009年5月14日(木)はれ

迷惑メールの件名や差出人にはときどき気の利いたのがある。たとえば、さきほどメールチェックしたら、言うに事欠いて「出会える確率無限大」ってメールが来た。百発百中でも確率は1だというのは秘密らしい。「穴がまる見えの無修正裏DVD」というのがどういうものかは大体想像がつく。きっと、これを注文すると、未使用のDVD-Rメディアが裏向きにして送られてくるに違いない。送信日時の詐称も多い。俺のメールボックスには、1977年に送信されたキリル文字のメールが毎日のように届く。インターネットのない時代の、ロシアというか、当時はソヴィエト連邦だけど、そんな時間と場所から、どうやってメールを送信したんだろう。先日は2063年に送信されたメールが届いた。どうやら今世紀中葉になると、時間をさかのぼってメールを送信する技術が開発されるらしい。なんかタイムボカンとかドラえもんの世界だけど、未来から届いたメールにどうやって返信すりゃいいんだ。(って、未来に送信するのは、時間さえかければできるけど、それは秘密だ。)

後日追記:迷惑メールフォルダを探したら、なんと2105年11月28日のメールがあった。いくらなんでもやりすぎだと思って、メールヘッダを表示させたら、驚いたことに Date フィールドには Date: Tue, 01 Jan 3603 04:35:37 +0200 とあった。受け取ったのはこの14日だけど、いまから1600年後の、37世紀の世界からのメールですよ。とてもとても、ドラえもんどころの騒ぎじゃない。残念ながらこれまたキリル文字で、何が書いてあるかは読み取れなかったけど、もし本当に1600年後の世界と交信できるなら、リーマン予想とP-NP問題のゆくえと、連続体問題に対するその頃の人の意見を聞いてみたいものだ。もっとも「それは何ですか? 余りにも古い話で記録も何もありませんけど」とか言われそうだ。

昨日の日記に書いたDOS上の NASM と Free Pascal の相性問題について。ひとまず同じ Hello World プログラムをVistaパソコンとDOSパソコンでコンパイルしてアセンブルリストを比較してみようと思ったのだが、アセンブルリストを出力してから、コンパイラのバージョンがVistaパソコンでは2.2.4であるのに対してDOSパソコンのは2.2.2であることに気がついた。これでは比較する意味がなくなってしまう。DOSパソコンに少し古いバージョンをインストールしてある理由は、FreeDOS上でバージョン2.2.4のインストーラがマトモに動かなかったからだ。さてどうしたものか。Free Pascal IDE (fp.exe) のデバッガ画面での逆アセンブルリストでは、、マトモに動いているバイナリとおかしな動きをするバイナリの違いを見つけることはできない。それどころか、Win32版(fpcバージョン2.2.4)とGO32v2 DOS Extender版(fpcバージョン2.2.2)でも、プログラム本体部分の逆アセンブルリストには、サブルーチンや静的データに割り当てられたアドレス以外には違いがない。

追記: Windowsパソコンで ZIP ファイルのダウンロードと unzip まで済ませたものを書き込んだ CD-ROMを FreeDOSパソコンにマウントしてインストーラを起動し、かつ、必要最小限のパッケージに絞り込んでインストールしなおした結果、Free Pascal version 2.2.4 を問題なくインストールすることができた。しかしながら、バージョン2.2.4のコンパイラでも、NASM との相性問題は解決していない。(2009年5月18日)

歩数計カウント12,508歩。


2009年5月13日(水)くもりはれ

きょうは体がだるくてつらかった。食事と睡眠のリズムが崩れるととたんに元気が出なくなる。なんとかしないといけない。歩数計カウント9,084歩。

これもだいぶ前に買ったのに結局積ん読状態のオライリー本『MIND HACKS』を、さきほど少し開いてみたら、こんなことが書いてあった。(表現は少し変えてある)

4枚のカードがあり、いずれも、表にはAまたはKの文字、裏には一桁の数字が書いてあるという。テーブルの上にこの4枚のカードが置かれ、[A][K][7][2]というぐあいに見えているとする。この状況で「表にAと書かれたカードの裏には偶数が書かれている」という命題を検証するためには、どのカードをめくればよいか。

正解は、[A][7] である。命題は [K] のカードについては何も言っていないし、「Aの裏は偶数」とは言っているが「偶数の表はA」とは言っていないので、 [2] をめくる必要もない。[A] をめくって裏が偶数かどうか確かめ、また [7] をめくって表がAでないことを確かめる必要がある。これは純粋に論理的思考のパズルである。

では次の問題はどうだろうか。

4枚のカードがあり、いずれも、表には「焼酎」または「ウーロン茶」のいずれか、裏にはそれを飲んでいる人の年齢が書いてあるという。テーブルの上にこの4枚のカードが置かれ、[焼酎][ウーロン茶][16][22]というぐあいに見えているとする。この状況で「未成年者は飲酒していない」という命題を検証するためには、どのカードをめくればよいか。

ウーロン茶を誰が飲んでいようがかまわないし、22歳の人がどちらの飲み物を飲んでいてもかまわない。焼酎を飲んでいる人の年齢と、16歳の人の飲んでいる飲み物をチェックしないといけない。この二つのパズルは、論理的・数学的にはまったく同型である。しかしながら、ひとがこの二つの問題に実際に直面したとき、後者のほうがよほどわかりやすく、パズルであるという意識すら生じさせずに正解に導かれることだろう。では、それはなぜだろうか・・・

『MIND HACKS』の著者は、抽象的・論理的に思考する力は生まれつき誰にでも備わっているわけではないことをこの問題は示している、と言っている。つまり 抽象的思考能力と論理能力とは別物 というわけだ。このことからは、数学を研究するにあたって、扱っている数学的構造に対する具体的なイメージをもつことがいかに大切かがわかる。大学の数学科で抽象的な「集合と位相」を教えることを生業としている数学教師兼数学者のハシクレである俺にとっては、これは未成年の飲酒喫煙の防止に劣らず重要な問題提起である。ふむ。教師はヒトの心理に通じていなければならないというわけだ。それはわかるけど、心理って、ちょっと苦手だなあ。

そして、買った本は読まねば意味がないというのがこの話のもうひとつの教訓である、とかなんとかいいながら、話は変わる。

やる気やる気やる気

昨日に引き続き Free Pascal の、こんどはDOS版(GO32v2 DOS Extender版)の話。うちの FreeDOS マシンには NASM がインストールされている。Free Pascal コンパイラのデフォルトのアセンブラは GNU as 互換で、AT&T 形式のアセンブリ言語コードを扱う。俺にはインテル形式のアセンブリ言語のほうが読みやすいし、また 昨年4月の日記に書いたような事情も考慮して、Pascal プログラムのアセンブリ段階では NASM を使うようにオプション設定する。ところが、DOS版 Free Pascal コンパイラでごく普通の Hello World プログラムをコンパイルするさいに、アセンブリ段階でNASMを使うと、できた実行ファイルが文字列をきちんと表示してくれない。最初は、Free Pascal のライブラリが壊れているのかと思ったが、アセンブラを GNU as にすれば問題なく動作するので、ライブラリの不具合ではない。NASM に渡すアセンブルリストがおかしいのかもしれない。この件については引き続き調査しよう。


2009年5月12日(火)はれくもり

昨日の話の続き。アクセスアップを目指すさほどの理由はないし、つい先日(今月7日に)「無理にサービス精神を発揮するよりは、平常心で毎日続けることにしよう。」と書いたばかりである。しかし、だからといって、来る日も来る日も「きょうも仕事に行きました」「今夜も酒を飲みました」では、なにより自分がつまらない。

考えてみるに、いろいろな人のアクセスを集めるネタというのは、ディテールを追求したものが多いようだ。2001年夏ごろに、まだ難しかった Debian (potato) のデスクトップ機の無線LANへの接続設定で悪戦苦闘した記録を公開した。単に「うまくいきませんでした」「うまくいきました」と書くだけでなく、この型番のこのデバイスをこのように設定したファイルをこれこれのディレクトリにおいたら、こうなってやっぱりうまくいかなかったけど、次の日にこう書いたらうまくいった、というぐあいに、自分にわかる範囲でできるだけ詳細に書いた。この記事はかなりの人に読んでもらったようで、見ず知らずの人から「おかげで助かりました」なんてメールをもらったこともある。いまでは普通のLinuxディストリビューションは主な無線LANアダプタのドライバの設定をデフォルトで組み込んでいるから、さすがにあの時に書いた内容はもう古くなった。ところが先日は、数年前に部品取りのために買ったジャンクのCDラジカセの型番を検索して「て日」にアクセスしてくれた人があった。そんなふうに、面倒くさがらずにいろいろのディテールを書き込んでいけば、いずれ誰かの役に立つ可能性がある。そして、詳しく書いてなおかつわかりやすい文章にしようと思えば、意識的に文の組み立てを整える必要もあるから、その点でも頭を使うことになる。アホな間違いをせずきちんと書こうとすれば、いろいろと慎重に確認してから公開することになる。そういういろいろの要因をあわせ考えるなら、結論として、どうせ書くなら詳しく書くべきだとなる。

やる気やる気やる気

ゴタクはこれくらいにして、そろそろ何か実質的なことを書かなくちゃ。大したことではないけど、Free Pascalでインラインアセンブルで遊んだことを書いてみる。

実用的な言語処理系として当然のことだけど、Free Pascalコンパイラはインラインアセンブルをサポートしている。たとえば次のプログラム

program FPUAsmExample1; {$ASMMODE intel } var X : Extended; begin X := 0.184184; { いやよいやよ } asm fldpi fstp X end; writeln('Result = ',X) end.

をWindows上のFree Pascalでコンパイルし、実行すると、変数 X の初期化した値 0.184184 ではなく、円周率πの値が表示される。これは アセンブリ言語のコード FLDPI で浮動小数点演算プロセッサ(FPU)のレジスタ st(0) に円周率の定数値が格納され、次のコード FSTP X でその値が変数 X に転送された結果、初期化した値が上書きされてしまったからだ。

出力結果

アセンブリ言語の心得のある人なら、この方法でFPUの演算命令を直接記述してプログラムが作れるというわけだ。

ただし、難点がある。たとえば、インデックスレジスタesiの指している80ビット浮動小数点実数の値をFPUのレジスタ st(0) に転送したかったとしよう。一般的なアセンブラ(以下の例ではNASM)ではこれを

fld tword [esi]

と書けばよい。ところが、Free Pascalのインラインアセンブリではこの記述が通らない。80ビットデータを意味する TWORD という表現をインラインアセンブラがどういうわけかサポートしないのである。これは、そのようにマニュアルに明記されているから、バグではない。バグではないが、仕様というにはいくらなんでもひどい仕様である。ためしに TWORD という表現を削除して

fld [esi]

に変えてみる。すると、コンパイルそのものは通るが、次の段階でアセンブラが "operation size not specified" と文句を言って実行ファイルが生成されない。それもそのはず、 FLD 命令の操作対象は、4とおりある。(メモリ空間上の32ビットデータ、同じく64ビットデータ、同じく80ビットデータ、または他のFPUレジスタ。) だから、FLD というアセンブリ言語のコードには、データのサイズに応じて別々の機械語コードが割り当てられるのだ。サイズを指定しないのは、マクドナルドに行ってただ一言「ポテトちょうだい」とだけ言ったようなもの。それでは、バイトくんが困るのである。

それでどうするかというと、コンパイル時に -s オプションをつけてアセンブル段階の手前で処理を中断し (このとき続きの手順を記述したバッチファイルが出力されるので、再開は簡単だ)、アセンブラに食わせるファイルを手作業で修正するということになる。たとえば、先ほどのプログラムを次のように変更したとしよう。ファイル名は FPUAsmExample2.pas とする。FPUに直接メモリ参照させる代わりにインデックスレジスタ edi に変数 X へのポインタを持たせた以外は、プログラム自身の動作に違いはない。

program FPUAsmExample2; {$ASMMODE intel } var X : Extended; begin X := 0.184184; { いやよいやよ } asm lea edi,[X] fldpi fstp [edi] { ← ここ!! } end; writeln('Result = ',X) end.

コマンドライン版のFree Pascal コンパイラで -Anasmwin32 -s -ar- -al というオプションをつけてコンパイルすると、FPUExample2.sという名前のアセンブルリストが出力される。問題の部分だけコピペすると、こんな具合だ。

lea edi,[U_P$FPUASMEXAMPLE2_X] fldpi fstp [edi]

この3行目の [edi] がアドレス指定だけあってサイズがわからないので、アセンブラを通らない。仕方がないので、エディタでここを

lea edi,[U_P$FPUASMEXAMPLE2_X] fldpi fstp tword [edi]

と修正するわけだ。だからといって、インラインasmブロックに最初からこう書いたら、今度はコンパイラを通らないのである。

しかも、腹立たしいことに、前のバージョンのプログラム (FPUAsmExample1.pas) のアセンブルリストを見ると、fstp X の部分のコードが

fstp tword [U_P$FPUASMEXAMPLE1_X]

となっているではないか。つまり、コンパイラ自身が Pascal のコードをアセンブリ言語に変換する部分ではちゃあんと TWORD という表現を使っているのである。ううむ。

これがコンパイラの仕様なんだと言われれば現段階では仕方がないが、FPUの制御なんてのはいちばんインラインアセンブルのし甲斐のあるところであり、そこでは当然のことに80ビットデータつまり TWORD を扱うことになる。そのたびに手作業でアセンブルリストを修正しなきゃならないのでは、なんかバカバカしい。仕様の改善を要求したいところだ。

なお、参考までに Free Pascal の現行バージョンは 2.2.4 であり、このさき仕様が変更される可能性はもちろんある。そして、誤解のないように付け加えておくけれども、俺は Free Pascal が大好きなのだ。Free Pascal は、いわばフリーソフトウエア版クロスプラットフォーム版の Delphi であり、たとえば Pixel image editor のような商用ソフトウエアや、身近な例ではAVRマイクロコントローラのプログラミングに俺も使っている GAVRASM など、実際のプログラム開発に用いられている実用的な言語処理系であって、その完成度は高い。ドキュメントもしっかりしている。ドキュメントがしっかりしているからこそ、このインラインアセンブルの変な動作がバグでなく仕様だとわかったわけだし。だから、この先も Free Pascal ネタは折にふれて書いていくことにする。


2009年5月11日(月)はれ

本当に久しぶりにTENASAKU.COMのアクセスログを開いてみた。一時期と比較して、アクセスはガタ落ち。あたりまえだ。GoogleやYahoo!を介してたくさんの人が読みに来てくれた「保健婦みろりのヘルストーク」と「松山ウィンドオーケストラ」と「てなさく読書欄」を閉鎖して以来、いまではコンテンツといえば「て日々」だけだからな。妻みろりは地域保健および育児支援への情報テクノロジーの応用を本気で研究するホゾを固めて大学院に入ったばかりだから、(研究室の雑用係みたいになっとるけど)自前ホームページでチマチマと小ネタを提供するなんてレベルの活動は当分しないだろう。松山ウィンドのホームページはすでに俺の手を離れている。とすると、復活する可能性があるのは読書欄だが、古い書評を再掲載する気はしない。本を読まにゃならぬ。一朝一夕にはできぬ。

そして、最近の「て日々」がつまらないことも、アクセス数が落ちる原因のひとつに違いない。有益な情報を公開できるだけの活動をしていないのだから、アクセス数は落ちて当然だ。だいたい、「自室の掃除をした」とか「息子が熱を出した」とか書いたところで、誰が読みに来るもんか。わはは。

商売でやっているわけじゃないから、アクセス数を稼がにゃならぬ理由はないし、好きなことを好きなように書けないくらいなら、そもそも公開Web日記なんて始めない。とはいうものの、誰も読んでくれないとなると、大学ノートにボールペンで日記を書いているのと変わらないわけで、やっぱり面白くない。ではどうするか・・・ふむ。

きょうも職場まで妻が迎えにきてくれたので、歩数計カウント6,918歩。


2009年5月10日(日)はれ

昨日に引き続き自室の掃除。外出は昼間にちょっとお酒とカーネーションを買いに出ただけ。カーネーションはもちろん子供たちが母親に手渡すためのものだ。掃除の傍らで、VistaパソコンにTux Paintをインストールして、お絵かき好きの【娘】に遊ばせたら大変面白がっていた。掃除が一段落してみると、これまでたくさんのゴミやチリやホコリと寝食を共にしていたのだと思い知らされる。

土日はできる範囲で家事を手伝う。きょうも昼食と夕食は俺が用意。


2009年5月9日(土)はれ

一日家から出ずに自室の掃除をした。合間に、FreeDOSパソコンにDJGPPFree Pascalをインストール。これらのコンパイラは高機能で使いやすく好ましいが、吐き出されるコードがDOSエクステンダとかDPMIとかに依存している点を考えると、DOS用のちょっとしたツールの開発という点から言って、Turbo C 2.01の存在価値もないわけではなさそうだ。いまさらDOSをいじるからには、だいぶ前に買ったのに結局積ん読状態の蒲地輝尚『はじめて読む486』をひも解いてプロテクトモードを勉強するとか、やってみたいことはいろいろある。

ネットを徘徊しているうちに ReactOS というものを知った。これは、Windows NT系OS(2000, XP, etc.)の互換品をゼロからフリーソフトウェアとして作ってしまおうというプロジェクトで、現時点ではα段階の0.3.9というバージョンではあるが、この先どうなるか、興味は津々たるものがある。それに、すべてをアセンブラで書いたインテル64ビットCPU向けのMenuetOSなんてOSもあるらしい。面白い試みの余地はまだまだあるみたいだ。


2009年5月8日(金)はれ

夕方、うちから「【息子】が発熱」と連絡。幼稚園の延長保育のときに先生が気づいてくれたらしい。一時は39度近く上がったようだ。といって、生活状況を考えると、いま話題の新型インフルエンザなんてことはありえない。俺が子供の時と同様、扁桃腺が弱いのだろう。幸い夕方からは妻が家にいるので、ピアノレッスンをキャンセルしてまで急いで帰宅する必要はなさそうだ。

さてそのピアノレッスン。ツェルニーはあいかわらず難しい。ショパンは少し進展したので、テンポを上げ曲想を表現するように先生に指示された。ちょっとづつでも毎日練習しなくちゃ。歩数計カウント16,506歩。


2009年5月7日(木)はれ

やっと普通の平日。小さな子供のいる親にとって連休は「お休み」ではない。疲れが出て、仕事をしながらも眠くて仕方がない。歩数計カウント16,171歩。

「て日々」を始めて半年がすぎたので、少し仕組みを変更して、目次を表示するようにした。最近記述がおざなりだとは自分でも思うが、無理にサービス精神を発揮するよりは、平常心で毎日続けることにしよう。


2009年5月6日(水) 振替休日はれ

午後の早いうちの船で松山に戻った。たまっていた日記をやっと公開できる。俺がこの日記を入力していたら妻が横からのぞくもんだから「あっちへ行けーっ」って怒鳴っちゃった。公開を前提に書いているものではあるが、作文をしている段階で中途半端に反応を返されたら邪魔なだけなのだ。とはいえ、いちばんの愛読者に邪険にしてはやっぱりいけないな。ごめん。とりいそぎ、今月1日の日記のちょっとしたマチガイを修正した。7年前に肥料を食った【娘】は胃洗浄をしなかったらしい。けさ、じいちゃんの家で【娘】の身長を測ったら120cmだった。あのときの肥料のおかげでスクスクと育っているようだ。

買いたいと思っているワイヤーストリッパーの型番は正確にはVESSEL No.3500E-2だ。それで、現在愛用しているのが赤いグリップのやつがVESSEL No.3500E-1。どちらも近所のダイキで売っているのだけど、その店頭価格がE-1で2,300円ちょっと、E-2で2,600円ちょっとだった。ところがAmazon.co.jp経由で買うと、どちらも送料無料の1,632円で買えてしまう。ううむ。土曜日に買わなかったのは正解だったようだ。


2009年5月5日(火) こどもの日はれ

けさは「ATMで引き出したお金が全部ニセ札で、しかもわけのわからん外国語のチラシやクーポン券がいっぱい挟まっていた」という、まったく縁起でもない夢をみた。

約束どおり昼食にラーメンを作った。しかしスープの材料には思いっきり妥協してしまったので、いかなる意味でも自家製スープではない。ニラとキャベツを刻み、餃子のタネも作った。エビ入り餃子である。包むのは妻と【娘】の役目。なかなか好評であった。午後は岳父の日曜大工作業の手伝い。キュウリの蔓を這わせるネットを張るのを手伝い、近所の保育園児たちが公園代わりに遊びに来るという河川敷で、排水路に渡すちょっとした橋を作るのを手伝った。橋の渡り初めは【娘】と【息子】にやらせ、【息子】がちょっと躓いてコケそうになった部分を改修。なんのことはない。渡り初めではなく実験台である。歩数計カウント12,231歩。


2009年5月4日(月) みどりの日くもり

久しぶりに徳山のマツノ書店に行った。船賃を妻と折半にした戻り金が所持金のすべてだから、高い本は買えないが、『世界の大思想6・ベーコン』『世界の名著65・現代の科学 I』『同66・現代の科学 II』『実践・言語技術入門』と、4冊を計1,200円で手に入れた。【息子】は本物の新幹線を近くで見られて満足。かつての繁華街は見る影もないが、時代に取り残されたこういう感じが俺はわりと好きだ。自分がなかば意図的に時代に取り残されているからかもしれない。けっこう歩いたので歩数計カウント10,499歩。


2009年5月3日(日) 憲法記念日くもり

朝7時過ぎの船で三津浜から柳井に渡る。草刈りを少し手伝った。歩数系カウント8,232歩。


2009年5月2日(土)くもり

連休中は例によって妻の実家に行くことになっている。世話になるお礼に「万長中華めん」(←新居浜の安葉製粉製麺の乾麺で、家族そろってお気に入り。松山では、職場近くのサニーマートで売っているが、ほかでは全然見かけない。)を使って自家製スープでラーメンを作って食わせようと計画した。麺のストックはあるが新たに買い足しておこうと、休日ではあるが職場近くのサニマへ向かった。途中のダイキにもちょっと用がある。いま使っているワイヤストリッパー(ヴェッセルの握りの赤いほう)は0.5mmより細い線がむけず、このままではひと山買いだめしてあるジュンフロン線が無駄になるので、0.25mmからむける姉妹品(握りの黄色いほう)も買おうと思っているのだ。財布が空っぽだったので、店内の銀行ATMで預金残高をチェック。なんと、往復の船賃を払ったらワイヤストリッパーはおろか乾麺も危ないと出た。すっかり買い物する気をなくして、すごすご引き返す。やっぱりストックの乾麺を持っていこう。

夜、妻が大学院の授業に行っている間、子供の面倒をみる。知人のお下がりのプラレールの列車に電池を入れてやると【息子】が大喜び。テレビ漬けにせずにすんだ。


2009年5月1日(金)はれ

ついこのあいだ正月がなんだかんだと言っていたと思ったら、もう五月である。(ひょっとして ひと月かふた月 とばしてない?) このところ晴天続き。街頭のツツジの花盛りだ。

昔話ひとつ。時は7年前のゴールデンウィークのある日(たしか5月3日)、ところは妻の実家。【娘】(当時1歳ちょっと)が植木鉢に置いた合成肥料を食ってしまった。妻と義母は、なまじ看護士看護師の経験と知識があるもんで、「誤嚥110番」の電話番号を調べようとして大騒ぎしている。「なんですぐに医者に連れていかんの?」と俺が言うと、二人の目から鱗がパラ ポロ ピレ ペリッと四枚落ちた。周東病院へ行って、念のため胃洗浄をしたが、当直のお医者さんに見てもらった。さいわい何事もなく、お金を払って帰るころには、【娘】は人の気も知らずスヤスヤ夢の中。電灯の消えた休日の病院から明るい表に出たとき、向かいの山のツツジの花がひどく色鮮やかに見えてまぶしかった。毎年ツツジのきれいなシーズンになると、決まってこの話を思い出すが、もちろん、張本人はそんなこと少しも覚えていない。

夕方からその【娘】を伴ってコミセンの図書館へ。キャメリアホールにファンキーモンキー誰やらいう有名な人が来ているらしく図書館前のピロティに人だかり。歩数計カウント13,328歩。ギャラリーを更新して、昨年のシチリア島行きの写真を掲載。