« いよいよ天皇杯ですが、台風が心配 | トップページ | 岡山一成 決勝ゴール »

2014/07/12

命令セットアーキテクチャを考える(番外編) 飽和演算

「ぼくのかんがえたさいきょうのめいれいせっと」では、SIMD演算(ベクトル演算)モードでは、自動的に飽和演算(サチュレート演算ともいう)となります。その6の整数加算命令ではSIMDモードについて以下のように書きました。

> ・condition code bitは変化しない。加算結果が最大値を超えた場合には最大値が、最小値(負数で絶対値が最大のもの)を超えた場合は最小値がセットされる(飽和演算)。

同様に、その7の浮動小数点加算命令のSIMDモードでも、以下のように書きました。

> ・SIMDモードの場合、CCR1は変化しない。結果の絶対値が最大値を超えた場合には符号付きの最大値が、計算できない場合にはNaNが返る。

飽和演算って言葉は普通は整数データにしか使わないような感じもするのですが、浮動小数点データだって、最大値付近のデータを加算すれば指数ビットがオーバーフローすることもありえます。ましてや乗算なら。

このような仕様にしたのは、演算結果の状態に応じてフラグをセットするためのCondition Code Registerが1組しかないのに、SIMD演算命令では同時に複数の演算結果が得られるため、CCRをセットしなくても良いようにしようという発想からであり、積極的に飽和演算機能を備えようと思ったからではありません。CCRが複数あると、条件付き分岐命令の際にどのCCRを見ればいいかとか、ややこしくなることも頭にありました。

普通の計算処理においては、計算結果がオーバーフローなどしたら変に丸めたりしないで、別の処理をとる必要があることがほとんどと考えています。その場合にはSIMDモードは使用できず、スカラーモードで繰り返し計算をしていただく必要があります。

つまり、「ぼくのかんがえたさいきょうのめいれいせっと」アーキテクチャではSIMD演算命令は自動的にすべて飽和計算モードになってしまい、それが嫌ならスカラーモードで繰り返し計算してください、という考え方です(でした)。


前置きが長くなってしまいましたが、「これでよかったのかなぁ」というのがこの番外編のテーマです。

「飽和演算になってしまうのは嫌だけど、SIMD(ベクトル)演算は必要だ」というニーズが多ければ、考え直さなければなりません。

その場合には、CCRをスカラー演算用セットの他に、ベクトル演算用にあと7セット(SIMD演算モードは最大8個のデータ処理を同時に行なうため)または8セット(スカラー演算用CCRとは別にする場合)追加すれば可能です。演算結果のどれかが例外割り込みが必要になった場合には、割り込み処理を呼び出し、あとは割り込みルーチン内でどの演算結果が(複数個の場合も含めて)例外になったのかどうかを判断して処理してもらえればいいでしょう。そのためには、CCRの内容を汎用レジスタに転送する特殊命令も必要そうです。
なお、条件付き分岐命令ではSIMD命令でセットされるCCRは見ないことにしてしまいましょう。


逆に、SIMDではない普通の(スカラー)演算で、飽和演算モードは必要でしょうか。
飽和演算モードが必要な場合、別の命令コードを起こしたり命令モードビットを立てるのは、命令フォーマットに余裕がないことから避けたいです。

その3の丸めモード指定レジスタを拡張して、飽和演算モードビットを追加するのが良さそうです。

> [Rounding Mode Register(Read/Write)]
> ・浮動小数点演算の丸め処理のモードを指定する
> ・特権モードでのみ設定可能、ユーザプログラムからは読み取りのみ可能。

その3を書いた時点では、この特殊レジスタはシステムに1個(各スレッドで共通)という想定でしたが、プログラムで丸めモードを変更するということになると、ユーザプログラムからも設定可能で、スレッド切り替え時には退避されるようにする必要があります。

|

« いよいよ天皇杯ですが、台風が心配 | トップページ | 岡山一成 決勝ゴール »

コメント

この記事へのコメントは終了しました。

トラックバック


この記事へのトラックバック一覧です: 命令セットアーキテクチャを考える(番外編) 飽和演算:

« いよいよ天皇杯ですが、台風が心配 | トップページ | 岡山一成 決勝ゴール »