Categories |
CPUの創りかた |
Modern Compiler Implementation in ML |
NerdTV |
PDP-11シミュレータで古代のUNIXを動かしてみる |
The Yakumo Project |
やさぐれ読書録
最近のツッコミ:1.Braritemeal(2008-08-25 00:41)
2.dyendignify(2008-08-18 10:20)
3.Dominic(2008-06-23 05:05)
最近のトラックバック:1.濃縮還元オレンジニュース:プロ.. (2006-12-22 22:02)
1月31日に買った「CPUの創りかた」の材料を調達しにアキバへ。
千石電商と秋月電子通商を行ったり来たりしながらパーツを揃えてゆく。秋月はいつも通りの満員電車状態。千石は地下、1階、2階の全フロアを回って買い物を進めた。今回の買い物の総額は1万円を少し超えるくらいだったか。ブレッドボードを使って手っ取り早く作るという手も考えたのだが、久しぶりにハンダ付けがしたい、というしょうもない理由で(^^;結局ユニバーサル基板とラッピングワイヤーを買った。
"Modern Compiler Implementation in ML" は121ページから動かず。型の整合性チェック部分のプログラミングを進めているのだが、なんとも先は長い…読了見通しは、7月初旬から9月初旬の間を予想。
アキバで調達した部品一式を並べてみた。こんなカンジ。
部品配置は「CPUの創りかた」にある製作例の写真を元に、それを忠実に再現することにした。オリジナリティとか、独自の工夫をこらす、なんてことを言い出すほどの経験はない(10年早い)ので…
PSXが発売されてからおよそ1ヶ月半が経った。2003年12月12日の日記で書いたチェックポイントについて再検証してみるにはちょうど良いタイミングと思われるので、少しまとめてみよう。
■ 出荷時のソフトウェアに存在する不具合について
加澤さんの日記（1月3日分）や他の情報を見る限りでは、大きな不具合は発見されていない。まずは良好な滑り出しと言えるだろう。
■ ファームウェアアップデートのためのインフラストラクチャの整備が完了するタイミングについて
SONYのページにあるアップグレードに関する案内を見ると、2月初旬にアップグレード開始予定とある。僕が予想していたよりも1ヶ月早いスケジュールであった。ネットワークを利用したアップデートと、CD-ROM配布によるアップデートを併用するという点も評価していいだろう。あとは本稼動がスムーズに行くかに注目したい。
■ ファームウェアアップデートにより解除される制限項目の数、および制限解除に伴う新たな不具合の混入について
12月に機能制限された7項目のうち、3点が今回のアップデートにより制限解除される。なお機能追加および改善項目が5つほどある模様。残りの制限項目は3月頃解除の予定とのことで、これも概ね良好。後は新たな不具合の混入がないかについて注意深く見守ってゆくことにする。
全体的にみると思ったよりも健闘しているようだ。後はアップグレード本番以降の結果待ちということになるが、さて。
村岡研現M1の斎藤くん（またの名をモニ(・@・)殿下）の日記によると、Canopusのエンコーダ付きTVチューナユニット「MTU2400」が不調になったため、見てみるとコンデンサが劣化していた（「もにっき」1月24日）ので、総とっかえを決行した（「もにっき」1月31日）とのこと。
これってもしかしたら、Ando's Processor Information Pageの2002年11月9日付記事「今度は電解液の不良」に出ている、台湾製電解コンデンサの不良騒ぎに関連があるのではないかな…この件に関する"Passive Component Industory Magazine"の記事によれば、出回った不良コンデンサは250時間程度で駄目になる可能性があると、Intelがコメントを出したとのこと。MTU2400の発売日が2002年11月15日なので、時期的にはオーバーラップしておらず、微妙にかすっているだけなのだが、状況からして限りなくクロに近い灰色という気配が…初期出荷品の在庫を買ってたりしたら危なそうだ。
'Executable UML:A Foundation for Model-Driven Architecture'を読了。予想以上に良い本であった。以下コメントを：
さて、「プログラミング言語としてのUML」派の最右翼である本書であるが、「スケッチとしてのUML」派の僕からみてもかなり評価出来る本であると言える。単純にUMLを使ったモデリングの教科書として見ても非常に良い。その理由としては：
一方、"Executable UML"が背景としている、モデル駆動開発が万能であるとも思っていない。モデルがまだ明らかになっていなかったり、流動的である領域、特にエンタープライズ系のアプリケーションでは、こういったモデリングが威力を発揮するであろうが、言語処理系など、モデルが既に確立している世界では、少々魅力が薄いのではないだろうか。「情報処理」2004年1月号の和田先生の言葉より：
「最近の開発技法には新味もあるかもしれぬが，例えばテキストエディタの 設計では，テキストは文字と行末記号の列；ポインタは文字や行末記号の 中間を指す；などと決めてかかれば整然たる仕様となる．当然だ． モデルという認識はない」（「編集系独白」）
ということで、「スケッチとしてのUML」派をやめて鞍替えする気はないが、無用に対立したり無視したりするべきでもないだろう。対極にあるもの同士をぶつけて何か新しいものを見出すきっかけになれば良いと思っている。
"Executable UML"を読み終わった後にしばらく考えていたのだが、結局僕が一番気にしていたのは、「プログラミング言語としてのUML」派の存在でも、「青写真（設計図）としてのUML」派の存在でもなく、「ファッションとしてのUML」派、つまり見た目の華やかさや流行に乗ってUMLを使う人々の登場なのではないかと思っている。
これはUMLに限った話ではない。「ファッションとしてのXXX」というのは、今昔を問わず世の中にあふれかえっているように見える。要するに僕は「ファッション」と名のつくものが嫌いなのだろう。
「流行が確立すると、第二の、ずっと大きな集団が、恐れからその流行に加わる。それらの人々は、目立ちたいからではなく、目立つのが恐いから流行を採り入れるのだ。」
（「口にできないこと ---What You Can't Say---」）
川崎のチネチッタで「ロード・オブ・ザ・リング／王の帰還」の先行上映を観る。本編は3時間半と、普通の映画の2本分の長さであるが、途中休憩はないので、見に行く人はご注意を。内容も普通の映画の2本分のボリューム。前売り券1300円分の価値は十分にあった。
僕にとっての因縁の本（2000年10月19日の日記参照）である''Object-Oriented Software Engineering: A Use Case Driven Approach''であるが、''Executable UML''読了の余勢を駆って再読してみることにした。読むのは"Part II: Concepts"にある7章分の予定。
"Modern Compiler Implementation in ML" 、型チェック部分のプログラミングは進行しているものの、ページ数は相変わらず121ページのまま。長期戦を覚悟することになりそう。読了見通しは7月中旬から9月中旬の間。型システムの実装って本当に大変（涙）
ちなみに作っているのはMLのコンパイラではなく、この本のために設計されたTigerという教材用言語向けのコンパイラで、これを現在MLで実装中である、という次第。Tigerがどんな感じの言語かについては、8-queensを解くプログラムのサンプルとか、Tigerの仕様書なんてのを見ると、なんとなくわかるかも。
ついに製作開始である。半田ゴテ用のスタンドは一応ちゃんとしたものを持っているのだが、万が一床に落としてフローリングを焦がしてしまっては末代までの恥、ということで、こんなもんを買ってきた。
100円ショップで買った耐熱マットまな板 x 2。
準備ができたのでおもむろに作業を開始する。ユニバーサル基板とワイヤーを相手に配線するのは実は初めて。どこから手をつけるかでしばらく悩んだが、順当に電源周りから始めることにした。30分後：
30分やってこれだけかよ（寂）
パスコンを取り付ける場所を微妙に間違えてるし…「CPUの創りかた」を持ってる人は278ページの写真と比べてみると分かるはず。パスコンは余分にあっても害はないはずなので、間違って付けた分はそのままにしておく。漢は見た目よりも中身が大事（違）
あれこれ考えていた時間も含めると、作業時間は1時間ほど。先はまだ長そうである。
まずは作業環境の再整備から。2月9日分の日記に対するコメントを受け、ちゃぶ台(\2400)を買った。この値段なら万が一表面を焦がしても痛くも痒くもない。ということで先日購入したまな板様には引退いただくこととなった。
さて、いよいよ製作再開なのだが、どこから手をつけるかでまたしばらく考え込んだ。「CPUの創りかた」で製作されるマイクロコンピュータは、以下の3つのコンポーネントから構成されている。
当初は、有極性の（＝プラスマイナスを間違えるとすぐ吹き飛ぶ）電解コンデンサが部品に含まれているクロックジェネレータを避け、部品配置が分かりやすく、すぐに着手できそうなROMモジュールから実装しようかと考えていたのだが、「CPUの…」での製作説明の順序（上のリストに示した順番である）に従った方が良さそうであること、部品点数が少なく、配置の問題さえクリアできれば実装と確認は容易であることから、クロックジェネレータの部分から着手することにした。まぁコンデンサは吹き飛ぶときは吹き飛ぶのだろう、と覚悟を決めつつ ^^;
ちょっとだけ部品がついた。右端のボタン二つのうち、上にあるのがステップ実行のためのボタン、下にあるのはリセットスイッチ。2月9日分の製作で余計につけてしまったパスコンは、ROM部分を製作する際に邪魔になることが分かったので結局取り除いている。
配線面。DCジャックを基板にどう固定するかを決めかねているため、電源周りの配線は実はまだ完結していない。「CPUの…」の製作例の写真を見ると、ドリルで基板に穴をあけて固定しているように見えるが…う〜ん、もっと簡単に済ませたいなぁ…どうしようか。
ここまでで、クロックジェネレータ部分の約3分の1の実装が完了。本日の実作業時間は1時間くらいか（ノロい、ノロすぎる…）
2月13日分の日記で課題となっていたDCジャックの取り付けについては、結局コード付きのジャックを千石電商で購入し、これを付けることで解決した。
今日は引き続きクロックジェネレータ部分の製作。2〜3個所ハンダ付けするごとに導通チェックをこまめに行う。全部ハンダ付けしてから確認、という手順をとらないのは、チェック漏れの発生する危険性が大きいこと、また、予期しないショートが起きている場合にはどこが原因かまったく見当がつかなくなる恐れがあるため。プログラミングの場合にも、コードを全部入力してからコンパイルやテストをするなんてことは、よほどの初心者でない限りやらないわけだが、ハードウェアの製作も同じ論理で進めることにする。
部品面。ケーブルつきのDCジャックが付いた。二つあるトグルスイッチのうち、上の方はステップ実行モードと通常実行モードの選択用。下の方はクロック周波数（1Hz/10Hz)を切り替えるためのもの。
ここまででクロックジェネレータの実装はほぼ完了。電解コンデンサの取り付けは結局製作の一番最後のフェーズにまわし、まずは他のコンポーネントの実装に着手することにした。導通チェックで、テスターの極性に気を回さなくて良いのはやはり気分的に楽である。本日の実作業時間は1時間30分ほど。
"Modern Compiler Implementation in ML" は型チェック部分のコードが現在240行ほどまで進行。仕上がり予定は350行くらいと見る。テストケース(51件)にはまだ手がつかない。ページ数は相変わらず121ページのまま。読了見通しは7月下旬から9月下旬の間。
2月7日から読んでいた、''Object-Oriented Software Engineering: A Use Case Driven Approach''を読了（2度目）。3年前に読んだ（2000年9月11日、9月13日、10月19日）ときには、やはり内容をちゃんと理解できていなかったのだということを再認識した。以下、前回読んでいたときに見落としていたポイント：
他にもいろいろあるがこの辺にしておこう。結局のところ、ユースケースが悪いのではなく、その適用の仕方を誤るのが問題であるという結論に落ち着く。ただし、読みづらい本であるという認識は変わらず。真意が伝わらないのはこの本自体にも非がありそうだ。
"Another typical example is when you encounter a situation in which the actual handling of instances is placed in the same block as the block that represents the instances themselves."(p.243)
などは悪文の典型。なんと言うか、出来の悪い大学入試の問題のような文章である。
Jacobsonときたら次はBoochだよね、ということで、''Object-Oriented Analysis and Design With Applications''も再読することにした。こちらも2000年9月に読んだ本。前回読了したときの日記（2000年9月10日）を見てみると…
最近，UML(Unified Modelling Language)の記法だけ簡単に紹介して「さあ使ってみましょう」と(参考文献リストすら無しに!）数ページで済ましてしまう雑誌記事を目にすることがあるが，これには少なからぬ危機感を覚える．当然のことながら，Booch法やOMT法，UMLのオブジェクト/クラス図を使うだけで良いオブジェクト指向プログラムが簡単に書けるようになる訳ではない．最低限の責任として，UML（あるいはその前提となったBooch法,OMT法, Jacobson法)の考え方・使い方を解説した本を参考文献に載せておくべきであろう．
なんか最近書いたことと、どことなく似ているカンジが…加澤さんの日記（2月12日分）に書かれていたこととオーバーラップしているようにも見える。状況はここ3年ほどの間、大して変化していなかったのではないかという気がしてきた。
いよいよディップスイッチ16個からなるROMモジュールの実装開始。作業のしやすい配線方法はどれか、などとまた悩みつつ作業を進めた。途中やり直しなどもあったが、とりあえずこんな姿に：
ディップスイッチが4個くっついた。しかしあと12個残っている。先は長い。
配線面。ここまでで配線が完了した個所は8。全部で128個所の配線が必要（実際にはもっと多い）なので、現在の進行状況は8/128=6.2%。先は長い…
今までは適当な長さにワイヤーを切り、配線してきていたが、微妙なとりまわしが必要になるといい加減にやったのではさすがにキビしい。ちゃんとサイズを計って切り出すために定規を購入することにした。
「圏外からのひとこと」経由にて発見した人工無能ししゃもの日記「ボクとsixamoとsixamoの生きる海」。この分野では人工無能うずらがずっと最強であると信じて疑わなかったのだが、この調子で育つとうずらを越えるかも。この先楽しみ。
ROMモジュールの実装作業の続き。やっとのことで1列4個のディップスイッチの配線が完了した。続いて2列目の取り付けと配線にかかる。
一応進んでいる…
配線は40(個所)/128(個所)=約30%くらいまで完了。地味な作業である。作業時間は3時間ほど。
…と、ここまで作業したところで「CPUの創りかた」をパラパラと拾い読みしていると、こんな一節を発見：
…ホントに面倒くさいので最初から「メモリーをフル実装」である必要はありません。（中略）というか、いきなり128bit分の配線をしたら本来の目的であるCPUが完成する前に根性が尽きちゃいます。CPUが動作したあと、ヒマなときにでも「メモリーの拡張」をすればよいと思います。(p.123)
ということで、ROMモジュールの実装は4個2列（現在作業している分）まで完了したところで、一旦ケリをつけることにし、その後CPU本体の実装にとりかかるよう、方針を変更した。所詮やさぐれ、根性なんてものは最初から持ち合わせていないのだ。:)
"mciML"は引き続き型チェック部分のコードを作成中。280行ほどまで進行。仕上がり予想は先週と同じ350行くらいと見る。読了見通しは8月中旬から10月中旬の間。
ここ数週間、特許について再びウスボンヤリと考えていたのだが、ふと、「特許というのは発明を前提としているのだ」という結論にたどりついた。発明があってこその特許。当たり前といえば当たり前である。
2003年9月18日の「やさぐれ日記」で
一方で、エンジニアリングという名に値しない、単なる思いつきに特許を与えることについては僕も反対である、ということも言っておく。「エンジニアリングという名に値する」というのは具体的に何を指すかについてはもう少し考えてみる必要がありそうだ…「値しない」モノは見た瞬間に分かるんだけどね。
などと書いていたのも、今にして思えば、発明になっていないものに特許が与えられているケースに感じていた違和感を言おうとしていたのだと思えば、納得が行く。
発明という活動に注意を向けることなしに「特許でゲットリッチ」なんてのを目指しても、そりゃまったくサマにならないわけだ。「発明でゲットリッチ」だったらまだ格好がつきそうな気もするが。
…なんてことを書いたところで、「発明でゲットリッチ」というキーワード経由にて、2003年9月19日のMatzにっきを発見。読む…あれれ、なんだ、同じようなことが書いてあるぞ…というかここまで書いてきた内容のほとんどがカバーされているではないか。半年遅れで似たようなことを書いている自分は一体…
＿|￣|○
最近、古来のUNIX系のシステムが基本にしてきていた「共有」モデル、つまり、1台のマシンを多くの人が使うという考え方と、MacintoshやWindowsが基本としてきた「パーソナル」モデルとの「すれ違い」が起きているように見える。いや、既に起きてから久しいのかも知れない。
■ 約10年前の話
かつてのUNIXの世界は、1台のマシンを何人もの人間が使う、いわゆる「共有」モデルを基本にしていた。アプリケーションのインストールは、基本的にはユーザのうちのごく一握りを占める管理者(root)の役目であり、その恩恵を、多くの人が受けることができた。
今を去ること10年と少し前、僕の配属された研究室では、同時に5人から6人、多いときには10人を超える人たちが、主力となるUNIXマシンをネットワーク経由で同時に使っている、という姿が当たり前であった。
作業に必要なソフトウェア、例えばエディタ(emacs)も、文書整形ツール(TeX)も、コンパイラ(gcc)も、メール送受信(MH)も、WWWブラウザ(Mosaic,Netscape)も、欲しいなと思ったときには既に管理者によってインストールされていた。僕らはこれらのソフトウェアを自分でインストールするなんて手間をかけることなしに、すぐにそれを使うことができたのだ。管理者はプログラムのコンパイルやインストールなど苦にも思わない連中だったし、逆にそれを楽しんでいたようにも見えた。
一方、その頃のMacintoshやPCは、完全な「パーソナル」コンピュータであった。使う人間は一人だけ、マシンの管理者という概念はまったくと言っていいほど存在していなかった。
同じく10年ほど前、大学の端末室には十数台のMacintoshが導入されていた。研究室のメンバーの一人が、その管理役をまかされていたのだが、一日が終わるごとに、利用者が勝手にインストールしたアプリケーションの消去や、あるいは利用者がうっかり消してしまったシステムファイルの回復に追われていたのを覚えている。Windowsについても状況は似たようなものだった。起動するごとにファイルサーバからシステムファイルをコピーするという仕組みで対抗しようとする試みもなされたが、その管理の手間はほとんど軽くならなかったように思う。
PC上で使えるUNIX互換システムが登場してきたのはちょうどその頃だ。数百万円もするワークステーションでしか使えないと思っていたシステムが、自分の持つ、20万円そこそこのマシンで動くことは、ただただ驚きであり、自分がそれを自由に使えることを思うと、管理者の背負う面倒な手間などは、まったく気にならなかった。少なくとも当時は。
そして端末室にはまもなくWindows NTが導入された。管理者権限とユーザ権限の分かれたOSの登場によって、管理役の作業はいくらか楽になったようだ。Macintoshは相変わらず「パーソナル」な、管理者泣かせのシステムであったが。
■ そして今
時は流れて現在。UNIX系システムはすっかり「パーソナル」な方向に進んでしまったかに見える。一人が一台のマシンの、唯一のユーザであり、管理者であるという状況が一般的になっている。その一方、WindowsとMacintoshは、管理者とユーザを分けるモデルを採用するようになった(Macintoshは見た目こそ今までのままだが、中身はもはやUNIXといって良いだろう)。両者は接近しているように見えて、実は「すれ違い」を起こしているのではないかという感触を最近僕は持っている。そして、これがいくつかの問題を引き起こしているとも感じている。以下、それについて説明することにしたい。
現在の「パーソナル」化したUNIX系のシステムでは、インストールの手間は各ユーザが負うことになってしまった。かつて管理者(root)をやっていた連中とは違い、プログラムを使うのが第一の目的であり、コンパイルやインストールなどという作業は単なる手間、苦痛である（その考え方は、ある意味正しいのであろう）という人にとって、このような手間のかかる作業は、使いこなす上での障害になっていることは想像に難くない。
村岡研OBである大島くんの、2月24日のBlogにある以下の一節
ソースをmakeして自分でバイナリ作成ってのは昔からあることなんだろうけど、いい加減こんな方法やめればいいのに。少なくとも実行環境としてさくっとできないと。こんなんが残ってるからlinuxとか一生メインストリームになれるわけない。
は、その気分を端的に示している。RPMなどのパッケージを使ってインストールすることにより、問題は軽減されるかも知れないが、それでもゼロになるわけではない。いや、場合によっては微妙な互換性問題（例１）（例２）（例３）にぶち当たって悩むなどということが起きる恐れだってある。UNIX系のシステムは本来多様性を持つものであり、それに起因する問題を解決するには、configureスクリプトとmakeの組み合わせが最善の解である、という結論に落ち着くのは、もしかしたら避けられないことなのかも知れない。
さて、もう一方の側であるWindows、Macintosh系のシステムはどうだろうか？管理者モデルは登場したものの、ユーザは一人だけ、しかもその唯一のユーザが管理者を兼ねる、となれば、もうこれを分けるなんてのは面倒以外の何者でもない、なんて考え方が出てきても不思議ではない。
今年1月に開催された、情報処理学会プログラミングシンポジウムのあるセッションにて、SoftEtherがユーザにより勝手にインストールされる可能性についての質問に、作者である登 大遊氏は、
SoftEtherは、インストールに当たりWindowsの管理者権限を要求する。管理者権限の管理がきちんとしている組織では、問題はおこらないはずである。
という旨の回答をしていた。大学の端末室ならばソフトウェアのインストールは関係者だけが出来るようにすることは困難ではないし、おそらくこのタイプの利用スタイルを念頭においた発言だったのであろう。しかし、一般の企業では、OSのインストールからアプリケーションの一つ一つのインストールに至るまで、各人が責任を持って（あるいは無責任に？）実行するのが当たり前になっている。そうでなければ管理コストはひたすら膨大とならざるを得ない。数千台、場合によっては数万台を相手にしているのだ。管理者が秩序をもたらすという考え方は、「パーソナル」な世界ではどう見てもうまく機能していない。なお、この件については、「圏外からのひとこと」2月14日分に、さらに優れた解説がある。結局のところ、「共有」モデルをもたない状態で管理者権限の機能強化をおこなっても、誰もそれを使わないというのが現実なのだろう。
前回に引き続き本日も地味〜にROMモジュールの製作。定規でケーブルの長さをきちんと計るのは作業効率向上に効果があったようだ。部品面は前回と状況が変わらないので、写真は省略。
配線面はこんなカンジ。作業時間は約2時間ほど。次回はいよいよROMモジュール（ただし半分だけ）完結編となる予定。
"mciML"は型チェック部分のコードがやっと進展を見せた（本当に長かったョ）。現在296行ほど。仕上がり予定は320行くらいと見た。テストケースは51件中31件までクリア。ちなみに本の方のページ数は(当然ながら）121ページのまま。読了見通しは8月中旬から10月中旬の間。
# 福盛 [まずは自分でツッコんでみます。 ]
# yooce [おお〜ぅ。ついに移行されましたな。 まあ、blogということにしてｗ、早速リンクさせて頂きます！ ]
# 三浦 [た、楽しそうだ…… ]
# shudo [ブロッガー！ ]
# (磁@磁) [ラッピングワイヤーといえば、その昔、(・@・)はラッピング用のＩＣソケットにラッピングツールでワイヤーを巻き巻きして..]
# 福盛 [ラッピングツールといえば…僕が村岡研に配属された頃に見かけた記憶があります。あの当時アレが何なのか理解してなかったの..]
# 三浦 [私の世代で既に半田付けのみでした…… ]