組み込まれたエンジニア

我輩は石である。名前はまだ無い。

SS版 SN/X更新

2008-07-31 22:44:37 | Weblog
今週で一連の講義は一応終了したのだが、Qパイプの分岐予測が気持ち悪かったし、少なくともQパイプのBZ命令の予測ミスの処理はバグっていることを確信していたので、多少修正。

修正のポイントは、分岐予測を同一クロックスロットでの予測と考えることで対応。(つまり、同一読み出し単位に二つの分岐が入ると、エントリの競合による性能低下を起こすが、普通はないことなの無視)


1)QパイプBZ命令not takenのtaken予測ミスの処理は、PCとの比較対照をQパイプの次命令アドレスとする(Pパイプと同一)

2)Qパイプのtaken予測ミス時にも、分岐予測バッファへの登録を行う。

これによって、ソートの例題で、11256クロックから10838クロックと400クロック以上の大幅な性能向上を得た。(もちろん、実行結果は同一)

先日のファイルに上書きしたので、ダウンロードは、ここ(IP ARCH, Inc.)から。

VISTAのWindowsディレクトリ

2008-07-25 11:34:57 | Weblog
sfl2vlのライセンスファイルをWindowsディレクトリに入れたが、なぜか古いファイルに置き換えられて、新しく入れたものにならない?
何度、古いファイルを消して入れなおしても同じように、古いファイルが復活する。

おそらく、何かしらの保護機能が働いているのかもしれないが、付き合っていられないので、古いファイルの中身を編集し、新しい内容に入れ替えて使っている。

VISTAって・・・

SN/X スーパースケーラ版

2008-07-24 21:20:25 | Weblog
そもそも、SN/Xはレジスタが少ないので、ほとんど2つのパイプがぶつかり、あまりスーパースケーラの効果はないのだが、サンプルとして作ってみた。

サンプルなので、とりあえず、やっつけ仕事で作ってみたが、まだバグが取りきれていない。アセンブラにも手を入れないと、PパイプでHLTしたときに、Qパイプにハザードデータが読まれて安全に停止できない・・

来週まであまり時間が取れないので、デバッグしていただける方がいたら、ご協力お願いします。


分岐予測と、ロードサプレスの条件が問題でした。とりあえず、解決したつもり。
その他のバグがないとは言い切れませんが・・
(コンパイルには20080717版のsfl2vlが必要です)

スーパースケーラ版 SN/X SFLファイル

同 テストベクトル


分岐予測はPパイプ(メイン側)しかしません。Qパイプでの分岐は必ず予測ミスとして分岐ストールを発行します。メモリはどちらのパイプも任意のアドレスから実行可能としてます。(普通は、アドレス固定するのですが、簡単のため。)
Pパイプでメモリ参照するときには、Qパイプはストールします。
等々、相当サボった実装なので、性能向上の役にはあまり立ちません。

sortの例題でパイプラインのデータキャッシュ付きに比べて、150クロック程度の
向上にとどまっています。

レジスタは4R3Wに変更しています。
LD/STがぶつからないようにしているので、キャッシュは2本のパイプで共用。

sfl2vl小変更

2008-07-17 22:45:46 | Weblog
先日、分岐予測のユニットを設計しているときに、SFLの仕様として、

submodule.control_output_term

を論理として参照することは許されているが、

submodule.control_input_term().control_output_term

を参照することが許されていないことに気が付いた。
これ、案外不便なので、この形を許容するようにsfl2vlを変更した。
20080717版からのサポートである。

SN/Xにおける割込みサポート

2008-07-16 16:17:46 | Weblog
テキストの巻末付録にはこっそり割込みをサポートしたパイプラインCPUのソースコードを掲載しているが、それとは、少し違うアーキテクチャで割込みをサポートしてみよう。


  1. 割込みベクタ、割込み時PCの格納先をデータメモリ1,0番地とする
  2. 割込み復帰用にメモリ間接分岐命令(BRI)を作り、この命令で割込み許可を可能とする
  3. ソフトウェア割込み命令(EXR)を追加
  4. 割込み入力信号ピンを追加
  5. リセット時は割込み禁止
  6. アドレス最上位ビットが1のアドレスをIO空間とし、キャッシュしない
  7. 割込み刈取りはソフト責任


などの特徴を持たせる。

割込みピンが追加されていたりするので、テストベンチも変更する必要があるし、命令追加に対応するため、アセンブラにも手を入れなくてはならないが、必要な人は個別に連絡をいただくとして、とりあえず、

SN/Xに割込みを追加するパッチ

と、

割込み付きパイプラインSN/Xのソース

をアップしておこう。

