みんな帰宅の時間なのか、電車が混んでいた。早朝に電車を降り、マウンテンで格闘し、姫路城を歩き回った我々には、立ちっぱなしの1時間半の電車はつらかった・・・。 岡山に到着した頃には、日も沈んでいた。この地方の特色は、マックよりロッテリアが多く、ロッテリアよりさらにミスタードーナツが多いこと。不思議だ。 宿に着いてから、夕食探し。この時間ともなると飲み屋かラーメン屋しかやっていない。F田のPHSでネットにつなげたので、この辺で有名なラーメン屋を検索。冨士屋というところで食べた。結構おいしかった。 帰りにお酒やらなにやらを買って、ホテルで飲んだ。が、飲み過ぎて一瞬で寝てしまった・・・。 *朝は起きた。ぼくの耳元で鳴るぼくの携帯電話で起きた隣に寝ていたH崎に起こされた。ぉーん。 朝起きて、後楽園の近くへ。 後楽園は眺めがきれいで、本格的なカメラマンも風景を撮影していた(笑 後楽園はきれいそうだったので入りたかったが、時間の都合であきらめ。 ちなみに、岡山の歩道は驚くほど広い。そして、町並みはきれいだし、とても住みやすいところではないかと思う。なんか、町全体に余裕が感じられる。F田曰く「岡山に住むのもいいな。秋葉原があれば」と。 そして、ついに四国へ！

姫路城 名古屋からちんたら電車に乗って姫路へ。 姫路といったら姫路城。というわけで、日本一美しい景観を誇るという姫路城へ向かった。 姫路城2 姫路城には、人を惹きつける美しさがある。ぼくは美術的なものに関してなにも知らないのでちゃんと説明はできないが、その白さのためか、形によってか、それとも配置のせいなのか。とにかく、きれいだった。 天守閣から 左の写真は天守閣最上階から見下ろす姫路城。その高さのおかげで、ものすごく眺めがいい。 姫路城で見つけたおもしろい物。 石垣には、古墳の石棺が使われている。なんと罰当たりな・・・。 罰当たり 外国人に受けそうな、腹切丸(Harakiri Maru)に笑みを隠せない観光客と、そこで切腹する人(笑 腹切丸へ 切腹 姫路では名産品(ということに決めた)穴子の料理を食べるつもりで必死で探したが、結局食べられず。あきらめて岡山へ。

ムーンライトながら号で寝ながら名古屋へ到着。名古屋で途中下車する目的はただ一つ 「名古屋が世界に誇る喫茶マウンテン」 へ行くことである。 マウンテン看板 とりあえずは有名なマウンテンに着いたことを喜び、中に入ってメニューを閲覧。楽しそうな名前のメニューばかり。 メニュー ぼくは「なベスパ」に挑戦。鍋焼きうどんのスパゲッティーバージョンと思われる。おいしそう。 1番に来たのはF田の「みそ煮込みスパ」 みそ煮込みスパ 「なぜスパゲッティ？」という疑問は押さえられないが、なかなかおいしそう。 次にぼくの「なベスパ」登場。 なべスパ 鍋の液体の部分がスパになったものが登場。鍋がゆでたスパゲッティで埋まってる。 もう、戦う前から降伏せざるを得ない感じです。 全員が衝撃を受ける中、U野の甘口いちごスパ登場。 甘口いちごスパ 見た目だけで既に衝撃だが、この赤いスパゲッティ(と呼ばれている何か)。砂糖が織り込まれていて甘い。 数十分の格闘の末、まずみんなの力でナベが空に。そして甘口いちごスパも完食。そしてH崎は灰になった(笑 完食 灰に・・ このお店のすごいメニュー、その原因は間違いなくマスターにある。 ぼく　「すみません、お箸もらえますか？」 マスター「手で喰えやー」 マスター「皿もいるか？」 ぼく　「いえ、箸を落としてしまっただけなので」 マスター「じゃぁ拾って使えやー」 そして、驚くべきことに我らがO住は、マスターと顔なじみだった。何度も来ているのを覚えていたそうだ。 さらに彼がT大生であることを見抜いた。 マスター　「こいつ、T大生に見えるよな？」 ぼく　「確かに！そんな気がしますね(笑」 そんなこんなでみんなで記念写真を撮ることに。 ぼく　「一緒に写真入ってもらえませんか？」 マスター　「おぅ。オレもそろそろお見合いしないといけねぇからな」 マスター　「シャッターはあそこの席のおネェチャンに頼んでこいや」 ぼく　「すみません、写真取ってもらえませんか？」 誰か　「は・・はい(笑」 なぜかお客さん　「兄ちゃん。電話番号と住所も聞いときなよ」 マスター　「いや、おネェチャンは店入った時から目ぇつけてたんよ」 そんなこんなで記念写真が撮れました。 マスターと記念写真

実はこれはあんまり書くことなかったり。 TAの菅原さんに「どうしてコンパイラ演習もHW演習もあるのに、シミュレータ演習はないんですか？」と聞いたら、「シミュレータくらいなにも教えなくなってそれくらい書けるだろ？(意訳)」とのことだったが、確かに「そうですよね」と言うしかない程度。 パイプラインや命令フェッチタイミング、キャッシュなどを考慮したシミュレータは、ハードウェア係がハードウェアを実装開始する前に実装してもいいと思う。実機よりもずっとデバッグしやすいし、タイミングが問題になる部分があるとシミュレータを実装していて書き方に困る。 シミュレータに関連してやった面白いことは、せいぜいグラフィカルなバージョンを作ったことくらい。 ・DirectXを久しぶりに触ってみたかった ・中間発表での単なるパフォーマンス という不純（？）な動機によって開発されたが、命令の並列度が低いと、それを視覚的に目の当たりにせざるを得なくなる。そういう意味では自分のやる気を引き出すのには有用だっただろう。 実際にはできなかった妄想としては「向上余地検知システム」があった。これは、効果的な複合命令などを多くの自動実験を元に探し出すという代物。面白いかな？と思っていたが、コンパイラ係海野がどんどん数値に基づいた改善案を出してくれていたので、これを実装する意味(言い訳)はなくなってしまった。 それから、バーチャルマシン。これは普通に面白そうだし、レイトレのようにシステムコールが発行されないターゲットはお手軽な気がする。うちの班のアセンブリがまともな速度で実行できるとなれば、CPU実験用のMLコンパイラもある程度まともな用途に使えることになるし、今からやってもいいかもしれない。

1月くらいになって、この「アーキテクチャは失敗だった・・・」となってはまずいので、10月にアーキテクチャを決める前にはプロセッサアーキテクチャに関する文書を結構読んだ気がする。なんでこのあとに計算機構成論の試験がないんだろう？ それはさておき、アーキテクチャを考えるに当たって「全てのことには理由がある」というのを重視した。アーキテクチャの細部に至るまで、適当に決めるのではなく、それが最善であるという理由付けができるように心がけた。これは、ぼく以外の3人を説得するためでもあるし、つい役に立たないものを実装するという無用な労力を避けるためでもある。 VLIWっぽいのにするかSuperScalarっぽいのにするかは結構悩んだ。まともなレベルのスケジューリングは1MゲートのFPGAではムリそうだったので、VLIWにすることに。VLIWだと予測分岐付きSuperScalarと比べて、分岐周辺でのオーバーヘッドが大きいのでそこら辺は注意が必要。それから、インストラクションキャッシュのサイズも問題になる。 インストラクションキャッシュミスの問題はnopをランレングス法みたいに圧縮するか、可変長バンドルかなにかで解決できるという考え。結局はキャッシュサイズは余り問題にならなかった(か、コンパイラ係海野の努力で問題が消された)ため、どちらの方法もとられなかったが。 分岐周辺については、予測分岐によって分岐のなくなった命令列に対してスケジューリングを行われてしまってはソフトウェアによる静的スケジューリングの勝ち目はないので、Predication(述語付き命令)による分岐除去で対応することに。アーキテクチャ設計時にはソフトウェアパイプライニングの実装も考えていたので、その障壁をとりのぞくという意味もあった。（結局ソフトウェアパイプライニングは効果が薄そうということで実装しなかったが） 命令形式については、ハードウェアによるデコードができるだけ簡単になる方法を選んだ。こんなところで貴重なハードウェア資源を使っている余裕はない。命令の最初にどの演算器に投入すべき命令かをめいきすることにより、デコードの手間を軽減した。 ある夜プレディケーションの有効活用について考えていたとき、命令のPredicationを指定するの部分に1ビットを加えて、横のPredicationの真偽を反転するかどうかを指示することを思いついた。この方法だと、複数の命令について「両方は絶対に発行されない」ことを簡単に見抜くことができ、複数クロック命令も1クロック差や場合によっては同時に発行できる。 この機能は例のごとくどこかの誰かが既に論文で発表しているかもしれないが、とりあえずは独自のものだと考えている。オリジナルってなんか気分いいよね。 ハードウェア担当のLadiemonが去年の平木班でLambdaユニットという即値テーブルを採用していることに気づき、うちの班でもそれを採用することにした。初期は複数のソースレジスタを結合して１つの即値を表していたが、2slot(当初は3slot)にしてからは命令長に余裕が出たので１つのオペランドとした。 搭載する命令については、完全に海野によるレイトレソースの分析によった。非常に早い段階でソースコードの全貌を解析してくれたことと、11月はじめまでにコンパイラが完成したことでアーキテクチャの細部の設計をレイトレに最適化することができた。 また、植松さんがほとんどの搭載可能性命令をHW実装してくれたため、ある命令がSW実装である場合とHW実装である場合のXXクロックまたはXXスライスといったトレードオフが具体的な値で分かり、適切な方を選ぶことができた。 レジスタへの書き込みを安全に行うには、1クロックで複数のレジスタへの書き込みは難しい。しかし、VLIWである以上何らかの形で複数レジスタの書き込みは行わないといけない。このため、整数と浮動小数点の各レジスタを上下の1つにわけ、4つにする。この4つのうち異なる2つにしか書き込みを行わないという形で問題を解決した。（大住班などでは同時実行する2つの命令は整数レジスタへの書き込みが1つと浮動小数点レジスタへの書き込みが1つとなっていなければならない。この点はうちのHW係の努力に感謝したい） 結果としてみても、うちの班のアーキテクチャは良いものだったと思う。強いて言えば、分岐に関してハードウェア側で高速な処理(命令フェッチ時に即値 or 数名例前に計算済みのアドレスへの分岐など)があれば最強だが、その程度しかさらなる向上のの余地がないと思われる。

終わったのか終わっていないのかよく分からない。 たけど、速度競争という意味でのCPU実験は終わったので、とりあえずまとめ。 今までは「班外秘」ということで(一応)秘密事項であったものが多かったが、もう公開してもOKだろう。 ハードウェア関連の作業(デバッグとか、メモリ周辺とか、基盤配線とか、回路の手動配置とか。)もやったけど、正直そっちは貢献したとは言い難いので、ソフトウェアの方について。 ぼくの主な仕事は ・アーキテクチャの設計 ・シミュレータ ・ソフトウェアスケジューラ の3つ。 と、ここまで書いておいてなんだが、これら3つを1カ所にごちゃごちゃ書くと見にくいので、別の項目として書くことにします。 で、ここには感想。 大変だったといえば、大変だった。「大変なこと=学ぶことが多い」とするなら、学んだことは多いだろう。 自分のソフトウェアの実装については、いくら大変だとはいえ、所詮自分の世界で完結しているので徹夜で実装して数日バグに悩んでむすーっとした顔をしていればできあがるわけだし。 それよりむしろ、自分の班の人たちをどうするかの方が大変だった。やる気がなくなっていそうなら、どうしたらやる気を取り戻してくれるか考え、変な方向へ開発が進みそうなら止め、衝突は回避し・・・。 人数が多ければ、仕事をしたくない人はしなくていいし、誰かが変な方向へ向かってもそれは放っておくだけでいい。 でも今回は、誰一人として失うわけにはいかなかった。リスクが大きいので、賭に出るわけにもいかなかった。 ぼく自身は時間とかを守らない方だけど、それが班員全体の士気の低下に結びつくのではないかと考えるとそうもいかない。 そういう辛さを体感したことが、このCPU実験で得た最大のものだと思う。 プレゼンは、眠くて正直自分自身でも何言っているか分からない感じだったので、聞いていて分かった人はほとんどいないと思う。 ・・・ので、ここにだけでもちゃんと書いておこう。あ、どこかにまとめておいて、来年のCPU実験でうちの班の遺産を取り入れてもらうっていうのもいいな。

急にMacOSX上の開発に関する話。 ユーザーインターフェース関係のことをMac上でやろうとすれば ・Cocoa ・Carbon からどっちか選ばなきゃいけないわけだが、 Cocoa : .Net Frameworkみたいな雰囲気 オブジェクト指向になってる Objective-Cで書かれてる Java bindingも一応程度にはあるが、全機能はサポートされていない Carbon : WindowsのAPIみたいな感じ Cで書かれてる というわけで、まぁCocoaの方が便利そうだし、Appleもこっちを推奨してるから、きっといいことがあるだろう。 だが、問題はObjective-Cとかいう言語。こんなけ毎日変な言語を習得しているわけだから別に新しい言語を習得してもいいけれど、 やっぱり使い慣れるには時間もかかるし、他の言語で書いたコードが(Cからの移行は楽だろうけど)そのまま利用できないのはうれしくない。 ・・・と考えていたのだが、ふと見つけたのがOSX 10.1以降はコンパイラでObjective-C++がサポートされている。 何かと思って調べてみると・・・C++とObjective-Cで相互にクラスを呼び出せるらしい！ ということは。だ。C++からObjective-Cで書かれたCocoaフレームワークを呼び出せる。簡単に言えば、C++でCocoaが使える！ まだちゃんと調べたわけじゃないけど、なんかそういうことらしいです。 でもちょっとネットを漁ると、制限がいろいろ多くて、複雑なことをやるといろいろあるようだ。 もうちょっと調べてみよう。

学科の数人で銀座のアップルストアへMac miniを見物に行きました。いやむしろ買いに行きました。 U野とF田は買う気満々。ぼくも、家に帰って予算計画を立てて、2人の日記で反応を見て明日にでも買おうという勢い。 で、見ていろいろさわって「やっぱMac miniはメモリは512MBに増設しないとまずそうだねー」と行ったところで。2人が購入決意。 商品の在庫があるのも確認済み。学割で買えることも確認して、BTOで512MBメモリで注文。 「16000円になります」 あれ？あれれれれ？いくらアップルストアのメモリが高いからといって、16000はなくないですか？ 256MB→512MBのアップグレードは8000円じゃないんですか？ 店舗のアップルストアでは BTO ≠ 自分の好きな構成にできる BTO = 自分の好きなパーツを同時購入すれば入れ替えてくれる だそうで。512MBを別途購入して、256MBと付け替えてくれるのだそうだ。 つまり・・・いらない256MBメモリを無理矢理8000円で買わされるというのだ。 あぁもうひどいひどいひどい。しかもオンラインで注文すると届くのは2〜3週間後とか書いてあるし。 なんと・・・。今日2人が買って、明日ぼくも買って、日曜には遊べる・・・はずが・・・。 なんてこった。 やはりアップルはその辺が何かおかしいというか何というか・・・・ 。表面上はいろいろなサービスを打ち出してはいるが、やはり全てを自社で何とかするのには限界があるのだろう。他者に何かをやらせるのをいやがるなら、せめてそれをカバーできる能力を備えてほしい。 参考リンク(笑 某外資系企業の罠 8000円で256MB Apple Store