アーキテクチャ

20 Mar

1月くらいになって、この「アーキテクチャは失敗だった・・・」となってはまずいので、10月にアーキテクチャを決める前にはプロセッサアーキテクチャに関する文書を結構読んだ気がする。なんでこのあとに計算機構成論の試験がないんだろう?

それはさておき、アーキテクチャを考えるに当たって「全てのことには理由がある」というのを重視した。アーキテクチャの細部に至るまで、適当に決めるのではなく、それが最善であるという理由付けができるように心がけた。これは、ぼく以外の3人を説得するためでもあるし、つい役に立たないものを実装するという無用な労力を避けるためでもある。

VLIWっぽいのにするかSuperScalarっぽいのにするかは結構悩んだ。まともなレベルのスケジューリングは1MゲートのFPGAではムリそうだったので、VLIWにすることに。VLIWだと予測分岐付きSuperScalarと比べて、分岐周辺でのオーバーヘッドが大きいのでそこら辺は注意が必要。それから、インストラクションキャッシュのサイズも問題になる。

インストラクションキャッシュミスの問題はnopをランレングス法みたいに圧縮するか、可変長バンドルかなにかで解決できるという考え。結局はキャッシュサイズは余り問題にならなかった(か、コンパイラ係海野の努力で問題が消された)ため、どちらの方法もとられなかったが。

分岐周辺については、予測分岐によって分岐のなくなった命令列に対してスケジューリングを行われてしまってはソフトウェアによる静的スケジューリングの勝ち目はないので、Predication(述語付き命令)による分岐除去で対応することに。アーキテクチャ設計時にはソフトウェアパイプライニングの実装も考えていたので、その障壁をとりのぞくという意味もあった。(結局ソフトウェアパイプライニングは効果が薄そうということで実装しなかったが)

命令形式については、ハードウェアによるデコードができるだけ簡単になる方法を選んだ。こんなところで貴重なハードウェア資源を使っている余裕はない。命令の最初にどの演算器に投入すべき命令かをめいきすることにより、デコードの手間を軽減した。

ある夜プレディケーションの有効活用について考えていたとき、命令のPredicationを指定するの部分に1ビットを加えて、横のPredicationの真偽を反転するかどうかを指示することを思いついた。この方法だと、複数の命令について「両方は絶対に発行されない」ことを簡単に見抜くことができ、複数クロック命令も1クロック差や場合によっては同時に発行できる。
この機能は例のごとくどこかの誰かが既に論文で発表しているかもしれないが、とりあえずは独自のものだと考えている。オリジナルってなんか気分いいよね。

ハードウェア担当のLadiemonが去年の平木班でLambdaユニットという即値テーブルを採用していることに気づき、うちの班でもそれを採用することにした。初期は複数のソースレジスタを結合して1つの即値を表していたが、2slot(当初は3slot)にしてからは命令長に余裕が出たので1つのオペランドとした。

搭載する命令については、完全に海野によるレイトレソースの分析によった。非常に早い段階でソースコードの全貌を解析してくれたことと、11月はじめまでにコンパイラが完成したことでアーキテクチャの細部の設計をレイトレに最適化することができた。
また、植松さんがほとんどの搭載可能性命令をHW実装してくれたため、ある命令がSW実装である場合とHW実装である場合のXXクロックまたはXXスライスといったトレードオフが具体的な値で分かり、適切な方を選ぶことができた。

レジスタへの書き込みを安全に行うには、1クロックで複数のレジスタへの書き込みは難しい。しかし、VLIWである以上何らかの形で複数レジスタの書き込みは行わないといけない。このため、整数と浮動小数点の各レジスタを上下の1つにわけ、4つにする。この4つのうち異なる2つにしか書き込みを行わないという形で問題を解決した。(大住班などでは同時実行する2つの命令は整数レジスタへの書き込みが1つと浮動小数点レジスタへの書き込みが1つとなっていなければならない。この点はうちのHW係の努力に感謝したい)

結果としてみても、うちの班のアーキテクチャは良いものだったと思う。強いて言えば、分岐に関してハードウェア側で高速な処理(命令フェッチ時に即値 or 数名例前に計算済みのアドレスへの分岐など)があれば最強だが、その程度しかさらなる向上のの余地がないと思われる。

Leave a Reply

Your email address will not be published.