18. 例外処理¶
ベクトル命令の実行中に例外が発生した(同期例外もしくは非同期割り込み)場合、既存のCSRには例外が発生したベクトル命令の命令アドレスが書き込まれ、vstartCSRには例外が受け付けられたベクトル命令の要素インデックスが書き込まれる。
vstartCSRを用意したのは、割り込みレイテンシを削減するために命令の実行再開を許という機構を用意するのと、命令を前に進める処理(forward-progress: xxx)を保証したかったためである。これはIBM 3090ベクトル機構と似ている。vstartCSRを使わずにForward Progressを保証するためには、ベクトル命令は常に命令実行中に例外を発生せずに、アトミックに命令実行を完了させる必要がある。これを特にストライド命令、スキャッタ・ギャザ―命令で保証する、さらにデマンドページングの仮想メモリで保証するのは難しいためである。
18.1. 正確なベクトル例外¶
正確なベクトル例外には以下の要件が必要となる :
- 例外が発生したベクトル命令よりも前のすべての命令はその結果をコミットしている必要がある。
- 例外が発生したベクトル命令よりも後ろの命令はアーキテクチャの状態を変えていない。
vstartCSRに格納される例外が発生したベクトル要素インデックスよりも前のベクトル要素については、その結果をコミットしている必要がある。vstartCSRに格納される例外が発生したベクトル要素インデックスおよびそのインデックスよりも後ろのインデックスのベクトル要素については、アーキテクチャ状態を変更していないか、命令実行を再開し完了後に正しいアーキテクチャ状態に変えている必要がある。
我々は、一番最後の制約を緩和しており、vstart以降のベクトル要素については例外が発生した時点については状態を更新していても問題なく、vstartから命令実行を再開したとしても再実行によりその要素の状態を上書きすればよい(xxx:
意味不明)
ほとんどのスーパバイザモードの環境では、正確な例外が必要であると想定している。
上記に示した以外に、ベクトル命令はその入力オペランドを上書きしても構わない。そしてほとんどのケースでは、例外が発生した場合ベクトル命令はvstartから命令実行を再開する。しかし、いくつかの命令ではこのオペランドの上書きを禁止している。これは、任意の場所から命令実行再開を可能にするためである。
18.2. 不正確なベクトル例外¶
不正確なベクトル例外では、正確でない例外である。特に、*epcよりも新しい命令が結果をコミットしており、*epcよりも古い命令が結果をコミットしていない状況である。不正確な例外は、エラーを通知し異常終了することが適切でない応答である場合に使用される。
プラットフォームによっては、割り込み処理が正確でどの、他の例外が不正確であるか指定している場合がある。多くの組み込みプラットフォームでは、不正確な例外しか生成せず、ベクトル命令にとっては致命的なエラーとなることを想定している。したがって再開可能なトラップはそのような環境では必要ない。
18.3. 正確な例外・不正確な例外の選択¶
いくつかのプラットフォームでは特権モードビットにおいて正確な例外と不正確な例外を選択する場合がある。不正確な例外モードでは高速実行が目的であるが、エラーの要因を探すことが困難になる。一方で正確な例外モードでは低速な実行となるが、エラーのデバッグや不正確な例外モードで発生した例外を再現できない可能性もある。
18.4. 交換可能な例外¶
ベクトルユニット内に、スワップ可能な例外モードをサポートできる。これは特殊な命令によってベクトルユニットのマイクロアーキテクチャの状態を保存することができ、不正確なトラップ後に正しく命令を実行することが可能になる。
この機構は、ベースベクトル命令のISAでは定義しない。