MIST1032SAおよびMIST32アーキテクチャは、H23年度IPA未踏に採択されたOpen Design Computer Projectの一部です。某開発をboostさせる目的での会議にて、開発日記というか開発経過記録みたいなのを付けてほしいといわれたのでこのページを作りました。現在まで採用が決まっている技術などは、MIST32アーキテクチャ決定事項のページであるMIST32をご覧ください。
個々の内容は日々更新します。MIST32アーキテクチャで採用する可能性がある技術または、すでに採用した技術。思い立ったことなど書きなぐっていきます。
命令実行より生じたフラグは、通常他のアーキテクチャではフラグを更新しない命令が続くと、そのフラグが後まで続くような仕組みになっています。つまり、x86において以下のような命令があると、ADD出発生したフラグが、CMPまで伝達される仕組みがあります。これをMIST32ではFlag Chainと呼びます。
x86(AT&T Syntax)
main: add ecx, eax ;eax = eax + ecx mov ecx, ebx ;ecx -> ebx cmp eax, ebx ;compare eax, ecx
当初MIST32においても、このようにFlag Chainに対応させる予定でしたが、With Flagの廃止と、リザベーションステーションの待ち受け項目が増えるという点、さらに昔のようにアセンブリ言語ではなく高級言語で使用される(コンパイラを通す)ことを考慮すると不要であることなどから、Flag Chainを廃止しました。
（書き途中）
一般的なプロセッサにはADCなどといったWith Flag命令が存在します。これはAdd with cary命令と言って、1つ前、または最後にキャリーフラグを更新した命令のキャリーフラグも一緒に加算をするという命令です。この命令はアウトオブオーダ実行において非常に多くの制約を生む原因となってしまうと私は考えていて、MIST32アーキテクチャでは徹底的に排除しています。
With Cary命令は2つの問題点があり、1つは必ず前の命令との依存性ができてしまうということで、2つ目はアウトオブオーダ実行で必須となるリザベーションステーション(待ち受けユニット)において、必ず専用のフィールドを持たなくてはならないということです。
前者の問題においては多倍長演算を行う際に必ず依存性ができるため、直接的な回避は難しいですが、MIST32アーキテクチャでは後者のリザベーションユニットが大きくなってしまうことについては問題と考えています。すべてのリザベーションユニットでフラグ専用のフィールドを持たず、別途専用のレジスタファイルをリネームさせて持たせることも可能ですが、どの程度の大きさで物理レジスタファイルを持つかという設計が重要となり、多くの多倍長演算を行うアプリケーションにおいてフラグ専用のレジスタファイルの制約により性能が制限されてしまうという問題があります。
これらの問題を解決するためにMIST32アーキテクチャではあえてWith Flag命令を排除しています。そして解決方法として多くの汎用レジスタを用意し、フラグを汎用レジスタに格納させるという手法をとりました。たとえば32bitプロセッサのx86プロセッサにおいて64bitの加算を行う場合以下命令で実現可能です。
x86(AT&T Syntax)
main: ;eax source low 32bits A ;ebx source high 32bits A ;ecx source low 32bits B ;edx source high 32bits B add ecx, eax ;Low 32bit ADD adc edx, ebx ;High 32bit & Cary ADD ;64bits Output {ebx, eax}
これに対して、MIST32では同様のことを以下命令にて実現しています。
MIST32(Intel Syntax)
main: ;r0 source low 32bits -A ;r1 source high 32bits -A ;r2 source low 32bits -B ;r3 source high 32bits -B move r4, r0 ;Copy Low 32bits -A add r0, r2 ;Low 32bits Add addc r4, r2 ;Low 32bits Add (Cary Flag only output) add r1, r3 ;High 32bits Add add r1, r4 ;High 32bits & Cary Add ;64bits Output {r1, r0}
上記のようにWith Flag命令を用いる場合よりも命令数が増えているいますが、RISC思考を用いているMIST32アーキテクチャはパイプラインロックが少ないということと、アウトオブオーダ実行される要素があるという点、そして豊富な論理汎用レジスタを用いることができるという点でとても有利になります。さらにこのような多倍長演算は一般的にループ内にて用いられることがいいお為、キャッシュされる可能性が高いという点でもこの方法は有効です。
現在のMIST1032SA : Proccessorでは、BranchとLoad/Storeのリザベーションステーションユニットは個別にしており、これらはインオーダに実行しなくてはならないため発行をコントロールするカウンタを用いて制御しています。一般的に、比較のコンパレータが比較的大きくなりますがリザベーションステーションをユニファイド化するとエントリが有効に使用される可能性が高くなるという特徴があります。 MIST32はリザベーションステーションを極力大きくせず低消費電力化を狙っているため、ユニファイド化をしたいところですが、Branchのリザベーションステーションはそれ以外のリザベーションステーションと比べ、Flag用のフィールド(5bit)を持っています。このためユニファイド化するとLoad/Storeには不要なFlagフィールドも余分に持つ必要があるという問題点があります。
これらを解決する方法としては、Flagフィールドを用いるBranch系のために別途Flag用のリザベーションステーションをリンクさせることでユニファイド化した際に無駄なフィールドを持たずに恩恵を受けることが可能となります。Load/Storeのアウトオブオーダ実行を行う際はこの方法は用いることができませんが、インオーダで行うという制約のもとであれば問題なく実装可能です。
BranchとLoad/Storeのリザベーションステーションユニットのユニファイド化はこのような構想はしておりますが、現在まだ取り入れておりません。
MIST32アーキテクチャは、特定高級言語へ特化したアーキテクチャではありません。特定の高級言語に最適化する場合、どうしても1つの命令で多くの処理を行うというCISC寄りになります。また、現在プロセッサレベルで見た場合の主要な高級言語はCまたはC++と想定しており、MIST32アーキテクチャは完全ロード/ストア型のRISCプロセッサとして命令レベルでの並列化によりパイプラインをいかに命令で埋めるかという点に対して、重点を置いています。