Categories |
CPUの創りかた |
Modern Compiler Implementation in ML |
NerdTV |
PDP-11シミュレータで古代のUNIXを動かしてみる |
The Yakumo Project |
やさぐれ読書録
最近のツッコミ:1.Dominic(2008-06-23 05:05)
2.CheapestCheapOEMoem(2008-06-17 03:00)
3.NewDownloadCreativAdobOEM(2008-06-12 20:00)
最近のトラックバック:1.濃縮還元オレンジニュース:プロ.. (2006-12-22 22:02)
2月17日から読んでいた、''Object-Oriented Analysis and Design With Applications''を読了（2度目）。実際に読んだのは6章から12章までの約240ページ。前回読んだとき（2000年8月17日、8月22日、9月10日）との違いを挙げてみる：
6章"The Process"と7章"Pragmatics"は開発にあたっての一般論が中心。前回読んだときにはなんとなく理解した気分になって、そのまま済ましていたが、改めて読んでみると、その分かりにくさに愕然とする。特に6章"The Process"は雲をつかむような話が続き、シンドかったの一言。
8章から12章までは、さまざまな分野のシステム開発の例を挙げ、各章ごとに具体的な開発の手順について説明。前回と比べると予備知識が増えている分、この辺りは読みやすくなっていた。文中のプログラム例はすべてC++で説明されているのだが、クラスの仕様を決定するのが設計の要点であることから、出てくるコードはほとんどヘッダファイルに限定されている。前回読んだときには実装のコードが出てこないかとひたすら探していたが、今回はヘッダファイルだけ見れば十分と割り切れたのが最大の違いか。
全体的にみるとやはり良い本だが、やはり少々古くなってきたかも。2000年8月17日の日記を見ると、「2001年初頭に第3版が刊行予定」とか書いてあるが、結局予定通りには出版されないまま、3年以上過ぎてしまった模様。amazonのページを見ると第3版は今年6月に登場ということになっているらしいが、ちゃんと出てくるのかな…
川崎のチネチッタにて、「イノセンス」を観る。感想を一言で言うならば：
去年の11月に公開された予告編については、2Dアニメーションと3Dアニメーションのタイミングが合っておらず違和感があるという話（ARTIFACT - 人工事実 2003年11月26日）があり、少々心配していた（確かに予告編を見たときになんとなくしっくりこないような雰囲気だった）のだが、映画本編を見た限りでは全く問題を感じなかった。ただし人によっては3Dアニメーション部分の滑らかさが気になる人もいる、かも。ここらへんはもはや各人の好みの問題になると思われる。
内容については詳しくは説明しないが、原作のセリフや場面、エピソードを丁寧に拾いあげており、非常に好感が持てる作り。押井守監督作品は独特のクセがあることが多いが、「イノセンス」ではそれほど気にならなかった。良くこなれているせいか、あるいは自分が慣れてきただけか？
1995年の劇場版第一作「攻殻機動隊」をこの前DVDで観たときにはさすがに（わずかながらではあるものの）古さを感じはじめていたのだが、今回の「イノセンス」で、再びはるか先に進んだ感じ。一方、オープニングのテーマ曲から全体的な話にいたるまで、この映画が「攻殻機動隊」の正当な続編であることを明確にアピールしていた作品であったし、その点でも非常に満足できるものであった。また観にいくかも。
再読シリーズの3冊目、''The Unified Software Development Process''（2001年1月28日の日記）を読み始める。改めて読んでみて気づいたのだが、いわゆる(Rational) Unified Processという開発方法論は、かなり「重たい」。開発にかかわる人々の分類だけ見ても、
と6種類もの人々が登場するワケで。これを10人以下のチームで使うのは非常に無理があるように見える。100人規模の開発となれば意味がでてくるような気がするが。
前回予告した通り、ROMモジュール（一応）完結編。今日の作業はDIPスイッチ用のプルアップ抵抗8個の取り付けと74HC154（アドレス選択用のDemultiplexer)、74HC540（インバータ部分だけ使い、DIPスイッチからの出力にかます）用のソケット取り付けと配線、という内容になった。
部品面。新たにICソケットが二つ付いた。左が74HC540用、右が74HC154用。
配線面。「TD4」の製作例に律儀に従い、配線は少し回り道ぎみにしてある。最終的にはグルーガン（千石電商で580円だったので衝動買い ^^;) を使って固定してやる予定。
本日の作業時間は3時間45分ほど。次はいよいよCPU本体部分にとりかかる。
"mciML"は型チェック部分にもう一つのヤマがあることが判明。ハマる。テストケースは36件までクリアしたものの、付属のテスト51件では捕まらない不具合があるため、自分で4件追加し、全55件となる。コードは現在316行ほど。あと2週間くらいは手をかけてやらないといけなさそうな気配。
さて、ついにCPU本体部分の製作に入るわけであるが、まずは部品配置と作業順序について少し考えてみる。製作例の写真を見ると、74HC154の右どなりの列に14ピンのICが縦に3個並ぶ構成になっている。材料のうち14ピンのICは74HC10, 74HC32, 74HC74の三つがあるのだが、どれが一番上に来るべきかを推理してみた。
ROMモジュールからは74HC540を経由して8ビット幅のデータバス（「TD4」の275ページにある回路図ではD0-D7と表示されているライン）が伸びて来ているのだが、このデータバスからの入力が最も多いのは74HC32,次に74HC10となっている。ちなみに74HC74にはデータバスからの入力はない。
データバス出力元の74HC540に近接させる順序もこれと同じにするのが良さそうである。結局上から、74HC32, 74HC10, 74HC74という順に配置することにした。
ということで製作開始。
部品面。ICソケットが新たに二つ取り付けられた。上が74HC32、下が74HC10。
配線面。データバス(D0-D7)のうち、まず配線できるものから作業を始め、いもづる式にその先に進むという流れとなった。
作業の手間はROMモジュールを製作していたときと比べてあまり変わらないのだが、単調さがなくなった分だけ、いくらか楽しくなってきた。本日の作業時間は2時間ほど。
"mciML"は型チェックでまだ格闘中。再帰的に宣言された型の取り扱い、例えば
type tree = {key: int, children: treelist}
type treelist = {hd: tree, tl: treelist}
とかは正しいものとして通し、一方
type b=c type c=b
みたいに循環してしまった型宣言はエラーとしてハジくように、きちんと実装しなければならないのだが、なかなか感覚が掴めずに苦労している。コードは現在325行ほど。テストケースは58件に増え、そのうち38件が消化という状況。ゴールはまだ遠い…
CPU本体部分の製作は、前回に引き続き74HC32, 74HC10部分の残りの配線、続いて74HC74の取り付け、配線へと進む。これら三つのIC間の配線が済んだところで一旦決着とし、次の列に進む。
製作例の写真では8ピンのICが三つ縦に並ぶ構成になっており、一番下のICは74HC283であることが分かっている（74HC283だけは写真上でラベルが読み取れるため判明）。残りの二つのICは74HC153であるものと推理した。
部品面。74HC74（縦に三つ並んだ列の一番下）、74HC153（74HC74のある列の右隣、縦に二つ並んでいる部分）用のソケットが追加された。ちなみにICソケットを一つ上下逆に取り付けてしまった（分かるかな？）ダサいが実害はないのでそのままにしておく。
配線面。ROMモジュールの配線を（なんとか）くぐり抜けた身からすると、IC周りの作業はまるで天国のよう、楽勝である。この調子で最後まで行ければ良いが…
今回の作業時間は3時間半ほど。完成は4月になってから、ということになりそうだ。
"mciML"はついにヤマを超えた。3月14日の日記で言っていた、再帰的に宣言された型についての課題はひとまずクリア。残る山は再帰的に定義された関数の取り扱い。コードは現在362行。テストケースは65件に増え、そのうち61件を消化。もう一息。
"mciML"は型チェック部分の製作がついに完了。1月25日に着手してから、ここまでたどり着くのに2ヶ月かかった…本当に長かった。コードは389行、テストケースは69件（全件消化）。コードには少々雑なところが残っているが、これは順次直していくことにしよう。残るは第5章の演習問題。これを片付ければ、次はいよいよ第6章、スタックフレームのお話に突入する。
「将棋の定跡」と「デザインパターン」の関係というと、いかにもありふれたお話に聞こえるかもしれない。「両者はよく似ている。以上。」と言ってしまえば、その時点で終わってしまいかねないトピックだ。
だがあまりにもストレートな題材であるせいか、意外と取り上げられていないこと、また、最近モニ(・@・)殿下こと斎藤くんの「プログラムは将棋でありジャズである」という文章を改めて読み返したことが、この文章を書くきっかけとなっている。
以下は将棋に関する僕の失敗談とそこから得られた教訓である。もしも将棋とプログラミングが類似しているならば、このようなお話も少しは役に立つかも知れない、と思う次第である。
■ 将棋の定跡を使おうとして失敗したお話
今を去るはるか昔のこと。当時小学生だった僕は、同年代の他の子供と同様、将棋に興味を持つようになった。父親に買ってもらった入門書には、ゲームの目的（自分の王将を取られないように守り、相手の王将を取ること）、最初の駒の配置（王将を一番下の列の中心に置き、その両隣に金、その両隣に銀を置く、など）、それぞれの駒の動かし方（飛車は上下左右に何マスでも動ける、王将は全ての方向に一マスだけ動ける、など）のルールが書かれており、僕はその一つ一つを少しずつ覚えて行った。
その入門書の最後の方には、「定跡」と呼ばれる章があり、「矢倉囲い」とか「美濃囲い」といった、王将を守るための陣形や、ゲームの序盤の典型的な駒の動かし方が説明されていた。僕はこれを使えばきっと勝てるのだ、と信じて、父を相手に、入門書を横目で見ながら、その定跡のいくつかを忠実に再現しようと試みた。しかしどうしてもうまく行かない。入門書に書かれていた「矢倉囲い」の形を完成させる前に、父の駒は僕の陣地に攻め入り、王将はあっけなく取られてしまった。また、序盤の典型的な駒の動かし方を再現しようとしても、父がそこに書かれていない駒を動かした途端、僕はどうすればよいのか途方に暮れることになった。
結局それ以降、友人と何度か将棋で遊ぶことはあったものの、定跡を使うことは二度となかった。僕の将棋の実力はその時点で止まったままである。
■ 教訓
さて、僕が定跡を使おうとして、なぜ失敗したのかを考えて見た結果を、具体的な教訓としてまとめてみることにする。それぞれの教訓は密接に結びついており、もしかしたら相互に若干の重複があるかも知れないが、まずは以下のようになるであろう。
■ プログラミングとデザインパターンの視点から
ここで視点をプログラミングとデザインパターンの方向に移してみることにしよう。IEEE SoftwareのMarch/April 2003の号に、Martin Fowlerの"Patterns"という記事があるので、そこから関係しそうな部分を引用する（ちなみにこの文章は、martinfowler.comからも参照可能）。
まずはパターンの多用について：
考えられる問題点の一つとしては、パターンは無条件に良いものであり、パターンを多く使うほど品質の高いプログラムが作られると考える人が登場してしまうことが挙げられる。"hello world"を表示するだけのアプリケーションに、decoratorパターンを三つ、strategyパターンを二つ、そして山ほどのsingletonパターンを使ったとかいう怪談も、そういったところから生まれるわけだ。
パターンそのものは良いものでも悪いものでもない―どちらかといえば状況に合っているか合っていないかという観点で見るのが適切であろう。確信が持てないときに、あるパターンを試しに使ってみることは悪くないと思うが、もし十分な効果がないときには、それを捨てることをためらってはならない。
（以上やさぐれ訳。かなりの意訳なので注意）
次にパターンとその変化形について：
…実際にパターンが使われた事例を一つ一つ見ると、それぞれ少しずつ異なっていることが分かる。私はよく、パターンというのは「生焼け」なのだという言い方を使う―つまり、自分のおかれた状況にパターンを適合させ、自分で仕上げなければならないということだ。
（以上同じくやさぐれ訳。かなりの意訳なので注意）
プログラミングの場合には「勝つ」ための条件は将棋よりもはるかに複雑であるため、デザインパターンを使ってみて失敗しても、その失敗したという事実に気がつきにくいこと、また将棋よりも幅広い変化が発生するため、それに対応できる力量が要求されること、などの課題があるものと思う。しかしその類似点は予想していたよりも多いように思われるが、いかがだろうか。
3/31追記：「教訓」の冒頭および最後の方の文章を変更した。また、「プログラミングとデザインパターンの視点から」の項を追加した。
"mciML"は第6章"Activation Records"に進む。この章はスタックフレームに関する解説が中心となっている。
スタックフレームは通常、関数呼び出しの際の引数の受け渡しやローカル変数の保持などに使われる。単純な実装では関数呼び出しが起こるたびに引数をスタックに積んで受け渡しをするが、RISC系のアーキテクチャでは、メモリからの読み書きの回数を減らすために引数の授受を可能な限りレジスタで行うというお話などが書かれている。現在は143ページまで読了。これから再びMLでのプログラミングに入る予定。
# washi [提示された教訓は、「定跡」を「デザインパターン」を置き換えればそのまま使えそうですね。 特に、目的は重要と思われます..]
# 福盛 [コメントありがとうございます。 目的と手段の逆転というのは、思ったよりも厄介なお話なのかも知れません。呼び名や姿が印..]
# washi [あ、記述が曖昧ですみません。 「その辺りの誤解が・・・」は、デザインパターンについて「一般的にはそのあたりの誤解が…..]