追記:このソースは、割込みがクロック同期であることを前提としています。
実用的にするには、CPU内部で割込み信号を同期化しましょう。

SN/Xデータキャッシュパッチ

2008-07-14 09:45:05 | Weblog
本来ならば明日某所で解説を行った後にブログに載せるのだけれど、一日前倒しで掲載して、明日はこのパッチを用いて解説してしまおう。

SN/Xをパイプライン化したときに、制御ハザードは分岐予測で押さえたが、ロード命令に起因する真のデータハザードは対処していなかった。命令実行のステージで、キャッシュを引くことができれば、他の命令と同じタイミングでレジスタ書き込みが行えるので、データハザードを起こさなくなる。

例題では元々メモリへのアクセス頻度が局所的なので、比較的小容量のキャッシュでOKであり、アドレス計算をしたとしても、小容量のキャッシュアクセスは実行ステージで実施しても遅延の問題は少ないだろう。

フルのキャッシュを用意するのは大変なので、分岐予測ユニットを流用して、ストアデータキャッシュとして利用できるようにしておく。

パイプランSN/X データキャッシュパッチ


snxp.patch~snxp4.patchまで、全てターゲットは snx.sfl にしているが、各パッチはインクリメンタリに作成しているので、順を追って差分を読んでいく方が分かりやすいかもしれない。

7/16追記:
受講生のI氏がロード時にもキャッシュ登録して効果があったので、ロード時登録をするデータキャッシュパッチを作成しておいた。(自分のサンプルはメモリデータはすべてストア命令で作っていたので、あまりロード時登録の効果は多くないかと思っていたが、何しろエントリ数が極少なので、十分な効果が得られる)


パイプランSN/X データキャッシュパッチ2



高円寺:とんかつ&ステーキ 宕(HIRO)

2008-07-09 13:13:09 | Weblog
学生のころ、高円寺に住んでいた。

このところ毎週東京に出ているので、
そのころ(ウン十年前)に訪れた店を訪ねてみた。
宕は私がいた当時はステーキ系のメニューしかなかったが、
とんかつも始めたらしい。もっとも、前の店は、「とんかつ とんき」の
目の前だったので、とんかつでわざわざ競争する必要はなかったのだろう。

そのころ、宕では、サービスステーキ定食が1000円で、
かなりやわらかくてよい肉を使っていたが、再び訪れてみると、
今でもステーキ定食は1000円のままだ。

まるで時間が止まっているかのように、同じ値段で、しかも、
肉もそのころと同じくおいしい♪

そのころ、高円寺に数店展開していたニューバーグは1店だけに
なってしまっているけれど、まだ健在だ。
ローズ亭も店の前まで行って見てきたが、おばちゃんは相変わらずらしい。

高円寺という街、まるで時間が進んでいないかのように懐かしい。

高円寺銀座が「純情商店街」になってしまったのは、いまいちだったが・・

SN/X分岐予測パッチ

2008-07-08 18:39:10 | Weblog
パイプライン化したSN/Xの制御ハザードを低減するために、分岐予測が有効である。

分岐予測は、単純な仕組みで効果がある。

分岐ターゲットバッファをダイレクトマップ4エントリ用意した、分岐予測パッチを作成した。

パッチを当てるときには、

patch -l snx.sfl snxp3.patch -o snxp.sfl


のように、空白の解釈で失敗しないようにオプション設定をすることに注意。

LSIレイアウトソフト:GNU Electric

2008-07-03 20:50:44 | Weblog
LSIレイアウトのフリーソフトで有名なものとして、Magicがある。これは、とても便利だし、軽快なのだけれど、UNIXとXwindowが必須なので、環境によっては実習に使うことが難しい場合がある。

前々からGNU Electricには興味を持っていたが、今年度、ようやく、このソフトでLSIレイアウトの演習にトライしてみた。

演習の内容を大槻氏に演習指導書としてまとめてもらったので、色々と活用できそうだ。


SN/X レジスタ書込みポート 2ポート化パッチ

2008-07-02 19:19:57 | Weblog
レジスタの書込みポートを2ポート化することで、LD命令と後続の演算命令が異なるレジスタに書込みを行うときには同時に実行可能で、ストールを減らせる。

ただ、普通のプログラムを実行するときには関係ないが、LD命令と後続の演算命令が同一のレジスタに書き込もうとすると、レジスタの同時更新となって、データが破壊される。

この場合、先行するLD命令の結果は使わない(後続命令によって上書きされる)ので、LD命令の実行をキャンセルする必要がある。

もちろん、普通はコンパイラはこんなコードを出さないので、チェックの必要性があるのかどうかも疑問だが・・


とりあえず、レジスタ競合の回避パッチを含めた、2ポート化のパッチを用意した。