Open Design Computer Project

オリジナルCPUから作る本格的自作コンピューター

ユーザ用ツール

サイト用ツール


hardware:log

開発日記

MIST1032SAおよびMIST32アーキテクチャは、H23年度IPA未踏に採択されたOpen Design Computer Projectの一部です。某開発をboostさせる目的での会議にて、開発日記というか開発経過記録みたいなのを付けてほしいといわれたのでこのページを作りました。現在まで採用が決まっている技術などは、MIST32アーキテクチャ決定事項のページであるMIST32 Processor Architectureをご覧ください。

個々の内容は日々更新します。MIST32アーキテクチャで採用する可能性がある技術または、すでに採用した技術。思い立ったことなど書きなぐっていきます。

2012/01/24 [MIST32] MIST32の特徴を生かした高性能化の計画1 マクロフィュージョンする

これから書くことはあくまで計画やアイディアであり、本当に採用するかわかりません。自分のメモのためにまとめてみます。

MIST32の命令セットは2オペランドです。gccでコンパイルされた結果次のような命令が頻繁に発生します。

  1. MIST32 ASM
main:
	move	r1,	r0		;r1 = r0
	add	r1,	1		;r1 = r1 + 1

これは要はr1 = r0 + 1と全く同じことです。このような例は良くあることであり、同じような状況は良く発生します。3オペランドでは1命令ですが、MIST32が採用している2オペランドでは2命令必要になります。しかし実際には、プロセッサの内部はdestination, source, sourceの3オペランドで構成せざるを得ません。

なので、このような2つのネイティブ命令を内部で1命令にすることによって高速化します。IntelはマクロフィュージョンといってPentium M(Banias)から採用している技術です。Intelがとっている方法は主にCompare命令とBranch命令を1命令にしているようですが、MIST32はx86みたいに汚い命令セットでもないし、もともと単純な命令セットなので、より多くの命令をFusionできるかもしれません。 ただ、これをIn-Orderコアで採用するのはすごく微妙。シンプルな命令セットを持つ利点があまり感じられなくなるからです。

しかしOut Of Orderコアではコア内部の例外とか、タスクのコンテキスト管理などで一部をマイクロコードとして構成する場合があります(ワイヤードでもできるけど複雑化するのでマイクロコードが最適だと思います)。このような場合においてはマクロフィュージョンの追加ハードウェアとしてはμ命令キャッシュの追加のみとなります。でも、もう少し検討が必要ですね、果たしてどの程度恩恵を受けれるか。

2012/07/12 [MIST32] Flag Chainの廃止について(さらに追加)

よくよく考えると、フラグを発生させる命令とそれを参照するブランチ命令がページをまたぐ状態にあり、ページフォルトが起こる場合、つじつまが合わなくなってしまうことに気づきました。具体的には以下のような状態です。

1Page = 16k

main:
	add	r0,	1		;r0 = r0 + 1
	cmp	r0,	r1		;compare r0, r1
--------------Next Page---------------
	b	r2,	#NE		;

cmpとb命令の間がページ教会になっており、このような状態でページフォルトが発生すると、フラグが消えてなくなってしまいつじつまが合わなくなってしまいます。ということで、やはりFlagレジスタの退避は必要でした。

2012/06/14 [MIST32] Flag Chainの廃止について(追加)

Flag Chainをなくすともう1ついいことがあります(見つかりました)。コンテキストスイッチをする際にFlagレジスタのコンテキストを保持しなくてよいという点です。なぜかというと、Flagは次のBranch系命令にのみしか作用しないため、アウトオブオーダにおいてBranchの前の命令でコミットしている状態以外にコンテキストスイッチを発生させればFlagのコンテキストを保持しなくてもよいことになります。

プログラマにはあらかじめフラグは次の1津の命令のみ、そしてそれはブランチ系命令にのみ作用するという制約があるため、ハードウェアでコンテキストスイッチを行うタイミングを、Branch命令を実行してから、またはBranch命令の2つ前の命令がコミットしてから行うという制御を行うことでこれらを実現できます。

2012/04/04 [MIST32] Flag Chainの廃止について

命令実行より生じたフラグは、通常他のアーキテクチャではフラグを更新しない命令が続くと、そのフラグが後まで続くような仕組みになっています。つまり、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を廃止しました。

Flag Chainはcase分などにおいて非常に便利ですが、これはcmp命令のそれに置き換えてしまっても速度的に問題ないと考えました。MIST32ではFlag Chainを禁止し、直近のブランチ系命令のみ受け付けるようにしたことでハードウェア規模を抑えました。

