Daily Ohkura Info

名古屋からちんたら電車に乗って姫路へ。
姫路といったら姫路城。というわけで、日本一美しい景観を誇るという姫路城へ向かった。

姫路城には、人を惹きつける美しさがある。ぼくは美術的なものに関してなにも知らないのでちゃんと説明はできないが、その白さのためか、形によってか、それとも配置のせいなのか。とにかく、きれいだった。

左の写真は天守閣最上階から見下ろす姫路城。その高さのおかげで、ものすごく眺めがいい。

姫路城で見つけたおもしろい物。

石垣には、古墳の石棺が使われている。なんと罰当たりな・・・。

外国人に受けそうな、腹切丸(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実験でうちの班の遺産を取り入れてもらうっていうのもいいな。