CUJJ#12/'90.9.18 発売号掲載
アナハイム USENIX の続編の今回は、まず日曜日に観光に出かけた話をする。次に Unix に関連深い人の話題を取り上げる。Unix を語る時はカーネルを作成した人でなく、コマンドや言語処理系を作った人にも注目すべきである。そのうちの一人、Unix の lint や PCC を作った S. C. Johnson に焦点を当てる。USENIX のセミナーやテクニカル・セッションの話題に触れ、最後に今月のニュースとして GNU Emacs の一部を急遽作り直しているという記事を取り上げる。
アナハイムは前述のようにディズニーランドを中心とした地区である。そこで USENIX が開催されたわけであるが、USENIX の開催地は、その季節での観光に適した場所をおおむね選んでいる。今回は夏のディズニーランドの近くのアナハイムである。これまで参加した USENIX で観光地との関連を考えてみると、表のようになるだろうか。
表 USENIX 開催場所
開催年と季節 場所 1986 年冬 デンバー(近くにスキー場がある) 1988 年夏 サンフランシスコ (改めて説明の必要のない観光地) 1989 年冬 サンディエゴ (水族館、動物園、博物館が近い) 1990 年冬 ワシントン (美術館、博物館が多く、しかも近い)
米国は広いので (ちなみにアナハイムは米国の西海岸にある)、ちょっとした観光やホテル以外の食事を試そうにも車がないと大変であることは改めて言うまでもない。比較的安全な街は電車や地下鉄でダウンタウンに行ってレストランに入ることができる。しかし、サンディエゴではダウンタウンはそれほど安全そうではなく、買い物や食事はもっぱら郊外のショッピング・センターにて、ということになる。にもかかわらず、筆者らは車の免許がないというハンディキャップをものともせず、今回日曜日に観光を行なった。
当初グランドキャニオンを考えた。アナハイムはロサンゼルスから車で南へ 1 時間の所に位置し、そこからグランドキャニオンへ行くには片道 5 時間はかかりそうであった。ちょっと遠すぎるが、不可能ではない。パンフレットを集めて研究したところ、一番良い出発点 (ベース・ポイント) はラスベガスであり、ロサンゼルスからだと時間的にきつく 1 泊になるツアーが多い。遠いため飛行機を利用したものもあるくらいである。おそらく日帰りだと朝一番に出発して夜遅くに帰ってくることになるだろう。いずれにせよ、頑張って手続きをしてみることにした。ツアー会社のパンフレットを探して電話した。当然英語なので、己を知っている者はおのずと心がけが違ってくる。今更言うまでもないが費用の点と、出発 (ホテルに戻ってくる) の時間 / 場所を正しくチェックしないととんでもないことになるからである。夕方電話をしたところ留守番電話である。グランドキャニオンのツアーに参加したい旨のメッセージを残した。
日本でも多くなってきているが、米国では留守番電話が非常に多い。小さな会社、事務所、個人宅では留守番電話である。アパートを探したり、引っ越す時の車の手配をするために電話をかけまくったが、留守番電話で対応しているところが多かった。片っぱしから自分の名前と電話番号、用件を伝えるが、普通のペースで折り返しの電話が来ればそれほど問題はないが、電話をかけまくっている合い間に折り返しの電話が殺到するとかけた本人がパニックになってしまう。
相手には、こちら側の英語が第 2 外国語 (ESL、English as the Second Laguage) の人間だとは伝わっていないので普通のスピードで話しかけてくる。で、「もう 1 度言ってください」という言葉を返すはめになる。たいていの場合、次は全体をゆっくり繰り返してくれるが、まれに (少し前まで FSF のメンバーで gdb の保守をしていた Randy Smith のように) 単語自体は普通のスピードで話し、節の間隔をあけて繰り返してくれる人がいる。その場合も往生する。
留守番電話ならある程度心の準備が可能であるが、自動発信の電話は手をつけられない。ボストンにいたころ、日曜日の朝を狙ってかけてくる。商品の案内がテープを通じて流れているのである。これはもう言語道断である。眠い目をこすりながら電話に出てみるとこれである。さすがに迷惑に感じている人もいるらしく、遠距離電話の契約時にこういった自動コールのリストに載せていいかどうかのチェック欄があった (しかし、市内通話には適用されないとのこと。つまり逆にいえば市内通話でかかってくる可能性は否定しないのである)。閑話休題。
その留守番電話のメッセージが伝わっているかどうか不安だったので、時間をおいて念のためにかけ直した。またまた留守だったので、もう 1 度同じメッセージを残して切った。
しばらくすると同じ人から 2 本電話があった。2 つのメッセージを残したおかげだと気付いた。その電話をかけてきたツアー事務所の人の話によると、日帰りのツアーはなく 1 泊になるとのこと。1 泊するほどの日程の余裕がないので、参加しないことにする。
第 2 案として候補に上がっていた (グランドキャニオンに比べれば) 近くのプールに行くことにした。コーラ会社が経営している Wild River にはさまざまなプールがある。最近は東京にも似たようなプールがあるようだが、種類と規模の大きさでは及ばないだろう。
さて、そこはマイナーな観光 (遊びの) スポットなのでツアーはない。従って車を借りていくか、それ以外の交通手段を探してそれを利用することになる。場所はあらかじめパンフレットで調べておく。次にバス会社の時刻表 (これは近くのショッピング・センターで収集したもの) とホテルと行き先周辺の地図 (North Orange Country と South Orange Country) を照らし合わせて、あらかじめどのルートで行けそうか見当をつける。それからバスの乗り換えを確認するために、バス会社のルート・サービス部門の電話番号を調べ、調べる項目も紙に書きつけてから、頑張って電話をする。たいてい話し中が多いがここでめげずにかけ続ける。あるいは別な部門でもいいから電話してしまう。普通はここに電話してください、と丁寧に教えてくれる。今回は最初電話したところではわからない、問い合わせた地区のルート・サービスは別の電話番号です、とのこと。そこにかけると端末を前にしている案内の人が出て、何時何分に出発してどこに行きたいか、その場所は何とかストリートと何とかドライブが交わるところ、といったふうに具体的に問い合わせないと答えてくれない。というよりは、答えられないのである。まして、Wild River と言ったところでわかってくれない。パンフレットを見てストリートとドライブを詳細に答えると親切に教えてくれる。アナハイム・マリオット・ホテルだと xx ストリートのバス停から yy 番のバスに乗って、ディズニーランド・ホテルへ行き、降りたバス停の反対側からサンタアナに行く zz 番のバスに乗りなさい、といったふうである。サンタアナでは 10 分の待ち合わせがあり、降りたバス・ターミナルから 1 ブロック離れたバス停からもう 1 度乗り換える、とのこと。これ以外の会話の 3 分の 1 位は聞きのがしているだろうが、情報が耳に残れば OK である。後で参照できるから。結局、ホテルから 3 時間程度かかることがわかる。意を決して出発した。◆1
前回は Unix の総本山 AT&T ベル研究所の Richie のキーノート・スピーチの中でプロジェクト GNU に触れている部分を紹介した。そういえば、Dennis M. Richie のログイン名は dmr であったのを思い出した。Ken Thompson は ken だったかな。どうして少し覚えているかというと、今は昔、筆者が学生のころ、Unix のバージョン 6 を導入したことがあった。そのテープの中のパスワード・ファイル (/etc/passward) に Dennis M. Richie や Ken Thompson のログイン名が入っていた。C コンパイラのソース・プログラムは Dennis M.Richie が所有者で、カーネルの I/O ドライバは Ken Thompson が所有者になっていたからである。閑話休題。◆2
S.C.Johnson は PCC(Portable C Compiler) と、lint★4 を作った人でもある。lint は Unix ツールの 1 つで、静的なチェック・プログラムである。PCC は Unix の典型的な C コンパイラで、最初 DEC 社のミニコンピュータ PDP11 用のオブジェクトを生成するものであった。当時 Unix 上の C コンパイラは全てこれをベースに作成したので、コンパイラ同士の非互換性はほとんどなかった。ベル研究所内でもこれをベースにさまざまな計算機の C コンパイラを作成した。例えば、汎用計算機 IBM 370 がある。VAX/BSD Unix で使われているコンパイラは、元はと言えば ATT 32V Unix のものを用いている。32V Unix はバージョン 7 Unix を DEC VAX に移植したもので、コンパイラは PCC をベースにしたものである。
PCC の後継のコンパイラとして 80 年代に PCC-2 というものがベル研究所で開発された。オブジェクト・コードの効率向上 (主に VAX) を狙っていた。
C コンパイラを移植する際に最初に決定しなければならない問題は、どのアセンブラを採用するか、あるいはアセンブラ・コードを生成しないで直接リロケータブル・ファイルを出力する方式をとるかである。
アセンブラ・コードを出力する方式を採用すれば見通しの良いコンパイラになる。コンパイラの出力もすぐチェックすることができる。逆に、C 言語の仕様を押さえておけば、既存のコンパイラのアセンブラ出力を眺めて、そのマシンの命令を学習することもできる。Lisp コンパイラ、特に商用のものはリロケータブル・ファイルを直接出力するタイプが多い。この場合、ほとんどのシステムでは便宜上、逆アセンブラのパッケージも提供している。
一般的にこれまでの資産がなければ、生成しやすいアセンブラ・ニュモニックを持った仕様の C コンパイラを選択して、最初から新たにそのアセンブラを作成すればよい。PDP11 や VAX の Unix、Sun OS(Motorola 社の 68000 系の CPU を使っているタイプ) では、DEC や Motorola 社が出しているニュモニックではなく Unix 独自のニュモニックを持ったアセンブラを用い、併せてそのようなアセンブラ・コードを出力するコンパイラを使っている。SONY NEWS は、Sun-3 と同じ Motorola 社の CPU を使っているが、ニュモニックも Motorola 社のものである。gcc ではこの Motorola 系 CPU の 2 つのタイプのニュモニックを MIT 形式と Motorola 形式と呼んで区別し、両方のニュモニックを生成できる仕様にしている。
どうしてこのような呼び方をしているか、想像を書いてみる。だいぶ以前に Motorola 社の 68000 が発表されてからしばらくは、処理系やアセンブラさえ豊富に用意されていない時期があった。しかしながら、直行性のある命令とリニアなアドレス空間、32 ビット構成に容易に移行できる拡張性から、当初さまざまな Unix 系のマシンで採用されていた。MIT では Lisp マシンを作成し、そのフロントエンド・プロセッサ、I/O プロセッサとして採用した。nu マシンという名前で開発が進められ、I/O プロセッサ用の処理系も作られた。PCC をベースにした C コンパイラやアセンブラである。◆3
C コンパイラの作りやすさに主眼を置いてアセンブラの仕様を決定したため、疑似命令は PDP11 アセンブラ /Unix(as) と同じもので、ここのニュモニックも as と似た形式のものを決めて作成したようである。ちなみに as 自体はアセンブラで書かれていたが、68000 用のもの (a68) は C 言語で書かれていた。これらの処理系は VAX/Unix で動くクロスコンパイラ、クロスアセンブラの構成を採っていた。以上のように MIT で採用された (仕様が決められた) ものなので「MIT 形式」と名付けられたのでは、と推定する。例えば、moveb というような書式が「MIT 形式」で、move.b という書式が「Motorola 形式」である。
Unix 系のアセンブラの特徴の 1 つに、アドレッシング・モードの遅延決定が可能という点があげられる。例えば、ジャンプ命令は VAX や、PDP11、68000 のいずれにも、ジャンプ先のオフセットの大きさによってショート・ブランチやロング・ブランチの区別がある。それをコンパイル時に決定するのは手間がかかるので、コンパイラは汎用のジャンプ命令を生成する。アセンブラは、汎用のジャンプ命令であれば、そのオフセットによって生成する命令、またはアドレッシング・モードを切り替えるという方法を採用している。◆4
Richard M. Stallman による gcc のチュートリアル・セミナーに参加した。以下のような内容★6 であった。
gcc の内部構成 (内部仕様)
フロントエンド (言語に依存する部分)
gcc をデバッグするための機能 (ソース・コードの読み方)
バックエンド (ターゲット・マシンに依存する部分)
マシン記述ファイル
GNU C コンパイラの移植 (注意点を含む)
gcc 次期バージョン 2.0 についても若干触れていた。
その中で気が付いた点をまとめる。gcc のフロントエンドと最適化フェーズ、バックエンドの関係を図 1 に示す。--- 図 1 ショウリャク ---
RTL(Register Transfer Language) とは gcc 内部で使われている中間コード形式であり、次の特徴がある。
1) ターゲット・マシンや言語フロントエンドに依存しない。
2) レジスタ個数が無限にあるものとしてレジスタの移動を記述している。最初のいくつかの最適化フェーズを実行する。
RTL を使う点といくつかの最適化のアイデアは文献 [7] を参考にしている。
図 1 に示したようにソース・コードは字句解析部、構文解析部を経て構文木 (tree node) が作られる。次のような種類がある。
ユニークな ID を保持する。
定数を保持するノード
現在注目している構文木内で完結している。
関数定義の開始を示す構文木
式の値を持つ構文木
関数のインライン展開 (例えば、引数のコピーやバインディング) を示す構文木。デバッグ情報を扱う。
言語ごと (現在は C と C++) に独自の構文木を使う。expand_expression 関数は、構文木を入力として RTL を生成する。
obstack という GNU の汎用メモリ管理パッケージを使っている。これはメモリをそれほど消費しないで高速にアクセスすることができる。
gcc バージョン 2.0 では次のような関数の入れ子が可能である。
foo (x,y)
int x,y;
{
int inc (int val){return val + 1;}
int (*ptr)(int);
ptr = inc;
return *ptr (x) * *ptr (y);
}
その中で、GNU ソフトウェア関連のものを紹介する。
これはカリフォルニア州立大学ディビス校で作成されたデバッガである。gdb バージョン 3.0 をベースにしたもの★8 で、イベント駆動型のデバッグ言語を備えている。Sun-3 でのみ現在動作する。プロジェクト GNU ではこれを gdb のバージョン 4.0 に組み込もうとしている。この発表の中で Dalek のソース・コードを入手できるのか、という質問があった。それに対して、電子メールを出してくれればその入手方法を教えるとの回答があったので、早速電子メールを出した。ソース・コードが置かれている anonymous ftp のサイト名とファイル名を教えてもらった。併せて、Dalek の論文を送るから、と付け加えてあった。anonymous ftp でソース・コードを入手し、Sun-3 で動作することを確認した。
しばらくすると前に言っていた Dalek に関する次のような論文が送られてきた。◆5
Ronald A.Olsson,Richard H.Crawfordf and W. Wilson Ho,
"A Dataflow Approach to Event-Based Debugging"
さらに、忘れたころに新しいバージョンを anonymous ftp サイトに置いたから、という電子メールが来た。このメールによれば、少し改良が加えられたとのこと。
依然として gdb バージョン 3.0 がベースである。
Sun-3(bsd)、Sun-3(SunOS4)、VAX をサポートする。
そうこうしているうちに別の論文が届いた。
W.Wilson Ho and Ronald A.Olsson,"An Approach to Genuine Dynamic Linking",August 7,1990,Division of computer Science,University of California Davis
これは GNU ld を改良した dld というダイナミック・ローダに関するもので、dld を作って次の応用をしてみた、というもの。
プログラムのカスタマイズ
インクリメンタルなプログラミング・ツール ◆6
デバッグとテストをサポートするツール
Ultrix/VAX や Sun-3/SPARCstation(Sun OS バージョン 3.4/4.0) 上で dld が動作しており、この成果も Dalek と同様に、フリーで入手可能とのこと。早速入手して調べてみたい。中断している C インタープリタに応用できるかもしれない。
今月リリースされたものの中から面白そうなものを取り上げる。小物のツールと、これまでリリースされたコマンドの修正情報である。これらのニュースは、uunet というネットワーク上の記事からピックアップしたものである。やはりどこも夏休みのせいか、大もののリリース情報はないが、あいかわらず GNU 関係のソフトウェアの動きから目が離せない。
GNU Emacs バージョン 19 の作業が開始されてからだいぶ時間がたっている。進捗はどうなっているのか、という問い合わせが相次いでいるようである。
それとは別に GNU Emacs に、1 つの問題が持ち上がった (gnu.emacs というニュース・グループの 6 月 24 日付の Rob Robertson の投稿記事を参考にした)。IBM が自社のワークステーション (AIX バージョン 3 R6000) に GNU Emacs を手数料のみで配布しようと計画していた。ところが「GNU Emacs の中に別のベンダのコードが入っている」という手紙を入手したため、FSF や FSF の弁護士が再保証したのにもかかわらず、配布をとりやめにしてしまった。そのため Richard Stallman は Gosling Emacs に漠然と似ている部分のソース・コードを全て捨てて、最初から書き直すことにした。ためらいを払拭するための作業を行ない、人々が GNU Emacs を使えるようにするために。
こういった背景から GNU Emacs の作業が遅れていることを含めて、現在の進捗報告がプロジェクト GNU の jla(Joseph Arceneaux) からあった。◆7
Gosling Emacs に漠然と似ているコードを捨てて、最初から書き直している (Emacs バージョン 18 と 19 の両方)。
この作業は書き直しに終始するのではなく、改良の方向で進めている。例えば、Undo(編集作業の取り消しを複数レベルまでさかのぼって可能にする) 機能の整理を行ない、Undo の回数の制限を外す。
その後 Emacs 19 の残りの作業 (メニューとキー割り当ての統合) を終え、2ヵ月程度のデバッグ期間に入る予定。
Epoch(X Window System 専用 GNU Emacs) が更新された。
Simon Kaplan
バージョン 3.1 と比較して 3.2 は主に次のような変更や改良が施された。
epoch::create-screen は生成中に画面をマップしないようにした。これにより、マッピングする前に画面上で適切に操作できるようになった。startup.el の変更点は主に、ある原因で初期化ファイルの中でエラーが発生した場合、最初の編集画面のマップを確認するようにした点である。
ボタンの取り扱いを全面的に変更した。新フォーマットに変換するボタン・コードの表が配布ソースの fix3-2.el に入っている。新しいスタイルは Denys Duchier のバージョンを基にしている。また、読み込みのみのボタンの属性を現在サポートしている。
X の属性はより良く (より汎用に) 動作するようにした。特に、X リソースをリストや配列を使って属性を定義することができる。
クライアント・メッセージがうまく動作するようになった。
マップ、リサイズ、ムーブ・イベント用の新ハンドラ
dot.emacs ファイルのロード用の各種ファイルのパッケージを複数個用意した。
epoch:: で始まる epoch 関数のための wrapper を完備した。これは Epoch 用の関数を普通の名前で低レベルでは定義できるが、高レベルでの GNU Emacs の関数名の既定値との衝突を防ぐために、低レベルで定義した関数に自動的に epoch:: を付けてくれる機能である。
次の (Internet を使った)anonymous ftp でアクセスするか、
方 法 anonymous ftp
マシン名 cs.uiuc.edu
ディレクトリ名 pub/epoch-files/epoch/
ファイル名 epoch-3.2b.tar.Z(Epoch バージョン 3.2 配布用)
epoch-3.2b.ps.Z(PostScript で記述されたマニュアル)
または、小切手 (もちろん米国で換金できるもの) の送付で入手できるが、日本からだと別途割り増しの郵送料が必要なのでここでは詳細を省略する。
cygint!gumby@labrea.stanford.edu
James Clark
実数のポイント・サイズのサポート
任意のファイルを作成することができる。
gpic への追加機能
-box の半径の引数に、ゼロ以外の値を指定すると角を丸くする。
-テキストを回転させることができる。ただし、PostScript の出力デバイスがある場合に限る。
方 法 anonymous ftp
マシン名 prep.ai.mit.edu
ファイル名 groff-0.4.tar.Z(約 760k バイト)
jjc@jclark.uucp または jjc@ai.mit.edu
7 月の終わりには、CMU から、Mach OS のマイクロカーネルについて何らかの情報があるはずであるが、今のところまだない。本文で触れたように GNU Emacs は 18.56 がリリースされることは確実である。これから新しいソフトウェアのリリースやバージョン・アップの多いシーズンになりそうである。GNU Emacs の 18.56 がリリースされるのはよいが、内部コードがだいぶ変わっていることだろう。これまで Emacs 18.55 をベースにしていたソフトウェアには、本文で触れた Epoch や、日本語を扱えるようにした Nemacs、そして Epoch と Nemacs をマージした Nepoch がある。これらを全て 18.56 に足並みをそろえるのは大変であろうことが十分予想される。Epoch は足並みをそろえなくても Emacs 19 が出てくれば事足りるだろうが、それがいつ出てくるか不確定だとすれば、それまでのつなぎとして対応する Epoch を使いたくなることは必定であろう。とにかく気を抜けない今日このごろである。◆8,9
interview、T.A.Dolotta「S.C.Johnson(I)」「C MAGAZINE」1990 年 7 月号、ソフトバンク
interview、T.A.Dolotta「S.C.Johnson(II)」「C MAGAZINE」1990 年 8 月号、ソフトバンク
Susan L.Graham,"Table-Driven Code Generation",IEEE Computer,August,1980,IEEE
S.C.Johnson,"Lint,a C Program Checker", UNIX Programmer's Supplementary Documents Vol.1(PS1),4.3BSD,April,1986
S.C.Johnson,"Postloading for Fun and Profit",pp.325~330,1990 Winter USENIX Conference Proceedings
Michael Tieman and Richard Stallman,"How GNU CC Works",USENIX Association,USENIX Tutorial Text,Summer,1990
Jack Davidson and Christopher Frase,"Register Allocation and Experience Vol.14 No.9,Sept.1984,pp.857~866
これはのぞき穴最適化プログラムに関する論文で、ターゲット・マシンに依存しない構成になっている。従って、ターゲット・マシンを変更することは容易である。のぞき穴最適化プログラムは、レジスタ割り当て、共通部分式の削除、参照されていない変数の検査、のぞき穴最適化の範囲の決定を行なう。
Ronald A.Olsson,Richard H.Crawford and W.Wilson Ho,"Dalek: A Improved Programmable Debugger",pp.221~231,1990 Summer USENIX Conference Proceedings
3 時間かけてプールまで出かけた話をした。途中の乗換場所では必ず帰りのバスの時間を確認しておかなければならない、ことを付け加える。特に終バスの時間は、である。途中のバス停の終バスが以外と早かったり、あるいは 1 時間も待つような乗り継ぎの場合もあるからだ。
ベル研究所ではプラン 9 という OS 用に ncc という C コンパイラを作成している。次の文献を参照のこと。
Ken Thompson,"A New C Compiler",pp.41-51,Proc.of the Summer 1990 UKUUG Conf.London
MIT の nu マシンは、その後商業化された Symbolics 社や LMI 社の Lisp マシンの原型になったものである。
オフセットはアセンブル時に容易に計算できるからである。
gdb をベースに拡張した Dalek について触れている。Dalek の特徴を gdb4.x でも採り入れる予定であったが、実際には gdb 4.6 でもそれほどは採用されていない。
「インクリメンタルな」というのは、ある環境の一部を変更する場合に、全体を再構築するのではなく差分のみを入れ替える、ということである。例えば、インクリメンタル・コンパイラでは、実行時に修正個所を含む関数のみをコンパイルしそれをロードする、というデバッグ技法がとられる。ソース・コード修正からテスト、デバッグまでのターン・アラウンド・タイムの短縮をはかることができる。
Emacs バージョン 19 はまだリリースされていない。作業は進められている。Emacs バージョン 19 の作業中のバージョンを大幅に書き改めて、Lucid 社から lemacs 19 という名前のバージョンがリリースされている。X Window System 用のものである。これで、X 用の Emacs は Epoch と lemacs の 2 つのローカルなバージョンができたことになる。Emacs 18.58 をベースにした Epoch 4.0 がリリースされている。Emacs 19 がリリースされる時には、Epoch の特徴は採り込んでいるが lemacs 19 の特徴は入らないだろう、という rms の話である。Emacs 20 では採用する予定とのこと。
CMU の Mach OS の中核部分であるマイクロカーネルは、コピー・フリーで現在既にリリースされている。
Nemacs を 18.58 対応にし、多国語化されたものが現在 Nemacs の開発者によって作業中である。