GCCプログラミング工房へのお便り
Last updated 2002-10-25

GCCプログラミング工房に寄せられた読者の方々からのお便りです。皆様から頂いたお便りが、本連載の原動力になっています。なお間違いの指摘なども含め、不明な点などありましたらいつでもお気軽にご連絡ください。

西 田 亙 (NISHIDA Wataru)


GCCプログラミング工房11月号の記事について 2002/10/21 木下様

木下と申します。突然メール差し上げて申訳ありません。
いつもUnix Userの『Gccプログラミング工房』をたのしく拝読させて頂いています。ところで、11月号の記事でキーボードデータ(?)の読み込み時の注意として(page121)

・データの読み込み(in命令)の場合
ステータスレジスタのbit0(OBF)が0となっていること

とありますが、これはOBF=1となっていることの間違いだと思うのですが、如何でしょうか?
私はここが0だと思いこんでプログラムを組んでキーボードを2回ぐらい殺してしまいました...(^^;)
ホームページの方にも注意がないみたいなので、私の方が間違いかなと思いつつメール差し上げた次第です。
もし間違いなら、ごめんなさい。

これは本連載中最大の大ポカでした、申し訳ありません。ご指摘の通り、正しくは

・データの読み込み(in 命令の場合)
 ステータスレジスターの bit0 (OBF) がとなっていること

です。ソースリストは合っていたのですが、肝心の説明文が間違っておりました。ありがたく返信したところ、木下さんから次のようなメールを頂きました。

わざわざ御返事のメールをいただき、ありがとうございます。私などから見ると、あのような記事を書かれている方からメールをいただけるとは、なんだか夢のような気分です。

先日のメールは仕事中に「そういえば」と思いだし、ばたばたと書いたものですから、なにか失礼なことがなかったでしょうか。取りあえず、考えていたことがその通りだったようで、ホッとしました。

できるだけサンプルを見ずにコーディングできるようになることを目指して、文章からコードを起こす努力をつづけていきたいなと思っていますので、また、なにか発見できればご報告させていただきます。

それにしても、以前から周辺機器などを操ってみたいと思っていたので、GCCプログラミング工房はほんとうに楽しみにしています。できれば1週間に1度ぐらい新しい記事を読みたい気分です。(書かれている方からすると「そんな無茶な」とお思いでしょうが...)

どうやったら、あのような周辺機器の情報や、ポートの番号を調べられるのでしょうか?私も記事を読みながら、カーネルソースと格闘する毎日です。

そうですね、プログラミングを修得するためには「自分の手を動かす」ことが一番です。

書道には「目習いと手習い」という言葉がありますが、いくら名筆を読んだところで書が上達する訳ではありません。筆跡を真似ながら、自分の手を動かし、筋肉と神経の動きを脳に刻み込む作業が不可欠です。

連載の都合上ソースリストは添付していますが、木下さんのようにあくまでも参考に留め、記事中の情報を基に自分自身で書き下ろして頂けると、より一層理解は深まることでしょう。

周辺LSIを制御するためには、残念ながら本連載で紹介している情報だけでは足りません。本当はもっと詳細に紹介したいのですが、ページ数の制限からそうもできません。詳細につきましては、お勧めの書で紹介している書籍が役立つことでしょう。

さて「週刊GCCプログラミング工房」ということですが、これはちょっと現状では無理ですね(苦笑)。連載で物足りない部分は、当サイトの情報もしくは Brainstorm ML をご参照ください。


いつも楽しく読んでいます 2002/9/12 中川様

はじめまして。

今僕は、情報科の大学3年なのですが、コンピュータをもっと理解したいと考えていて、そしたらたまたまUNIX USERの「GCCプログラミング工房」を見つけて楽しみながら勉強しています。

コンピュータの勉強をしていていつも思うことは、「何から勉強したらいいのか??」がよく分からないという事です。この連載はその答えになっていて、最高だな〜と思います。これからも西田さんのHPをどんどん活用させていただきます。これからも頑張って面白くて、ためになる情報をよろしくお願いします。