2012/02/20 [MIST32] With Cary命令の置き換えについて

一般的なプロセッサには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 & Carry 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 (Carry Flag only output)
	add	r1,	r3		;High 32bits Add
	add	r1,	r4		;High 32bits & Carry Add
 
	;64bits Output {r1, r0}

上記のようにWith Flag命令を用いる場合よりも命令数が増えているいますが、RISC思考を用いているMIST32アーキテクチャはパイプラインロックが少ないということと、アウトオブオーダ実行される要素があるという点、そして豊富な論理汎用レジスタを用いることができるという点でとても有利になります。さらにこのような多倍長演算は一般的にループ内にて用いられることがいいお為、キャッシュされる可能性が高いという点でもこの方法は有効です。

2012/02/09 [MIST1032SA] BranchとLoad/Storeのリザベーションステーションについて

現在のMIST1032SA : Processorでは、BranchとLoad/Storeのリザベーションステーションユニットは個別にしており、これらはインオーダに実行しなくてはならないため発行をコントロールするカウンタを用いて制御しています。一般的に、比較のコンパレータが比較的大きくなりますがリザベーションステーションをユニファイド化するとエントリが有効に使用される可能性が高くなるという特徴があります。 MIST32 Processor Architectureはリザベーションステーションを極力大きくせず低消費電力化を狙っているため、ユニファイド化をしたいところですが、Branchのリザベーションステーションはそれ以外のリザベーションステーションと比べ、Flag用のフィールド(5bit)を持っています。このためユニファイド化するとLoad/Storeには不要なFlagフィールドも余分に持つ必要があるという問題点があります。

これらを解決する方法としては、Flagフィールドを用いるBranch系のために別途Flag用のリザベーションステーションをリンクさせることでユニファイド化した際に無駄なフィールドを持たずに恩恵を受けることが可能となります。Load/Storeのアウトオブオーダ実行を行う際はこの方法は用いることができませんが、インオーダで行うという制約のもとであれば問題なく実装可能です。

BranchとLoad/Storeのリザベーションステーションユニットのユニファイド化はこのような構想はしておりますが、現在まだ取り入れておりません。

2012/02/06 [MIST32] 特定の高級言語への最適化について(RISC思考について)

MIST32アーキテクチャは、特定高級言語へ特化したアーキテクチャではありません。特定の高級言語に最適化する場合、どうしても1つの命令で多くの処理を行うというCISC寄りになります。また、現在プロセッサレベルで見た場合の主要な高級言語はCまたはC++と想定しており、MIST32アーキテクチャは完全ロード/ストア型のRISCプロセッサとして命令レベルでの並列化によりパイプラインをいかに命令で埋めるかという点に対して、重点を置いています。

  • CISCの特徴
    • CISCの場合非常に大きな処理を1つの命令で行おうとします。そうすると命令長は可変長になりやすく、キャッシュの1ラインに1つまたはそれ以上の命令が収まらない可能性が出てきており、メモリアクセスを要求される可能性がRISCよりも増えると考えています。現在のようにプロセッサに比べメモリが非常に遅い場合において、メモリアクセスは非常に多くのレイテンシが発生します。
    • CISCの場合命令長が可変であることが多く、それはデコーダを複雑にしてしまうという問題があります。また可変長なためにメモリアクセスのアライメントが完全自由になり、ハードウェアハードウェア規模での欠点が挙げられます。しかし、これはメモリ効率という点では利点であり、組み込みMPU等においては非常に効率が良い方法です。
  • RISCの特徴
    • RISCでは1つの命令がCISCに比べて非常に単純な命令です。命令が単純になるということはプロセッサの規模も最低限に抑えることが可能となり、消費電力に対して有利となります。しかし、単純な命令をいかにパイプラインに埋めることができるかということが、RISCにおいて非常に重要な部分となります。
    • RISCにおいては命令レベルでのスケジューリングが容易に行うことができます。それは1つの命令が単純なため、命令間における依存性の解釈を容易に行えるという点があります。MIST32アーキテクチャでは、できるだけ副作用を発生させる命令を排除し、一般的な命令にて置き換えることを命令アーキテクチャレベルで要求しています。CISCにおいても高性能をうたっているものはuCodeを用いてRISC命令に変換して同じようなことをやっていますが、CISC命令のデコードに多くのハードウェア規模を割いてしまったり、キャッシュのヒット率などで足を引っ張ってしまいます。
hardware/log.txt · 最終更新: 2013/07/22 00:24 by hktechno