コンピュータアーキテクチャの観点から注目されるのは、スカウトスレッドとトランザクションメモリのサポートである。スカウト(斥候)スレッドは、本来の計算処理を行う実行スレッドの前を走って必要となるデータをメモリからキャッシュに持ってくるという役目のスレッドで、理想通りに動けばメモリのアクセスレーテンシを隠して、実行スレッドの処理時間を短縮することができる。一方、トランザクションメモリは、例えば数百命令からなる処理全体を、他のプロセサから見ると、論理的には一瞬に実行されたように見せる技術で、マルチコアの並列プログラムの書き方を容易にする切り札となる技術として注目されている。このスカウトスレッドとトランザクションメモリは、コンピュータアーキテクチャの学会ではホットなトピックであるが、商用のプロセサで採用された前例はなく、このRockが、これらの技術を採用した最初のプロセサとして記録されることになる。

スカウトスレッドであるが、スカウトが必要なメモリを先取りしてキャッシュにロードして実行スレッドのスピードが向上すると、どうしても実行スレッドが前を走るスカウトスレッドに追いついてしまうので、理想的なスカウトスレッドは存在しない。そこで、いかにして物量と複雑度を抑えて、メモリの先読みなどの性能向上効果を理想に近づけるかということになる。

ISSCCでの論文発表と、筆者がTremblay氏に質問した回答によると、Rockのスカウトスレッドは次のように動く。実行スレッドは、ロード命令がキャッシュミスを起こしたりして長時間の待ちが生じるケースが発生すると、その時点のアーキテクチャ状態をチェックポイントに格納して、実行を停止する。そして、その状態を引き継いでスカウトスレッドが実行を開始し、後続のメモリアクセス要求を発行する。そして、キャッシュミスを起こした最初のロード命令のデータが到着すると、スカウトスレッドを終了して、元の実行スレッドに戻るようである。

スカウトスレッドは、実行スレッドと同様に命令の実行を続け、メモリをアクセスする命令だけでなく、演算命令も実行してしまう。但し、キャッシュミスしたロード命令のデータをオペランドとして使う命令はデータが到着しておらず実行できないので、128エントリの後回し命令キュー(Deferred Instruction Queue)に詰め込み、データが揃っていて実行可能な命令だけを実行して行く。このような処理で、次のロード命令のアドレスが求まっていれば、このロード命令が実行され、メモリアクセス要求が出される。このように、スカウトスレッドにより、次々と後続のロード命令を発行し、メモリアクセスを開始する。

そして、最初にキャッシュミスしたロード命令のデータが到着すると実行スレッドを再開するのであるが、実行スレッドが後続のロード命令のデータを必要とするときには、既に、データは既に到着しているか、到着していない場合でも、到着までの時間が短縮されることになる。

実行スレッドは、再開にあたって、スカウトスレッドが実行した演算命令などの結果は引継ぎ、単に、後回し命令キューに入っている命令を処理するだけと思われる。

このように、前のロード命令が終わらない内に次の命令列の処理を続けて、後続のロード命令を実行するのは、通常のOut-of-Orderマシンでもやられていることであり、どうも、Rockがアウトオブオーダ実行をやっていると言うのと、スカウトスレッドによりメモリレーテンシを隠蔽するというのは、同じことを別の言い方で表現したという感じである。

なお、後回し命令キューは、命令キャッシュから読まれた新たに実行すべき命令のキューと並列の位置にあり、Rockは、何らかのアルゴリズムで両方のキューから命令を選択して、実行パイプラインに投入している。このような処理を行うと、ある時点で見ると、プログラム順で前にある命令が後回し命令キューに残って、実行されておらず、後の命令は実行が終わっているという矛盾した状態が生じる。このような状態で例外が起こると、例外処理からの復帰が難しいという問題がある。この点についてTremblay氏に質問すると、最初のキャッシュミスでスカウトスレッドを起動する時点で、チェックポイントを作成するので、後回し命令キューやその他の命令の仕掛り状態をクリアして、チェックポイントの状態を回復することで整合性の取れた状態を回復できる。また、外部割込みの場合は、後回し命令キューの命令を全部実行してしまってから例外処理に入るという手も取れるという回答であった。