最後にお願いなのですが、「GCCプログラミング工房」を知ったのがつい最近で、第1回から数回読み損ねてしまいました。UNIX USERの連載が終わりましたら(または区切りがついたら)まとめて書籍にして頂けないでしょうか??是非ともよろしくお願いします。

心温まるメールをありがとうございます。真剣にプログラミングの学習に取り組んでおられる中川さんのひたむきさが、メールを通じて私にも伝わってきました。本連載が中川さんのお役に立てましたら幸いです。

さて、「書籍」の件ですが同様のメールを他の方々からも頂いています。皆さまのご支持のおかげで、近い将来ご期待に応えることは出来そうですが、UNIX USER の読者アンケートでその旨編集部に直接伝えて頂けますと、発刊の日取りが早まる・・かもしれません。


勝手に弟子になりました 2002/8/24 Toki様

西田さんの記事、本当にすばらしいです。
私は、コンピュータに関して全くの素人ですが、このような明解でしかもここまでほり下げた内容の解説は、きっと今までなかったのでは、と思われます。アセンブラやハードウェアの知識が全くなく、UNIXについての知識も乏しい(dosやwindowsはもっと知らない)私が、このようにコンピュータの根本ともいえる深い内容を、しかも知らない用語がたくさん出てくるのにもかかわらず、とてもよく理解できるんですから驚きです。

これは、西田さんが御自身の力で発見してきた知識に基づいて、解説しておられるからだと思います。それと同時に文章そのもの(構成も含めて)もすばらしい。仮に同じ内容を他の人が書いても、このように明解にはならないと思います。文章の大切さを痛感しました。

これからも師匠 (勝手に西田さんの弟子になりました) に「ついて行き」ますので、すばらしい解説を期待しています。記事を本にされるとき等の御参考になればと、師匠の記事のミスプリと思われるもののうち、HPにのっていないものを下にあげてみました。こちらの勘違いもあるかもしれませんし、みな本質的ではないものばかりですが、もし、少しでもお役にたてば幸いです。

西田さんの解説記事に「飢えている」 一弟子 より

第1回
P.134 図2 ファイル内配置の中: セクション数 -> セグメント数

第2回
P.120 右 8行目: .-R -> -R
P.121 図2 3行目: .. FC 00 00 00 00 00(ここの白抜きが切れている)00 00
..
第5回
P.127 リスト5 3行目: #str -> #sym
P.129 donar -> donor ?

第7回
P.102 右 6行目: acquire_console_sem -> console_conditional_schedule

第10回
octopus1.c
l.75, l.176 : okto -> octo ?

Interface 特集記事の訂正も含め、極めて詳細なご指摘をありがとうございました。「舐めるように読む」とはまさしく Toki さんの事ですね。「コンピューターに関して素人」の方からのご指摘とはとても思えません。「真剣に文書を読む」という点に関しては、逆にこちらが弟子にさせて頂きたいほどです。深い読み込みに、感服しました(スルメイカのように味わって頂き、連載記事もさぞかし喜んでいることでしょう)。

何分人間がやることですから、必ず誤りが発生します。もちろん、原稿・校正の段階で最大限努力はしているつもりなのですが、なかなか完全なものをお届け出来るまでに至っておりません。せめて、間違いが発生した際には迅速に訂正できればと考えています。今後も Toki 通信、よろしくお願い致します。

なおソースコメント中の "okto" ですが、これはギリシャ語の接頭辞として記述しています。


GCCプログラミング工房[第1回]について 2002/8/4 上林様

どうもはじめまして上林と申します。
西田さんの記事を第1回から再度良み直しております。(初回はほとんど理解できなかったので…)
今回は思い切って質問のメールを出そうと思い筆をとった次第です。
初歩的な質問になってしまうかも知れませんが、御理解いただければ幸いです。

  1. 今回は西田さんの記事の第1回目について質問させていただきます。p137 の始めにある、x86CPUのデスクリプタテーブルとはなんでしょうか?西田さんのページの「お勧めの書」をみて、書店に「はじめて読む486」を注文しています。この本を読めば理解できることなのでしょうか?
  2. 同 p137 の、「hello.cを取り巻くもの」での「逆アセンブルの結果を見る通り」での、足し算で最終的に「たかだか50バイト」になるとかかれていますが、逆アセンブル -> 34バイト
    メッセージデータ -> 15バイトの詳しい算出方を教えていただけませんでしょうか?

    初めてで色々とおきき致しますが、よろしくお願いもうしあげます。

白状しますと、ご指摘の点については説明不足を承知で書いておりました。誠に申し訳ありません。

  1. 「はじめて読む486」は確かに良書なのですが、おそらくこの本を一度読んだ程度では理解できないと思われます。x86 における、プロテクトモードについては今後 GCC プログラミング工房の連載を通じて詳細に解説する予定ですので、今しばらくお待ち頂けますでしょうか。当面は、ディスクリプターテーブルが理解できなくとも心配はありません。まずは、9月号から始まる仮想機械 octopus を用いたアセンブリ言語について理解を深めて頂ければ幸いです。
  2. こちらも鋭いご指摘です。確かに執筆しながら「後ろ髪をひかれた」部分のひとつです。
    実行例5の逆アセンブルリストをご覧ください。
    この結果を見ると、 Hello, world! プログラムの実行コード本体は push %ebp から ret までです(命令の詳細について今は理解できなくとも心配ありません)。左端のアドレスを見ると、それぞれ0番地および33番地(16進数で 0x21)になっていますから、コードサイズは「34バイト」となります。リスト最後 0x22, 0x29 番地の計14バイトはGCCが出力した「ゴミ」です。これも今は無視してください。

    次に、 "Hello, world!\n" 文字列の長さ、「15バイト」を足すと49バイトになります。15バイトには Hello, world! の13文字、改行文字(\n)、およびC言語における文字列終了コードであるヌルコード(0)、
    が含まれています。

    以上でよろしいでしょうか?曖昧な点が残ることのないよう、納得いくまで繰り返しご質問ください。頂いたご指摘は今後の執筆にあたり、大変参考になります。それでは、第2回以降に対するご質問も楽しみにお待ちしております。

連載記事の感想 2002/5/30 大野様

はじめまして。大野と申します。
UNIX USER誌とInterface誌の記事、大変楽しく読ませていただいてます。

私も下手の横好きでプログラミングが趣味なのですが、Linuxを使いはじめたことをきっかけにOSの仕組みやアセンブラやCPUなどシステム寄りなことに興味を持つようになり、そういう情報を集めたりしていたのです、ある程度は理解できてもしっかり身につけることはできず消化不良をおこすばかりでした。

そんなときに西田さんの各誌の連載を知り、読んでみると「これが知りたかった!」という情報ばかりでした。ベテランのプログラマーの方々が言う「DOSの時代は単純で、コンピュータを理解するのにはいい時代だった」というのを聞くたびに「もっと昔に生まれたかった…」と思っていたのですが、西田さんの記事を読みつつキーボードを叩いていると少しずつですが目に見えない"壁"を崩していけるような気がします。

執筆活動、大変かと思いますがお体を壊すことのないようお祈りしております。
これからもワクワクするような記事が読めることを期待しています。

大野さんから頂いたこのメールは Brainstorming in Ehime 開催のきっかけとなりました。「目に見えない壁が崩れ、その先に新しい視界が広がる」という表現は、著者冥利に尽きる言葉であり、本連載の目的がまさに達成されつつあることを実感することができました。ありがとうございます。

 

Your SysOp is Wataru Nishida , M.D., Ph.D.