(57)【特許請求の範囲】
【請求項１】
最適化あるいは順序を変えることなく、第１の命令セットアーキテクチャによるバイナリ表現のプログラムによって、コンピュータＣＰＵからバスへメモリ参照を発行する工程と、
前記第１の命令セットアーキテクチャによるバイナリ表現のプログラムにおけるメモリ参照によりバス上でアクセスされたデバイスが正しく挙動するメモリかまたは正しく挙動しないメモリかをコンピュータの記憶装置に記録する工程であって、前記正しく挙動するメモリとは、読み出しにより、メモリ領域に最後に記憶されたデータを受け取るメモリであり、かつ、前記正しく挙動しないメモリとは、読み出しにより、前記メモリに状態を変えさせる特性か、読み出しにより、最も最新に前記メモリ領域に記憶されたデータを必ずしも返さない特性か、あるいは、２つの連続する読み出しにより、区別されるデータを返すメモリ特性のいずれか一つを持つメモリである工程と、
少なくともプログラムのバイナリ表現のセグメントを、前記第１の命令セットアーキテクチャから第２の命令セットアーキテクチャへ変換する工程であって、正しく挙動するメモリに向けられると考えられるメモリ参照を、正しく挙動しないメモリに向けられると考えられるメモリ参照と区別するために、前記記録を使用し、その使用によって、前記第１の命令セットアーキテクチャから第２の命令セットアーキテクチャへ変換する際に、メモリ参照は正しく挙動するメモリに向けられていると考える工程と、
前記第２の命令セットアーキテクチャにおけるプログラムの前記変換されたセグメントを実行する工程と、
変換時に正しく挙動するメモリに向けられると考えられたが、実行時に正しく挙動しないメモリに向けられると判明したメモリ参照を識別する工程と、
識別されたメモリ参照を中断する工程と、
プログラムの前記変換されたセグメントの少なくとも一部分を、前記第１の命令セットで再実行する工程とを含む
コンピュータのメモリを参照する方法。
【請求項２】
前記変換されたセグメントを実行する工程の後に、
前記第２の命令セットアーキテクチャへ変換する工程においてコンピュータＣＰＵによって実行された命令により開始されたメモリ参照を監視し、そのメモリ参照が論理アドレスを参照するものである工程と、
論理アドレスを物理アドレスに変換し、その変換が参照のメモリページが保護された状態にあるかどうかを評価する工程を含むものである工程と、
前記メモリページが保護されていない場合、前記メモリページを保護された状態にし、それによって前記メモリページが他の命令によって修正されることがないようにする工程とをさらに含む請求項１記載の方法。
【請求項３】
前記再実行する工程は、命令のメモリ参照が、正しい挙動を保証できないデバイスを参照する場合、代替実行モードで前記第２の命令セットアーキテクチャにおける命令を再実行する工程を含む請求項１記載の方法。
【請求項４】
入出力空間への参照が正しく挙動しないメモリへの参照として記録される請求項１記載の方法。
【請求項５】
前記変換する工程において、前記記録の形式が、前記プログラムの命令によって消費され、あるいは操作されたデータに対する参照を必要とせずに、メモリ参照が正しく挙動するメモリかまたは正しく挙動しないメモリへのものであったかの判定を可能にする請求項１記載の方法。
【請求項６】
前記記録の形式が、メモリ参照を発行した命令のアドレスを示す請求項１記載の方法。
【請求項７】
前記メモリ参照がロードである請求項１記載の方法。
【請求項８】
前記記録が、主にプログラム制御フローを記録するプロファイルの一部である請求項１記載の方法。
【請求項９】
前記変換する工程は、バイナリ変換プログラムによって、前記記録を読み出す工程を含み、前記バイナリ変換プログラムは、少なくともプログラムのバイナリ表現のセグメントを、第１の命令セットアーキテクチャから第２の命令セットアーキテクチャへ変換する処理を行うプログラムである請求項１記載の方法。
【請求項１０】
メモリ参照が正しく挙動しないメモリに向けられていることを前記記録が示す場合、前記バイナリ変換プログラムが、メモリ参照を変換し、メモリ参照が最適化されることあるいは順序を変えられることを禁止する請求項９記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
背景
本願は、参照としてここに組み込まれ、１９９９年１月２８日出願の出願番号０９／２３９，１９４の一部継続出願である出願番号０９／３２２，４４３の一部継続出願である、１９９９年８月３０日出願の出願番号０９／３８５，３９４の一部継続出願である。
【０００２】
本発明は、コンピュータ中央処理装置のインプリメンテーションに関する。
コンピュータによる実行のための各命令は、コンピュータのメモリに記憶された２進数として表現される。コンピュータの個々の異なるアーキテクチャは、命令を異なって表現する。例えば、ある命令、つまりある２進数がＩＢＭシステム／３６０コンピュータ、ＩＢＭシステム／３８、ＩＢＭ  ＡＳ／４００、ＩＢＭ
ＰＣおよびＩＢＭ  ＰｏｗｅｒＰＣによって実行される場合、これらの５つのコンピュータは一般に、たとえ５つ全部が同じ会社により製造されていても、５つの完全に異なる動作を実行するであろう。コンピュータの命令のバイナリ表現と、応答してコンピュータがとる動作との間のこの対応は、命令セットアーキテクチャ（ＩＳＡ）と呼ばれる。
【背景技術】
【０００３】
特定のコンピュータファミリーのためにバイナリＩＳＡでコード化されたプログラムは、しばしば単に「バイナリ」と呼ばれる。商用ソフトウェアは一般にバイナリ形式で配布される。前段で指摘した非互換性は、あるアーキテクチャ用のバイナリ形式で配布されたプログラムが一般に別のコンピュータにおいて走行しないことを意味している。従って、コンピュータユーザはあるアーキテクチャから別のものに変わることを極めて嫌がり、コンピュータ製造業者は、各自のコンピュータアーキテクチャを修正する際に限られた範囲に制約される。
【０００４】
コンピュータは、そのコンピュータが一員であるアーキテクチャファミリーのＩＳＡである、そのネイティブＩＳＡでコード化されたプログラムを最も自然に実行する。別の非ネイティブＩＳＡのコンピュータ用にコード化されたバイナリを本来通りに実行するためのいくつかの方法が知られている。ハードウェアエミュレーションでは、コンピュータは、非ネイティブ命令を実行することに特定的に向けられたハードウェアを有する。エミュレーションは一般に、モードビット、電子スイッチによって制御され、非ネイティブバイナリが実行されなければならない場合、エミュレートするコンピュータにおける特別な命令がモードビットを設定し、制御を非ネイティブバイナリに転送する。非ネイティブプログラムが抜け出ると、以降の命令がネイティブＩＳＡにより解釈される必要があることを指定するために、モードビットがリセットされる。通常、エミュレータでは、ネイティブおよび非ネイティブ命令は異なるアドレス空間に記憶される。第２の代替策は、非ネイティブアーキテクチャのコンピュータをモデル化するコンピュータ上で走行するプログラムであるシミュレータ（時に「インタプリタ」としても知られる）を使用する。シミュレータは、非ネイティブバイナリの命令を順次的にフェッチし、各命令の意味を順番に決定し、非ネイティブコンピュータのソフトウェアモデルにおいてその結果をシミュレートする。シミュレータもやはり、一般に、ネイティブおよび非ネイティブ命令を別個のアドレス空間に記憶する。（用語「エミュレーション」および「シミュレーション」は、産業全体において、ここに含意した定義によって示唆され得る通りに均一に適用されるものではない。）第３の代替策では、バイナリ変換、トランスレータプログラムが、非ネイティブバイナリ（プログラム全体またはプログラムの断片）を入力として受け取り、それを処理し、コンピュータにおいて直接走行するネイティブの命令セット（「ネイティブバイナリ」）の対応するバイナリを出力として生成する。
【０００５】
一般に、エミュレータは、顧客に対する移行支援として、同一製造業者による古いコンピュータアーキテクチャのエミュレーションのために新しいコンピュータにおいて見られる。シミュレータは、同じ目的で提供されるとともに、顧客が所有しない機械のためにバイナリ形式でしか入手できないソフトウェアに単にアクセスしたい顧客が使用するために、独立ソフトウェアベンダによって供給されている。いずれの技法によっても、非ネイティブの実行は、ネイティブの実行より低速であり、非ネイティブプログラムはネイティブプログラムが利用可能な資源の一部にしかアクセスできない。
【０００６】
コンピュータまたはコンピュータプログラムのビヘイビアをプロファイルする公知の方法には以下を含む。公知の１プロファイリング方法では、プログラムによって占有されたアドレス範囲が複数の範囲に分割されて、タイマは時々オフになる。ソフトウェアプロファイルアナライザが、プログラムが実行していたアドレスを計算し、そのアドレスを含む範囲に対応してカウンタを増分する。一定時間後、カウンタは、ある範囲が多く実行され、別の範囲はほとんどまったく実行されないことを指示する。別の公知のプロファイリング方法では、カウンタがコンパイラによってプログラムのバイナリテキストに生成される。これらのコンパイラ生成されたカウンタは、ある領域が実行された回数をカウントするかまたは、ある実行点を通過したかまたはある分岐が取られた回数をカウントすることができる。
【発明の概要】
【課題を解決するための手段】
【０００７】
概要
全体的に、第１の態様において、本発明は、第１および第２の命令セットの命令を実行するように設計された命令プロセッサ、プログラムの記憶用メモリ、ページに対応したエントリのテーブル、スイッチ、遷移ハンドラおよび履歴記録を備えるコンピュータを特徴とする。メモリは仮想メモリマネージャによる管理のためにページに分割される。プログラムは、第１および第２の命令セットの命令でコード化され、第１および第２のデータ記憶規約を使用する。スイッチは、各テーブルエントリに記憶された第１のフラグ値に応答し、命令のメモリページに対応するテーブルエントリの第１のフラグ値による指示に従って代替的に第１または第２の命令セットのもとで命令を解釈するように命令プロセッサを制御する。遷移ハンドラは、プログラム実行が第１のデータ記憶規約を使用する命令のページから第２のデータ記憶規約を使用する命令のページに移行した時を、各ページに対応するテーブルエントリに記憶された第２のフラグ値による指示に従って認識し、その認識に応答して、コンピュータのデータ記憶構成を第１の記憶規約から第２のものに調整するように設計されている。履歴記録は、最近実行された命令の分類の記録を遷移ハンドラに提供するように設計されている。
【０００８】
第２の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。命令データは、コンピュータのメモリの単一アドレス空間の第１および第２の領域からフェッチされる。第１および第２の領域の命令は、それぞれ、第１および第２のアーキテクチャのまたは、第１および第２のデータ記憶規約に従っているコンピュータによる実行のためにコード化される。メモリ領域は第１および第２のインジケータ要素と関係づけられ、インジケータ要素は各々、関係する領域からの命令がそのもとで実行されるアーキテクチャまたはデータ記憶規約を指示する値を有する。命令データの実行が第１の領域からの第２のものへ流れると、コンピュータは第２のアーキテクチャまたは規約における実行に適応される。
【０００９】
第３の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。命令は、仮想メモリマネージャにより管理されるコンピュータメモリのページに記憶される。ページの命令データは、それぞれ２つの異なるアーキテクチャのコンピュータによる、および／または２つの異なる実行規約のもとでの実行のためにコード化される。メモリのページと関係づけられて、ページの命令が実行されるべきアーキテクチャまたは規約を指示する対応するインジケータ要素が記憶される。ページからの命令は共通プロセッサにおいて実行され、プロセッサは、ページインジケータ要素に応答して、その命令のページに対応するインジケータ要素によって指示されたアーキテクチャの、または規約のもとで命令を実行するように設計されている。
【００１０】
第４の態様において、本発明はマイクロプロセッサチップを特徴とする。チップの命令ユニットは、仮想メモリマネージャにより管理されるメモリから命令をフェッチするように構成され、第１および第２の異なるコンピュータアーキテクチャ用にコード化された、または第１および第２の異なるデータ記憶規約をインプリメントするためにコード化された命令を実行するように構成されている。マイクロプロセッサチップは、（ａ）メモリの各ページと関係づけられて記憶されたインジケータ要素を検索し、各インジケータ要素はそのページの命令が実行されるアーキテクチャまたは規約を指示しており、（ｂ）それぞれの関係するインジケータ要素による指示に従って、命令実行が第１のアーキテクチャまたは規約のページから第２のもののページに流れた時を認識し、そして（ｃ）第２のアーキテクチャまたは規約のページと関係するインジケータ要素に従って命令の実行を行うように、命令ユニットの処理モードまたはメモリの記憶内容を変更するように設計されている。
【００１１】
第５の態様において、本発明は、方法および、その方法を実行することができるマイクロプロセッサを特徴とする。コンピュータオブジェクトコードのセクションは、２つの実行の間にコードセクションの修正を伴わず２度実行される。コードセクションは行先アドレスをレジスタに具体化し、間接的にそのレジスタを介して行先アドレスに制御を直接転送するようにアーキテクチャ的に定義される。２つの実行は２つの異なる行先アドレスを具体化し、２つの行先のコードは２つの異なる命令セットでコード化される。
【００１２】
第６の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。コンピュータの命令セットのうちの制御フロー命令は、複数のクラスに分類される。コンピュータでのプログラムの実行の間に、その命令セットの命令の実行の一部として、一番最近実行された分類された制御フロー命令のクラスを記録するために、記録が更新される。
【００１３】
第７の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。ソース実行コンテキストから行先実行コンテキストでの実行のための行先命令に制御を転送する制御転送命令が実行される。行先命令を実行する前に、コンピュータの記憶コンテキストは、ソース実行コンテキストのもとで解釈される通りにコンピュータの論理コンテキストを行先実行コンテキストのもとで再確立するために調整される。再構成は少なくともある程度、制御転送命令の分類によって決定される。
【００１４】
全体的に、第８の態様において、本発明は、コンピュータを動作させる方法を特徴とする。並行実行スレッドは、コンピュータの既存のスレッドスケジューラによってスケジューリングされる。各スレッドは関係するコンテキストを有し、スレッドとコンテキストのコンピュータ資源の集合との間の関係づけはスレッドスケジューラによって維持される。スレッドスケジューラを修正することなく、関係づけは、スレッドの１つと、スレッドスケジューラにより誘起されたコンテキスト変更によるスレッドの拡張コンテキストとの間で維持され、拡張コンテキストはスレッドとの関係がスレッドスケジューラにより維持されるそうした資源以上のコンピュータの資源を含む。
【００１５】
第９の態様において、本発明は、コンピュータを動作させる方法を特徴とする。エントリ例外が、指定のエントリポイントまたは指定の条件でコンピュータのオペレーティングシステムへの各エントリで生じるように、確立される。再開例外が、指定のエントリに続くオペレーティングシステムからの各再開で生じるように、確立される。コンピュータの中断したプロセスからオペレーティングシステムへの指定のエントリを検出すると、エントリ例外が生じ、サービスされる。再開例外が生じサービスされ、制御は中断したプロセスに返される。
【００１６】
第１０の態様において、本発明は、コンピュータを動作させる方法を特徴とする。コンピュータのオペレーティングシステムを修正することなく、オペレーティングシステムへの指定のエントリポイントまたは指定のエントリ条件での実行のためにエントリハンドラが確立される。エントリハンドラは、修正されたコンテキストをオペレーティングシステムに引き渡す前に、中断したスレッドのコンテキストを保存し、スレッドコンテキストを修正するようにプログラムされている。オペレーティングシステムを修正することなく、エントリハンドラによるエントリに続くオペレーティングシステムからの再開時の実行のために、出口ハンドラが確立される。出口ハンドラは、エントリハンドラの対応する実行により保存されたコンテキストを復元するようにプログラムされている。
【００１７】
第１１の態様において、本発明は、コンピュータを動作させる方法を特徴とする。コンピュータのサービスルーチンの呼び出しにおいて、リンケージリターンアドレスが渡され、このリターンアドレスは、サービスルーチンからの復帰時にリターンアドレスからの命令を実行する試みがプログラム実行の例外を生じるように、意図的に選択される。サービスルーチンからの復帰時に、選択された例外が生じる。その例外にサービスした後、制御はサービスルーチンの呼び出し側に返される。
【００１８】
本発明の特定の実施例は以下の特徴の１つ以上を含み得る。領域は仮想メモリマネージャによって管理されるページとしてよい。指標は、仮想アドレス変換エントリ、そのエントリが対応する仮想ページと関係づけられているテーブル、そのエントリが対応する物理ページフレームと関係づけられているテーブル、変換索引バッファエントリ、または命令キャッシュのラインにおいて、記憶され得る。第１の行先のコードは、浮動小数点引き数を受け取り、レジスタベースの呼び出し規約を用いて浮動小数点戻り値を返すことができ、他方、第２の行先のコードは、メモリスタックベースの呼び出し規約を用いて浮動小数点引き数を受け取り、トップオブスタックポインタにより指示されるレジスタを用いて浮動小数点値を返すことができる。
【００１９】
２つのアーキテクチャは２つの命令セットアーキテクチャとすることができ、コンピュータの命令実行ハードウェアは、指標に従った２つの命令セットアーキテクチャに従って命令を解釈するように制御され得る。命令の実行のモードは、実行が第１の領域から第２のものに流れた時にさらなる介入を伴わず変更することができ、またはモードは、実行が第１の領域から第２のものに流れた時にコンピュータが例外を行った場合に例外ハンドラによって変更することができる。領域のうちの１つは、コンピュータにとって非ネイティブの命令セットでバイナリコード化されたオフザシェルフオペレーティングシステムを記憶し得る。
【００２０】
２つの規約は第１および第２の呼び出し規約とすることができ、コンピュータは、プログラム実行が、第１の呼び出し規約を使用する領域から第２の呼び出し規約を使用する領域に移行した時を認識することができ、その認識に応答して、コンピュータのデータ記憶構成は第１の呼び出し規約から第２のものに調整される。２つの呼び出し規約のうちの一方はレジスタベースの呼び出し規約とすることができ、他方の呼び出し規約はメモリスタックベースの呼び出し規約とすることができる。第１のアーキテクチャの資源と第２のものの資源との間に定義されたマッピングが存在可能であり、このマッピングは、それらの資源が２つのアーキテクチャの呼び出し規約の類似の機能を提供する時には、２つのアーキテクチャの対応する資源をコンピュータの共通の物理資源に割り当てる。構成の調整は、データのビット表現を第１の表現から第２の表現へ変更することを含み、表現の変更は、実行規約の変更にまたがりデータの意味を保存するように選択され得る。データを第１のロケーションから第２のものにコピーするための規則は、実行を第２の領域に転送した命令の分類および／または、認識された実行転送の前の実行のロケーションに関係するデスクリプタを試験することによって、少なくともある程度決定できる。
【００２１】
命令の第１のクラスは、呼び出し規約に従って渡された引き数に関係するサブプログラム間で制御を転送するための命令を含み、命令の第２のクラスは、存在する場合に引き数が呼び出し規約に従って渡されない分岐命令を含み得る。実行コンテキストのうちの一方はレジスタベースの呼び出し規約であり、他方の実行コンテキストはメモリスタックベースの呼び出し規約とし得る。この再構成は、２つのデータ記憶規約のもとでの類似の実行コンテキストを反映し、再構成プロセスは少なくともある程度、命令分類記録によって決定される。制御フロー命令の一部において、分類は、命令の即値フィールドにおいてコード化することができ、即値フィールドは、クラスの記録を更新するためを除き、それがコード化される命令の実行に対していかなる作用も及ぼさない。制御フロー命令の一部において、分類は命令の演算コードによって静的に決定され得る。制御フロー命令の一部では、分類は、プロセッサレジスタおよび／またはコンピュータの汎用レジスタの状態によって動的に決定され得る。制御フロー命令の一部では、分類は、トップスタックポインタにより指示されるレジスタの満／空の状態に基づき動的に決定することができ、レジスタは機能結果値を保持する。この再構成は例外ハンドラによって実行することができ、ハンドラは、ソースデータ記憶規約、行先データ記憶規約および命令分類記録に少なくともある程度基づき例外ベクトルによって選択される。命令セットの命令は、ドントケアクラスのメンバとして分類することができ、その結果、ドントケアクラスの命令が実行される際に、記録は、一番最近実行された分類された命令のクラスを指示するために乱されずそのままにしておかれる。行先命令は、コンピュータに非ネイティブな命令セットにおいてコード化されたオペレーティングシステムのためのオフザシェルフバイナリへのエントリポイントとなり得る。
【００２２】
オペレーティングシステムは、そのコンピュータにネイティブなアーキテクチャ以外のコンピュータアーキテクチャのためのオペレーティングシステムとすることができる。コンピュータは、コンピュータにネイティブなオペレーティングシステムを付加的に実行することができ、各例外は２つのオペレーティングシステムのうちの一方によるハンドリングのために分類できる。スレッドの再開のためのリンケージリターンアドレスは、関係づけを維持するために使用される情報を含むように修正され得る。修正されたレジスタの少なくとも一部はタイムスタンプで上書きされ得る。エントリ例外ハンドラは、プロセスをオペレーティングシステムに引き渡す前にオペレーティングシステムによりそのプロセスと関係づけられて維持されるプロセスコンテキストの一部のデータレジスタの少なくとも半分を変更することができ、レジスタの少なくとも１つにバリデーションスタンプが冗長的に記憶され、ここにおいて、修正されたレジスタの少なくとも一部は、修正の前にスレッドコンテキストの少なくとも一部が保存される記憶場所を指示する値で上書きされる。オペレーティングシステムおよび中断したスレッドは、コンピュータの異なる命令セットアーキテクチャにおいて実行できる。エントリ例外にサービスする間に、コンピュータのコンテキストの一部は保存されることができ、中断したスレッドのコンテキストは、中断したスレッドおよびその対応するコンテキストをオペレーティングシステムに引き渡す前に変更され得る。スレッドスケジューラおよびスレッドがコンピュータの異なる実行モードで実行する場合、スレッドとコンテキストとの間の関係づけを維持するステップが、スレッド実行モードからスレッドスケジューラ実行モードへの遷移時に自動的に呼び出される。スレッドコンテキストは、コンテキストが保存されるべき空の記憶場所は待ち行列の先頭から割り当てられ、再使用のために最近空になった記憶場所は待ち行列の先頭にエンキューされ、保存された満杯の記憶場所は待ち行列の末尾で列を作るという、キューイング規則によって管理される記憶場所のプールから割り当てられた記憶場所に保存され得る。スレッド実行モードのための呼び出し規約は、スレッドスケジューラ実行モードに適合するためにオペランドをある形式から別のものに変換するために取られるアクションを指定する値へのレジスタの設定を必要とし得る。割込みの引き渡しは、スレッドがチェックポイントに到達可能にするために十分な時間だけ遅延されるか、または、スレッドの実行がチェックポイントまでロールバックされることができ、このチェックポイントは、スレッドとの資源関係づけがスレッドスケジューラによって維持されるようなもの以上のスレッドの資源である、拡張コンテキストの量が縮小される、スレッドの実行におけるポイントである。リンケージリターンアドレスは、そのページから命令を実行する試みに際して選択された例外を生じるメモリ属性を有するメモリページをポイントするように選択され得る。サービスルーチンは、コンピュータにネイティブなアーキテクチャ以外のコンピュータアーキテクチャのためのオペレーティングシステムの割込みサービスルーチンとすることができ、このサービスルーチンは非同期割込みによって呼び出すことができ、呼び出し側はアーキテクチャにネイティブな命令セットでコード化され得る。
【００２３】
一般に、第１２の態様において、本発明は方法およびコンピュータを特徴とする。コンピュータプログラムがコンピュータの論理アドレス空間において実行し、アドレス変換回路はプログラムによって生成されたアドレス参照をプログラムの論理アドレス空間からコンピュータの物理アドレス空間へ変換する。プログラムの実行間隔の間に参照された物理記憶アドレスを記録するプロファイル情報が記録される。
【００２４】
一般に、第１３の態様において、プログラムがコンピュータにおいて実行され、このプログラムは仮想アドレスによりメモリを参照する。プログラムの実行と並行して、プログラムにより行われたメモリ参照を記述するプロファイル情報が記録され、このプロファイル情報はプロファイルされたメモリ参照の物理アドレスを記録する。
【００２５】
一般に、第１４の態様において、本発明は、命令パイプライン、メモリアクセスユニット、アドレス変換回路およびプロファイル回路を備えるコンピュータを特徴とする。命令パイプラインおよびメモリアクセスユニットは、コンピュータのメモリの論理アドレス空間の命令を実行するように構成されている。アドレス参照を変換するためのアドレス変換回路は、プログラムの論理アドレス空間からコンピュータの物理アドレス空間にプログラムによって生成される。プロファイル回路は、命令パイプラインと協働的に相互接続され、実行プロファイリングのためのコンパイラの援助を要さずに、命令パイプラインで生じるプロファイル可能事象の発生を検出するように構成されており、プログラムの実行間隔の間に参照された物理メモリアドレスを記述するプロファイル情報を記録するためにメモリアクセスユニットと協働的に相互接続されている。
【００２６】
本発明の実施例は、以下の特徴の１つ以上を含み得る。記録された物理メモリ参照は、命令ポインタにより参照されたバイナリ命令のアドレスを含み、記録された命令参照の少なくとも１つはアドレス空間のページ境界にまたがる順次的実行フローの事象を記録することができる。ページ境界をまたいで記録された実行フローは単一の命令内で発生し得る。ページ境界をまたいで記録された実行フローは、論理アドレス空間において順次的に隣接する２つの命令間で発生し得る。記録された命令参照の少なくとも１つは、外部割込みに伴う制御フローの分岐とし得る。記録された命令参照の少なくとも１つは、プロファイルされた実行間隔の間にコンピュータにより実行された命令の最後のバイトのアドレスを指示し得る。記録されたプロファイル情報は、コンピュータのバイナリ命令の意味を決定するプロセッサモードを記録できる。記録されたプロファイル情報は、コンピュータのレジスタに関する満／空マスクに対するデータ依存性の変更を記録することができる。命令パイプラインは、コンピュータの資源のほとんど全部へのアクセスを可能にするネイティブ命令セットおよび、コンピュータの資源のサブセットへのアクセスを可能にする非ネイティブ命令セットという、２つの命令セットの命令を実行するように構成することができる。命令パイプラインおよびプロファイル回路はさらに、非ネイティブ命令セットでコード化されたオペレーティングシステムの実行の間隔を記述するプロファイル情報の記録を行うように構成することができる。
【００２７】
一般に、第１５の態様において、本発明は方法を特徴とする。コンピュータにおいてプログラムが実行される。そのプログラムの実行に関してプロファイル情報が記録され、プロファイル情報は、実行のプロファイル間隔の間にコンピュータにより実行された少なくとも１つの命令の最後のバイトのアドレスを記録する。
【００２８】
一般に、第１６の態様において、本発明は方法を特徴とする。プロファイルされた実行についてプログラムがコンパイルされることなく、コンピュータにおいてプログラムが実行され、プログラムは、命令の変換が、命令のバイナリ表現に表現されないプロセッサモードに依存する命令セットでコード化される。プログラムの実行の間隔およびプログラムのプロファイル間隔の間のプロセッサモードを記述するプロファイル情報が記録され、プロファイル情報は、バイナリコーディングにおけるモード依存性を解決するために十分なプロセッサモード情報により、プロファイルされたバイナリコードに注釈を付けるように効率的に仕立てられる。
【００２９】
一般に、第１７の態様において、本発明は、命令パイプラインおよびプロファイル回路を備えるコンピュータを特徴とする。命令パイプラインは、コンピュータの命令を実行するように構成される。プロファイル回路は、実行プロファイリングのためのコンパイラの援助を要さずに、命令パイプラインで生じる事象のシーケンスの発生を検出および記録するように構成されており、そのシーケンスは、プロファイルされる事象の時間独立な選択判定基準に一致する、プロファイルされた実行間隔の間に発生するすべての事象を含み、記録は所定の停止条件に到達するまで継続し、実行のプロファイルされない間隔の後、プロファイルされた実行間隔を開始するために所定の条件の発生を検出するように構成されている。
【００３０】
一般に、第１８の態様において、本発明は、方法および、その方法の実行のために構成された回路を備えるコンピュータを特徴とする。コンピュータにおけるプログラムの実行のプロファイル間隔の間に、プロファイルされた実行についてプログラムがコンパイルされることなく、実行を記述するプロファイル情報が記録され、プログラムは、命令の解釈が、命令のバイナリ表現で表現されないプロセッサモードに依存する命令セットでコード化され、記録されたプロファイル情報は以下の２つのクラスのプロファイルされた実行間隔の間に発生する少なくとも全部の事象を記述している。（１）順次的実行からの実行の分岐、および（２）モード変更命令の前にプロセッサモードとともに得られるプロセッサモード変更を誘起する命令の演算コードから推論できないプロセッサモード変更。プロファイル情報はさらに、実行間隔の間に実行された命令テキストの各個別の物理ページを識別する。
【００３１】
本発明の実施例は以下の特徴の１つ以上を含み得る。プロファイルされた実行間隔はタイマの満了時に開始され、記録されたプロファイルは、プロファイルされる事象の時間独立な選択判定基準に一致するすべての事象を含む事象のシーケンスを記述しており、その記録は所定の停止条件に到達するまで継続される。プログラム実行の制御フローが順次的実行から分岐する制御フロー事象のソースおよび行先を指摘するプロファイルエントリが、後の分析のために記録される。記録されたプロファイル情報は、プログラムのバイナリコードと関係なく、プロファイルされた実行間隔の間に実行されたオブジェクトコードの全部のバイトを識別するために効率的に仕立てられる。単一のプロファイル可能事象を記述しているプロファイルエントリは、その事象のロケーションのページオフセットを明示的に記述し、直前のプロファイルエントリから事象のロケーションのページ数を継承する。プロファイル情報はプログラムの事象のシーケンスを記録し、そのシーケンスは、プロファイルされるプロファイル可能事象の時間独立な判定基準に一致するプロファイルされた実行間隔の間のすべての事象を含む。記録されたプロファイル情報は、実行のプロファイル間隔の間にコンピュータによって実行された命令バイナリテキストの範囲を指示し、実行されたテキストの範囲は各範囲の下限および上限の境界として記録される。記録された上限の境界は、その範囲の最後のバイト、または最後の命令の第１バイトを記録する。捕捉されたプロファイル情報は２種類のサブユニットを含み、第１の種類のサブユニットは命令境界の命令解釈モードを記述し、第２の種類のサブユニットはプロセッサモード間の遷移を記述している。プログラム実行のプロファイルされない間隔の間には、プロファイル可能事象について所定の選択判定基準に一致するプロファイル可能事象の発生に応答して、いかなるプロファイル情報も記録されない。プロファイル回路は、記録された事象の時間を記述するタイムスタンプを記録するように設計されている。プロファイル回路は、記録された各プロファイル可能事象のクラスを記述する事象コードを記録するように設計されている。事象コードを記録するために使用されるビットの数は、区別された事象クラスの数のｌｏｇ２未満である。
【００３２】
一般に、第１９の態様において、本発明は方法を特徴とする。コンピュータにおいてプログラムを実行する間、命令パイプラインで生じるプロファイル可能事象の発生が検出され、命令パイプラインは、プロファイル可能事象の発生と本質的に並行してプロファイル可能事象を記述するプロファイル情報を記録するように命じられ、この検出および記録はソフトウェア介入を要さずにコンピュータのハードウェアの制御のもとで行われる。
【００３３】
一般に、第２０の態様において、本発明は、命令パイプラインおよびプロファイル回路を備えるコンピュータを特徴とする。命令パイプラインは演算装置を含み、コンピュータのメモリおよびプロファイル回路から受け取った命令を実行するように構成されている。プロファイル回路は、命令パイプラインと共通のハードウェアコントロールである。プロファイル回路および命令パイプラインは、命令パイプラインで生じるプロファイル可能事象の発生を検出するために協働的に相互接続されており、プロファイル回路は、ソフトウェア介入を要さずに、プロファイル可能事象の発生と本質的に並行してプロファイル可能事象を記述するプロファイル情報を記述するプロファイル情報の記録を行うように動作可能である。
【００３４】
一般に、第２１の態様において、本発明は、第１および第２のＣＰＵを特徴とする。第１のＣＰＵは、プログラムを実行し、そのプログラムの実行を記述するプロファイルデータを生成するように構成されている。第２のＣＰＵは、実行およびプロファイルデータ生成が第１のＣＰＵで継続する間に、生成されたプロファイルデータを分析し、収集されたプロファイルデータの分析に少なくともある程度基づき第１のＣＰＵにおけるプログラムの実行を制御するように構成されている。
【００３５】
一般に、第２２の態様において、本発明は方法を特徴とする。コンピュータにおいてプログラムを実行する間、コンピュータは命令結果の記憶のために汎用レジスタファイルのレジスタを使用し、命令パイプラインで生じるプロファイル可能事象の発生が検出される。プロファイル可能事象を記述するプロファイル情報は、プロファイル可能事象が発生すると、最初にコンピュータのメインメモリに情報を捕捉することなく、汎用レジスタファイルに記録される。
【００３６】
一般に、第２３の態様において、本発明は、レジスタの汎用レジスタファイル、命令パイプラインおよびプロファイル回路を備えるコンピュータを特徴とする。命令パイプラインは演算装置を含み、コンピュータのメモリキャッシュからフェッチされた命令を実行するように構成されており、命令結果の記憶のための汎用レジスタファイルのためのレジスタとデータ通信する。プロファイル回路は、命令パイプラインと動作可能に相互接続されており、命令パイプラインで生じるプロファイル可能事象の発生を検出し、プロファイル可能事象が発生すると、最初にコンピュータのメインメモリに情報を捕捉することなく、汎用レジスタファイルにプロファイル可能事象を記述する情報を捕捉するように構成されている。
【００３７】
一般に、第２４の態様において、本発明はコンピュータを特徴とする。命令パイプラインは、コンピュータの命令を実行するように構成されている。プロファイル回路は、コンピュータハードウェアにおいてインプリメントされており、実行プロファイリングのためのコンパイラの援助を要さずに、命令パイプラインで生じるプロファイル可能事象の発生を検出し、プログラムの実行間隔の間に発生するプロファイル可能事象を記述するプロファイル情報の記録を導くように構成されている。コンピュータハードウェアにおいてインプリメントされたプロファイル制御ビットは、プロファイル回路の動作の解決を制御する値を有する。バイナリトランスレータは、第１の命令セットアーキテクチャでコード化されたプログラムを第２の命令セットアーキテクチャの命令に変換するように構成されている。プロファイルアナライザは、記録されたプロファイル情報を分析し、また、プロファイル制御ビットをバイナリトランスレータの動作を改善するための値に設定するように構成されている。
【００３８】
本発明の実施例は以下の特徴の１つ以上を含み得る。記録の少なくとも一部は、命令パイプラインに投機的に導入された命令によって実行される。プロファイル回路は、パイプラインへの命令の注入による記録を導くために命令パイプラインと相互接続されており、その命令は、プロファイル可能事象がコンピュータのアーキテクチャ的に可視の記憶レジスタにおいて具体化されるようにパイプラインを制御する。プロファイリングに関連しないコンピュータによる実行に対し一次的効果を有するコンピュータの命令は、プロファイルされた事象の性質をコード化しプロファイル情報において記録される、事象コードのための即値フィールドを有しており、この即値フィールドは、プロファイルされた事象の事象コードを決定するため以外、コンピュータの実行に対していかなる作用も及ぼさない。命令のインスタンスは、コンピュータの他の事象監視回路によって以前に決定された事象コードをそのままにしておく事象コードを有する。プロファイルされた情報は、いかなる明示的な即時値もソフトウェアにおいて記録されることなく、その事象コードが命令実行ハードウェアによって分類された事象の記述を含む。命令パイプラインおよびプロファイル回路は、単一のプロファイル可能事象の発生時にプロファイル回路による命令パイプラインへの複数の命令の注入をもたらすように動作可能に相互接続されている。命令パイプラインおよびプロファイル回路は、プロファイル回路による命令パイプラインへの命令の投機的な注入をもたらすように動作可能に相互接続されている。コンピュータのレジスタポインタは、プロファイル情報を記録するための汎用レジスタを指示し、インクリメンタは次のプロファイル情報を記録するための次の汎用レジスタを指示するためにレジスタポインタの値を増分するように構成されており、この増分はソフトウェア介入を要さずに行われる。リミットディテクタはレジスタポインタと動作可能に相互接続され、プロファイル情報を収集するために使用可能なレジスタの範囲が費消された時を検出し、ストアユニットは、費消が検出された時にプロファイル情報を汎用レジスタからコンピュータのメインメモリへ記憶するようにさせるためにリミットディテクタと動作可能に相互接続されている。プロファイル回路は、複数のパイプライン段に構成された複数の記憶レジスタよりなり、いずれかのパイプライン段において記録された情報は対応する機械語命令が命令パイプライン内を進行するにつれて修正を受ける。命令の命令フェッチが変換索引バッファ（ＴＬＢ）において失敗を生じた場合、その命令のフェッチはプロファイル可能事象をトリガするが、ＴＬＢの失敗はサービスされ、ＴＬＢの訂正された状態はプロファイル可能な命令について記録されたプロファイル情報に反映される。プロファイル制御ビットは、プロファイル回路がプロファイル可能事象について命令パイプラインを監視する必要がある頻度を指定するタイマ間隔値を含む。プロファイル回路は、複数のパイプライン段に構成された複数の記憶レジスタよりなり、いずれかのパイプライン段において記録された情報は対応する機械語命令が命令パイプライン内を進行するにつれて修正を受ける。
【００３９】
一般に、第２５の態様において、本発明は、２つの命令セットアーキテクチャのもとでコンピュータ命令の解釈を代替的にもたらすように設計された命令パイプライン回路を備えるコンピュータを特徴とする。パイプライン制御回路は、命令セットアーキテクチャのうちの下位性能のものでコード化されたプログラム領域を実行しようとする時に、命令セットアーキテクチャのうちの上位性能のものでコード化されたプログラム領域が存在するかどうかの照会を、ソフトウェア介入を要さずに開始するために命令パイプライン回路と協働的に設計されており、その上位性能領域は下位性能領域と論理的に等価である。回路および／またはソフトウェアは、上位性能領域への制御転送命令が下位性能の命令セットでコード化されてことを要さずに、実行制御を上位性能領域に転送するように設計されている。
【００４０】
一般に、第２６の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。コンピュータプログラムの少なくとも選択された部分が、第１のバイナリ表現から第２のバイナリ表現に変換される。コンピュータにおけるプログラムの第１のバイナリ表現の実行の間に、実行がその選択部分に入ったことが認識され、その認識は、照会も、第２のバイナリ表現への制御の転送のいずれも第１のバイナリ表現にコード化されることなく、コンピュータの基本命令実行によって開始される。認識に応答して、制御は第２の表現での変換に転送される。
【００４１】
一般に、第２７の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。コンピュータにおいて命令を実行する一部として、命令の代替コーディングが存在することが認識され、その認識は、認識をトリガするために代替コーディングまたは照会命令への制御の転送を実行することなく開始される。代替コーディングが存在する場合、命令の実行が打ち切られ、制御は代替コーディングに転送される。
【００４２】
一般に、第２８の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。コンピュータの命令パイプライン回路におけるプログラムの実行の間に、命令パイプライン回路により実行中の第１の命令ストリームから第２の命令ストリームへ制御を転送するかどうかの決定が、照会または第２の命令ストリームへの制御の転送が第１の命令ストリームにコード化されることなく開始される。第１の命令ストリームの実行は、第２の命令ストリームの実行の後に確立され、第１の命令ストリームの実行は、第１の命令ストリームのコードが処理可能となった場合に支配的となるはずであるものと論理的に等価なコンテキストにおいて、制御が捕捉されるポイントから下流のあるポイントで再確立される。
【００４３】
一般に、第２９の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。コンピュータプログラムの実行は、プログラムの第１のバイナリイメージを用いて開始される。第１のイメージの実行の間に、制御は同じプログラムを異なる命令セットでコード化する第２のイメージに転送される。
【００４４】
一般に、第３０の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。コンピュータにおいて命令を実行する一部として、命令の代替コーディングが存在するかどうかのヒューリスティックな概ね正確な認識が評価され、その認識のプロセスは統計的にトリガされる。代替コーディングが存在する場合、命令の実行は打ち切られ、制御は代替コーディングに転送される。
【００４５】
一般に、第３１の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。マイクロプロセッサチップは、命令パイプライン回路、ルックアップ回路、マスクおよびパイプライン制御回路を有する。ルックアップ回路は、マイクロプロセッサの基本命令処理サイクルの一部としてルックアップ構造からエントリをフェッチするように設計されており、ルックアップ構造の各エントリはコンピュータのメモリの対応するアドレス範囲と関係づけられている。マスクは、タイマによって少なくともある程度設定される値を有する。パイプライン制御回路は、マイクロプロセッサの基本命令処理サイクルの一部として命令パイプライン回路による命令の処理を、命令パイプライン回路によって処理される命令が存在するアドレス範囲に対応するエントリの値、およびマスクの現在値に少なくともある程度依存して、制御するように設計されている。
【００４６】
一般に、第３２の態様において、本発明は、方法および、その方法の実行のためのマイクロプロセッサチップを特徴とする。マイクロプロセッサチップは、命令パイプライン回路とともに以下の回路を有する。命令パイプライン回路によって実行される命令の実行に応答して、実行された命令を少数のクラスに分類し、分類コード値を記録する命令分類回路と、マイクロプロセッサの基本命令処理サイクルの一部としてルックアップ構造からエントリをフェッチするように設計されており、ルックアップ構造の各エントリはコンピュータのメモリの対応するアドレス範囲と関係づけられている、ルックアップ回路と、そして、マイクロプロセッサの基本命令処理サイクルの一部として命令パイプライン回路による命令の処理を、命令アドレスが存在するアドレス範囲に対応するエントリの値および、記録された分類コードに少なくともある程度依存して制御するように設計されているパイプライン制御回路。
【００４７】
一般に、第３３の態様において、本発明は、方法および、その方法の実行のためのマイクロプロセッサチップを特徴とする。マイクロプロセッサチップは、命令パイプライン回路とともに以下の回路を含む。回路の制御のためにコンピュータ機械状態の一部の概略評価を保持するように設計されており、そのオンチップテーブルの各エントリはコンピュータで発生する事象の各クラスに対応している、オンチップテーブルと、そして、オンチップテーブルの相談に基づき、マイクロプロセッサの基本命令処理サイクルの一部として命令パイプライン回路による命令の処理を制御するために、命令パイプライン回路と協働的に設計されたパイプライン制御回路。
【００４８】
一般に、第３４の態様において、本発明は、方法および、その方法の実行のためのマイクロプロセッサチップを特徴とする。マイクロプロセッサチップは、命令パイプライン回路とともに以下の回路を含む。オンチップテーブルの各エントリはコンピュータで発生する事象のクラスに対応しており、そのクラスの事象が発生した時にはコンピュータのメモリのオフチップテーブルの相談を制御するように設計されているオンチップテーブルと、分類された事象が発生するとマイクロプロセッサの基本命令処理サイクルの一部としてオンチップテーブルに相談するように命令パイプライン回路と協働的に設計されたパイプライン制御回路と、そして、望ましい値がオンチップテーブルから得られた後にオフチップテーブルの相談に基づき命令パイプライン回路での事象について定義されたデータの操作または制御の転送に作用するように命令パイプライン回路およびパイプライン制御回路と協働するように設計された制御回路および／またはソフトウェア。
【００４９】
本発明の実施例は以下の特徴の１つ以上を含み得る。上位性能領域への実行制御の転送は、プログラムカウンタのアーキテクチャ的に可視の変更によって生じ得る。実行されようとする領域には制御転送命令によって入ることができる。第１のイメージは、コンピュータでのハードウェアエミュレーションの場合、コンピュータにとって非ネイティブの命令セットでコード化できる。第２のバイナリ表現の命令は、第１のバイナリ表現の命令とは異なる命令セットアーキテクチャでコード化され得る。第２のイメージは第１のイメージからバイナリトランスレータにより生成され得る。バイナリトランスレータは、そのネイティブの命令セットアーキテクチャでの非ネイティブプログラムの実行と異なる実行のある程度のリスクを受け入れつつ、実行速度の増大のために第２のイメージを最適化することができる。第１のイメージから第２のものへ制御を転送するかどうかについての決定は、コンピュータの制御変数に基づくことができる。事象のクラスは、コンピュータのメモリの対応する各アドレス範囲のメモリ参照となり得る。アドレス範囲は割込みベクトルテーブルのエントリに対応し得る。認識は、実行される命令のプログラムカウンタアドレスによりアドレスされる内容アドレス指定可能メモリに相談することによって開始できる。内容アドレス指定可能メモリは変換索引バッファとすることができる。オフチップテーブルは、アドレス変換ページテーブルへのサイドテーブルとして編成され得る。オンチップテーブルは、オフチップテーブルからロードされる、オフチップテーブルの圧縮された近似を含み得る。ルックアップ構造はビットベクトルとすることができる。命令アドレスが存在するアドレス範囲に対応するエントリのビットは、命令パイプライン回路に関係するマスクの対応するビットと論理積がとられ得る。オンチップテーブルの近似の誤差は、その評価が記憶されるコンピュータの機械状態の部分に対する若干のタイムラグによって誘起され得る。パイプライン制御回路は、命令パイプライン回路による命令の処理を、命令アドレスが存在するアドレス範囲に対応するエントリの値および記録された分類コードを評価し、マイクロプロセッサチップによってアドレスされるメモリの内容のソフトウェア評価をトリガすることによって制御するように設計することができる。命令処理の制御は分岐行先処理を含み得る。
【００５０】
一般に、第３５の態様において、本発明は、方法および、その方法の実行のためのマイクロプロセッサチップを特徴とする。命令はコンピュータにおいて実行され、コンピュータの命令パイプライン回路は、命令の少なくともいくつかを処理するための第１および第２のモードを有する。２モード命令の実行が、第１の実行モードが成功している間、連続する２モード命令について第１のモードで試みられる。第１のモードのもとで２モード命令の不首尾の実行が検出された場合、後続する２モード命令は第２のモードで実行される。
【００５１】
一般に、第３６の態様において、本発明は、方法および、その方法の実行のためのマイクロプロセッサチップを特徴とする。コンピュータ命令は、少なくともいくつかの命令を処理するための第１および第２のモードを有する命令パイプライン回路において実行される。タイマの満了時に、命令パイプライン回路は、第１のモードから第２のものに切り換え、このモードスイッチはタイマ満了の直前に実行されていたプログラムのために以後に実行される命令のために持続する。
【００５２】
一般に、第３７の態様において、本発明は、方法および、その方法の実行のためのマイクロプロセッサチップを特徴とする。コンピュータの事象は事象クラスに割り当てられる。コンピュータ命令パイプラインの基本命令実行サイクルの一部として、ソフトウェア介入を伴わず、クラスの事象に対する応答の記録が維持される。命令パイプライン回路における実行のために個々の分類された事象が現れると、同じクラスの事象の以前の試みへの応答を決定するために記録が照会される。以前の試みが成功したことを記録が指示した場合、およびその場合にのみ、その応答は試みられる。
【００５３】
本発明の実施例は以下の特徴の１つ以上を含み得る。第１および第２のモードは、代替キャッシュポリシー、または浮動小数点演算を実行するための代替モードとすることができる。不首尾の実行は、高コストでの命令の正確な完了を含み得る。コスト測度は実行時間とすることができる。第１のモードでの命令のコストは、命令の完了後に確認可能であるにすぎない。命令パイプライン回路は、第２のモードから第１のものにスイッチバックされ、スイッチは次のタイマ満了まで持続する。記録の全部は、対応する事象の以前の試みが成功したことを指示するために定期的に設定され得る。
【００５４】
一般に、第３８の態様において、本発明は、方法および、その方法の実行のためのマイクロプロセッサチップを特徴とする。コンピュータで実行する非スーパバイザモードプログラムの命令を実行する基本命令サイクルの一部として、テーブルが参照され、そのテーブルは命令の属性について、実行された命令のアドレスによってアドレスされる。命令のアーキテクチャ的に可視のデータ操作ビヘイビアまたは制御転送ビヘイビアは、命令に関係するテーブルエントリの内容に基づき制御される。
【００５５】
本発明の実施例は以下の特徴の１つ以上を含み得る。異なる命令は、実行された命令のＩＳＡとは異なる命令セットアーキテクチャ（ＩＳＡ）でコード化できる。アーキテクチャ的に可視のデータ操作ビヘイビアの制御は、そのもとで命令がコンピュータにより解釈される命令セットアーキテクチャを変更することを含み得る。テーブルの各エントリは、仮想メモリマネージャによって管理されるページに対応することができ、テーブルエントリをロケートするための回路はコンピュータの仮想メモリアドレス変換回路と統合されている。プロセスの命令の実行時に、コンピュータのメモリ状態および命令のアドレスに少なくともある程度基づき、同期して割込みがトリガされ得るが、命令のアーキテクチャ上の定義は割込みを要求しない。割込みにサービスし、割込みをトリガさせた命令フロー以外のプロセスの命令フローに制御を返すために、割込みハンドラソフトウェアを設けることができ、誤りなく続行するための復帰命令フローはプロセスの通常処理を取り扱う。
【００５６】
一般に、第３９の態様において、本発明は、方法および、その方法の実行のためのマイクロプロセッサチップを特徴とする。マイクロプロセッサチップは命令パイプライン回路、アドレス変換回路およびルックアップ構造を有する。ルックアップ構造は、アドレス変換回路によって変換される個々の対応するアドレス範囲に関係するエントリを有し、エントリは、各対応アドレス範囲にロケートされた命令の代替コーディングの存在の可能性を記述する。
【００５７】
本発明の実施例は以下の特徴の１つ以上を含み得る。エントリは変換索引バッファのエントリとすることができる。代替コーディングは、アドレス範囲でロケートされた命令のＩＳＡとは異なる命令セットアーキテクチャ（ＩＳＡ）でコード化できる。
【００５８】
一般に、第４０の態様において、本発明は、方法および、その方法の実行のためのマイクロプロセッサチップを特徴とする。マイクロプロセッサチップは、命令パイプライン回路および割込み回路を有する。割込み回路は、プロセスの命令の実行時に、コンピュータのメモリ状態および命令のアドレスに少なくともある程度基づき、同期して割込みをトリガするように命令パイプライン回路と協働的に設計されており、命令のアーキテクチャ上の定義は割込みを要求しない。
【００５９】
本発明の実施例は以下の特徴の１つ以上を含み得る。割込みハンドラソフトウェアは、割込みにサービスし、割込みをトリガさせた命令フロー以外のプロセスの命令フローに制御を返すように設計することができ、誤りなく続行するための復帰命令フローはプロセスの通常処理を取り扱う。割込みハンドラソフトウェアは、そのもとで命令がコンピュータにより解釈される命令セットアーキテクチャを変更するようにプログラムできる。復帰命令から始まる命令テキストは、中断した命令から始まる命令テキストと論理的に等価となり得る。
【００６０】
一般に、第４１の態様において、本発明は、方法および、その方法の実行のためのマイクロプロセッサチップを特徴とする。命令のストリームを実行する一部として、一連のメモリロードがコンピュータのＣＰＵからバスに発行され、一部は適切（正常）に動作するメモリに向けられ、一部は入出力空間の正常に動作しないデバイスに向けられる。コンピュータの記憶装置は、適切（正常）に動作しないメモリにメモリロードを発行したストリームの命令のアドレスを記録し、その記録の記憶形式は、その記録に記憶されたいずれのメモリアドレスの解決も要さずに、メモリロードが正常に動作するメモリかまたは正常に動作しないメモリに向けられたかの決定を可能にする。
【００６１】
一般に、第４２の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。成功したメモリ参照がコンピュータのＣＰＵからバスに発行される。コンピュータの記憶装置は、メモリ参照によりバス上でアクセスされたデバイスが、正常に動作するメモリかまたは正常に動作しないメモリであるかを記録する。代替的に、メモリは、正常に動作するメモリ以外のデバイスを参照したメモリ読出し命令の記録を記憶することもできる。
【００６２】
本発明の実施例は以下の特徴の１つ以上を含み得る。記録は、主にプログラム制御フローを記録するプロファイルの一部とすることができる。記録はバイナリ変換プログラムによって読むことができ、ここにおいて、バイナリ変換プログラムは、メモリロードが正常に動作しないメモリに向けられていると記録が指示した場合、より控えめな仮定を用いてメモリロードを変換する。入出力空間への参照は、正常に動作しないメモリへの参照であるとして記録され得る。記録は若干誤っていることもあり、その誤りはメモリ参照が正常に動作するメモリにアクセスした時を決定する際の控えめな評価によって誘起され得る。記録の形式は、記録に記憶されたいかなるメモリアドレスの解決も要さずに、メモリ参照が正常に動作するメモリかまたは正常に動作しないメモリへのものであったかの判定を可能にし得る。記録の形式は、メモリ参照を発行した命令のアドレスを指示し得る。メモリ参照はロードとしてよい。プロファイル監視回路はコンピュータのＣＰＵと混交することができる。ＴＬＢ（変換索引バッファ）は、ＴＬＢのエントリによってマップされたメモリが正常に動作するメモリかまたは正常に動作しないメモリであるかの決定を保持するように設計され得る。プロファイル監視回路はコンピュータの汎用レジスタに記録を生成することができる。プロファイル監視回路は、コンピュータＣＰＵのパイプラインフラッシュを誘起するように設計され得る。
【００６３】
一般に、第４３の態様において、本発明は、方法および、その方法の実行のためのコンピュータ回路を特徴とする。コンピュータのＤＭＡ（直接メモリアクセス）メモリ書込みトランザクションが監視され、ＤＭＡメモリ書込みトランザクションによって書き込まれた記憶場所の指標は、ＣＰＵにより事前にメモリ書込みトランザクションを知らされることなく動作する回路によって記録される。指標はプロセッサによって読まれる。
【００６４】
一般に、第４４の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。コンピュータの第１のプロセスは、第１の表現でメモリに記憶された情報の第２の表現をコンピュータメモリにおいて生成する。第２のプロセスにより開始されるＤＭＡメモリ書込みトランザクションによる第１の表現の上書きは、第２のプロセスがそのＤＭＡメモリ書込みトランザクションを第１のプロセスに知らせることなく、第１のプロセスによって検出され、この検出は、ＤＭＡメモリ書込みトランザクションに続く第２の表現の次のアクセス以前に行われるように保証されている。
【００６５】
一般に、第４５の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。コンピュータのメインメモリが、仮想メモリマネージャによる管理のためにページに分割される。マネージャは、メモリに記憶されたテーブルを用いてページを管理する。回路は、メインメモリのページへの修正の指標を、メインメモリのアドレス空間の外部で複数のレジスタに記録する。仮想メモリ管理テーブルは、レジスタに記憶された修正指標の補助記憶を行わない。
【００６６】
一般に、第４６の態様において、本発明は、方法および、その方法の実行のためのコンピュータ回路を特徴とする。コンピュータのメインメモリの内容に対する修正が監視され、修正の検出時には、修正のアドレスの近似が複数のレジスタうちの１つのアドレスタグに書き込まれ、そして、修正のアドレスの精細な指標がレジスタの複数のセルのうちのメモリセルに書き込まれる。修正のアドレスの精細な指標は、ＣＰＵからの読出し要求によってコンピュータのＣＰＵに提供される。
【００６７】
本発明の実施例は以下の特徴の１つ以上を含み得る。記録された指標は、記憶場所だけを記録し、そのロケーションに書き込まれたデータは記録しない。ＣＰＵによって読まれた値に少なくともある程度基づき、キャッシュされたデータは消去され得る。アドレスおよび時間的に相互に近い２つのＤＭＡメモリ書込みは、書込みの単一の記録だけを生成し得る。メインメモリのロケーションの記録された指標は、そのメモリの物理アドレスを指示し得る。ビットベクトルの各ビットの値は、メインメモリの対応する領域が最近修正されたかどうかを指示し得る。マッチング回路は、メモリ修正のアドレスを、以前の近いメモリ修正の以前に記憶された指標のアドレスと突き合わせるために設けることができる。メインメモリのロケーションの記録された指標は最初に、メインメモリの外部かつコンピュータの汎用レジスタファイルの外部でアーキテクチャ的に可視のロケーションに記録することができる。メインメモリのロケーションの記録された指標は、メモリのページの自然に整列されたブロックから各々構成されている領域へのメインメモリの下位分割に少なくともある程度基づき記録され得る。ＤＭＡ監視回路は、ＣＰＵとＤＭＡデバイスとの間の入出力ゲートウェイ回路のトランザクションを監視するように設計されている。ＤＭＡ監視回路は、読出しの副作用としてＤＭＡ監視回路の内容を解放することができる。アドレスタグに記憶された修正のアドレスは、物理記憶アドレスとし得る。メモリセルのベクトルはビットベクトルを含み、ビットベクトルの各ビットの値は、メインメモリの対応する領域が最近修正されたかどうかを指示するように設計されている。アドレスタグは内容アドレス指定可能メモリを含み得る。複数のレジスタのうちの１つは、アドレスをその１個のレジスタのアドレスタグに書き込むことによって、アドレス範囲と関係づけられ得る。後に、その１個のレジスタは、異なるアドレスをその１個のレジスタのアドレスタグに書き込むことによって、異なるアドレス範囲と関係づけられ得る。ビットベクトルの各ビットの値は、メインメモリの対応する領域が最近修正されたかどうかを指示し得る。
【００６８】
一般に、第４７の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。コンピュータにおいてプログラムが実行されると、コンピュータのメインメモリの保護領域への書込みが検出され、その報告は、コンピュータの監視回路によって実行される。検出の報告を受け取ると、書込みが検出された保護領域の内容に対応する内容のデータ構造が、メモリから削除される。
【００６９】
一般に、第４８の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。メモリ読出し参照がコンピュータのＣＰＵにおいて生成され、このメモリ参照は論理アドレスを参照する。参照のメインメモリページが保護された状態にあるかどうかを、回路および／またはソフトウェアが評価する。保護されていないページは保護された状態にされる。
【００７０】
一般に、第４９の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。メモリ参照はコンピュータのＣＰＵにより生成され、このメモリ参照は論理アドレスを参照する。物理アドレスへの論理アドレスの変換は、参照のページがアクセスから保護されているかどうかを評価する。保護されているページは、ページの内容を修正することなく、各自の保護を修正させる。
【００７１】
本発明の実施例は以下の特徴の１つ以上を含み得る。監視および検出回路は、コンピュータのパイプライン回路によって実行される命令により開始される記憶動作によって生成されるメモリ書込みに応答し得る。評価回路は、コンピュータのＣＰＵによるメモリ読出しアクセスの一部として生成される論理アドレスを物理アドレスに変換するように設計されたアドレス変換回路に組み込むことができる。メモリ領域の保護はエントリのテーブルに記録することができ、各エントリはメインメモリのページに対応する。そのテーブルエントリは、メインメモリの物理ページに対応して編成することができる。テーブルエントリは、コンピュータの仮想メモリマネージャによって使用されるページテーブルとは別個のメインメモリにおけるテーブルとなり得る。エントリのテーブルは変換索引バッファとしてよい。コンピュータのプロファイリングまたは監視機能は、コンピュータのメモリの領域について、各領域が保護されているかまたは保護されていないかに基づき、イネーブルまたはディスエーブルにすることができる。演算結果または命令の分岐の行先は、命令を含んでいる領域が保護されているかまたは保護されていないかに基づき制御され得る。データ構造は、第１の命令セットアーキテクチャの保護領域に記憶されたコンピュータプログラムを第２の命令セットアーキテクチャに変換することによって形成され得る。検出の報告を受け取ると、ソフトウェアを呼び出すために割込みが生じ、呼び出されたソフトウェアは保護領域の内容と関係なくメモリの内容に作用を及ぼす。メモリ読出し参照は命令フェッチとなり得る。
【００７２】
一般に、第５０の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。コンピュータにおいて命令のストリームを実行する一部として生成されたメモリ参照は、命令の個々のメモリ参照が、有効なメモリアドレスを有するが正常な動作を保証できないデバイスを参照するかどうかを判定するために評価される。
【００７３】
一般に、第５１の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。プログラムのバイナリ表現の少なくともセグメントを第１の命令セットアーキテクチャから第２の命令セットアーキテクチャの第２の表現へ変換する間に、正常に動作するメモリに向けられると考えられる各メモリロードは、正常に動作しないメモリデバイスに向けられると考えられるメモリロードと区別される。第２の表現を実行する間、変換時には正常に動作するメモリに向けられると考えられていたが、実行時に正常に動作しないメモリに向けられるとわかったロードが識別される。識別されたメモリロードは打ち切られる。識別に少なくともある程度基づき、プログラムの変換されたセグメントの少なくとも一部が第１の命令セットで再実行される。
【００７４】
一般に、第５２の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。バイナリトランスレータは、プログラムの少なくともセグメントを、第１の命令セットアーキテクチャの第１の表現から第２の命令セットアーキテクチャの第２の表現へ変換し、第２の表現における副作用のシーケンスは第１の表現の変換されたセグメントの副作用のシーケンスと異なる。命令実行回路および／またはソフトウェアは、副作用のシーケンスにおける相違がプログラムの実行に対し実質的な作用を及ぼし得る第２の表現の実行における事例を識別する。第１の表現の実行で発生するはずである状態と等価なプログラム状態が確立される。実行は、第１の表現の副作用シーケンスを反映する実行モードでの確立された状態から再開する。
【００７５】
本発明の実施例は以下の特徴の１つ以上を含み得る。参照が正常な動作を保証できない場合、命令は代替実行モードで再実行されるか、または、プログラム状態が以前の状態に復元され得る。第２の表現は、正常に動作するメモリに向けられると考えられる各メモリロードと、正常に動作しないメモリに向けられると考えられるメモリロードとの間での区別の指標により注釈が付けられる。有効なメモリアドレスを有するデバイスは、コンピュータの入出力空間のアドレスを持ち得る。メモリ参照命令を包含するプログラムユニットのプリアンブルのコードは、命令実行回路の状態を確立することができ、命令実行回路は、デバイスへの参照の状態および評価の両方の評価に基づき例外を生じるように設計されている。命令に埋め込まれた注釈は、正常に動作しないデバイスへの参照が例外を生じるべきであるかどうかを決定するために評価され得る。個々の副作用の命令が例外を生じるべきであるかどうかの評価は、コンピュータのアドレス変換回路に埋め込まれた回路において行われ得る。例外は、セグメントデスクリプタおよび副作用の評価の両方の評価に基づいて生じ得る。セグメントデスクリプタにおいてコード化された注釈は、正常に動作しないデバイスへの参照が例外を生じるべきであるかどうかを決定するために評価され得る。セグメントデスクリプタは、別のセグメントデスクリプタをコピーし、注釈を変更することによって形成され得る。形成されたセグメントデスクリプタは、副作用のシーケンスの変更に対する変換の仮定の感度を指示する変数をコピーすることができる。副作用の順序づけの相違は、相互に対する２つの副作用の再順序づけ、変換による副作用の除去、またはバイナリトランスレータにおける２つの副作用の結合を含み得る。復元ステップは、例外が目的プログラムで発生した場合に開始され得る。実行は復元された状態から再開でき、再開された実行は、参照インプリメンテーションの精確な副作用エミュレーションを実行する。変換中に生成されたデスクリプタは、状態を例外前の参照状態に復元するために使用することができる。
【００７６】
一般に、第５３の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。第１のインタプリタが命令セットでコード化されたプログラムを実行し、この第１のインタプリタは完全には正確ではない。基本的にハードウェアによる、第２の十分に正確なインタプリタは、命令セットの命令を実行する。不正確な解釈のいずれかの副作用が不可逆的にコミットする前に、モニタが第１のインタプリタによる十分に正確な解釈からのあらゆる逸脱を検出する。モニタが逸脱を検出すると、実行は、プログラムにおける安全なポイントまで少なくとも完全な命令によってロールバックされ、第２のインタプリタにおいて実行は再び開始される。
【００７７】
一般に、第５４の態様において、本発明は、方法および、その方法の実行のためのコンピュータを特徴とする。バイナリトランスレータが原始プログラムを目的プログラムに変換し、変換された目的プログラムは原始プログラムとは異なる実行ビヘイビアを有する。割込みハンドラは、目的プログラムの実行の間に発生する割込みに対し、原始プログラムの実行の間に発生したはずである状態に対応し、そこから実行が継続し得る、プログラムの状態を確立することによって応答し、その確立された状態から原始プログラムの実行を開始する。
【００７８】
本発明の実施例は以下の特徴の１つ以上を含み得る。第１のインタプリタは、ソフトウェアエミュレータおよび／またはソフトウェアバイナリトランスレータを含み得る。第２のインタプリタは、コンピュータにネイティブではない命令セットの命令を解釈できる。ソフトウェアバイナリトランスレータは、プログラムの全体より小さいセグメントを変換するために、プログラムの実行と並行して動作し得る。実行の継続は、少なくとも２つの完全な命令により第１のインタプリタの実行をロールバックすることを含み得る。実行の継続は、いくつかの命令の複数の別個のサブオペレーションが第１のインタプリタによって混合された状態から第１のインタプリタの実行をロールバックすることを含み得る。実行の継続は、チェックポイントに実行をロールバックする、または第１のインタプリタにおけるチェックポイントまで実行を前進させることを含み得る。十分に正確な解釈からの検出された逸脱は、バイナリトランスレータによって導入されたプログラム変換の無効性の検出、または同期実行例外の検出を含む。
【発明の効果】
【００７９】
本発明の実施例は以下の利益のうちの１つ以上を提供できる。
古いアーキテクチャのコンピュータ用に製造されたプログラムが、新しいアーキテクチャのコンピュータにおいて実行できる。古いバイナリをいかなる修正も伴わずに実行できる。古いバイナリを新しいものと混ぜることができる。例えば、古いアーキテクチャ用にコード化されたプログラムは、新しい命令セットでコード化されたライブラリルーチンを呼び出すことができ、または逆も可能である。古いライブラリおよび新しいライブラリを自由に混ぜることができる。新しいバイナリおよび古いバイナリが同じアドレス空間を共有でき、それにより、共通のデータを共有できる新しいバイナリおよび古いバイナリの能力を改善する。あるいはまた、古いバイナリを、いかなるデータもいずれの新しいバイナリと共有させることなく、新しいコンピュータの保護された個別のアドレス空間において実行できる。呼び出し側は呼び出された側がコード化されているＩＳＡを知る必要がないので、コンテキストを明示的に保存および復元する負担を回避できる。本発明はソフトウェアの複雑さを低減させる。すなわち、ソフトウェアは、バイナリの全部の可能なモードおよび混合物との全部の可能なエントリおよび出口のための明示的な備えを設ける必要がない。古い命令および新しい命令を処理するためのパイプラインはインプリメンテーションの断片を共有することができ、２つの命令セットをサポートするコストを低減させる。新しいコンピュータは古いコンピュータを完全にモデル化することができ、いずれかの特定のソフトウェア製造物によって課される何らかのソフトウェア規約にまったく頼らずに、新しいコンピュータが、変化するオフザシェルフオペレーティングシステムを含む古いコンピュータ用のあらゆるプログラムを実行可能にする。変換されたターゲットコードがソースコードの物理ページと関係づけられて追跡されるので、たとえ物理ページが仮想アドレス空間の異なるポイントでマップされても、単一の変換が全部のプロセスに再使用されるはずである。これは共有ライブラリの場合に特に有利である。
【００８０】
プロファイルデータは、頻繁に実行されるようなプログラムの部分を識別する「ホットスポット」ディテクタにおいて使用され得る。そうした頻繁に実行される部分はその後、プログラマまたはソフトウェアのいずれかによって、より迅速に走行するように変更することができる。プロファイルデータは、命令のバイナリコーディングにおける曖昧さを解決するために、バイナリトランスレータによって使用され得る。プロファイラにより生成された情報は、命令テキスト自体を参照する必要なく、ホットスポットディテクタがプロファイルから離れて駆動され得るほど十分に完全である。これはキャッシュの汚染を減らす。Ｘ８６命令テキストにおける曖昧さ（命令テキストから推定できないあるセットの命令の意味、例えばセグメントデスクリプタからのオペランドサイズ情報）は、プロファイル情報の参照によって決定される。プロファイラによって収集された情報は、相対的にほとんどオーバヘッドを伴わず、従ってキャッシュ汚染を低減し、ホットスポットディテクタおよびバイナリトランスレータに必要な情報を簡潔に表現している。プロファイラは、コンピュータのハードウェアインプリメンテーションに組み込まれ、プログラムにおける遅延をほとんど伴わず、高速に走行できるようにし、プロファイリングのオーバヘッドは実行速度のわずか数パーセントである。
【００８１】
制御は、最適でない命令ストリームに対するいかなる変更も伴わず、最適でない命令ストリームから最適化された命令ストリームに転送され得る。それらの場合も、最適でない命令ストリームは、正確な実行のための参照として使用可能であり続ける。命令ストリームは、多様な実行条件を制御するための情報で注釈され得る。
【００８２】
どのプログラム変換最適化が安全かつ正確であるか、また、いずれが誤りのリスクを呈しているかを決定するために、プロファイルが使用できる。危険な最適化または高速化の上述のすべての機会を差し控えるのではなくむしろ、最適化または高速化が試行され、実際の成功／失敗について監視される。実際に最適化が危険であると判明した場合、より低速な最適でない実行モードが呼び出され得る。
【００８３】
単一の命令コーディングが、プログラマおよびコンパイラに露呈されるＲＩＳＣ命令セットとして、またマイクロコード命令セットとして使用され得る。これは、設計の試験可能性を改善し、設計の量を減らす。プログラムはマイクロアーキテクチャの完全な性能および柔軟性を利用することができる。ネイティブのマイクロ命令は単純である。個々のマイクロ命令は、それぞれのコンテキストからほとんど完全に独立して実行し、任意の命令は、以前または以後の命令と関係なく、常に同じ動作を実行する。連続する命令間でのインタロックの量も低減する。Ｘ８６命令セットといった複雑な命令セットをインプリメントする複雑さの多くは、ハードウェアから取り除かれ、誤りが容易に回避、検出および訂正されるソフトウェアエミュレータに移される。
【００８４】
個々の命令は、以前または以後の命令とほとんどまったくコンテキスト上の関係を伴わず、実行し退去する。ネイティブの命令の実行ビヘイビアは、命令の演算コードビット、明示的なオペランドと呼ばれるレジスタの内容、そしてごくまれに機械モードにおいて、命令シーケンスまたは他のコンテキストによって決定される。命令は、単純なロード／記憶／演算形式の命令に通常かつ自然に含まれている情報以上にほとんどまったく注釈を必要としない。例えば、ネイティブのタペストリー命令は、ネイティブのタペストリーバイナリから受け取ったかまたは、コンバータによりＸ８６命令から生成されたかにかかわらず、同じ機能を実行する。コンバータによって生成された命令は、それらが、Ｘ８６命令のレシピの最初の命令であるか、レシピの最後の命令であるか、またはレシピの真ん中の命令であるかどうかにかかわらず、同じ機能を実行する。
【００８５】
命令は個々に退去する。すなわち、命令の副作用（アーキテクチャ的に可視のレジスタまたはメモリに書き込まれた結果、制御の転送、例外など）がコミットすると、それらは、後の命令による取り消しのためにそれ以上追跡される必要がない。Ｘ８６命令のためのレシピを構成しているネイティブの命令は、レシピの全部のネイティブ命令について副作用を収集する必要なく、個々に退去できる。個々の退去は、ハードウェアの単純化を可能にし、一部のクリティカルパスを減少させる。副作用が、グループとしてコミットするために複数の命令の間で収集されるのではなく、各命令が退去すると同時にコミットする場合、「アカウンティング」は簡素化される。
【００８６】
個々の機構は、多くのニーズの間で共有されるように全体的に適用可能であるように設計されている。例えば、例外インタフェースは、従来の例外および、実行をソフトウェアエミュレータに転送する命令内例外の両方をサポートするように設計されている。エミュレータからの復帰は、従来の機械のあらゆる他の例外からの復帰とほとんどまったく同様である。汎用レジスタファイルは、レジスタファイルとしての従来の用途のために、また、コンバータ内における、命令内中間結果を保持するために設計されている。プロセッサレジスタ機構は、従来の機械制御機能および、ハードウェアでのＸ８６実行、ソフトウェアでのＸ８６実行および、シングルステッピング、デバッグなどといった複雑なＸ８６機能性のエミュレーションの間におけるインタフェースの制御の両方に対して広範に適用可能である。
【００８７】
ハードウェアは、Ｘ８６の複雑なビヘイビアの多くをソフトウェアエミュレータに移すことによって相対的に単純に保たれる。エミュレータは、他の機械例外に使用される機構によって呼び出される。複雑なＸ８６セグメンテーションおよびページングビヘイビアといったほとんどすべての命令ごとに使用される複雑なＸ８６機能は、性能を改善するために、ハードウェアにおいてインプリメントされる。例えば、ある組のＸ８６命令間の割込みの禁止は、ハードウェアではなくソフトウェアにおいてインプリメントされる。
【００８８】
上記の利益および特徴は、代表的な実施例のもののみにすぎず、本発明の理解の助けとなるためだけに提示されている。本発明の付加的な特徴および利益は、以下の説明、図面および請求の範囲から明白になるであろう。
【図面の簡単な説明】
【００８９】
【図１ａ】コンピュータシステムのブロック図である。
【図１ｂ】コンピュータシステムのブロック図である。
【図１ｃ】コンピュータシステムのブロック図である。
【図１ｄ】コンピュータシステムのブロック図である。
【図１ｅ】図１ａ〜１ｄに示すシステムのＰＳＷ（プログラムステータスワード）の図である。
【図２ａ】図ｌｅのＰＳＷの数ビットの意味に関する表である。
【図２ｂ】例外ハンドラのアクションに関する表である。
【図２ｃ】例外ハンドラのアクションに関する表である。
【図３ａ】コンピュータシステムのブロック図である。
【図３ｂ】メモリ内のプログラムフローを示すブロック図である。
【図３ｃ】メモリ内のプログラムフローを示すブロック図である。
【図３ｄ】メモリ内のプログラムフローを示すブロック図である。
【図３ｅ】メモリ内のプログラムフローを示すブロック図である。
【図３ｆ】メモリ内のプログラムフローを示すブロック図である。
【図３ｇ】流れ図である。
【図３ｈ】流れ図である。
【図３ｉ】流れ図である。
【図３ｊ】流れ図である。
【図３ｋ】データ宣言またはデータ構造を示す。
【図３ｌ】メモリ内のプログラムフローを示すブロック図である。
【図３ｍ】メモリ内のプログラムフローを示すブロック図である。
【図３ｎ】メモリ内のプログラムフローを示すブロック図である。
【図３ｏ】メモリ内のプログラムフローを示すブロック図である。
【図４ａ】メモリ内のプログラムフローおよび、そのプログラムフローを記述するプロファイル情報を示すブロック図である。
【図４ｂ】プロファイリング事象コードおよびそれらの意味の表である。
【図４ｃ】データ宣言またはデータ構造を示す。
【図４ｄ】データ宣言またはデータ構造を示す。
【図４ｅ】メモリ内のプログラムフローおよび、そのプログラムフローを記述するプロファイル情報を示すブロック図である。
【図４ｆ】メモリ内のプログラムフローおよび、そのプログラムフローを記述するプロファイル情報を示すブロック図である。
【図４ｇ】コンピュータのプロセッサレジスタを示す。
【図４ｈ】コンピュータのプロセッサレジスタを示す。
【図４ｉ】コンピュータのプロセッサレジスタを示す。
【図５ａ】プロファイラの制御のための有限状態機械を示す。
【図５ｂ】回路ブロック図である。
【図６ａ】ＰＩＰＭ（物理ＩＰマップ）およびそのエントリのブロック図である。
【図６ｂ】回路ブロック図である。
【図６ｃ】流れ図である。
【図７ａ】回路ブロック図である。
【図７ｂ】回路ブロック図である。
【図７ｃ】コンピュータのプロセッサレジスタを示す。
【図７ｄ】流れ図である。
【図７ｅ】回路ブロック図である。
【図７ｆ】回路ブロック図である。
【図７ｇ】回路ブロック図である。
【図７ｈ】回路ブロック図である。
【図７ｉ】コンピュータのプロセッサレジスタを示す。
【図７ｊ】データ宣言またはデータ構造を示す。
【図８ａ】コンピュータのプロセッサレジスタを示す。
【図８ｂ】流れ図である。
【図８ｃ】流れ図である。
【図９ａ】コンピュータシステムのブロック図である。
【図９ｂ】コンピュータのプロセッサレジスタを示す。
【図９ｃ】コンピュータの命令を示すデータ構造図である。
【図９ｄ】コンピュータの命令と関係する情報を示す表である。
【図９ｅ】Ｘ８６命令の擬似コードおよび対応するネイティブのタペストリー命令を示す。
【図９ｆ】コンバータによる一時レジスタの使用を示す表である。
【図９ｇ】Ｘ８６命令の擬似コードおよび対応するネイティブのタペストリー命令を示す。
【図９ｈ】Ｘ８６命令の擬似コードおよび対応するネイティブのタペストリー命令を示す。
【図９ｉ】Ｘ８６命令の擬似コードおよび対応するネイティブのタペストリー命令を示す。
【図９ｊ】Ｘ８６命令の擬似コードおよび対応するネイティブのタペストリー命令を示す。
【図９ｋ】Ｘ８６命令の擬似コードおよび対応するネイティブのタペストリー命令を示す。
【発明を実施するための形態】
【００９０】
説明
説明は以下の通り編成されている。
Ｉ．タペストリーシステムの概要および、本発明のいくつかの態様における一般的使用の特徴
Ａ．システム概要
Ｂ．タペストリー命令パイプライン
Ｃ．システム機能のための制御ポイントとしてのアドレス変換
Ｄ．バイナリ変換、ＴＡＸｉおよびコンバータセーフティネットの概要
Ｅ．システム全体の制御
Ｆ．ＸＰビットおよび保護されていない例外
【００９１】
ＩＩ．プログラムテキストのための命令セットアーキテクチャ（ＩＳＡ）の指標
【００９２】
ＩＩＩ．Ｘ８６スレッドと関係づけられたタペストリープロセッサコンテキストの保存
Ａ．概要
Ｂ．サブプログラムＰｒｏｌｏｇｓ
Ｃ．Ｘ８６−タペストリー遷移ハンドラ
Ｄ．タペストリー−Ｘ８６遷移ハンドラ
Ｅ．タペストリーオペレーティングシステムにおける割込みまたは例外時のＩＳＡクロッシングの処理
Ｆ．Ｘ８６オペレーティングシステムからのタペストリー実行の再開。
Ｇ．実施例
Ｈ．代替実施例
【００９３】
ＩＶ．あるＩＳＡから他方への遷移を管理するための代替方法
Ａ．プログラムテキストのための呼び出し規約（ＣＣ）の指標
Ｂ．制御転送セマンティクスの記録および呼び出し規約の調停
【００９４】
Ｖ．変換のためのホットスポットを決定するためのプロファイリング
Ａ．プロファイリングの概要
Ｂ．プロファイル可能事象および事象コード
Ｃ．プロファイルされた事象のための記憶形式
Ｄ．特定の例示事象（ページストラッドル）のために収集されたプロファイル
【００９５】
情報
Ｅ．プロファイラを制御する制御レジスタ
Ｆ．プロファイラ状態機械およびプロファイラの動作
Ｇ．４ビット記憶形式からの５ビット事象コードの決定
Ｈ．プロファイラ、例外、およびＸＰ保護／非保護ページプロパティの対話
Ｉ．代替実施例
【００９６】
ＶＩ．変換を求めるためのプロービング
Ａ．プロービングの概要
Ｂ．統計プロービングの概要
Ｃ．統計プロービングのためのハードウェアおよびソフトウェア構造
Ｄ．統計プロービングの動作
Ｅ．プロービングの付加的な特徴
Ｆ．ＴＡＸｉコードの実行の完了およびＸ８６コードへの復帰
Ｇ．プロービングおよびプロファイリングの対話
Ｈ．適応便宜的統計技法の代替使用
【００９７】
ＶＩＩ．変換された命令の有効化および無効化
Ａ．簡素化したＤＭＵモデル
Ｂ．少メモリ使用設計のデバイスの概要
Ｃ．セクタ監視レジスタ
Ｄ．インタフェースおよび状態レジスタ
Ｅ．動作
Ｆ．回路
Ｇ．ＤＭＵ＿状態レジスタ
Ｈ．ＤＭＵ＿コマンドレジスタ
【００９８】
ＶＩＩＩ．故障結果の管理
Ａ．最適化変換により再順序づけされた事象の順序正しいハンドリングの保証
Ｂ．正常に動作しないメモリへの参照のプロファイリング
Ｃ．精確な境界に到達するための規範的機械状態の調停
Ｄ．セーフティネット実行
【００９９】
ＩＸ．コンバータ
Ａ．概要
１．パイプライン構造および変換レシピ
２．エミュレータ
３．サイドバンド情報：ｆｒａｃビット、命令境界、割込み可能ポイントなど
４．割込み、トラップおよび例外
５．ｆｒａｃビットおよび、レシピの継続
６．外部形式からフォーマットされた形式への拡張
【０１００】
Ｂ．命令の個々の退去
１．一時レジスタのレシピの使用
２．異なる参照クラスに適した記憶保護検査をトリガするメモリ参照命令
３．ターゲットリミットチェック命令
ａ．ＬＯＡＤ／ＳＴＯＲＥおよび分岐リミットチェック
ｂ．ニアレジスタ関連ＣＡＬＬのターゲットリミットチェック
４．コアトミック実行を保証するための命令の特殊グループ化。
５．ＬＯＯＰ命令のエミュレータにおける展開
６．反復ストリング命令
【０１０１】
Ｃ．単一Ｘ８６命令の複数の副作用をエミュレートするために複数のネイティブ命令の結果の収集
１．ロード／記憶アドレスデバッグ比較結果の収集およびフィルタリング
２．ＦＰ  ＤＰ／ＩＰ／ＯＰ延期
３．次の命令とのＳＴＩＳ（命令ストリームへの記憶）フラッシュ境界
【０１０２】
Ｄ．マイクロ命令セットとしての外部露呈ＲＩＳＣ  ＩＳＡ−−ユーザアクセス可能な第１の命令セットによる第２の命令セットの変換およびインプリメンテーション
１．外部マイクロコード
２．その他の特徴
【０１０３】
Ｅ．リスタート可能な複合命令
１．ネイティブシングルステップによるアトミックＭＯＶ／ＰＯＰスタックセグメントペア
２．ネイティブシングルステップによるＩＦビット変更禁止
【０１０４】
Ｘ．割込み優先順位
Ｉ．Ｔａｐｅｓｔｒｙ（タペストリー）システムの概要および本発明のいくつかの側面における一般的な使用の特徴
Ａ．システム概要
図１ａ、１ｂ、および１ｃを参照すると、カリフォルニア州サニーベールにあるＣｈｒｏｍａｔｉｃ  Ｒｅｓｅａｒｃｈ，Ｉｎｃ（クロマティック・リサーチ・インク）のＴａｐｅｓｔｒｙ（タペストリー；以下、本件明細書において『タペストリー』とする）製品に具体化された本発明が示されている。『タペストリー』は、Ｉｎｔｅｌ（インテル）Ｘ８６ファミリ・プロセッサの適正なインプリメンテーションを提供するハードウエアおよびソフトウエア機能を伴う高速ＲＩＳＣ（縮小命令セット）プロセッサ１００である。（「Ｘ８６」は、８０８６、８０１８６、．．．８０４８６、Ｐｅｎｔｉｕｍ（登録商標）（ペンティアム（登録商標））、およびＰｅｎｔｉｕｍ（登録商標）  Ｐｒｏ（ペンティアム（登録商標）・プロ）を含むファミリを指す。このファミリについてはＩｎｔｅｌ  Ｃｏｒｐｏｒａｔｉｏｎ（インテル・コーポレーション）のＩＮＴＥＬ  ＡＲＣＨＩＴＥＣＴＵＲＥ  ＳＦＴＷＡＲＥ  ＤＥＶＥＬＯＰＥＲ'Ｓ  ＭＡＮＵＡＬ（インテル・アーキテクチャ・ソフトウエア・デベロッパーズ・マニュアル）１−３巻（１９９７年）に説明が掲載されている。）『タペストリー』は、たとえばＭｉｃｒｏｓｏｆｔ（マイクロソフト）またはＩＢＭのオペレーティング・システムによって負わされるソフトウエア規約にまったく依存することなく、Ｘ８６のアーキテクチャ、特に、メモリ・マネジメントを含めたＭＭＸ拡張を伴う完全なＰｅｎｔｉｕｍ（登録商標）（ペンティアム（登録商標））を完全にインプリメントする。『タペストリー』システムは、通常、対称共有メモリ・マルチプロセッサとして相互接続された２つないしは４つのプロセッサを含む（図１ａ、１ｂ、および１ｃには、そのうちの１つだけが示されている）。
【０１０５】
『タペストリー』プロセッサ１００は、インストラクション・キャッシュ（Ｉ−キャッシュ）１１２、もしくはメモリ１１８の、ＩＰ（インストラクション・ポインタ、他のマシンにおいては、一般にＰＣ、つまりプログラム・カウンタとして知られる）１１４によって指定されるロケーションから、Ｉ−ＴＬＢ（インストラクション翻訳ルック−アサイド・バッファ）１１６によって提供される仮想アドレス‐物理アドレス変換を用いてインストラクションをフェッチする（ステージ１１０）。Ｉ−キャッシュ１１２からフェッチされたインストラクションは、ＲＩＳＣ実行パイプライン１２０によって実行される。従来のＩ−ＴＬＢによって提供されるサービスに加えて、Ｉ−ＴＬＢ  １１６は、フェッチしたインストラクション・バイトの解釈を行うインストラクション環境を選択する複数のビット１８２、１８６のストアを行う。一方のビット１８２は、メモリ・ページ上のインストラクションに関するインストラクション・セット・アーキテクチャ（ＩＳＡ）を選択する。したがって、『タペストリー』ハードウエアは、ネイティブ・インストラクションならびにＩｎｔｅｌ（インテル）Ｘ８６  ＩＳＡのいずれも容易に実行することができる。この特徴については、後述のセクションＩＩにおいてさらに詳しく説明する。
【０１０６】
Ｘ８６  ＩＳＡにおいてエンコーディングされたプログラムの実行は、通常、ネイティブ『タペストリー』ＩＳＡにコンパイルされた同じプログラムの実行より遅くなる。プロファイラ４００は、Ｘ８６プログラムの実行フローの詳細を記録する。プロファイリングについては、後述のセクションＶにおいてさらに詳しく説明する。ホット・スポット・ディテクタ１２２は、プロファイルを分析して、プログラムの「ホット・スポット」部分、すなわち頻繁に実行される部分を探し出す。ホット・スポットが検出されると、バイナリ・トランスレータ１２４がホット・スポットのＸ８６インストラクションを、「ＴＡＸｉコード」と呼ばれる最適化したネイティブ『タペストリー』コードに翻訳する。Ｘ８６プログラムのエミュレーションの間は、プローバ６００が、ネイティブ・コードに翻訳されたＸ８６インストラクションの実行に関するプログラム・フローをモニタする。プローバ６００が、実行しようとしているＸ８６コードに対応する翻訳済みネイティブ『タペストリー』コードが存在すること、かつそれに加えてそれが正しいことの叙述が満たされていることを検出すると、プローバ６００は、そのＩＰをリダイレクトし、Ｘ８６コードからではなく、翻訳済みネイティブ・コードからインストラクションをフェッチする。プロービングについては、後述のセクションＶＩにおいてさらに詳しく説明する。Ｘ８６コードと翻訳済みネイティブ『タペストリー』コードの間の対応は、ＰＩＰＭ（物理インストラクション・ポインタ・マップ）６０２において維持される。
【０１０７】
実行の間にＸ８６プログラム・テキストが修正されることがあるため、システムは、それ自体をモニタして、以前のＸ８６プログラム・テキストを無効にするおそれのあるオペレーションを検出する。こういった無効にするおそれのあるオペレーションには、自己修正コード、およびダイレクト・メモリ・アクセス（ＤＭＡ）転記がある。この種のオペレーションが検出されると、システムは、潜在的な修正Ｘ８６テキストに対応するネイティブ『タペストリー』翻訳があれば、それを無効にする。同様に、たとえばプロファイル・データのように、修正されたＸ８６データに関連付けされている取り込み済みもしくはキャッシュ済みデータがあればそれを無効にする。この有効性管理メカニズムについては、後述のセクションＩ．Ｆ、ＶＩＩ、およびＶＩＩＩにおいて詳細を説明する。
【０１０８】
このシステムは、非ＤＲＡＭメモリ、たとえばＩ／Ｏデバイス用のＲＯＭ  ＢＩＯＳ、メモリ‐マップ済みコントロール・レジスタ等にストアされているインストラクションの翻訳を行わない。
【０１０９】
翻訳済みネイティブ『タペストリー』コード用のストレージは、たとえばＬＲＵ（リースト−リーセントリー−ユーズド；もっとも参照されていないページを入れ替える方式）または先入れ先出し（ＦＩＦＯ）といった入れ替えポリシーの下に解放し、再利用することができる。
【０１１０】
Ｘ８６プログラムの一部が、プログラムのシングル実行の間に複数回にわたってネイティブ『タペストリー』コードに翻訳されることがある。通常、翻訳は、『タペストリー』マルチプロセッサのうちの１つのプロセッサ上において実行されるが、その間には別のプロセッサ上において実行が進行している。
【０１１１】
数年にわたり、Ｉｎｔｅｌ（インテル）その他は、ＲＩＳＣ実行コアを使用してＸ８６インストラクション・セットをインプリメントしてきたが、このＲＩＳＣインストラクション・セットは、プログラムによる使用のために公開されていない。『タペストリー』コンピュータは、３つの新しいアプローチを採用した。第１に『タペストリー』マシンは、ネイティブＲＩＳＣインストラクション・セットならびにＸ８６インストラクション・セットをともに公開し、それによりその両方におけるシングル・プログラムのコーディングを、両者の間における順逆の呼び出しの自由度を伴って可能にする。このアプローチは、ＩＳＡビット１８０、１８２、コンバータ１３６に対するコントロール、および例外ハンドラ（後述のセクションＩＩおよびＩＩＩを参照されたい）によって、あるいは別の実施態様においては、ＩＳＡビット１８０、１８２、呼び出し規約ビット２００、セマンティック・コンテキスト・レコード２０６、および対応する例外ハンドラ（後述のセクションＩＶを参照されたい）によって可能になる。第２に、Ｘ８６プログラムをネイティブＲＩＳＣコードに翻訳することが可能であり、それによりＸ８６プログラムは、ＲＩＳＣインストラクション・セットにおいて得られる高速化の機会を格段に利用することが可能になる。この２番目のアプローチは、プロファイラ４００、プローバ６００、バイナリ・トランスレータ、およびメモリ・マネジメントの特定の機能（後述するセクションＶ〜ＶＩＩを参照されたい）によって可能になる。第３に、これら２つのアプローチが協働し追加のレベルの恩典を提供する。
【０１１２】
この開示において論じている特徴の多くは、「ＰＰ＿ｅｎａｂｌｅ」（ページ・プロパティ・イネーブル）と名付けられたプロセッサ・コントロール・レジスタ内のシングル・ビットによるグローバル・コントロールの下に置かれる。このビットがゼロのときは、ＩＳＡビット１８０、１８２が無視され、インストラクションが『タペストリー』ネイティブ・モードで解釈され、プロファイリングがディセーブルされ、かつプロービングがディセーブルされる。
【０１１３】
Ｂ．『タペストリー』命令パイプライン
図１ｃおよび図９ａを参照すると、『タペストリー』プロセッサ１００は、８または９ステージのパイプラインをインプリメントしている。ステージ１（ステージ１１０）は、Ｉ−キャッシュ１１２からラインをフェッチする。ステージ２（整列ステージ１３０）および３（変換ステージ１３４、１３６、１３８）は、Ｘ８６モードとネイティブ『タペストリー』モードとで異なった動作をする。ネイティブ・モードにおいては、整列ステージ１３０が、パイプラインの残部と非同期で動作し、Ｉ−キャッシュから伸縮プリフェッチ・バッファ１３２にデータをフェッチする。Ｘ８６モードにおいては、整列ステージ１３０が、可変長Ｘ８６インストラクションの間の境界を決定するためにインストラクション・ストリームを部分的にデコードし、完全なＸ８６インストラクションを変換ステージ１３４に渡す。Ｘ８６エミュレーションの間は、ステージ３、つまり変換ステージ１３４、１３６が各Ｘ８６インストラクションをデコードし、それをコンバータ１３６がネイティブ『タペストリー』コードのシーケンスに変換する。Ｘ８６インストラクションからネイティブ・インストラクションへの分解においては、コンバータ１３６が、１サイクルごとに１つもしくは２つの『タペストリー』インストラクションを発行する。各『タペストリー』プロセッサ１００は、４つの並列したパイプライン化された機能ユニット１５６、１５８、１６０、１６２を有し、パイプラインの残りの５ステージの４−ウェイ・スーパースカラー問題をインプリメントする。ネイティブ・モードにおいては、変換ステージ１３４、１３８が最大で４つの、同時に実行可能な独立したインストラクションを決定し、それを下流の４つのスーパースカラー実行パイプラインに向けて発行する。（別のマシンの記述においては、これを『スロッティング』と呼んでいることもあり、充分なリソースおよび機能ユニットが使用可能であるか、またいずれの機能ユニットに対していずれのインストラクションを発行すべきかといったことを決定する。）デコード・ステージ１４０（または「Ｄ−ステージ」）、レジスタ読み出しステージ１４２（または「Ｒ−ステージ」）、アドレス生成ステージ１４４（または「Ａ−ステージ」）、メモリ・ステージ１４６（または「Ｍ−ステージ」）、実行ステージ１４８（または「Ｅ−ステージ」）、およびライト−バック・ステージ１５０（または「Ｗ−ステージ」）は、少なくともセクションＩ〜ＶＩＩＩに開示している本発明の目的に関して、従来のＲＩＳＣパイプライン・ステージと考えることができる。パイプラインについては、セクションＩＸにおいて図９ａ〜９ｃの説明を行うときに詳しく述べる。
【０１１４】
コンバータ１３６は、各Ｘ８６インストラクションをデコードし、それを１ないしは複数の単純な『タペストリー』インストラクションに分解する。これらの単純なインストラクションは、Ｘ８６インストラクションに関する「レシピ」と呼ばれる。
【０１１５】
表１を参照すると、Ｘ８６コンバータ１３６がアクティブのときには、Ｘ８６リソースと『タペストリー』リソースの間に固定されたマッピングが存在する。たとえばＸ８６アーキテクチャのレジスタＥＡＸ、ＥＢＸ、ＥＣＸ、ＥＤＸ、ＥＳＰ、およびＥＢＰは、コンバータ・ハードウエア１３６によって、それぞれ『タペストリー』物理マシンのレジスタＲ４８、Ｒ４９、Ｒ５０、Ｒ５１、Ｒ５２およびＲ５３にマップされる。１６ビットの符号および指数に分けられるＸ８６の８つの浮動小数点レジスタ、および６４ビットの小数は、レジスタＲ３２〜４７にマップされる。Ｘ８６メモリは、後述のセクションＩ．Ｃにおいて論じているように『タペストリー』メモリにマップされる。
【０１１６】
レジスタの使用は、Ｘ８６レジスタへのマッピングも含めて、表１に要約されている。「ＣＡＬＬ（呼び出し）」列は、レジスタを使用してネイティブ『タペストリー』呼び出し規約において引数を渡す方法を記述している。（呼び出し規約については、後述のセクションＩＩＩ．Ａ、ＩＩＩ．Ｂ、およびＩＶにおいて詳細を論じる。）「Ｐ／Ｈ／Ｄ」列は、『タペストリー』呼び出し規約の別の側面を記述しており、呼び出しを通じて保存されるレジスタ（呼び出されるサブプログラムがレジスタを修正する場合には、開始時にそのレジスタを保存し、終了時にそれを復元しなければならない）、半保存されるレジスタ（下位３２ビットが呼び出しを通じて保存されるが、上位３２ビットは修正が許容される）、および破壊されるレジスタについて示している。「Ｘ８６  ｐ／ｄ」列は、３２ビットＸ８６レジスタに対応するレジスタの下位３２ビットが、呼び出しによって保存されるか、あるいは破壊されるかを示している。「コンバータ」、「エミュレータ」、および「ＴＡＸｉ」列は、３つの異なるコンテキストの下に『タペストリー』レジスタとＸ８６レジスタの間におけるマッピングを示している。レジスタｒ３２〜ｒ４７について、Ｘ８６列内の「ｈｉ（ハイ）」は、そのレジスタがＸ８６の拡張精度浮動小数点値における１６ビット符号および指数部分を保持していることを示し、「ｌｏ（ロー）」は、６４ビットの小数を示す。
【０１１７】
【表１−１】
0005427742.tif 000002
【０１１８】
【表１−２】
0005427742.tif 000003
【０１１９】
【表１−３】
0005427742.tif 000004
【０１２０】
Ｒ０は読み出し専用であり、常にゼロになる。Ｘ８６エミュレーションの間、Ｒ１〜Ｒ３は、例外ハンドラ用に予約される。Ｒ４は、イミディエートとして表現できない値を具体化するためにアッセンブラが使用するためのアッセンブラ・テンポラリである。Ｘ８６エミュレーションの間、Ｒ１５〜Ｒ３１は、後述のセクションＶにおいて論じるように、プロファイラ４００による使用に割り当てられ、Ｒ５〜Ｒ１４は、「ＣＴ１」〜「ＣＴ１０」として指定されているが、セクションＩＸ．Ｂ．１において論じるように、「コンバータ・テンポラリ」としての使用のために予約される。
【０１２１】
『タペストリー』は、Ｘ８６の特徴の多くをスーパーセットしている。たとえば、『タペストリー』ページ・テーブル・フォーマットは、Ｘ８６ページ・テーブル・フォーマットとまったく同じであり；図１ｄに示したように、ページ・フレームに関する追加情報が『タペストリー』プライベート・テーブル、ＰＦＡＴ（ページ・フレーム属性テーブル）１７２にストアされる。図１ｅに示したが、『タペストリー』ＰＳＷ（プログラム・ステータス・ワード）１９０は、Ｘ８６
ＰＳＷ  １９２を埋め込んでおり、さらにいくつかの追加ビットを含んでいる。
【０１２２】
『タペストリー』ハードウエアは、Ｘ８６アーキテクチャを完全にはインプリメントしない。あまり洗練されていない、使用頻度の少ない一部の特徴は、ソフトウエア・エミュレータ（図３ａの３１６）においてインプリメントされる。しかしながら、ハードウエア・コンバータ１３６とソフトウエア・エミュレータ３１６の組み合わせによって、Ｘ８６アーキテクチャの完全かつ忠実なインプリメンテーションがもたらされている。
【０１２３】
後述するセクションＩＩＩには、エミュレータ３１６の１つの特徴が詳しく説明されている。ハードウエア・コンバータ１３６とソフトウエア・エミュレータ３１６の間における相互作用については、包括的には後述するセクションＩＸに、より詳細に述べればセクションＩＸ．Ａ．２、ＩＸ．Ｂ．５、ＩＸ．Ｃ、およびＩＸ．Ｅにおいて説明されている。
【０１２４】
Ｃ．システムの特徴に関するコントロール・ポイントとしてのアドレス変換
図１ｄを参照すると、Ｘ８６アドレス変換が『タペストリー』のネイティブ・アドレス変換によってインプリメントされることが示されている。Ｘ８６エミュレーションの間は、ネイティブ仮想アドレス変換１７０が常時オンになる。Ｘ８６アドレス変換がオフになるモードにおいてＸ８６のエミュレーションが行なわれる場合であっても、『タペストリー』アドレス変換は、アイデンティティ・マッピングをインプリメントするためにオンとなる。『タペストリー』アドレス変換ハードウエアを介する各メモリの参照を強制することによって、アドレス変換が、Ｘ８６コンバータ１３６のアクティビティのほとんどをインタセプトする上で、またコンバータの実行をコントロールする上で有利な位置に置かれる。さらに、本発明の多くの特徴に関するコントロール情報を、アドレス変換および仮想メモリ・マネジメントに従来から使用されていたテーブルに関連付けされたテーブル、もしくはそれに類似のテーブルに都合よくストアすることができる。こういったアドレス変換への「係合」によって、『タペストリー』プロセッサおよびソフトウエアは、たとえばＶＧＡグラフィックス・ハードウエア、コントロール・レジスタ、メモリ・マップされるデバイス・コントロール等の「奇妙な」振る舞いを有するＸ８６の部分、および伝統的なＩｎｔｅｌ（インテル）チップ・セットによって特別な扱いが与えられているＸ８６アドレス空間の部分のエミュレーションを仲裁することが可能になる。
【０１２５】
Ｘ８６プログラムが使用している可能性のあるストレージの部分の意味が変更されることを防止するために、それが規約を外れる使用である場合であっても、『タペストリー』プロセッサがＸ８６アドレス変換テーブル内に、その情報をストアすることはない。ページに関する『タペストリー』固有の情報は、『タペストリー』エミュレーションのために特別に作られたＸ８６の構造内にストアされる。ただし、これらの構造の定義は、Ｘ８６アーキテクチャ内にはなく、またエミュレートされたＸ８６ないしはＸ８６上において実行されるプログラムからは不可視となる。ＰＦＡＴ（ページ・フレーム属性テーブル）１７２は、これらの構造の１つである。ＰＦＡＴ  １７２は、物理ページ・フレームに対応し、それらのページ・フレームの処理ならびにマネージのためのデータを保持するエントリを有するテーブルであり、ある意味でＶＡＸ／ＶＭＳ仮想メモリ・マネージャ（たとえば、参照を通じて本件明細書にその内容が取り込まれている１９８４年Ｄｉｇｉｔａｌ  Ｐｒｅｓｓ（ディジタル・プレス）出版のＬＡＷＲＥＮＣＥ  ＫＥＮＡＨ（ローレンス・ケナー）およびＳＩＭＯＮ  ＢＡＴＥ（サイモン・ベイト）による「ＶＡＸ／ＶＭＳ  ＩＮＴＥＲＮＡＬＳ  ＡＮＤ  ＤＡＴＡ  ＳＴＲＵＣＴＵＲＥＳ（ＶＡＸ／ＶＭＳ内部およびデータ構造）」を参照されたい）のＰＦＮ（ページ・フレーム番号）データベースに類似している。ＰＦＡＴ  １７２は、各物理ページ・フレームに対応する１バイト・エントリ１７４を１つ有している。
【０１２６】
後述のセクションＩＩ、ＩＶ、ならびにＶ、およびＶＩにおいて論じるが、ＰＦＡＴエントリ１７４は、対応するページのインストラクションのデコードに使用するＩＳＡをいずれにするか、対応するページ上において使用する呼び出し規約をいずれにするかということをコントロールするビット、あるいはプロービングのコントロールするビットを含んでいる。
【０１２７】
Ｄ．バイナリ変換、ＴＡＸｉおよびコンバータ・セーフティ・ネットの概要
再度図１ａおよび１ｂを参照すると、ＴＡＸｉ（「Ｔａｐｅｓｔｒｙ  ａｃｃｅｌｅｒａｔｅｄ  ｅｘｅｃｕｔｉｏｎ（『タペストリー』加速実行）」；「ＴＡＸｉ」と呼ばれる）は、バイナリ翻訳システムである。ＴＡＸｉは、２つの実行モード、すなわち完全なＸ８６アーキテクチャに絶対価値基準を置くゴールド・スタンダード・インプリメンテーションを忠実にインプリメントするハードウエア・コンバータ１３６（ランタイム・システムにおけるソフトウエア補助を伴う）、およびＸ８６バイナリを『タペストリー』ネイティブ・バイナリに翻訳するソフトウエア・バイナリ・トランスレータ１２４を密接に結合させるが、正当性を侵害するおそれのある特定の楽観的な仮定を行って、翻訳後のコードを最適化する。
【０１２８】
すでに現存するＸ８６バイナリがコンバータ１３６において実行されることから、Ｘ８６バイナリにおけるホット・スポット（頻繁に実行される部分）の認識（１２２）がなされ、『タペストリー』インストラクションへのオン−ザ−フライの翻訳（１２４）が行なわれる。ハードウエア・コンバータ１３６（特に複雑なインストラクションについてはＸ８６エミュレータ３１６と結合される）は、Ｘ８６インストラクションが厳格に順序どおりに実行されなければならないことから、必然的に翻訳後のコードより遅くなる。ハードウエア・コンバータ１３６において単一のインストラクションが「翻訳」されることに対して、Ｘ８６の完全なホット・スポットを翻訳することによって、より多くの最適化の機会が生まれる：Ｘ８６インストラクションは、小さいデータ非依存の『タペストリー』インストラクションに分解可能となり、その後それを、順序から外れて実行し、パイプライニングし、あるいは４つのスーパースカラー・パイプライン（図１ｃの１５６、１５８、１６０、１６２）において実行することが可能になる。
【０１２９】
Ｘ８６コードの実行はプロファイリングされる。このプロファイリング情報は、Ｘ８６プログラムにおける「ホット・スポット」、すなわちプログラムのもっとも頻繁に実行される部分であり、したがってネイティブ『タペストリー』コードへの翻訳からもっとも多くの恩典がもたらされる部分の識別１２２に使用される。Ｘ８６コードにおけるホット・スポットは、トランスレータ１２４によってネイティブ『タペストリー』コード（ＴＡＸｉコード）に翻訳される。Ｘ８６プログラムの実行の進行に従って、実行がモニタされ、実行されようとしているＸ８６コードに関する翻訳済みの等価コードが存在するか否かについての判断が行なわれる。それが存在するときには、翻訳済みのネイティブ『タペストリー』コードに実行が移される。
【０１３０】
ＴＡＸｉトランスレータ１２４は、マシンの振る舞いをいくぶん簡素化した見方を採用している；たとえば、一部のＸ８６インストラクションについては翻訳されない。またトランスレータ１２４は、楽観的な視点を有している。たとえば、トランスレータ１２４は、浮動小数点の例外あるいはページ違反がないことを前提としており、その結果、プログラムの振る舞いを変更することなくオペレーションを再整理し、あるいは推論的に再スケジュールすることが可能になる。さらにトランスレータ１２４は、すべてのメモリ参照が良好な振る舞いを有するメモリに対してなされることを前提とする。（「良好な振る舞いを有するメモリ」とは、最後にストアされたメモリ・ロケーションのデータを負荷が受け取ることになるメモリである。「良好でない振る舞いを有するメモリ」は、メモリ・マップされるデバイス・コントローラに代表され、「Ｉ／Ｏ空間」とも呼ばれ、それにおいては読み出しによってメモリが状態を変化し、もしくは読み出しがもっとも新しく書き込まれた値を返す必要がなく、あるいは２つの連続する読み出しが明瞭に区別されるデータを返す。）たとえばバイナリ・トランスレータ１２４は、メモリ読み出しが再整理可能であることを前提とする。翻訳済みネイティブ『タペストリー』コードは、コンバータ１３６より高速に実行され、翻訳が正しいことが保証できたとき、あるいはあらゆる逸脱が捕捉され、修正できたときに使用される。
【０１３１】
ＴＡＸｉコードの実行は、楽観的な前提の侵害を検出するためにモニタされ、それにより、Ｘ８６コードの適正なエミュレーションからのあらゆる逸脱が検出可能になる。事前チェックによって、正しく実行されるとの保証が得られない翻訳済みコードの領域に実行が入ろうとしていることを検出することも可能であり、あるいは楽観的な前提の侵害があったという事実の後で、ハードウエアが例外を引き渡することも可能である。いずれの場合においても、正当性が保証されないとき、あるいはトランスレータ１２４にとってどのように翻訳するべきかが未知のコードがあるときには、翻訳済みのネイティブ『タペストリー』コードの実行が中止されるか、もしくは安全なチェック・ポイントまで巻き戻され、ハードウエア・コンバータ１３６内において実行が再開される。ハードウエア・コンバータ１３６は、もっとも保守的な前提を採用し、順序、ゴールド・スタンダードの正当性を保証しつつ、あまりリスクを嫌わないバイナリ・トランスレータ１２４に関するセーフティ・ネットとして機能する。
【０１３２】
このセーフティ・ネットのパラダイムによって、バイナリ・トランスレータ１２４をより積極的なものとすることが可能になり、またデベロッパは、正当性の問題をセーフティ・ネットに任せ、パフォーマンス問題に焦点を集中できることから開発が容易になる。セーフティ・ネットのパラダイムの詳細については、セクションＶＩＩＩに議論を譲る。
【０１３３】
『タペストリー』およびＴＡＸｉは、完全なＸ８６アーキテクチャをインプリメントする。Ｘ８６ソフトウエアからの歩み寄りはまったく必要ない；確かに、あらゆるＸ８６オペレーティング・システムは『タペストリー』上において動作可能であり、それには『タペストリー』用に特別な適合がなされていない既製のオペレーティング・システムも含まれる。『タペストリー』およびＴＡＸｉは、プロセス、スレッド、可能アドレス空間、アドレス・マッピングといったオペレーティング・システムのエンティティに関する仮定を一切行わない。すなわち、『タペストリー』およびＴＡＸｉは、Ｘ８６の仮想アドレスもしくは線形アドレスではなく、仮想Ｘ８６の物理メモリに関して動作する。（Ｉｎｔｅｌ（インテル）の「仮想」アドレスと「線形」アドレスの間における相違は、この開示に関してはほとんど現れない；したがって、これらの間における明確な区別が必要となる場合を除き、この開示においては、「仮想アドレス」にこれら両方のコンセプトを包含させている。）たとえば、物理アドレスを使用することにより、オペレーティング・システム・レベルにおいて異なるプロセスの間で共有されるライブラリ・コードは、『タペストリー』インプリメンテーション上において物理メモリが共有されることから、自動的にＴＡＸｉプロセスによって共有される。オペレーティング・システムによって共有されるコードは、異なるプロセスにおいて異なるアドレスにマップされる場合であっても共有される。プロセスが実際に同一の物理ページを共有しているときには、ＴＡＸｉが同一の翻訳済みコードを共有することになる。
【０１３４】
翻訳済みコードのバッファは、先入れ先出し（ＦＩＦＯ）順にリサイクルされる。翻訳済みコードのバッファに再利用のためのマーキングが行なわれても、直ちにそれが破棄されることはない；むしろ、再使用のための準備済みという形でマークされる。コンテンツが破壊される前に再使用のための準備済みバッファ内への実行の再入があると、そのバッファがＦＩＦＯキューの先頭にリサイクルされる。別の実施態様においては、バッファ内に実行が入ると、常にそれがＦＩＦＯキューの先頭に移動される；これは、ＬＲＵ（リースト−リーセントリー−ユーズド；もっとも参照されていないページを入れ替える方式）入れ替えポリシーを近似する。
【０１３５】
ＴＡＸｉシステムの多くの特徴は、プロファイリングに結びつけられている。たとえば、プロファイリングされていないコードの領域がホット・スポットとして識別されることはなく、したがって翻訳されることもない。翻訳抜きではプロービングが成功することがないため、同様にプロファイリングが行なわれていない領域についてはプロービング（後述のセクションＶＩを参照されたい）がディセーブルされる。この不変性は、多数の設計の詳細を簡略化し、それについては以下において適宜論じる。
【０１３６】
Ｅ．システム全体の制御
ＰＳＷ  １９０は、ユーザ‐モードのアクセスが許可されていない機能への、ユーザ−モードによるアクセスを可能にするＴＡＸｉ＿Ａｃｔｉｖｅ（ＴＡＸｉアクティブ）ビット１９８を有している。ＰＳＷ．ＴＡＸｉ＿Ａｃｔｉｖｅ（ＴＡＸｉアクティブ）１９８は、Ｘ８６プログラムのネイティブ『タペストリー』翻訳が実行されている間、真にセットされる。ＰＳＷ．ＴＡＸｉ＿Ａｃｔｉｖｅ（ＴＡＸｉアクティブ）１９８が真のとき、ユーザ‐モードのプログラムは、Ｘ８６のＬＤＡ／ＳＴＡロック機能にアクセスが許され、すべての『タペストリー』プロセッサ・レジスタに対する読み出しならびに書き込みアクセスを有し、かつ拡張ＴＲＡＰインストラクション・ベクトルにアクセスすることができる（より具体的に述べれば、エミュレータ機能の呼び出しが可能になる）。さらに、拡張精度浮動小数点演算用のＸ８６互換セマンティクスがイネーブルされる。
【０１３７】
プローブが成功すると、ＴＡＸｉ翻訳済みコードにＲＦＥによるリターンを行う前に、それによってＰＳＷ．ＴＡＸｉ＿Ａｃｔｉｖｅ（ＴＡＸｉアクティブ）１９８がセットされる。ＴＡＸｉ翻訳済みコードの実行が完了すると、翻訳未済のＸ８６コードに戻ったプロセスが、コンバータ１３６にＲＦＥによるリターンを行う前にＰＳＷ．ＴＡＸｉ＿Ａｃｔｉｖｅ（ＴＡＸｉアクティブ）１９８をクリアする。ＴＡＸｉ翻訳済みコードにおいて例外が発生した場合には、エミュレータ３１６が呼び出されて、その例外をＸ８６仮想マシンに戻す。エミュレータ３１６は、ＥＰＣ．ＴＡＸｉ＿Ａｃｔｉｖｅ（ＴＡＸｉアクティブ）１９８をチェックしＴＡＸｉにコントロールを戻してＸ８６マシンのコンテキストを復元し、ＲＦＥによりコンバータ１３６に戻ってＸ８６インストラクションを再実行する。
【０１３８】
Ｆ．ＸＰビットおよび保護されていない例外
再度、図１ａ、１ｂおよび２ａを参照すると、ＴＡＸｉトランスレータ１２４は、Ｘ８６バイナリの翻訳を生成している。ＴＡＸｉシステムは、全体として非常に複雑なキャッシュを表し、それにおいてはＸ８６コードがより低速なメモリ・レベルを表し、翻訳済みＴＡＸｉコードがより高速なメモリ・レベルを表す。プロファイリングにおいては、いずれのアドレスにおいていずれのイベントが生じるか、あるいはどこにインストラクションの境界が存在するかといったことについての知識の記録を行うために、ＴＡＸｉが、プロファイリング時に情報のキャッシングを開始する。さらに、バイナリ・トランスレータ１２４がＸ８６コードを、意味論的に等かな『タペストリー』のネイティブ・コードに翻訳するときにもキャッシングが行なわれる。Ｘ８６のアーキテクチャ・モデルを侵害しないために、ＴＡＸｉは、失効したＸ８６コード、すなわち消失したか修正されたＸ８６コードに対応する翻訳済み『タペストリー』ネイティブ・コードの実行を防止している。基礎をなすプライマリ・データ（Ｘ８６インストラクション・テキスト）が修正された場合には、ＣＰＵからのメモリ書き込みによるか、あるいはデバイスからのＤＭＡ書き込みによるかによらず、キャッシュ済みデータ（Ｘ８６コードおよびそれから生成されたＴＡＸｉコードを記述したプロファイル）が無効化され、その結果、それが実行されることはなくなる。実行は、修正された形式のＸ８６テキストに戻される。修正されたＸ８６テキストがホット・スポットになると、それが認識（１２２）され、再翻訳（１２４）が行なわれる。
【０１３９】
通常のキャッシュと同様に、ＴＡＸｉキャッシュは有効ビット−ＸＰビットを有している（ＰＩＰＭエントリ６４０においては１８４、Ｉ−ＴＬＢにおいては１８６；図１ａ、１ｂを参照されたい）。Ｘ８６コード、および「キャッシュされた」翻訳済みネイティブ『タペストリー』コードの有効性は、ＸＰ書き込みプロテクト・ビット１８４、１８６、およびページの保護をマネージする例外ハンドラによって、ＣＰＵによる修正から保護されている。それとともに、フラグおよび例外が、コヒーレントな翻訳済み『タペストリー』バイナリを、Ｘ８６プログラムの「キャッシュされた」コピーとして維持し、その一方でＸ８６プログラム（オリジナルのＸ８６形式においてエンコーディングされているか、あるいは翻訳済みのネイティブ『タペストリー』形式においてエンコーディングされているかによらず）によるメモリに対する書き込みを、その書き込みが自己修正コードをインプリメントする場合であっても可能にする。いずれのモードにおいても、マシン（Ｘ８６コンバータ１３６またはＴＡＸｉシステムのいずれか）がそのプログラムのセマンティクスを忠実に実行することになる。保護ありおよび保護なしの例外が、従来の書き込み保護例外と同様な形でプロセスを終了することはなく、単にそれは、ＴＡＸｉコードの有効性をマネージするために仲裁しなければならないことをＴＡＸｉシステムに通知するだけである。
【０１４０】
Ｘ８６コードのページが保護されているとき、つまりＸＰプロテクト・ビット１８４、１８６が「１」であるとき、Ｘ８６コードに関連付けされたＴＡＸｉコードを無効にするイベントのクラスが２つ存在する。第１は、『タペストリー』プロセッサがＸ８６ページの１つにストアできることである。これは、プログラムが自己修正コードを使用しているとき、あるいはプログラムがオン‐ザ‐フライで書き込み可能なストレージ（スタックまたはヒープ）内にコードを生成しているときに起こり得る。第２は、ＤＭＡデバイスがページに書き込みできることであり、たとえばプログラムのロードもしくはアクティブ化に続いてプログラム・テキストのページがページングされ、ページ違反を生じる。いずれの場合においても、『タペストリー』が割り込みを発生し、その割り込み用のハンドラがＸＰ「有効」ビットをリセットして、そのＸ８６ページに対応するあらゆるＴＡＸｉコードがプローブから到達し得ないことを示す（セクションＶＩ．Ｄを参照すると、プロービングは、ＸＰビット１８４、１８６が「１」にセットされているＸ８６ページ上においてのみイネーブルされる）。
【０１４１】
書き込みプロテクト・ビットを「ＸＰ」と呼んでいるが、本来は「ｅｘｔｅｎｄｅｄ  ｐｒｏｐｅｒｔｙ（拡張プロパティ）」の略語である。つまり、ページ用のＩＳＡビット（ＰＦＡＴ  １７２においては１８０、Ｉ−ＴＬＢにおいては１８２）がＸ８６  ＩＳＡを示しているとき、ＸＰビット（ＰＩＰＭエントリ６４０においては１８４、Ｉ−ＴＬＢにおいては１８６）が解釈されて、そのページに関する修正プロテクト・プロパティがエンコードされる。ＸＰビット１８４、１８６は、ページごとの細分性で保護メカニズムをコントロールする。マシン全体に関する保護システムは、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｕｎｐｒ（ＴＡＸｉ＿コントロール．ｕｎｐｒ）ビット（ＴＡＸｉ＿Ｃｏｎｔｒｏｌ（ＴＡＸｉコントロール）レジスタのビット＜６０＞、すなわち図４ｇの４６８；後述のセクションＶ．Ｅを参照されたい）によってイネーブルおよびディセーブルがコントロールされる。
【０１４２】
物理的なページは、マネジメントに関して『タペストリー』オペレーティング・システム（図３ａの３１２）とＸ８６オペレーティング・システムの間において分割され、それに応じてそのページ用のＰＦＡＴ．ＩＳＡビット１８０（Ｉ−ＴＬＢ．ＩＳＡビット１８２内にキャッシュされる）が、『タペストリー』については「０」、Ｘ８６については「１」にそれぞれセットされる。すべてのＸ８６ページについて、ＸＰビット（ＰＦＡＴ  １７２においては１８４、Ｉ−ＴＬＢ  １１６においては１８６）が「保護なし」を示す「０」にクリアされる。ＸＰビット１８４、１８６は、『タペストリー』ページ上には効果を及ぼさない。
【０１４３】
ＸＰビット１８４、１８６の振る舞いは、ＭＥＳＩ（Ｍｏｄｉｆｉｅｄ，Ｅｘｃｌｕｓｉｖｅ，Ｓｈａｒｅｄ，Ｉｎｖａｌｉｄ、つまり修正、排他、共有、無効）キャッシュ・プロトコルにある意味で類似している。ＸＰの「保護なし」状態は、概略でＭＥＳＩの「排他」状態に等価であり、このページからキャッシュされる情報はなく、ページは保護されないまま残されるという意味を有する。ＸＰ「保護あり」状態は、概略でＭＥＳＩの「共有」状態に等価であり、このページから情報がキャッシュされることは可能だが、このページをパージした後でなければ書き込みはできないという意味を有する。４つのポイントの類比を次の表２に示す。
【０１４４】
【表２】
0005427742.tif 000005
【０１４５】
アクション１：データのキャッシュ済みコピーをすべて破棄し、キャッシュなし／排他状態に遷移する。
アクション２：共有／複製コピーをフェッチし、キャッシュあり／共有状態に遷移する。
【０１４６】
ＭＥＳＩの「共有された」キャッシュ・ラインに対する書き込みは、他のすべてのプロセッサに対してキャッシュ・ラインをパージし、それらのラインを「排他」にセットすることを強制する。同様に、ＸＰ保護（１８４、１８６）されたページに対する書き込みは、そのページを保護なしにセットさせる。表２においては、これら２つの類似したアクションが「アクション１」として示されている。ＩＳＡビット１８０、１８２が「１」であり、ＸＰビット１８４、１８６が「１」であれば、これは保護されたＸ８６インストラクション・ページである。ＸＰビット１８４、１８６が「１」にセット（保護）されているＸ８６  ＩＳＡページに対するストアは、カレント・コードがＸ８６ネイティブ・コードであるか、あるいはＴＡＸｉコードであるかによらず、中止され、コントロールが保護あり例外ハンドラに渡される。ハンドラは、そのページのＸＰビット１８４、１８６を「０」にセットすることによって、そのページを保護なしとしてマークする。そのページに関連付けされているすべてのＴＡＸｉコードは破棄され、この破棄を反映するべく、ＴＡＸｉコードを追跡するＰＩＰＭデータベース６０２がクリアされる。その後、ストアがリトライされる−−そのページのＸＰビット１８４、１８６が「０」にクリアされていること（保護なし）から、今回のストアは成功することになる。ＴＡＸｉコードが、Ｘ８６ページに書き込む場合であって、このＴＡＸｉコードがその翻訳である場合には、全体的なメカニズムは機能する−−例外ハンドラは、実行中のＴＡＸｉコードを無効にし、コンバータに戻り、そのストアを実行したＴＡＸｉコードに代えてオリジナルのＸ８６テキストに戻す。
【０１４７】
「排他」キャッシュ・ラインに対する書き込み、もしくはＸＰ保護なし（１８４、１８６）ページに対する書き込みは、状態変化を招かない。ＸＰビット１８４、１８６が「０」（保護なし）であれば、ストアを完了することができる。表２においては、これら２つの状態が「３」として示されている。
【０１４８】
ＭＥＳＩの「共有」キャッシュ・ラインからの読み出しは、そのキャッシュ内のデータがカレントであることから追加の遅延を伴うことなく進められる。同様に、コンバータ１３６によるＸＰ保護（１８４、１８６）されたページからのインストラクションの実行は、翻訳済みＴＡＸｉコードがそのページ上のインストラクションから生成されたものであれば、そのＴＡＸｉコードがカレントであることから遅延を伴うことなく進められ、プロファイリングおよびプロービングのメカニズム（４００、６００；後述するセクションＶおよびＶＩを参照されたい）は適正に振る舞う。表２においては、これらの類似した応答が「４」として示されている。
【０１４９】
別のプロセッサにおいて「排他」状態に維持されているキャッシュ・ラインからの読み出しは、当該別のプロセッサからメモリにそのラインをストアすることを強制し、その後そのラインは、読み出しているプロセッサのキャッシュ内において「共有」状態として読み出される。同様に、コンバータ１３６がＸＰ保護（１８４、１８６）のないページ（ＩＳＡが「１」すなわちＸ８６コードを表し、ＸＰビット１８４、１８６が「０」すなわち保護なしを示す）からのコードを実行し、特定の追加の条件とともに、プロファイルをトレース‐パケット・エントリに書き込もうとしているとき、マシンは「保護なし」例外を取り、対応するハンドラに向きを変える。ハンドラは、そのページを保護し、そのページを他のプロセッサと同期させる。表２においては、これらの類似のアクションが「アクション２」として示されている。保護なし例外は、保護されていないＸ８６ページ（後述のセクションＩＩにあるように、そのページのＩ−ＴＬＢ．ＩＳＡビット１８２が「１」であり、かつＩ−ＴＬＢ．ＸＰビット１８６が「０」になっている）からインストラクションがフェッチされ、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｕｎｐｒ（ＴＡＸｉ＿コントロール．ｕｎｐｒ）４６８が「１」であり、かつ次に示すいずれかの場合に生じる。
【０１５０】
（１）プロファイル取り込みインストラクションが発行されて新しいプロファイル・パケットが開始された場合（ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（図４ｈの４８２；ＴＡＸｉ＿状態．プロファイル＿アクティブ）が「０」、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿リクエスト）４８４が「１」、かつＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）４８６、４８７が、図４ｂの「開始パケット」４１８が真であるイベント・コードを含むとき）または、
【０１５１】
（２）コンバータ・レシピ内の最初のインストラクションが発行され、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２が「１」の場合。
この式のＴＡＸｉ＿Ｓｔａｔｅ（ＴＡＸｉ＿状態）項については、セクションＶ．ＥならびにＶ．Ｆおよび図４ｇ、４ｈ、５ａならびに５ｂにおいて説明する。
【０１５２】
保護なし例外ハンドラは、ＥＰＣ．ＥＩＰ（ＥＰＣは例外によってスタックにプッシュされたネイティブ例外ワード（インストラクション・ポインタおよびＰＳＷ）であり、ＥＰＣ．ＥＩＰは、インストラクション・ポインタの値である）から、もしくはＴＬＢ違反アドレス・プロセッサ・レジスタからフェッチされたインストラクションの物理ページ・アドレスを調べる。割り込みサービス・ルーチンは、そのページ用のＰＦＡＴ．ＸＰビット１８４およびＩ−ＴＬＢ．ＸＰビット１８６を「１」にセットし、そのページが保護されていることを示す。この情報は、共有メモリ・マルチプロセッサのキャッシュ・システムにおける「ＴＬＢシュート‐ダウン」に類似した態様に従って他の『タペストリー』プロセッサおよびＤＭＵ（ＤＭＡモニタリング・ユニット）７００に伝播される。例外ハンドラは、カレント・プロファイル・パケット（後述するセクションＶ．Ｆを参照されたい）を中止するか、あるいはプロファイル・パケットを継続できるコンテキストにマシンを置く。その後例外ハンドラは、コンバータ１３６に戻って実行を再開する。
【０１５３】
ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｕｎｐｒ（図４ｇの４６８；ＴＡＸｉ＿コントロール．ｕｎｐｒ）がクリアされると、ＸＰビット１８４、１８６の値が無視される：例外は生成されず、ＴＡＸｉソフトウエアは、プロファイル・パケットの確認および「保護された」ページ属性のセットを引き受ける。
【０１５４】
別の実施態様においては、保護なし例外ハンドラがカレント・プロファイル・パケットを中止し、そのページのアイデンティティを調べる。その後、仮想メモリ・システムにおけるページ・ピュアリファイアに類似のレイジー・エージェントがＰＦＡＴ．ＸＰビット１８４、Ｉ−ＴＬＢ．ＸＰビット１８６、およびＤＭＵ（ＤＭＡモニタリング・ユニット）を操作してそのページを保護する。次にそのページに実行が入るとき、そのページは保護されており、プロファイリングは通常のコースを進むことになる。
【０１５５】
保護されたページに対する書き込みを試みると（たとえば自己修正コードによる、あるいはテキストとデータが混合されたページに対する書き込み）それがトラップされ、そのページが再度保護なしにセットされる。
【０１５６】
ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｕｎｐｒ（ＴＡＸｉ＿コントロール．ｕｎｐｒ）４６８が「１」の間、保護されていないページに関するプロファイルを試みることが、保護なし例外を生じさせ、かつ保護なし例外ハンドラによってそのページが保護されるか、あるいはそのプロファイル・パケットが中止されることから、最終的にはプロファイリングがディセーブルされる。保護されていないページに関するプロファイリングをオフにすることは、保護されていないページがホット・スポットとして認識されないこと、したがって翻訳されないことを保証する。それに対して、ページが保護できないとき（たとえばそのページがアドレス空間ゼロの良好な振る舞いを有するメモリではなく、Ｉ／Ｏバスにマップされている場合）、現在収集されているすべてのプロファイル・パケットが中止される。この規則のインプリメンテーションおよびいくつかの限定的な例外については、後述のセクションＶ．Ｈにおいて説明する。
【０１５７】
ＸＰ保護メカニズムについては、後述のセクションＶＩＩＩにおいてさらに詳しく説明する。ＤＭＡデバイスによる書き込みに対してページを保護するための第２の保護メカニズムについては、後述のセクションＶＩＩにおいて説明する。
【０１５８】
ＩＩ．プログラム・テキストのための命令セットアーキテクチャ（ＩＳＡ）の指標
図１ａ、１ｂ、１ｃおよび１ｄを参照すると、プログラムは、領域１７６に分割され、それぞれの領域が対応するフラグ１８０を有している。フラグ１８０は、ＩＳＡのアサート（１７８）を行い、その下に、インストラクション・デコード・ユニット１３４、１３６、１４０が、パイプライン１２０に対して直接、ＩＳＡ選択１７８によってインストラクションｆ  １３８をデコードすることになる。ＩＳＡビット１８０、１８２が「１」となっているページ１７６からインストラクションがフェッチされると、そのインストラクションが、ＩＳＡ選択１７８のコントロールの下にパイプラインの変換ステージ１３４、１３６に渡され、それにおいてインストラクションがＩｎｔｅｌ（インテル）Ｘ８６インストラクションとして解釈される。領域は、仮想メモリもしくは物理メモリのいずれにおいても隣接している必要はない−−Ｘ８６テキストの領域は、ページごとを基準に、ネイティブ『タペストリー』テキストの領域と混在することができる。
【０１５９】
１つのＩＳＡに関して記述されたプログラムは、いずれのＩＳＡでコーディングされたライブラリ・ルーチンも呼び出すことができる。たとえば、特定のプログラムが、データベース・マネジメント・システムおよびマルチメディア機能をともに使用することができる。マルチメディア・サービスは、最適化済み『タペストリー』ネイティブ・コードのライブラリによって提供することができる。データベース・マネージャは、Ｘ８６用の既製のデータベース・システムとなることもある。呼び出しているプログラムは、Ｘ８６もしくは『タペストリー』のいずれに対してコンパイルされているかによらず、容易に両方のライブラリを呼び出すことが可能であり、またその組み合わせもシームレスな協働を提供する。
【０１６０】
一実施態様においては、ＩＳＡビットのインスタンスが２つの場所に作られる；すなわち、マスタ・コピー１８０および高速アクセスのためのキャッシュ・コピー１８２である。マスタ・コピー１８０は、ＰＦＡＴ  １７２内の各エントリ１７４に含まれるシングル・ビットである。メモリ１１８の各物理ページに対応してそれぞれ１つのＰＦＡＴエントリ１７４が存在し、所定のＰＦＡＴエントリ１７４内のＩＳＡビット１８０の値は、『タペストリー』プロセッサ１００が、対応するページからフェッチしたインストラクションをネイティブ・インストラクション・セットのアーキテクチャの下に解釈するか、あるいはＸ８６インストラクションとして解釈するかをコントロールする。Ｉ−ＴＬＢミスに応答して、Ｉｎｔｅｌ（インテル）フォーマットのページ・テーブルからＩ−ＴＬＢ内に、キャッシュ済みコピー１８２としてＰＴＥがロードされる。このページ・テーブルからの物理ページ・フレーム番号は、ＰＦＡＴ  １７２にインデクスを行うために使用され、対応するＰＦＡＴエントリ１７４を見つけ出し、ＰＦＡＴエントリ１７４からの情報を使用してＩｎｔｅｌ（インテル）フォーマットのＩ−ＴＬＢエントリを補う。このように、インストラクションのフェッチ１１０の間の、ビットのクエリが行なわれる時点までには、ＩＳＡビット１８０ビットが、この種のクエリに関する本来のロケーション、すなわちＩ−ＴＬＢ  １１６に収められる。同様に、プロセッサが、一体化されたインストラクションおよびデータＴＬＢを使用する場合には、ページ・テーブルおよびＰＦＡＴ情報が、一体化ＴＬＢ内の適切なエントリにロードされる。
【０１６１】
別の実施態様においては、順方向マッピングであるか逆方向マッピングであるかによらず、ＩＳＡビット１８０がアドレス変換テーブル内に配置される。この実施態様は、すでに存在する固定仮想メモリ・アーキテクチャのインプリメンテーションに対する拘束が緩い実施態様においてより望ましく、それにおいては、コンピュータの設計者が、複数アーキテクチャのインプリメンテーションに関するより多くのコントロールを有することができる。さらに別の実施態様においては、ＩＳＡビット１８０、１８２を、Ｉ‐キャッシュ１１２内のデータとしてコピーすることができる。
【０１６２】
実行のフローが１つのＩＳＡ  １８０、１８２のページから別のページに移るとき（たとえば、コントロール・フローのソースが１つのＩＳＡ内にあり、そのディスティネーションが他に含まれるとき）、『タペストリー』は変化を検出し、「遷移例外」と呼ばれる例外を取るする。この例外は、プロセッサを２つの例外ハンドラのうちの一方、すなわち『タペストリー』−Ｘ８６ハンドラ（図３ｉの３４０）またはＸ８６−『タペストリー』ハンドラ（図３ｈの３２０）に向け、それにおいて特定の状態ハウスキーピングが実行される。特に、例外ハンドラはＥＰＣ（割り込みが行なわれたＸ８６プロセスの状態をスナップショットするＰＳＷのコピー）内のＩＳＡビット１９４を変更し、それにより、遷移例外ハンドラ３２０、３４０のエンドにおいてＲＦＥ（例外からのリターンを示すインストラクション）は、変更されたＥＰＣ．ＩＳＡビット１９４をＰＳＷ内にロードする。ＰＳＷ．ＩＳＡビット１９４の内容は、プロセッサ１００の実際の実行をコントロールする状態変数であり、変更されたＩＳＡ選択１７８は、実行を再開したときに有効になる。ＰＦＡＴ．ＩＳＡコピー１８０およびＩ−ＴＬＢ．ＩＳＡコピー１８２は、例外に関するトリガを行うだけである。この例外メカニズムによって、古いＩＳＡ内のインストラクションをパイプラインから排出し、新しいＩＳＡモードの実行に対する変更を有効にするために必要となるコントロール回路の量を抑えることが可能になる。
【０１６３】
『タペストリー』アーキテクチャおよびＸ８６アーキテクチャが共通のデータ表現（ともにリトル・エンディアン、３２ビット・アドレス、ＩＥＥＥ−７５４浮動小数点、構造メンバ・アライメント規則等）を共有することから、プロセスは、マシンのデータ・ストレージ状態に対する変更を必要とすることなく新しいＩＳＡにおいて実行を再開することができる。
【０１６４】
別の実施態様においては、マシンの実行がＩＳＡビット１９４のＩ−ＴＬＢ．ＩＳＡコピーによってコントロールされ、ＰＳＷ．ＩＳＡコピー１９０がコントロール・ビットではなく、ヒストリ・ビットになる。ＩＳＡビット１８０、１８２が以前のページのＩＳＡビット１８０、１８２と一致しないページに実行のフローが向けられるとき、インプリメンテーションを行う側の選択肢として、マシンに遷移例外を取らせるか、あるいは遷移例外を取らせずに「ギア・チェンジ」を行わせることができる。
【０１６５】
プロセッサ・コントロール・レジスタの１つに、「ページ・プロパティ・イネーブル」ビットが含まれている。システムがパワー・オンになったときのこのビットは「０」であり、ページ・プロパティはディセーブルである。この状態においては、ＰＳＷ．ＩＳＡビットがソフトウエアによって操作されてコンバータ１３６をオン・オフし、遷移例外およびプローブ例外はディセーブルになる。システムの初期化が完了すると、このビットが「１」にセットされ、ＩＳＡビットのＰＦＡＴならびにＴＬＢコピーが、前述のようにシステムの振る舞いをコントロールする。
【０１６６】
ＩＩＩ．Ｘ８６スレッドに関連づけられた『タペストリー』プロセッサコンテキストの保存
Ａ．概要
図３ａ〜３ｆを参照すると、２つのインストラクション・セットのいずれかにおいてプログラムを実行する機能によって、単一のプログラムを両方のインストラクション・セットにおいてコーディングできるという可能性がもたらされることがわかる。図３ｂに示したように、『タペストリー』システムは、発呼側から被呼側へのトランスペアレントな呼び出しを提供し、それにおいては互いに他方のＩＳＡを知る必要がなく、また発呼側または被呼側のいずれも、他方と協働するための特別なコーディングを必要としない。図３ｃに示されるように、Ｘ８６の発呼側３０４は、協働するためには被呼側がＸ８６インストラクション・セットによりコーディングされていること、あるいはそれがネイティブ『タペストリー』ＲＩＳＣインストラクション・セット３０８によりコーディングされていることという制約を伴うことなく被呼側のサブプログラムに対して呼び出しを行うことが可能である。被呼側がＸ８６インストラクション・セットによりコーディングされている場合には、この呼び出しが通常の呼び出しとして実行される。被呼側３０８がネイティブ『タペストリー』インストラクション・セットによりコーディングされている場合には、『タペストリー』プロセッサ１００が、被呼側３０８に入るときに遷移例外３８４を取り、『タペストリー』被呼側３０８からＸ８６発呼側３０４に戻るとき、別の遷移例外３８６を取る。これらの遷移例外３８４、３８６およびそれらのハンドラ（図３ｈの３２０および図３ｉの３４０）は、マシン状態をＸ８６発呼側によって設定されたコンテキストから、『タペストリー』被呼側３０８によって期待されているコンテキストに変換する。
【０１６７】
図３ｃ〜３ｆを参照すると、類似した遷移例外３８４、３８６およびハンドラ３２０、３４０が、Ｘ８６発呼側とその被呼側の間（図３ｃ）、ネイティブ『タペストリー』発呼側とその被呼側の間（図３ｄ）、Ｘ８６発呼側とその被呼側の間（図３ｅ）、およびネイティブ『タペストリー』発呼側とその被呼側の間（図３ｆ）に接続を提供し、かつ、各発呼側−被呼側ペアのＩＳＡ間における独立性を提供することがわかる。
【０１６８】
図３ａならびに図３ｌおよび表１を参照すると、Ｘ８６オペレーティング・システム３０６によってマネージされたＸ８６スレッド（たとえば３０２、３０４）は、ｒ３２〜ｒ５５の下位半分に表されているＸ８６レジスタ、Ｘ８６インストラクションの実行に影響を与えるＥＦＬＡＧＳビット、カレント・セグメント・レジスタ等を含めて、通常のＸ８６コンテキストを運ぶ。それに加えて、Ｘ８６スレッド３０２、３０４がネイティブ『タペストリー』ライブラリ３０８を呼び出すと、Ｘ８６スレッド３０２、３０４は、相当量の拡張コンテキスト、Ｘ８６アーキテクチャの内容を超える『タペストリー』プロセッサのコンテキストの部分を具体化する。スレッドの拡張コンテキストには、各種の『タペストリー』プロセッサ・レジスタ、汎用レジスタｒ１〜ｒ３１およびｒ５６〜ｒ６３、およびｒ３２〜ｒ５５の上位半分（表１参照）、ＩＳＡビット１９４のカレント値（および、後述するセクションＩＶの実施態様においては、ＸＰ／呼び出し規約ビット１９６ならびにセマンティック・コンテキスト・フィールド２０６のカレント値）を含ませることができる。
【０１６９】
『タペストリー』システムは、仮想Ｘ８６  ３１０全体をそのすべてのプロセスおよびスレッド、たとえば３０２、３０４とともに、単一の『タペストリー』プロセッサ３１１としてマネージする。『タペストリー』オペレーティング・システム３１２は、ＰＳＷ  １９０のＩＳＡビット１９４を含めて、『タペストリー』プロセッサ３１１、３１４の間のコンテキストの切り替え時におけるプロセッサ・コンテキストの保存および復元に、従来のテクニックを使用することができる。しかしながら、仮想Ｘ８６プロセス３１１内において既製のＸ８６オペレーティング・システム３０６（たとえば、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）（マイクロソフト・ウィンドウズ（登録商標））またはＩＢＭ  ＯＳ／２）によってマネージされるスレッド３０２、３０４に関しては、拡張コンテキストの保存および復元のために、かつ拡張コンテキスト情報とＸ８６オペレーティング・システム３０６によってマネージされるスレッド３０２、３０４の間の結合を維持するために、『タペストリー』システムは、仮想Ｘ８６  ３１０に入り、またそこから出るときある種の追加のハウスキーピングを実行する。（『タペストリー』エミュレーション・マネージャ３１６がＸ８６オペレーティング・システム３０６の下で動作しており、したがってＸ８６オペレーティング・システム３０６によってマネージされるエンティティ、たとえばプロセスおよびスレッド３０２、３０４がそれに気づかないということをここで想起されたい。）
【０１７０】
図３ａ〜３ｏは、現在『タペストリー』拡張リソースを使用しているＸ８６スレッド３０４（つまり、Ｘ８６オペレーティング・システム３０６のマネジメントの下にあり、したがって『タペストリー』オペレーティング・システム３１２に対して不可視のスレッド）の完全なコンテキストを保存し、復元するために使用されるメカニズムを示している。概略を述べれば、このメカニズムは、仮想Ｘ８６  ３１０に対してアーキテクチャ的に不可視となるメモリ・ロケーション３５５に、完全な拡張コンテキストをスナップショットする。ストアされたコンテキストのメモリ・ロケーション３５５とそのＸ８６スレッド３０４の間の対応は、『タペストリー』オペレーティング・システム３１２およびＸ８６エミュレータ３１６によって、Ｘ８６オペレーティング・システム３０６の協働を必要としない方法で維持され、その結果、Ｘ８６オペレーティング・システム３０６がＸ８６スレッドを再開したとき、割り込みの行なわれたＸ８６スレッド３０４の再開前にＸ８６オペレーティング・システム３０６がＸ８６スレッド３０２の間のコンテキスト切り替えを実行している場合であっても、拡張コンテキストが復元される。Ｘ８６エミュレータ３１６または『タペストリー』オペレーティング・システム３１２は、Ｘ８６オペレーティング・システム３０６への入出を含めて、Ｘ８６から『タペストリー』への遷移またその逆の遷移のそれぞれにおいて、一時的にコントロールを獲得して適時拡張コンテキストの保存およびその復元を行う。
【０１７１】
ハードウエア・コンバータ１３６とソフトウエア・エミュレータ３１６の間における相互作用については、後述するセクションＩＸにおいて概要を、セクションＩＸ．Ａ．２およびＩＸ．Ｂ．５において詳細をそれぞれ説明する。
【０１７２】
図３ｇ〜３ｋに示した実施態様の説明は、あらゆる任意の移動（条件付きジャンプ等）に関する遷移を許容する完全に一般的な場合ではなく、定義済みの状況における１つのＩＳＡから別のそれへのクロス（サブプログラム呼び出しならびにリターンおよび割り込み）に焦点が当てられている。任意のクロスＩＳＡ遷移において『タペストリー』ソースまたはディスティネーションが必ず存在することから、かつこの種の移動が生じ得るサイトの数が比較的限定されることから、各遷移サイトの『タペストリー』サイドに、ソース・コンテキストにおいて設定された状態からディスティネーション・コンテキストにおいて期待される状態にマシン状態を変換するために採用されるステップを示す情報をコメントすることができる。セクションＩＶで述べる代替実施態様においては、ハードウエアがこのソフトウエア・コメントを補い、完全に包括的なＩＳＡクロッシングを可能にする。
【０１７３】
ネイティブ『タペストリー』環境とＸ８６環境の間の相互作用は、Ｘ８６−『タペストリー』遷移例外ハンドラ（図３ｈの３２０）、『タペストリー』−Ｘ８６遷移例外ハンドラ（図３ｉの３４０）、『タペストリー』オペレーティング・システム３１２の割り込み／例外ハンドラ（図３ｊの３５０）、およびＸ８６エミュレータ３１６（ハードウエア・コンバータ１３６において都合よく実行できないＸ８６の振る舞いの一部をエミュレートするソフトウエア）の協働によってもたらされる。
【０１７４】
すべてのネイティブ『タペストリー』インストラクションが本質的に「０  ｍｏｄ  ４」の境界に整列していることから、『タペストリー』インストラクション・アドレスの２つの下位ビット＜１：０＞は常に「０」になることがわかっている。したがって、エミュレータ３１６と、『タペストリー』オペレーティング・システム３１２の例外ハンドラ３２０、３４０、３５０は、『タペストリー』インストラクション・アドレスのビット＜１：０＞を用いて互いに情報を渡すことができる。一例を考えるのであれば、ネイティブ『タペストリー』コードからの呼び出しのリターン・アドレス、またはネイティブ・コードの割り込みに対する再開用アドレスは、必然的に最下位２ビットに２つのゼロを有している。コントロールを獲得するコンポーネント（『タペストリー』−Ｘ８６遷移ハンドラ３４０もしくは『タペストリー』オペレーティング・システム３１２のいずれか）は、これら２つの下位ビットを次の表３に示すようにセットしてコンテキスト情報をストアする。
【０１７５】
【表３】
0005427742.tif 000006
【０１７６】
その後、コントロールが『タペストリー』発呼側もしくは割り込みが行なわれた『タペストリー』ネイティブ・コードに戻ると、Ｘ８６−『タペストリー』遷移例外ハンドラ３２０がこれらの２ビットを使用して、復元されることになる発呼側のコンテキストを決定し、これら２ビットをゼロに戻して、コントロールを適切なアドレスに返す。
【０１７７】
第２の情報ストアは、ＸＤレジスタ（表１のレジスタＲ１５）である。『タペストリー』呼び出し規約（後述するセクションＩＩＩ．Ｂを参照されたい）は、このレジスタを、状態情報を通信するため、およびＸ８６呼び出し規約の下におけるマシン状態から、『タペストリー』呼び出し規約の下における意味論的に等価のマシン・コンテキストに、あるいはその逆をマッピングするために予約している。『タペストリー』クロスＩＳＡ呼び出し規約は、発呼側が、Ｘ８６インストラクションによってコーディングされていることもある被呼側サブプログラムを呼び出そうとするとき、ＸＤレジスタに発呼側の引数リストを記述する値をセットする。同様に、『タペストリー』被呼側が、たとえばＸ８６発呼側にリターンするとき、呼び出し規約によって、被呼側がＸＤに、関数によって返された戻り値を記述する値をセットすることが求められる。この記述からソフトウエアは、Ｘ８６呼び出し規約の下に、被呼側による受け入れのために戻り値をどのように変換するべきかを決定することができる。いずれのケースにおいても、『タペストリー』コードによってセットされるＸＤ値はゼロにならない。最後に、Ｘ８６−『タペストリー』遷移ハンドラ３２０が、ＸＤをゼロにセットし、Ｘ８６呼び出し規約に従って引数リストが渡されたことを『タペストリー』ディスティネーションに示す。詳細については後述するが、各『タペストリー』サブプログラムは、プロローグを有し、それが到来するＸＤ値を解釈して、Ｘ８６呼び出し規約の引数リストを『タペストリー』呼び出し規約の引数リストに変換し（ＸＤ値がゼロである場合）、『タペストリー』−Ｘ８６例外ハンドラ３４０が、『タペストリー』関数から返されたＸＤ値を解釈して関数の戻り値をＸ８６形式に変換するようにプログラムされる。
【０１７８】
『タペストリー』呼び出し規約は、発呼側のスタックの深さを被呼側が保存することを求める。Ｘ８６呼び出し規約には、その種の要件の強制がない。Ｘ８６−『タペストリー』遷移ハンドラ３２０および『タペストリー』−Ｘ８６遷移ハンドラ３４０は、協働してこの制約をＸ８６被呼側に強制する。『タペストリー』−Ｘ８６遷移ハンドラ３４０がＸ８６被呼側に対する呼び出しを検出したとき、遷移ハンドラ３４０は、レジスタＥＳＩ（表１のＲ５４）内のスタックの深さを記録する（図３ｉの３４３）。ＥＳＩは、Ｘ８６呼び出し規約によって半保存され、ネイティブ規約によって全保存される。リターン時には、Ｘ８６−『タペストリー』遷移ハンドラ３２０がＥＳＩをＳＰにコピーし直し、それによってオリジナルのスタックの深さが復元される。これは、『タペストリー』−Ｘ８６遷移ハンドラ３４０によってスタック上に生成された（図３ｉの３４４）３２バイトの隠されたテンポラリを割り当て解除するという望ましい副次的な効果を有している。
【０１７９】
Ｂ．サブプログラムのＰｒｏｌｏｇｓ
「呼び出し規約」は、１つのコンポーネントから次にデータをどのように渡すかということについての単なるソフトウエア・コンポーネント間の取り決めである。すべてのデータが同一の規約に従ってＲＩＳＣアーキテクチャおよびエミュレートされたＣＩＳＣアーキテクチャの両方にストアされるとすれば、２つのＩＳＡ環境間における遷移は比較的容易になる。しかしながら現実はそうならない。たとえば、Ｘ８６呼び出し規約は、概略Ｘ８６アーキテクチャによって定義されている。サブルーチンの引数は、メモリ・スタック上で渡される。特別なＰＵＳＨ（プッシュ）インストラクションが、サブプログラム呼び出しの前に引数をスタック上にプッシュし、ＣＡＬＬ（コール）インストラクションがコントロールを移動し、スタック上にリターン・リンケージ・ロケーションを保存し、かつＲＥＴ（リターン）インストラクションがコントロールを発呼側に戻し、被呼側のデータをスタックからポップする。被呼側プログラムの内側においては、スタック・ポインタからの既知のオフセットにおいて引数が参照される。これに対し、『タペストリー』呼び出し規約は、多くのＲＩＳＣ呼び出し規約と同様に、ソフトウエア・プロデューサ（コンパイラおよびアッセンブリ言語のプログラマ）の間の合意によって定義される。たとえば、すべての『タペストリー』ソフトウエア・プロデューサは、レジスタ３２内において最初のサブプログラムの引数が、レジスタ３３内において２番目の引数が、レジスタ３４内において３番目の引数が渡されるという形で、以下同様に引数引き渡しが行なわれることを承知している。
【０１８０】
図３ｇを参照すると、Ｘ８６発呼側から呼び出される可能性のある『タペストリー』コンパイラによってコンパイルされた任意のサブプログラムに、ＧＥＮＥＲＡＬ（ジェネラル）エントリ・ポイント３１７および専用ＮＡＴＩＶＥ（ネイティブ）エントリ・ポイント３１８が与えられている。ＧＥＮＥＲＡＬ（ジェネラル）エントリ・ポイント３１７は、Ｘ８６発呼側または『タペストリー』発呼側のいずれによっても呼び出される完全な汎用性を備え、ＸＤレジスタ（表１のＲ１５）内の値を解釈（３１９）して、コントロールがサブプログラムの本体に達する前に、そのパラメータ・リストが『タペストリー』呼び出し規約に適合することを保証する。またＧＥＮＥＲＡＬ（ジェネラル）エントリ・ポイント３１７は、Ｘ８６発呼側にリターンする間に有用と考えられる情報をスタックのリターン遷移引数エリア（ＲＸＡ；図３ｈの３２６）にストアし、スタック・ポインタのカレント値、および大きな関数の戻り値がストアされている可能性のある隠されたメモリ・テンポラリのアドレスを示す。ＮＡＴＩＶＥ（ネイティブ）エントリ・ポイント３１８は、直接呼び出し（ポインタ、仮想関数等を通過しない）によってサブプログラムを呼び出す『タペストリー』発呼側による使用のみが可能であり、より効率的なリンケージを備える；ＮＡＴＩＶＥ（ネイティブ）エントリ・ポイント３１８によってもたらされる唯一の複雑性は、「サイズ可変引数」の引数リスト、または１６個のパラメータ・レジスタＰ０〜Ｐ１５（表１のＲ３２〜Ｒ４７）に収まらない引数リストである。ＧＥＮＥＲＡＬ（ジェネラル）エントリ・ポイント３１７の値は、サブプログラムのアドレスを獲得した任意のオペレーションによって返される。
【０１８１】
Ｃ．Ｘ８６−『タペストリー』遷移ハンドラ
図３ｈを参照すると、Ｘ８６−『タペストリー』遷移ハンドラ３２０に入る条件が３つあることが示されている：すなわち、（１）Ｘ８６  ＩＳＡ内のコードがネイティブ『タペストリー』コードを呼び出すとき、（２）Ｘ８６被呼側サブプログラムがネイティブ『タペストリー』発呼側にリターンするとき、および（３）Ｘ８６オペレーティング・システム３０６が、非同期外部割り込みによってネイティブ『タペストリー』コードの実行間に割り込みの行なわれたスレッド３０４を再開するとき、の３つである。
【０１８２】
Ｘ８６−『タペストリー』遷移ハンドラ３２０は、ＥＰＣ．ＥＩＰにおいて獲得されたディスティネーション・アドレスの下位２ビットを用いてコードに対するディスパッチ（３２１）を行って、これらの条件のそれぞれを処理する。ここで、これらの２ビットが、前述の表３に示した値にセットされることに留意されたい。
【０１８３】
これらの下位２ビットＥＰＣ＜０１：００＞が「００」、すなわちケース３２２であれば、この遷移が、Ｘ８６発呼側から『タペストリー』被呼側に対するＣＡＬＬ（呼び出し）であることが示される（通常は、その発呼側がＸ８６バイナリ・コードを用いてコーディングされていることが期待されるライブラリ・ルーチンに関する『タペストリー』ネイティブ置換）。遷移ハンドラ３２０は、メモリ・スタックからリンケージ・レジスタＬＲ（表１のレジスタＲ６）内にリターン・アドレスをポップ（３２３）する。ポップ（３２３）は、Ｘ８６発呼側の引数リストの最初の引数をポイントしているＳＰ（スタック・ポインタ；表１のレジスタＲ５２）をそのまま残す。ＳＰ値は、ＡＰレジスタ（引数ポインタ；表１のレジスタＲ５）にコピーされる（３２４）。ＳＰは、リターン遷移引数エリア（このリターン遷移引数エリアは、被呼側のＧＥＮＥＲＡＬ（ジェネラル）エントリ・ポイント（図３ｇの３１７）によって使用されることがある）のためのスペースを割り当てるために８デクリメント（３２６）され、その後ＳＰは、切り捨てられて（３２７）３２バイトにそろえられる。最後に、ＸＤがゼロにセット（３２８）されて、被呼側のＧＥＮＥＲＡＬ（ジェネラル）エントリ・ポイント３１７に対して、この呼び出しが、Ｘ８６呼び出し規約に従って構成されたマシンとともに生じることを通知する。
【０１８４】
下位２ビットのリターン・アドレスＥＰＣ＜０１：００＞が「１０」もしくは「１１」であった場合、すなわちケース３３２もしくはケース３２９であった場合には、Ｘ８６被呼側から『タペストリー』発呼側へのリターンであることが示される。これらの値は、期待される関数リターン結果の特性に従い、Ｘ８６被呼側が呼び出された時点において、あらかじめ『タペストリー』−Ｘ８６遷移ハンドラ３４０によってストアされる。
【０１８５】
下位ビットが「１１」であるとき、すなわちケース３２９は、Ｘ８６呼び出し規約によって指定されるように、Ｘ８６被呼側が大きな関数結果（たとえば１６バイトのｓｔｒｕｃｔ（ストラクト））がメモリ内に生成されることを示す。この場合、『タペストリー』呼び出し規約によって指定されているように、遷移ハンドラ３２０が関数結果をレジスタＲＶ０〜ＲＶ３（レジスタＲ４８〜Ｒ５１；表１参照）内にロードする（３３０）。下位ビットが「１０」であるとき、すなわちケース３３２は、関数結果がすでにレジスタ内（整数または浮動小数点）に収められていることを示す。
【０１８６】
レジスタの戻り値が「１０」、すなわちケース３３２においては、Ｘ８６−『タペストリー』遷移ハンドラ３２０が、２つのレジスタ−ベースの変換を行って、関数結果の値をＸ８６のホームからその『タペストリー』のホームに移動する。第１に遷移ハンドラ３２０は、整数結果（ＥＡＸの最下位３２ビット、ＥＤＸの最上位３２ビット）のＸ８６表現をネイティブ規約の表現、すなわちＲＶ０（表１のＲ４８）内の６４ビットに変換する。第２に遷移ハンドラ３２０は、浮動小数点スタックのトップにあるＸ８６の８０ビットの値を、ネイティブ規約によるＲＶＤＰ（倍精度浮動小数点結果が返されるレジスタ；表１のＲ３１）内の６４ビット表現に変換（３３４）する。
【０１８７】
６４ビットから８０ビットの浮動小数点の変換は、プロセス・コンテキストをそのソース・モードからそのディスティネーション・モードにおける意味論的に等価の形式に変換するために使用できるビット表現における変更（１つのロケーションから別のロケーションに同一のビット・パターンをコピーすることに対立するものとして）の一例である。たとえば、別の変換においては、ＡＳＣＩＩ（アスキー）表現からＥＢＣＤＩＣへ、もしくはその逆の文字列の変更、ＩＢＭの基数１６フォーマットの浮動小数点からＤｉｇｉｔａｌ（ディジタル）固有の浮動小数点フォーマットまたはＩＥＥＥフォーマットもしくは別の浮動小数点フォーマットへの変更、単精度から倍精度への変更、ビッグ−エンディアンからリトル‐エンディアンもしくはその逆の整数の変更等が関係することも考えられる。要求される変換のタイプは、インプリメントされているネイティブ・アーキテクチャと非ネイティブ・アーキテクチャの特性に応じて異なる。
【０１８８】
ネイティブ『タペストリー』サブプログラムの呼び出しの間に保留されていたＸ８６スレッドを再開するケース３７０、すなわち「０１」の場合は、遷移ハンドラ３２０が関連する保存済みコンテキストをロケートし、それが改ざんされていないことを確認し、それを再生する（割り込みの行なわれたネイティブ『タペストリー』サブプログラム内の真のネイティブ・アドレスを含む）。ケース３７０のオペレーションについては、後述のセクションＩＩ．ＦおよびＩＩＩ．Ｇにおいて詳しく説明する。
【０１８９】
ケース−バイ−ケースの処理３２２、３２９、３３２、３７０の後、ＥＰＣ内のリターン・アドレスの下位２ビット＜１：０＞（エラーＰＣ）は、「００」にリセット（３３６）されて、ネイティブの調整不良のＩ−フェッチ誤りが回避される。ケース３２９および３３２の最後には、オリジナルの呼び出し時におけるスタック深度に戻るため、レジスタＥＳＩ（表１のＲ５４）がＳＰにコピー（３３７）される。ＲＦＥインストラクション３３８は、割り込みの行なわれたプログラムを再開し、この場合は、ＩＳＡクロッシングのコントロール移動のターゲットにおいて再開する。
【０１９０】
Ｄ．『タペストリー』−Ｘ８６遷移ハンドラ
図３ｉを参照すると、『タペストリー』−Ｘ８６遷移ハンドラ３４０に入る条件が２つあることが示されている：すなわち（１）ネイティブ『タペストリー』発呼側がＸ８６被呼側を呼び出すとき、および（２）ネイティブ『タペストリー』被呼側がＸ８６発呼側にリターンするとき、の２つである。いずれのケースにおいても下位４ビットＸＤ＜３：０＞（移動記述子レジスタ；表１のＲ１５）が『タペストリー』コードによってセットされて、マシン・コンテキストを『タペストリー』呼び出し規約からＸ８６呼び出し規約に変換するために採用するステップが示される（３４１）。
【０１９１】
下位４ビットＸＤ＜０３：００＞が、『タペストリー』被呼側からＸ８６発呼側へのリターンを示している（３４１）とき、選択されるロジック３４２が、関数結果の値をその『タペストリー』ホームからＸ８６呼び出し規約によって指定されるロケーションにコピーする。たとえば、ＸＤは、ＲＶ０に返された６４ビットのスカラ整数の結果を、ＥＡＸ内もしくはＥＤＸ：ＥＡＸレジスタ・ペア内のスカラとして返すことを指定し、倍精度浮動小数点結果をＲＶ０から８０ビットの拡張精度値としてＸ８６浮動小数点スタックのトップにコピーすることを指定し、あるいはＲＶ０〜ＲＶ３（表１のＲ４８〜Ｒ５１）に返される大きな戻り値をオリジナルのＸ８６発呼側によって指定されたメモリ・ロケーションにコピーし、ＲＸＡに保存することを指定する。スタックの深さは、ＧＥＮＥＲＡＬ（ジェネラル）エントリ・ポイント３１７によってＲＸＡ内にあらかじめ保存されているスタック・カットバック値を使用して復元される。
【０１９２】
『タペストリー』発呼側はレジスタ内に結果があることを期待しているが、Ｘ８６呼び出し規約の下に、同一プロトタイプを伴うＸ８６関数がＲＶＡメカニズムを介して返す（戻り値を引数リスト内の隠された最初の引数によってポイントされるメモリ・ロケーションに返す）ことを理解している場合には、『タペストリー』発呼側がＸＤ＜３：０＞をセットして、以下に示すメカニズムをハンドラ３４０に要求する。リターン時においてスタックの深さが復元されることを保証するために、発呼側のスタック・ポインタがＥＳＩレジスタ（表１のＲ５４）にコピー（３４３）される。本質的に整列される３２バイトのテンポラリがスタック上に割り当てられ（３４４）、そのテンポラリのアドレスがＲＶＡ（表１のＲ３１）値として使用される。Ｘ８６−『タペストリー』遷移ハンドラ３２０に対して、Ｘ８６発呼側が『タペストリー』発呼側にリターンするとき、割り当て済みバッファからの３２バイトをＲＶ０〜ＲＶ３（表１のＲ４８〜Ｒ５１）にロードすることを要求するために、ビットＬＲ＜１：０＞が「１１」にセット（３４５）される。
【０１９３】
ＲＶＡメカニズムを使用しない呼び出しの場合（たとえば被呼側がスカラ整数または浮動小数点値を返すか、値をまったく返さない場合）は、『タペストリー』−Ｘ８６遷移ハンドラ３４０によって、次に示すアクションが取られる。リターン時におけるスタックの深さが復元されることを保証するため、発呼側のスタック・ポインタがＥＳＩレジスタ（表１のＲ５４）にコピー（３４３）される。ネイティブ発呼側へのリターン（３３２）時のＸ８６−『タペストリー』遷移ハンドラ３２０に対するフラグとしてビットＬＲ＜１：０＞が「１０」にセット（３４６）される。呼び出しに関しては、ハンドラ３４０がＸＤの残部を解釈（３４７）して、引数リストを『タペストリー』呼び出し規約のレジスタからＸ８６規約のメモリ・ロケーションにコピーする。リターン・アドレス（ＬＲ）は、スタックにプッシュされる。
【０１９４】
『タペストリー』被呼側からＸ８６発呼側へのリターンに関しては、Ｘ８６の浮動小数点スタックおよびコントロール・ワードが設定される。
【０１９５】
『タペストリー』−Ｘ８６遷移ハンドラ３４０は、最後に、このほかのＸ８６実行環境のアスペクトを設定し（３４８）、たとえばエミュレータ３１６およびプロファイラ４００に関するコンテキストをセットアップする。ＲＦＥインストラクション３４９は、Ｘ８６ルーチン内の移動先にコントロールを戻す。
【０１９６】
Ｅ．『タペストリー』オペレーティングシステムにおける割り込みまたは例外時のＩＳＡクロッシング処理
図３ｊを図３ａおよび３ｌとの関連から参照すると、ほとんどの割り込みおよび例外が『タペストリー』オペレーティング・システム３１２内の単一のハンドラ３５０を通過することが示されている。この時点において、多数のハウスキーピング関数が実行されて、『タペストリー』オペレーティング・システム３１２、Ｘ８６オペレーティング・システム３０６、これら２つのオペレーティング・システムによってマネージされるプロセスならびにスレッド３０２、３０４、３１１、３１４、およびこれらのプロセスならびにスレッドの、一方の呼び出し規約から他方のそれに渡すために変更が必要になることがあるデータ・コンフィグレーションが調整される。
【０１９７】
図３ｊには図示していないコードによって、多数の割り込みおよび例外が選別されて処理される。これには、別の『タペストリー』プロセス内において生じたすべての同期例外を含む、仮想Ｘ８６  ３１０の外側にあるものに向けられたすべての割り込み、『タペストリー』オペレーティング・システム３１２自体のハウスキーピング関数をドライブする割り込み（たとえばタイマ割り込み）、および『タペストリー』ネイティブ・プロセス３１４（『タペストリー』オペレーティング・システム３１２のマネジメントの下におけるプロセス）によってもたらされる例外が含まれる。図３ｊの外側において扱われるプロセス指向の割り込みには、非同期割り込み、必ずしも現在実行中のプロセスによって生じない割り込み（たとえばクロス‐プロセッサ同期割り込み）が含まれる。これらの割り込みは、『タペストリー』オペレーティング・システム３１２において従来の方法に従って処理される：つまり、スレッドの完全な『タペストリー』コンテキストが保存され、割り込みが処理され、さらに『タペストリー』オペレーティング・システム３１２が再開するスレッドを選択する。
【０１９８】
このように、図３ｊに示したコードに実行が到達するまでに、割り込みが仮想Ｘ８６  ３１０内のものに向けられることが保証され（たとえば、Ｘ８６スレッド３０２、３０４をブロックしないディスク完了割り込み、もしくはＸ８６スレッド３０２、３０４によってもたらされるページ違反、浮動小数点例外、またはＩＮＴソフトウエア割り込みインストラクション）、かつおそらくはＸ８６オペレーティング・システム３０６による扱いのために、この割り込みが『タペストリ』ハンドラから仮想Ｘ８６  ３１０に反映されなければならないことが保証される。
【０１９９】
Ｘ８６オペレーティング・システム３０６がコントロールを獲得した後、Ｘ８６オペレーティング・システム３０６がＸ８６プロセッサ３０２、３０４の間においてコンテキスト切り替えを行う可能性がある。このとき扱われるケースのクラスは２つ存在する。第１のクラスはケース３５１、３５３、および３５４を含み、詳しくは後述する。このケースのクラスにおいては、割り込みの行なわれたプロセスが、保存に関係するＸ８６状態のみを有している。したがって、コンテキストとスレッドの間における結合を維持するタスクは、Ｘ８６オペレーティング・システム３０６に渡すことができる：このオペレーティング・システムのコンテキスト切り替えメカニズムは、従来の方法に従って実行され、コンテキストとプロセスの間の結合を維持する。これに対して、プロセスが、保存およびカレント・マシン・コンテキストとの関連付けが行われなければならない拡張コンテキスト（たとえばＸ８６  ＯＳによってマネージされるプロセスに代わって呼び出される『タペストリー』ライブラリ内の拡張コンテキスト）を有している場合には、より複雑なマネジメント・メカニズムを採用しなければならず、それについてはケース３６０との関連から後述する。
【０２００】
割り込みの行なわれたスレッドが、ＥＰＣのＩＳＡビット１９４によって示されるように、コンバータ１３６内において実行されている場合には、ケース３５１によってその例外が扱われる。割り込みの行なわれたスレッドが仮想Ｘ８６内のＸ８６コードを完全に実行していることから、スレッドのコンテキストの保存、割り込みのサービス、およびスレッドの選択および再開のタスクは、完全にＸ８６オペレーティング・システム３０６に委ねることができる。したがって、『タペストリー』オペレーティング・システム３０６は、Ｘ８６エミュレータ３１６内の「割り込み引き渡し」ルーチン（図３ａの３５２）を呼び出し、その割り込みを仮想Ｘ８６  ３１０に反映させる。Ｘ８６オペレーティング・システム３０６は、この割り込みを受け取り、従来の方法に従ってそのサービスを行う。
【０２０１】
ＴＡＸｉコード（Ｘ８６プログラム内の「ホット・スポット」の翻訳済みネイティブ・バージョン；前述の説明を参照されたい）が実行されている間に（ＥＰＣのＴＡＸｉ＿Ａｃｔｉｖｅ（ＴＡＸｉアクティブ）ビット１９８によって示される）、仮想Ｘ８６  ３１０内のものに対して割り込みが向けられた場合、その割り込みはケース３５３によって扱われる。実行がＸ８６インストラクションの境界まで巻き戻される。Ｘ８６インストラクションの境界においては、Ｘ８６  ３１０の外のすべての『タペストリー』拡張コンテキストが無効になり、意味論的に等価の『タペストリー』状態とＸ８６マシン状態の間における比較的単純な対応を確立することができる。『タペストリー』実行は破棄される−−割り込みが引き渡された後は、コンバータ１３６内において実行を再開することができる。その後、割り込みが非同期外部割り込みであれば、ＴＡＸｉが、再構成されたＸ８６マシン状態を供給する仮想Ｘ８６に対して適切なＸ８６割り込みを引き渡し、従来の方法に従ってＸ８６オペレーティング・システム３０６によって割り込みが扱われることになる。それに該当しない場合には、同期イベントによって巻き戻しが誘導され、それによりＴＡＸｉがコンバータ１３６内において実行を再開し、例外が再トリガされ、Ｘ８６を示すＥＰＣ．ＩＳＡ１９４とともに、その例外がケース３５１によって扱われることになる。
【０２０２】
割り込みの行なわれたスレッドが、ＥＰＣのＥＭ８６ビットによって示されるように、Ｘ８６エミュレータ３１６内において実行されている場合には、その割り込みがケース３５４によって扱われる。これは、たとえば、複雑なインストラクション（たとえばゲートを介した「遠い」呼び出し）のエミュレーション中もしくは優先度の低い割り込みのサービス中のＸ８６エミュレータ３１６に、優先度の高いＸ８６割り込みが割り込みを行った場合に生じることがある。この割り込みは、エミュレータ３１６に引き渡され、それがこの割り込みを扱う。エミュレータ３１６は、再入コーディングを使用して記述されており、長い実行ルーチンの間における再入自己割り込みが可能になっている。
【０２０３】
ケース３６０は、割り込みもしくは例外が仮想Ｘ８６  ３１０内のものに向けられるケースをカバーし、それにおいてカレント・スレッド３０４は、Ｘ８６オペレーティング・システム３０６によってマネージされるＸ８６スレッドを介し、『タペストリー』コード３０８を現在実行中である。たとえば、Ｘ８６プログラムがネイティブ『タペストリー』ライブラリを呼び出していることが考えられる。このとき、この割り込みもしくは例外は、Ｘ８６オペレーティング・システム３０６によってサービスされることになるが、現在のスレッドは『タペストリー』拡張コンテキストに依存している。そのようなケースにおいては、Ｘ８６オペレーティング・システム３０６がＸ８６コンテキストのコンテキスト切り替えを実行し、最終的にこのスレッドが再開されるとき、完全な『タペストリー』コンテキストを復元しなければならない。しかしながらＸ８６オペレーティング・システム３０６は、『タペストリー』拡張コンテキストを保存するためのそれに関する知識がまったくなく（かつ当然のことながら、そのアドレス指定能力もなく）、ましてその復元のための知識については論外である。したがって、ケース３６０は、カレント『タペストリー』コンテキストとＸ８６スレッド３０４を関連付けするステップを採用しており、その結果、Ｘ８６オペレーティング・システム３０６がそのスレッドの実行を再開したとき、完全なコンテキストが（図３ｈのコード３７０によって）スレッド３０４に再結合される。
【０２０４】
ここで簡単に図３ｋを参照すると、システムの初期化の間に『タペストリー』システムが、ケース３６０を扱うために、『タペストリー』拡張コンテキストの保存用の「保存スロット」３５５として使用する特定量のページ不可能なストレージを予約していることがわかる。この保存スロットとして予約されたメモリは、仮想Ｘ８６  ３１０からアクセスすることができない。各保存スロット３５５は、完全な『タペストリー』コンテキストのスナップショットを保持するためのスペース３５６を有している。各保存スロット３５５には、識別用の番号３５７、保存スロットの内容がストアされた時刻を示すタイムスタンプ３５８が割り当てられる。満／空フラグ３５９は、保存スロットの内容が、現在有効であるか否かを示す。別の実施態様においては、タイムスタンプ３５８がゼロであることが、このスロットが使用されていないことを示す。
【０２０５】
図３ｊに戻るが、ケース３６０は、以下に示すように扱われる。現在空いている保存スロット３５５の中からスロットを割り当て（３６１）、そのスロットを使用中としてマーク（３５９）する。空いている保存スロットがまったくない場合には、タイムスタンプ３５８がもっとも古い保存スロットを、取り残されているものと見なし、強制的にリサイクルにまわす。前述したように保存スロット３５５が、ページ不可能なストレージから割り当てられることから、続いて行なわれるその保存スロットに対するストアにページ違反が招かれることはない。割り当てられた保存スロット３５５のコンテキスト・スペース３５６内に、Ｘ８６コンテキストならびに拡張コンテキストを含めた『タペストリー』コンテイスト全体、およびＥＩＰ（例外インストラクション・ポインタ；割り込みの行なわれるインストラクションのアドレス）が保存（３６２）される。ＥＩＰ（Ｘ８６  ＩＰに割り込みが行なわれたアドレス）の下位２ビットが、Ｘ８６−『タペストリー』遷移ハンドラ３２０に対してケース３７０を通知する値「０１」に上書きされる（３６３）。これ以外の場合には、ＥＩＰがそのまま残され、その結果、割り込みのあったポイントから実行が再開されることになる。（ここで、マシンがネイティブ『タペストリー』コードを実行中のときに限ってケース３６０に入ったことを想起されたい。つまり、ハンドラ３５０の開始時においては、ＥＩＰの下位２ビットが値「００」を伴って到来し、したがって、それらを上書きしても情報はまったく失われない。）６４ビットのカレント・タイムスタンプが、ＥＢＸ：ＥＣＸペア（レジスタＲ４９およびＲ５１の下位半分；表１を参照されたい）に、また冗長性を得るためにＥＳＩ：ＥＤＩ（レジスタＲ５４およびＲ５５の下位半分）に、さらに保存スロット３５５のタイムスタンプ・メンバ（図３ｋの３５８）にロード（３６４）される。割り当て済み保存スロット３５５の３２ビットの保存スロット番号３５７が、Ｘ８６  ＥＡＸレジスタ（レジスタＲ４８の下位半分）に、また冗長性を得るためにＥＤＸレジスタ（レジスタＲ５０の下位半分）にそれぞれロード（３６５）される。以上により『タペストリー』拡張コンテキストがすべて保存スロット３５５にストアされ、この時点において『タペストリー』オペレーティング・システム３１２の割り込みハンドラ３５０は、Ｘ８６エミュレータ３１６の「割り込み引き渡し」のエントリ・ポイント３５２にコントロールを移す。Ｘ８６オペレーティング・システム３０６が呼び出されてこの割り込みが処理される。
【０２０６】
割り込みの引き渡しは、仮想Ｘ８６  ３１０に関する割り込みの保留をもたらす。この割り込みは、Ｘ８６の割り込み受け入れ優先度が充分に高いとき、Ｘ８６エミュレータ３１６によって受け付けられる。Ｘ８６エミュレータ３１６は、割り込みもしくは例外に対するＸ８６ハードウエアの応答をエミュレートすることによって、Ｘ８６に対する割り込みもしくは例外の引き渡しを完了する：すなわち、スタック上に例外フレームをプッシュし（ビット＜１：０＞がステップ３６３において変更され、ＥＰＣにストアされた、割り込みの行なわれたＸ８６  ＩＰを含む）、コントロールを適切なＸ８６割り込みハンドラに向ける。
【０２０７】
この時点において実行が、通常はＸ８６オペレーティング・システム３０６のカーネル内の、例外によって向けられたＩＳＲにおいてＸ８６のＩＳＲ（割り込みサービス・ルーチン）に入る。Ｘ８６のＩＳＲは、既製の、まったく修正されていない従来ルーチンとすることができる。通常のＸ８６のＩＳＲは、Ｘ８６コンテキスト（例外フレーム内にまだ存在しない部分−−通常はプロセスのレジスタ、スレッドＩＤ等）をスタックに保存することから開始する。このＩＳＲは、通常、割り込み条件の診断、そのサービス、および割り込みの解除を行う。ＩＳＲは、Ｘ８６コンテキストに対する完全なアクセスを有する。Ｘ８６オペレーティング・システム３０６が、Ｘ８６プロセッサのコンテキストを調べ、あるいはそれに依存することはない：コンテキストは、「ブラック・ボックス」として扱われ、全体として保存および再開が行なわれる。割り込みサービスの一部として、割り込みの行なわれたスレッドが終了されるか、スリープされるか、あるいは再開予定として選択される。いずれのケースにおいても、ＩＳＲがあるスレッドを選択して再開し、そのスレッドのＸ８６コンテキストを復元する。ＩＳＲは、通常、Ｘ８６のＩＲＥＴインストラクションもしくはＸ８６のＪＵＭＰ（ジャンプ）のいずれかを介して選択されたスレッドにコントロールを戻す。いずれの場合においても、再開されるスレッドのアドレスは、再開予定のスレッドに割り込みが行なわれたときにＸ８６例外フレーム内にプッシュされたアドレスとなる。Ｘ８６オペレーティング・システム３０６によって再開されるスレッドは、割り込みの行なわれたスレッド３０４もしくは別のＸ８６スレッド３０２とすることができる。
【０２０８】
Ｆ．Ｘ８６オペレーティング・システムからの『タペストリー』実行の再開
再度図３ｈを参照すると、最終的にＸ８６オペレーティング・システム３０６が、ケース３６０の割り込みの後に、割り込みのポイントにおいて、割り込みの行なわれたスレッド３０４を再開する。Ｘ８６オペレーティング・システム３０６は、このスレッドがＸ８６インストラクションに従ってコーディングされていることを前提としている。最初のインストラクションのフェッチは、『タペストリー』ページからとなる（割り込みの行なわれるスレッド３０４が『タペストリー』ネイティブ・コードを実行しているときにのみ、例外がケース３６０に入ったことを想起されたい）。これによって、Ｘ８６−『タペストリー』遷移例外を生じ、それがＸ８６−『タペストリー』遷移ハンドラ３２０に方向を変える。ＰＣの下位２ビットが「０１」にセット（図３ｊのステップ３６３）されていることから、コントロールが「０１」のケース３７０をディスパッチする（３２１）。
【０２０９】
ステップ３７１においては、Ｘ８６  ＥＡＸならびにＥＤＸレジスタ内の保存スロット番号がクロス‐チェックされ（図３ｊのステップ３６５において保存スロット番号がこれらのレジスタ内にストアされたことを想起されたい）、ＥＢＸ：ＥＣＸにストア（３６２）されているタイムスタンプが、ＥＳＩ：ＥＤＩストアされているタイムスタンプとクロス‐チェックされる。これらのクロス‐チェックのいずれかに失敗し（３７１）、レジスタの内容が改ざんされていることが示されると、エラー回復ルーチンが起動される（３７２）。このエラー・ルーチンは、単に改ざんされたスレッドを切り捨てるもの、あるいはＴＡＸｉシステム全体をシステム・ダウンさせるものとすることができ、いずれにするかはインプリメントする側のオプションとなる。タイムスタンプが有効性の確認に適合した場合には、ＥＢＸ：ＥＣＸレジスタ・ペアからのタイムスタンプが、例外ハンドラの、完全なネイティブ・コンテキストを復元する間に上書きされない６４ビットの一時レジスタ内に死蔵（３７３）される。レジスタＥＡＸの内容は、『タペストリー』コンテキストがストア（３６２）されている保存スロット３５５をロケート（３７４）するための保存スロット番号として使用される。完全なネイティブ・コンテキストの復元は、すべてのＸ８６レジスタの値の復元を含めて、ロケートされた保存スロット３５５から行なわれる（３７５）。さらにこの復元（３７５）は、下位２ビットＥＰＣ＜１：０＞をゼロに復元する。保存スロットのタイムスタンプ３５８と、一時レジスタ内に死蔵（３７３）されているタイムスタンプがクロス−チェック（３７６）される。これら２つのタイムスタンプが一致せず、保存スロットが改ざんされていることが示されると、エラー回復ルーチンが起動される（３７７）。この時点において保存スロットが空になり、満／空フラグ３５９をクリアするか、あるいはそのタイムスタンプ３５８をゼロにセットすることによって空としてマーク（３７８）される。ＲＦＥインストラクション３３８により、ＥＰＣ．ＥＩＰ値において、『タペストリー』コードの割り込みの次のポイントから実行が再開される。
【０２１０】
再度図３ｋを参照すると、別の実施態様においては、保存スロット３５５がキューのバリエーションの中に維持されることがわかる：満たされる予定の希望的に空の保存スロットは、常にキューのヘッド３７９ａから割り当てられ、空にされる予定の完全な保存スロットは、キューの中央からリンクが解かれ、かつ保存スロットは、詳細を後述するようにヘッド３７９ａまたはテール３７９ｂからキューに入れることができる。キュー・エントリのダブル−リンク・リストは、リンク３７９ｃによって維持される。ステップ３６１においては、割り当てキューのヘッド３７９ａから保存スロットが割り当てられる。ステップ３６５の後、満たされた保存スロット３５５が、保存スロット・キューのテール３７９ｂにおいてキューに入れられる。ステップ３７７では、空にされた保存スロット３５５が、キューのヘッド３７９ａにおいてキューに入れられる。
【０２１１】
この別の実施態様における保存スロット３５５に関するヘッド−アンド−テール・キューイング・プロトコル３６１、３７９ａ、３７９ｂ、３７９ｃ３７５は、次のような効果を有している。キューのソートが２つのパーティション内に維持される。ヘッド３７９ａに向かう部分は、解放されていることが既知のすべての保存スロット３５５を蓄積する。テール３７９ｂに向かう部分は、ビジーであると考えられるすべてのスロットを、ＬＲＵ（リースト−リーセントリー−ユーズド；もっとも参照されていない）順序に従って保持する。時間の経過とともに、すべての取り残されたスロット（ビジーであると考えられるが、そのスレッドが消失しているスロット）が２つのパーティションの境界に蓄積されることになるが、これは、取り残されたスロットのタイムスタンプより古いタイムスタンプを伴うスロットが再開されると、空のスロットがビジー・スロット用のテール部分から取り除かれ、解放されたスロット用のヘッド部分に移動されることによる。通常、真にビジーのスロットをビジー・スロット用のパーティションのテールに集める一方、解放されたスロット用のパーティションのヘッドにおいて最後に解放されたスロットを集中的にリサイクルすることによって割り当てが行なわれる。解放されていることが既知のすべての保存スロット３５５を使い切り、ビジーの可能性が否定できない保存スロット３５５が上書きされるようになると、ＬＲＵ（リースト−リーセントリー−ユーズド；もっとも参照されていない）からもっとも新しいものに向かってビジーの保存スロット３５５が選択される。
【０２１２】
別の実施態様においては、ネイティブ『タペストリー』プロセスによるＸ８６ライブラリ３０８への呼び出しが許容される。Ｘ８６コード内において生じた例外は、『タペストリー』オペレーティング・システム３１２によって処理され、デシジョン・ポイントが図３ｊに示したコードの始まりに到達する前に、図３ｊのハンドラ３５０内においてフィルタ・アウトされる。
【０２１３】
Ｇ．例
図３ｍを、図３ａ、３ｇ、３ｈ、３ｉ、３ｌ、および３ｎとの関連から参照し、Ｘ８６発呼側スレッド３０４による『タペストリー』被呼側ライブラリ３０８に対する呼び出し、Ｘ８６オペレーティング・システム３０６によってサービスされるライブラリ内における割り込み３８８、別のＸ８６スレッド３０２に対するコンテキスト切り替えならびに『タペストリー』被呼側３０８の再開、およびＸ８６発呼側３０４へのリターンについて考える。
【０２１４】
『タペストリー』ライブラリ３０８は、３２ビット・フラットのアドレス空間３８０にマップされる（３８２）。Ｘ８６発呼側スレッド３０４の立場から見ると、これはプロセスのアドレス空間になる。『タペストリー』のマシンおよびオペレーティング・システム３１２の立場から見ると、３２ビットのアドレス空間は、単なる、ページ・テーブル（図１ａおよび１ｄの１７０）を介してマップされた、その内容および意味が、完全にＸ８６オペレーティング・システム３０６のマネジメントに任せられたアドレス空間ということになる。
【０２１５】
当初、仮想Ｘ８６  ３１０上においてスレッド３０４が実行されている。スレッド３０４は、Ｘ８６のＣＡＬＬ（呼び出し）インストラクション３８３を実行し、ライブラリ・サービスを求める。スレッド３０４用のバイナリ・コードは、従来のＸ８６コードであり、『タペストリー』システム用に特別にコンパイルされたものではない。ＣＡＬＬ（呼び出し）インストラクション３８３は、コントロールをライブラリ３０８のエントリ・ポイントに渡す（矢印（１））。これは、このライブラリに関する『タペストリー』‐バイナリ置換のためのＧＥＮＥＲＡＬ（ジェネラル）エントリ・ポイント（図３ｇの３１７）である。『タペストリー』ネイティブ・ライブラリ・ルーチン３０８に関するエントリのプリアンブル３１７、３１９からの最初のインストラクションのフェッチは、Ｘ８６  ＩＳＡから『タペストリー』ＩＳＡへの変更を導く。プロセッサ１００は、遷移例外３８４を取り、Ｘ８６−『タペストリー』遷移ハンドラ（図３ｈの３２０）に方向を変える（矢印（２））。すべての『タペストリー』インストラクションが「０  ｍｏｄ  ４」の境界に整列されていることから、割り込みアドレスの下位２ビットは「００」である。したがって、遷移ハンドラ３２０は、「００」のケース３２２をディスパッチし（３２１）、『タペストリー』コンテキスト内の実行に関する前提条件を設定する（３２ビット整列スタック等）。遷移ハンドラ３２０のエンドにおいては、ＧＥＮＥＲＡＬ（ジェネラル）エントリ・ポイント３１７において実行を再開する（３３８；矢印（３））。ＧＥＮＥＲＡＬ（ジェネラル）エントリ・ポイント３１７は、Ｘ８６プリアンブル（図３ｇの３１９）を実行することによって開始し、それにおいてパラメータ・リストがＰ０〜Ｐ１５のパラメータ・レジスタにコピーされ、『タペストリー』ライブラリ・ルーチン３０８の実行が開始する。
ここで『タペストリー』ライブラリ・ルーチン３０８が割り込みもしくはＸ８６コードに対するコール・バックを伴わずに動作し、完了すると仮定する。
【０２１６】
『タペストリー』ライブラリ・ルーチン３０８が完了（３８５）すると、ルーチン３０８は、その戻り値の形式を記述する値をＸＤレジスタ（表１のＲ１５）にロードする。この値は、適宜ＲＶ０、ＲＶＦＰ、もしくはメモリ・ロケーション内の戻り値を示すことになる。ルーチン３０８は、リターン（矢印（４））のための『タペストリー』ＪＡＬＲインストラクションをもって完了する。Ｘ８６発呼側スレッド３０４から最初のインストラクションがフェッチされるとき、『タペストリー』ＩＳＡからＸ８６  ＩＳＡへの遷移３８６が認識され、コントロールの方向が『タペストリー』−Ｘ８６遷移ハンドラ（図３ｉの３４０）に変わる（矢印（５））。遷移ハンドラは、ＸＤ＜０３：００＞の値に応じてリターン・ケース３４２の１つにディスパッチ（３４１）し、それがその『タペストリー』ホームからＸ８６呼び出し規約の下におけるそのホームに戻り値をコピーする。ハンドラ３４０が完了するとき、それから初期ＣＡＬＬ（呼び出し）３８３に続くスレッド３０４内のインストラクションにコントロールが戻される（図３ｉのＲＦＥインストラクション３４９；図３ａ、３ｌおよび３ｍの矢印（６））。
【０２１７】
図３ｎを、図３ａ、３ｈ、３ｊ、および３ｌとの関連から参照し、『タペストリー』ライブラリ・ルーチン３０８の実行の途中で外部非同期割り込み３３８が発生した場合について考える。例を設定するため、ここでこの割り込みを、２番目のより優先度の高いＸ８６スレッド３０２をブロックしないディスク完了割り込みとする。この割り込みは、『タペストリー』オペレーティング・システム３１２の割り込み／例外ハンドラ（図３ｊの３５０）に方向を変更する（矢印（７））。割り込みハンドラ３５０は、ケース３５１、３５３、３５４に不適合となった後に、ケース３６０を選択する。完全なプロセッサ・コンテキストが保存スロット３５５内に保存（３６２）され、下位２ビットＥＩＰ＜０１：００＞が、表３において説明したように「０１」に上書きされ（３６３）保存スロット番号ならびにタイムスタンプがＸ８６レジスタにロード（３６４、３６５）される。割り込みハンドラ３６０は、割り込みをＸ８６エミュレータ３１６の割り込みエントリ・ポイント３５２に割り込みを引き渡す（図３ｊの３６９）（矢印（８））。Ｘ８６エミュレータ３１６は、Ｘ８６オペレーティング・システム３０６にコントロールを渡す（矢印（９））。Ｘ８６オペレーティング・システム３０６は、従来の方法に従って割り込みサービスを行う。しかしながら、スレッド３０４に関してＸ８６オペレーティング・システム３０６がサービスするコンテキストは、タイムスタンプおよび保存スロット番号情報のコレクションであり、下位２ビットを除いてＥＩＰには着手されずに『タペストリー』例外ハンドラ３６０のステップ３６３によって、表３に適合するように作られる。このパラグラフの最初に仮定したように、Ｘ８６オペレーティング・システム３０６は、スレッド３０２を選択して再開する（矢印（１０））。
【０２１８】
Ｘ８６スレッド３０２は、しばらく実行を続けた後、たとえばタイム・スライスの超過によって、最終的にコントロールをＸ８６オペレーティング・システム３０６に戻すと（矢印（１１））、新しいディスク要求等を発行する。ここで、Ｘ８６オペレーティング・システムのスケジューラがスレッド３０４の再開を選択したと仮定する。Ｘ８６オペレーティング・システム３０６によって復元されるコンテキストは、割り込みハンドラ３６０によって作られたタイムスタンプおよび保存スロット番号の「コンテキスト」である。復元されるこのコンテキストのＥＩＰは、下位２ビットに「０１」を伴う、割り込み３８８の行なわれたインストラクションに続くインストラクションをポイントする。Ｘ８６オペレーティング・システム３０６は、ＩＲＥＴインストラクションを実行して、この復元されたコンテキストにおいて実行を再開する（矢印（１２））。このインストラクションのフェッチは、Ｘ８６オペレーティング・システム３０６のＸ８６  ＩＳＡから『タペストリー』ライブラリ３０８の『タペストリー』  ＩＳＡへの遷移３８９を認識し、Ｘ８６−『タペストリー』遷移ハンドラ３２０（図３ｈ）に方向を変更する（矢印（１３））。遷移ハンドラ３２０は、ＥＩＰアドレスの下位２ビットに応答してケース３７０にディスパッチ（３２１）する。ケース３７０のコードは、Ｘ８６レジスタ内を探して、再開するプロセスに対応する保存スロット３５５のアドレスを見つけ出す。Ｘ８６レジスタの内容および見つけ出された保存スロット３５５は、冗長性のためにストアされているタイムスタンプおよび保存スロット番号との相互比較によって有効性が確認される（３７１、３７４、３７６）。保存スロット３５５の内容は、完全な『タペストリー』プロセッサ・コンテキストを復元する（３７５）。遷移ハンドラ３２０は、オリジナルの外部割り込み３８８のポイントにおいて、『タペストリー』ライブラリ・ルーチン３０８を再開する（３７８）（矢印（１４））。
【０２１９】
図３ｏを、図３ａ、３ｈ、３ｊ、および３ｌとの関連から参照し、『タペストリー』ネイティブ発呼側３９１からＸ８６被呼側３９２に対する呼び出しの場合について考える。（図３ｂを参照した議論において、このシナリオに関して、いずれも特別なコーディングがなされていないと述べたことを想起されたい−−Ｘ８６被呼側は、従来のＸ８６コンパイラによって生成され、『タペストリー』発呼側３９１は、被呼側がＸ８６被呼側３９２であるか、『タペストリー』被呼側であるかによらず、良好な機能が等しく得られるようにコーディングされている。）発呼側３９１は、ＸＤレジスタ（表１のＲ１５）を、その引数リストの『タペストリー』レジスタ（表１のＲ３２〜Ｒ４７）内のレイアウトを記述する値にセットする（３９３）。その後、発呼側３９１は、ＪＡＬＲインストラクション３９４を発行して被呼側３９２を呼び出す。被呼側３９２の最初のインストラクションに到達すると、プロセッサ１００は、『タペストリー』−Ｘ８６遷移３９５を認識する。実行の方向が『タペストリー』−Ｘ８６例外ハンドラ（図３ｉの３４０）に変わる（矢印（１５））。下位４ビットＸＤ＜３：０＞は、インストラクションによってセット（３９３）されてＸＤ記述子の基本分類を含んでおり、これらの４ビットに従って実行が、通常はコード・セグメント３４３〜３４５、またはセグメント３４３、３４６、３４７にディスパッチされる（３４１）。ディスパッチ先のコード・セグメントは、ＸＤレジスタの残部によって示されるように、実際のパラメータを『タペストリー』ホームからそのＸ８６ホームに移動（３４７）する。ハンドラ３４０は、表３に示すように、発呼側３９１がリターン結果を期待しているロケーションを示すように、リターンＰＣの下位２ビットＬＲ＜１：０＞を「１０」もしくは「１１」に上書きする（３４５、３４６）。ハンドラ３４０は、被呼側３９２の最初のインストラクションにリターンし（矢印（１６））、従来の方法に従ってそれが実行される。被呼側３９２が完了すると、Ｘ８６  ＲＥＴインストラクションがコントロールを発呼側３９１に返す（矢印（１７））。発呼側３９１からの最初のインストラクションのフェッチは、遷移例外３９６をトリガすることになる。この例外は、コントロールの方向をＸ８６−『タペストリー』ハンドラ３２０に変える（矢印（１８））。ハンドラ３２０は、ＬＲの下位２ビットに基づいて関数の戻り値の再フォーマットおよび／または再配置（３３０、３３３、３３４）を行う。ハンドラが完了すると（３３６、３３８）、コントロールが、発呼側３９１のオリジナルの呼び出し３９４の続きに戻る（矢印（１９））。
【０２２０】
再度図３ａおよび３ｌを参照するが、これにおいては複雑性がクロスＩＳＡ呼び出しのケースに制限されている。クロスＩＳＡ呼び出しの取り扱いにおける複雑性は、トランスペアレントなクロスＩＳＡ呼び出しが、これまでにこの分野において知られていないことから許容範囲である。発呼側、被呼側、およびオペレーティング・システムがすべて共通のＩＳＡを共有している場合においては、遷移例外がまったく発生しない。たとえば、『タペストリー』プロセス３１４が同一の『タペストリー』ライブラリ・ルーチン３０８を呼び出すとき（矢印（２０））、ルーチン３０８はＮＡＴＩＶＥ（ネイティブ）エントリ・ポイント３１８を通って入るか、ＧＥＮＥＲＡＬ（ジェネラル）エントリ・ポイント３１７を介して『タペストリー』ショート・パスを獲得する。（ここで、ルーチン３０８が『タペストリー』プロセス３１４のアドレス空間内に個別にマップ（３９７）されなければならないことに注意が必要である−−『タペストリー』プロセス３１４が『タペストリー』オペレーティング・システム３１２のマネジメントの下に置かれ、Ｘ８６プロセスのアドレス空間３８０が完全にＸ８６オペレーティング・システム３０６によってマネージされ、完全に『タペストリー』オペレーティング・システム３１２の視野の外となっていたことを想起されたい。）同一の外部割り込み３８８が発生（矢印（２１））した場合、その割り込みは、『タペストリー』オペレーティング・システム３１２（図３ｊのコードの外）において扱うことが可能であり、コントロールは、ハンドラの遷移を通じたトレースを必要とすることなく、割り込みに続くインストラクションにおいて直接再開する（矢印（２２））。『タペストリー』ライブラリ・ルーチン３０８が完了すると、従来の方法に従ってコントロールが発呼側に返る（矢印（２３））。唯一のオーバーヘッドは、単一のインストラクション３９３であり、被呼側にＸ８６コードが用いられている場合にＸＤの値をセットする。
【０２２１】
Ｈ．代替実施例
別の実施態様においては、メモリの「復元ターゲット・ページ」がＸ８６アドレス空間のオペレーティング・システム領域内に予約される。ＰＦＡＴ  １７２において、復元ターゲット・ページのためのＩＳＡビット１８０がセットされ、そのページに関するインストラクションが『タペストリー』インストラクション・セットの下に解釈されるべきであることが示される。この復元ターゲット・ページは、ページ不可能に設定される。図３ｊのステップ３６３において、ＥＩＰ値が、復元ターゲット・ページ内をポイントするＸ８６アドレスに置換され、つまり通常、保存スロットの番号をストアしているこの置換ＥＩＰのバイト・オフセット・ビットに置換される。別の実施態様においては、ＥＩＰが復元ターゲット・ページをポイントするべくセットされ、保存スロット番号がＸ８６レジスタの１つ、たとえばＥＡＸにストアされる。いずれの場合においても、Ｘ８６オペレーティング・システム３０６がスレッドを再開するとき、復元ターゲット・ページが、そのＰＦＡＴエントリおよびＩ−ＴＬＢエントリ内に『タペストリー』ＩＳＡビット・セットを有していることから、最初のインストラクションのフェッチによって、復元ターゲット・ページからの最初の実際のインストラクションが実際に実行される前に、Ｘ８６−『タペストリー』遷移例外がトリガされる。Ｘ８６−『タペストリー』遷移ハンドラ３２０は、フェッチしたインストラクションのアドレスを近似することによって開始する。復元ターゲット・ページに関するアドレスは、復元する拡張コンテキストが存在することを知らせる。保存スロット番号は、インストラクション・アドレスから抽出される（ここで、保存スロット番号が例外のエントリ時にＥＰＣもしくはＥＡＸ内にコーディングされ、そのいずれもがスレッドの再開のプロセスにおいてＸ８６オペレーティング・システム３０６によって復元されたことを想起されたい）。プロセッサ・コンテキストは、保存スロットから、スレッドに対するオリジナルの割り込みがあったＥＰＣ．ＥＩＰ値を含めて復元される。別の実施態様においては、（Ｘ８６コンテキストを含まずに）拡張コンテキストのみが保存スロットから復元され、その結果、オペレーティング・システムによってもたらされたＸ８６コンテキストに対する変更があるときには、そのすべてがそのまま残される。Ｘ８６−『タペストリー』遷移ハンドラ３２０は、ＲＦＥ  ３３８を実行して割り込みの行なわれた『タペストリー』コード内において実行を再開する。
【０２２２】
ここで、復元ターゲット・ページからのインストラクションが実際に実行されることがない点に注意する必要がある；そのアドレスは、Ｘ８６−『タペストリー』遷移ハンドラ３２０に対する単なるフラグである。唯一必要なことは、アドレスをＸ８６オペレーティング・システム３０６およびそのスレッド・スケジューラに渡すことができるように、復元ターゲット・ページのアドレスがＸ８６アドレス空間内において表現できることである。別の実施態様においては、復元ターゲット・ページからのフェッチが別の例外−−すなわち非整列インストラクション違反、またはアクセス保護違反を生じることがある。しかしながら、生じる違反がＸ８６アーキテクチャ内に定義されていない違反となることは望ましいことであり、その結果、いずれのユーザ・プログラムもその違反に関するハンドラを登録することができない。
【０２２３】
この別の実施態様においては、Ｘ８６−『タペストリー』遷移ハンドラ３２０の「０１」ケース３７０が、Ｘ８６スレッドの特権モードを保存し、特権リング「０」においてＸ８６発呼側が動作している場合であっても特権レベルをユーザにリセットすることができる。特権モードは、システムの保全性を保護するために変更され、『タペストリー』の「トロイの木馬」がＸ８６セキュリティ・チェックをくぐり抜けることを不可能にする。
【０２２４】
別の実施態様においては、保存スロットとＸ８６スレッドの間の対応が、Ｘ８６オペレーティング・システム３０６へのスレッドＩＤ呼び出しを使用することによって維持される。各保存スロット３５５は、そのスレッドが持続する間にわたってＷｉｎｄｏｗｓ（登録商標）（ウィンドウズ（登録商標））スレッド番号と関連付けすることができる。ガーベジ・コレクタを使用すれば、かなり以前に満たされ、現在は見捨てられていると見られる保存スロットを認識することができる。ガーベジ・コレクタは、システムの調整可能周期の後に、あるいはそれが満たされた時間的古さを基礎として、そのスレッドがＸ８６オペレーティング・システム３０６によって終了されることを仮定し、保存スロットを再利用する。
【０２２５】
さらに別の実施態様においては、Ｘ８６コンバータ・モードの間に『タペストリー』が例外を取ると、拡張コンテキストのスナップショットも行なわれる。オペレーティング・システムがＸ８６  ＴＳＳ（タスク−ステート・セグメント）を使用してマルチ−タスキングをインプリメントしている場合には、拡張コンテキストのＰＳＷ部分（ＩＳＡビット１９４、ＸＰ／呼び出し規約１９６、およびセマンティック・クラス２０６；後述するセクションＩＶを参照されたい）をＸ８６  ＴＳＳの使用されていない部分にスナップショットすることができる。それ以外の場合には、関連するデータの量、すなわち５ビット（ＩＳＡビット１９４、ＸＰ／呼び出し規約１９６、およびセマンティック・クラス２０６）は、充分に小さく、ＥＦＬＡＧＳのトップにある使用されていない１０ビットに死蔵することができる。一部の実施態様においては、Ｘ８６空間内の例外スタックにプッシュされる追加のワードとして拡張コンテキストをプッシュすることができる。
【０２２６】
さらに別の実施態様においては、Ｘ８６に対してアクセス不能な『タペストリー』空間内のメモリに拡張コンテキストをストアすることができる。ハッシュ・テーブル（またはそれと等価な結合ソフトウエア構造）が特定のＸ８６例外フレームと、それに関連付けされた拡張『タペストリー』コンテキストのスナップショットをリンクし、その結果、例外の出口もしくはタスクの再スケジューリングに際して、プロセッサが特定のＸ８６コンテキストをＥＰＣ（エラーＰＣおよびプログラム・ステータス・ワード）に再ロードし、続いてそれがＲＦＥインストラクションによってＰＳＷに再ロードされるとき（またはＸ８６  ＰＯＰＦインストラクションがエミュレートされるとき）、拡張『タペストリー』コンテキストをロケートし、ＥＰＣ内に配置することが可能になる。
【０２２７】
ＩＶ．あるＩＳＡから他方への遷移を管理するための代替方法
Ａ．プログラム・テキストのための呼び出し規約（ＣＣ）の指標
セクションＩＶ．ＡおよびＩＶ．Ｂの説明は、ともにサブプログラムとの間におけるデータの授受に関する規約を決定するために使用される代替メカニズムに関するものであり、それによりサブプログラムの引数または関数の戻り値がストアされるロケーションが、コントロール移動イベントの前に決定され、例外ハンドラは、コントロール・フロー・イベントの後に実行されることになるコードによって期待されているロケーションにデータを移動することができる。
【０２２８】
Ｘ８６  ＣＩＳＣアーキテクチャの代替『タペストリー』エミュレーションにおいて、ネイティブ・コードの大半は、２つの異なる呼び出し規約の一方を順守する（前述のセクションＩＩＩ．Ｂを参照されたい）：一方は、ネイティブ『タペストリー』コードからネイティブ『タペストリー』コードへの呼び出しのためのＲＩＳＣレジスタ‐ベースの呼び出し規約であり、他方は、エミュレートされたＣＩＳＣ呼び出し規約に類似するものとして示される疑似ＣＩＳＣメモリ‐ベースの規約であり、呼び出しがもっとも頻繁に一方のＩＳＡから他方にクロスするであろうと考えられるときに使用するための規約である。セクションＩＶ．ＡおよびＩＶ．Ｂにおいて説明している特徴は、マシン・コンテキストに関する充分な情報を提供し、その結果、一方のＩＳＡから他方へのシームレスな遷移をもたらすことができる。
【０２２９】
再度図３ａを参照するが、ネイティブ『タペストリー』インストラクション・セットにおいてコーディングされたプログラムは、サブプログラムを呼び出すとき、レジスタ−ベースのＲＩＳＣ呼び出し規約、もしくはＸ８６呼び出し規約に匹敵するメモリ−ベースの呼び出し規約のいずれかを使用することができる。Ｘ８６コンバータ・モードにおいては、すべてのサブプログラム呼び出しがメモリースタック−ベースの呼び出し規約を使用する。いずれのモードにおいても、データが、特定メモリ内のそのロケーションもしくはレジスタ・ロケーションによりソースからディスティネーションに渡る内部ジャンプによって、コントロールが移動されることがある。
【０２３０】
ビット２００によってプログラム・テキスト領域１７６に注釈が付され、その領域のコードによって使用される呼び出し規約が示される。実行のフローが、一方の呼び出し規約を順守しているソースから、他方を順守しているディスティネーションに向かうと、呼び出し規約ビット２００の相違が遷移例外をトリガする。遷移例外ハンドラは、このサブプログラムの引数をソースの規約によって確立された周知のロケーションから、ディスティネーションによって期待される周知のロケーションにコピーする。これにより発呼側および被呼側のサブプログラムを、他方によって使用されている呼び出し規約をまったく頼ることなくコンパイルすることが可能になり、同質でないＩＳＡのバイナリならびにライブラリの環境におけるよりシームレスなシステム・オペレーションが可能になる。
【０２３１】
図１ｄおよび２ａを参照すると、前述のセクションＩＩにおいて説明したように、ＩＳＡビット１８０、１８２と類似の態様において、呼び出し規約ビット２００がＰＦＡＴエントリ１７４およびＩ−ＴＬＢ  １１６に、ＰＳＷ  １９０の呼び出し規約ビット１９６内にある以前のインストラクションの呼び出し規約の記録とともにストアされる；当該セクションにおいて説明した別の実施態様は、これにおいても同様に適用することができる。（呼び出し規約プロパティ２００は『タペストリー』コードのページに関してのみ意味を有し、かつＸＰ書き込みプロテクト・プロパティ１８４、１８６（前述のセクションＩ．Ｆにおいて説明済み）がＸ８６コードのページに関してのみ使用されることから、所定のページに関する２つのプロパティは、ＸＰ書き込みプロテクト・ビット１８４、１８６に重ねて、単一の物理ビット内にエンコードすることが可能である−−この単一ビットは、ＰＳＷ．ＩＳＡビット１９４に応じて異なる意味を有する。）
【０２３２】
図２ｂおよび２ｃを参照すると、実行が一方の呼び出し規約２００の領域から他方の呼び出し規約２００の領域にクロスするとき（列２０４）、マシンが例外を取る。遷移の方向（『タペストリー』−Ｘ８６またはＸ８６−『タペストリー』）およびその遷移を誘発したインストラクションのクラス分け（後述するセクションＩＶ．Ｂにおいて説明する表４に示す）に基づいて、この例外が、その方向ならびにクラス分けに対応する例外ハンドラに向けられる。図２ｃの８つの行２４２〜２５６には、８つの呼び出し規約遷移例外ベクトルが示されている。（呼び出し規約遷移に関する８つの例外ベクトルは、前述のセクションＩＩにおいて論じたＩＳＡに関する２つの例外ベクトルと明確に区別される。）例外の方向の変更は、充分に具体的であり、特定のハンドラへの到達時に、古いマシン・コンテキストから、新しい環境における実行のための前提条件を満たすマシン・コンテキストへのマッピングの概略を決定することができる。例外ハンドラは、一方のロケーションから他方にデータをコピーすることによってこのマッピングをインプリメントする。例外ハンドラは、ソース・インストラクションとディスティネーション・インストラクションの間に介挿された例外の存在する間にわたって動作し、マシン・コンテキストを、ソースの最後のインストラクションによって生成されたコンテキスト（たとえばＣＡＬＬ（呼び出し）の前に設定された引数を渡すエリア）をディスティネーションの最初のインストラクションによって期待されているコンテキスト（たとえば、その引数の使用を開始するコードが期待される）に変換する。
遷移例外のプロセス、および個々の例外のケースの扱いに使用される情報について、次のセクションＩＶ．Ｂに説明する。
【０２３３】
Ｂ．制御転送セマンティクスの記録および呼び出し規約の調停
単に遷移の方向（Ｘ８６呼び出し規約から『タペストリー』呼び出し規約もしくはその逆）を明らかにするだけでは、データ・ストレージ規約が一致しない場合に遷移例外に応答して取らなければならないアクションを決定する上で充分ではない。このセクションにおいては、遷移例外時に適切なアクションを取ることができるようにマシン・コンテキストを解釈するために使用される残りのテクニックについて説明する。概略において、各コントロール移動インストラクションが実行されるとき、そのインストラクションの意図もしくはセマンティック・クラスがＰＳＷ（プログラム・ステータス・ワード）１９０のＳＣ（セマンティック・クラス）フィールド２０６（ＰＳＷ．ＳＣ）内に記録される。遷移例外に際しては、この情報が使用されて、古い状態から新しい前提条件への遷移をもたらすために、一方のロケーションから他方にデータをコピーするべくプログラムされた例外ハンドラに方向が変えられる。
【０２３４】
【表４】
0005427742.tif 000007
【０２３５】
図１ｅならびに２ｃおよび表４を参照すると、『タペストリー』ＩＳＡおよびＸ８６  ＩＳＡのいずれのコントロール‐フロー・インストラクションについても、５つのセマンティック・クラス：すなわち、ＪＵＭＰ（ジャンプ）、ＣＡＬＬ（呼び出し）、ＲＥＴＵＲＮ−ＮＯ−ＦＰ（倍精度浮動小数点結果を返さないサブプログラムからのリターン）、ＲＥＴＵＲＮ−ＦＰ（明確に倍精度浮動小数点結果を返すサブプログラムからのリターン；『タペストリー』ネイティブ被呼側からのリターンのコンテキスト内においてのみ使用される）、およびＲＥＴＵＲＮ−ＭＡＹＢＥ−ＦＰ（６４ビット倍精度もしくは８０ビット拡張精度倍精度浮動小数点結果を返すと考えられるか、明確にそれを返すサブプログラムからのリターン；Ｘ８６被呼側からのリターンのコンテキスト内においてのみ使用される）に分類される。各ＩＳＡモードに関して可能性のある遷移が４つであることから、２つのビット２０６（ＰＳＷ．ＩＳＡビット１９４と組み合わされる）は、列挙した５つの状態を識別する上で充分である。
【０２３６】
このセマンティック・クラス分類のほとんどは、インストラクションのオペコードによって静的である。一部のインストラクション、たとえばＸ８６のＪＵＭＰ（ジャンプ）およびＣＡＬＬ（呼び出し）インストラクションは、意味論的に明確である。たとえばＸ８６のＲＥＴは、ＣＡＬＬ（呼び出し）もしくは内部コントロール・フローのＪＵＭＰ（ジャンプ）と誤ることがあり得ない。このように、『タペストリー』システムがＸ８６バイナリに関するソース・コードを調べなくても、Ｘ８６インストラクションがそのオペコードに、インストラクションのセマンティック・クラスを決定するための充分な情報を含んでいる。
【０２３７】
表４を参照するが、セマンティック・クラス分類の一部は、コンパイラによってインストラクション内にエンコーディングされる。たとえば、『タペストリー』のＪＡＬＲインストラクション（インストラクションのソース・レジスタによって指定されたロケーションに対する間接ジャンプ、およびディスティネーション・レジスタ内へのリンクＩＰ（インストラクション・ポインタ）のストア）は、いくつかの役割、たとえばサブプログラムからのリターン（リンクＩＰが読み出しゼロ・レジスタ内にストアされる）、単一ルーチン内においてＦＯＲＴＲＡＮによって割り当てられるｇｏ−ｔｏ（飛び越し）、あるいはサブプログラム呼び出し等を提供する。ＪＡＬＲインストラクションのあいまい性を解決するために、コンパイラによって、インストラクションの実行に使用されないビットにセマンティック・クラス・コードの１つが含められ、インストラクションの実行時に、そのコードがイミディエートとして当該インストラクションからＰＳＷ．ＳＣ  ２０６にコピーされる。ソース・コードからコンパイルされる『タペストリー』ネイティブ・バイナリの場合には、コンパイルされるプログラムのソース・コードから収集されるセマンティック情報の補助によってもＪＡＬＲインストラクションのこのイミディエート・フィールドが満たされる。Ｘ８６から『タペストリー』に翻訳されたバイナリの場合には、Ｘ８６インストラクションのセマンティック・クラスが使用されて対応する『タペストリー』インストラクションのセマンティック・クラスが決定される。このように、『タペストリー』コンパイラは、プログラムを解析して各種のアドレスに対するブランチ（たとえば、ＦＯＲＴＲＡＮによって割り当てもしくは演算されるｇｏ−ｔｏ（飛び越し）、あるいはジャンプ・テーブルを介したＣＡＳＥ（ケース）ブランチ）に関するＪＡＬＲとファンクション・リターンに関するＪＡＬＲの区別（さらに、浮動小数点と非浮動小数点の場合の区別）、サブプログラム呼び出しに関するＪＡＬＲとの区別を行い、明示的に２ビットのセマンティック・クラス・コードをＪＡＬＲインストラクション内に含ませる。
【０２３８】
セマンティック・クラスの一部は、マシン・コンテキストの実行時の解析によって実行される。Ｘ８６のＲＥＴ（サブプログラムからのリターン）インストラクションは、２つのセマンティック・コンテキスト・クラス、すなわちＲＥＴＵＲＮ−ＮＯ−ＦＰ（サブプログラムからのリターン；明示的に倍精度浮動小数点結果を返さない）およびＲＥＴＵＲＮ−ＭＡＹＢＥ−ＦＰ（可能性として、あるいは明確に浮動小数点結果を返すリターン）に分類される。Ｘ８６呼び出し規約は、浮動小数点の関数結果が浮動小数点スタックのトップに返されること、および整数の関数結果がレジスタＥＡＸ内に返されることを指定している。いずれの場合のインストラクション・コードも同一であり、コンバータ１３６は、Ｘ８６の浮動小数点スタックのトップに基づいてオン‐ザ‐フライでＲＥＴインストラクションを分類する。このスタックのトップが空にマークされている浮動小数点レジスタをポイントしている場合には、Ｘ８６呼び出し規約から、ＲＥＴが浮動小数点値を返していないことが明確に保証され、セマンティック・クラスがＲＥＴＵＲＮ−ＮＯ−ＦＰにセットされる。しかしながら、このスタックのトップが満たされたロケーションをポイントしている場合には、整数の戻り値があることもあり、セマンティック・コンテキストがＲＥＴＵＲＮ−ＭＡＹＢＥ−ＦＰにセットされて、このあいまい性が示される。
【０２３９】
例外が生じると、ＰＳＷ  １９０（ＩＳＡビット１９４、呼び出し規約ビット１９６、およびＳＣフィールド２０６を含む）が例外ＰＳＷ、すなわちマシンのコントロール・レジスタ内にスナップショットされる。例外ハンドラは、例外ＰＳＷ内のＰＳＷビットの吟味および修正を行うことができる。例外ハンドラが完了するとき、ＲＦＥ（例外からのリターン）インストラクションが、スナップショット済みの例外ＰＳＷをＰＳＷ  １９０内に復元し、マシンの例外が再開する。このように、ＰＳＷ．ＳＣ  ２０６は、例外ハンドラの実行間に更新される場合であっても、例外を通じて保存される（例外ハンドラが例外ＰＳＷを修正することによって意図的にそれを修正する場合を除く）。
【０２４０】
図２ｂおよび２ｃは、呼び出し規約の遷移がどのように例外ハンドラに向けられるかを示している。呼び出し規約の遷移例外が生じると、５つのデータが使用されて適切なハンドラに方向が変えられ、ハンドラが取るべきアクションが決定される：すなわち、古いＩＳＡ  １８０、１８２、新しいＩＳＡ  １８０、１８２、古い呼び出し規約１９６、新しい呼び出し規約１９６、およびＰＳＷ．ＳＣ
２０６である。図２ｂにおいて、最初の列２０４は、最初の４つに基づく遷移、すなわちＩＳＡおよびＣＣビットの遷移の性質を示す。たとえば、第３行２１６は、ネイティブ『タペストリー』のレジスタ‐ベースの呼び出し規約を使用するネイティブＩＳＡ（ＩＳＡおよびＣＣビットの値「００」によって表される）からＸ８６呼び出し規約の使用を必要とするＸ８６コード（Ｘ８６  ＩＳＡについては「１」、ＣＣビットについては「無関係」を示す値「ｘ」とする値「１ｘ」によって表される）への遷移を論じている。表４は、いくつかの異なる状況によって同一の例外ハンドラに方向が変えられることを示している。ここで、たとえば行２１４および２１６が、同一グループのハンドラに方向を変えることに注意されたい。これらの符合は、Ｘ８６規約がネイティブ『タペストリー』インストラクションによって順守されているか、Ｘ８６インストラクションによって順守されているかによらず、ネイティブ『タペストリー』呼び出し規約からＸ８６呼び出し規約への変換、もしくはその逆の変換に必要となるメモリ操作が概略で同一になることから生じる。
【０２４１】
図２ｃは、セマンティック・クラスに基づいて適正な例外ハンドラにマシンの方向を変更する方法を示している。たとえば行２４２、２４４、２４６、および２４８は、コントロール−フロー・インストラクションの４つの可能性のあるセマンティック・クラスに基づいて、００＝＞０１および００＝＞１ｘ（ネイティブ呼び出し規約を使用するネイティブ『タペストリー』コードからＸ８６規約を使用するＸ８６コードへ）のＩＳＡおよびＣＣの遷移に関する４つの可能性のあるハンドラを開始する。行２５０、２５２、２５４、および２５６は、０１＝＞００および１ｘ＝＞００の遷移に関する４つの可能性のあるハンドラを、これらの遷移を生じることがある４つのインストラクションのセマンティック・クラスに基づいて開始する。
【０２４２】
図２ｂを参照すると、１つのサブプログラムから別のサブプログラムにクロスするとき、ソースおよびディスティネーションが、引数を渡すために使用する規約に関して一致していれば、それらがＩＳＡおよび呼び出し規約に関して一致（行２１２、２２０、２２８、２３０）することから、もしくはＩＳＡに関して不一致であっても呼び出し規約に関して一致（行２２２、２２６）することから、あるいは単にソースおよびディスティネーションの実行環境において同一のストレージ・ロケーションにストアされることによってデータが渡される（表２４４、２５２）ことから、仲裁が必要ないことがわかる。たとえば、Ｘ８６呼び出し規約を使用するＸ８６  ＩＳＡからＸ８６呼び出し規約を使用する『タペストリー』ネイティブＩＳＡに、あるいはその逆のクロスを行う場合、表１に示し、前述のセクションＩ．Ｂにおいて論じた固定マッピングを使用する、Ｘ８６仮想リソースと『タペストリー』物理リソースの間の固定マッピングを使用して、実際に一方のハードウエア・エレメントを他方に移動することなく、一方の環境から他方の環境にデータが渡される。
【０２４３】
たとえば、行２２２に示したように、疑似Ｘ８６呼び出し規約に基づいてメモリを使用する『タペストリー』ネイティブ・コードの発呼側が、Ｘ８６コードのルーチンを呼び出す場合（もしくはその逆；行２２６）には、引数を移動する必要がない；インストラクションのデコード・モードを変更するだけでよい。
【０２４４】
これに対し、呼び出し規約２００が一致せず、一方の呼び出し規約の下に引数が渡され、他方の規約の下に受け取られるとき、呼び出し規約例外ハンドラが仲裁を行い、引数データをソース規約によって使用される周知のロケーションから、ディスティネーション規約によって期待される周知のロケーションに移動する。たとえば、Ｘ８６発呼側からネイティブ『タペストリー』呼び出し規約を使用するネイティブ『タペストリー』コードの被呼側へ（行２２４、２５０）、あるいはそれと等価になるＸ８６呼び出し規約を使用する『タペストリー』コードからネイティブ規約を使用するネイティブ『タペストリー』への（行２１８、２５０）サブプログラムＣＡＬＬ（呼び出し）は、メモリ・スタック‐ベースの発呼側規約によって指定されるロケーションからレジスタ‐ベースの被呼側規約によって指定されるロケーションに引数を移動しなければならない。
【０２４５】
図２ｂおよび２ｃの行２４１、２４２は、発呼側がレジスタ‐ベースのネイティブ呼び出し規約を使用する『タペストリー』ネイティブ・コードであり、被呼側も『タペストリー』ネイティブ・コードであるが疑似Ｘ８６呼び出し規約を使用する場合のサブプログラム呼び出しについて示している。（同様に行２１６に示すように、発呼側がレジスタ−ベースのネイティブ呼び出し規約を使用する『タペストリー』ネイティブ・コードであり、被呼側がＸ８６ＩＳＡでコーディングされている場合には、同じ例外ハンドラ２４２が呼び出され、同じ処理が行われる。）例外ハンドラは、サブプログラム引数を、ネイティブ規約の下に引数が渡されたそれらのレジスタ・ポジションから、Ｘ８６呼び出し規約の下に期待されるメモリ・スタック・ポジションにプッシュする。引数が、サイズにおいて変化するタイプである場合には、引数バッファのＸ８６スタック・レイアウトは、かなり複雑になり、『タペストリー』レジスタ内の引数からその引数バッファへのマッピングも、それに応じて複雑になる。引数のコピーは、記述子、すなわちコンパイラによって発呼側サイトの注釈用に生成された引数によって指定される。これは、「サイズ可変引数」ルーチンの場合に特に重要となる。ネイティブ発呼側が『タペストリー』コンパイラによって生成されていることから、コンパイラは、遷移例外によって実行されるデータ・コピーを完全に記述する記述子を生成することができる。その後データは、被呼側によって期待されるロケーションに収められ、ディスティネーションＩＳＡモードにおいて例外が再開される。
【０２４６】
Ｘ８６被呼側（または疑似Ｘ８６呼び出し規約を使用する『タペストリー』発呼側）の場合は、発呼側によって設定された引数ブロックのデータが『タペストリー』被呼側によって期待されているロケーションにコピーされる。たとえば、リンケージ・リターン・アドレスがスタックのトップからｒ６（『タペストリー』リンケージ・レジスタ；この目的からＬＲのエイリアス名が与えられている）にコピーされる。このスタックの続く数バイトが、迅速なアクセスのために『タペストリー』レジスタ内にコピーされる。呼び出し記述子（呼び出し引数のフォーマットを記述するデータ）がレジスタｒ５１（エイリアスＣＤ）内に作られ、その引数がＸ８６規約の下に渡されることを示すべくセットされる。ヌル戻り値記述子が、スタック上に作られる；このリターン記述子は、その情報が既知になると、戻り値のフォーマットを指定するように修正される。
【０２４７】
被呼側関数からのリターン時に、発呼側ならびに被呼側の呼び出し規約２００およびリターン・インストラクションのセマンティック・クラス２０６は、関数の戻り値を、被呼側によって期待されている適正なロケーションに収めるために必要なアクションを決定する。表１に示されるように、Ｘ８６呼び出し規約は、倍精度浮動小数点関数戻り値を、浮動小数点スタックのトップによって示される浮動小数点レジスタ内に返す。Ｘ８６呼び出し規約は、３２ビットもしくはそれ以下のその他のスカラをレジスタＥＡＸに、３３〜６４ビットの結果をＥＡＸ：ＥＤＸレジスタ・ペアにそれぞれ返し、６５ビットもしくはそれ以上の関数戻り値については、被呼側の引数リストにあらかじめ追加された引数によってポイントされるメモリ・ロケーション内に返される。ネイティブ『タペストリー』呼び出し規約は、倍精度浮動小数点値をｒ３１（この目的から、ＲＶＤＰのエイリアス名が与えられている）に、それ以外の、２５６ビットもしくはそれ以下の戻り値をレジスタｒ４８、ｒ４９、ｒ５０、およびｒ５１（エイリアス名ＲＶ０、ＲＶ１、ＲＶ２、およびＲＶ３が与えられている）に、それを超える戻り値をｒ３１（この目的から、エイリアス名ＲＶＡが与えられている）によってポイントされるメモリ・ロケーション内に返す。
【０２４８】
『タペストリー』呼び出し規約、および『タペストリー』とＸ８６リソースの間のマッピングは、少なくとも部分的に相互設計され、共通の使用を最大化し、それによって呼び出し規約の遷移に必要となるデータのコピーの量が抑えられている。したがって、スカラの関数戻り値のリターンに使用される２つのレジスタ−−『タペストリー』におけるｒ４８（ＲＶ０、Ｘ８６におけるＥＡＸ）−−が互いにマップされる。
【０２４９】
ネイティブ呼び出し規約の被呼側からＸ８６発呼側もしくはＸ８６規約を使用する『タペストリー』発呼側にリターンするときは、当該リターンのセマンティック・クラスが（関数が浮動小数点値を返すか否かが、コンパイラによって導かれるＪＡＬＲのセマンティック・クラス・ビット内にエンコーディングされていることから）明確に既知となり、そのセマンティック・クラスは、次の２つのパラグラフにおいて説明するように、生じる可能性のある２つのケースにおいて取られる２つのアクションを明確に区別する。
【０２５０】
ネイティブ規約の関数が倍精度（６４ビット）浮動小数点値をＸ８６規約の発呼側に返すとき（行２４８に示したＲＥＴＵＲＮ−ＦＰのケース）、関数戻り値は、ｒ３１（ＲＶＤＰ；『タペストリー』が倍精度の関数結果を返すレジスタ）におけるＩＥＥＥ−７５４の６４ビット表現から、Ｘ８６のＦＰスタックのトップが現在ポイントしているレジスタ・ペア（通常はｒ３２〜ｒ３３；Ｘ８６のＦ０にマップされた『タペストリー』レジスタ・ペア）内における８０ビットの拡張精度に拡張させる。浮動小数点スタックのトップによりポイントされるレジスタは、「満」にマークされており、残りすべての浮動小数点レジスタは「空」にマークされている。（『タペストリー』は、Ｘ８６のＦＰＣＷ（浮動小数点コントロール・ワード）、ＦＰＳＷ（浮動小数点ステータス・ワード）、およびＦＰＴＷ（浮動小数点タグ・ワード）の機能を包含する浮動小数点ステータス・レジスタを有しており、レジスタの「満」または「空」がこれらのステータス・レジスタのタグ・ビット内にマークされる。）
【０２５１】
『タペストリー』ネイティブ被呼側の非浮動小数点関数からＸ８６規約の被呼側へのリターン（行２４８に示したＸ８６規約の被呼側に対するＲＥＴＵＲＮ−ＮＯ−ＦＰのケース）においては、関数の戻り値がｒ４８内にそのまま残されるが、これは、単独のこのレジスタが、『タペストリー』関数がその結果を計算するレジスタであり、かつＸ８６のレジスタＥＡＸ（関数結果のリターン・レジスタ）がマップされたレジスタであることを理由とする。
【０２５２】
ネイティブ被呼側が６４ビットより大きな値をＸ８６規約の発呼側に返す場合、スタック上にストアされているリターン記述子が、戻り値がストアされている場所（通常、レジスタｒ４８（ＲＶ０）、ｒ４９（ＲＶ１）、ｒ５０（ＲＶ２）、およびｒ５１（ＲＶ３）の中、もしくはｒ３１（ＲＶＡ）によってポイントされるメモリ・ロケーションの中）を示す；戻り値は、Ｘ８６規約の下に指定されるロケーション（通常は、スタック上の引数ブロック内にストアされたアドレスのメモリ・ロケーション）にコピーされる。
【０２５３】
Ｘ８６被呼側からＸ８６規約を使用する『タペストリー』発呼側にリターンするときには、表１のレジスタ・マッピングが規約の変換をインプリメントしていることから、必要なアクションがまったくない。
【０２５４】
Ｘ８６被呼側からネイティブ『タペストリー』発呼側にリターンするときには、２つのセマンティック・クラスＲＥＴＵＲＮ−ＭＡＹＢＥ−ＦＰおよびＲＥＴＵＲＮ−ＮＯ−ＦＰによって２つのケースが識別される。行２２４ならびに２５４のＲＥＴＵＲＮ−ＮＯ−ＦＰのケースにおいては、ｒ４８、すなわち『タペストリー』のスカラ戻り値レジスタにマップされたＸ８６のレジスタＥＡＸ内に戻り値が計算されていることから、必要なアクションはない。ＲＥＴＵＲＮ−ＭＡＹＢＥ−ＦＰのケースにおいては、例外ハンドラによって保守的に、任意のスカラ結果がｒ４８内に残ることが保証され、かつ浮動小数点スタックのトップからの値が、８０ビットの拡張精度表現からｒ３１（ＲＶＤＰ）内における６４ビットの倍精度表現に縮小される。
【０２５５】
翻訳済みネイティブ・コードを実行しているときは、ディスティネーションもネイティブ・コードである場合を除いて『タペストリー』がＪＡＬＲサブプログラムのリターンを実行することはない。このインプリメンテーションにおけるセマンティック・クラス・コードが、Ｘ８６インストラクションが浮動小数点結果を返すか否か（ＲＥＴＵＲＮ−ＦＰとＲＥＴＵＲＮ−ＭＡＹＢＥ−ＦＰ）についてだけあいまいな解決をもたらし、ネイティブ・セマンティック・クラス・コードは明確（ＲＥＴＵＲＮ−ＦＰとＲＥＴＵＲＮ−ＮＯ−ＦＰ）であることから、バイナリ・トランスレータ１２４は、そのディスティネーションも翻訳される場合を除いて最終的なＸ８６のＲＥＴを翻訳しない。
【０２５６】
別の実施態様においては、第３の規約値、すなわち「遷移」値を提供することもできる。マシンは、遷移ページへ、またはそれからクロスするとき例外を取らない−−遷移呼び出し規約が、Ｘ８６呼び出し規約および『タペストリー』呼び出し規約の両方において「一致」する。通常、遷移呼び出し規約のページは、『タペストリー』ＩＳＡ値を有することになる。これらの遷移ページは、遷移処理を明示的に実行する「グルー」コードを保持している。たとえば、『タペストリー』被呼側の呼び出しを希望するＸ８６発呼側は、最初に、遷移呼び出し規約ページのグルー・ルーチンを呼び出すことができる。このグルー・ルーチンは、引数を、それらのＸ８６呼び出し規約ホームから、それらの『タペストリー』ホームにコピーし、さらに可能性としてはその他のハウスキーピングを実行する。その後グルー・ルーチンは、『タペストリー』被呼側を呼び出す。『タペストリー』被呼側のリターンはグルー・ルーチンに対してなされ、それにおいてグルー・ルーチンは、戻り値のコピーを実行し、さらにその他のハウスキーピングを実行し、その後その発呼側であるＸ８６発呼側にリターンする。
【０２５７】
当業者であれば、図２ｂおよび２ｃに示した遷移例外の各ケースをインプリメントする引数コピーについて理解されよう。一実施態様は、米国特許出願第０９／３８５，３９４号ならびに第０９／２３９，１９４号のマイクロフィッシュ付録に完全な詳細が示されており、これらのアプリケーションについては、参照を通じて本件出願に採り入れられている。
【０２５８】
セクションＩＩ、ＩＩＩ、もしくはＩＶに公開した幅広い設計のいずれかに対する変形実施態様においては、コンピュータが３ないしはそれ以上のインストラクション・セット・アーキテクチャ、および／または３ないしはそれ以上の呼び出し規約を提供することも考えられる。それぞれのアーキテクチャもしくは規約には、２ないしはそれ以上のビットによって表されるコード番号が割り当てられる。１つのコードを伴う領域もしくはページから別のコードを伴う領域もしくはページにアーキテクチャがクロスする場合には、ハードウエア・コントロールに対して適切な調整がなされるか、適切な例外ハンドラが呼び出されてコンピュータのデータ・コンテンツの調整、および／またはハードウエア例外モードの明示的なコントロールが行なわれる。
【０２５９】
Ｖ．変換のためのホット・スポットを決定するためのプロファイリング
Ａ．プロファイリングの概要
図１ａ、１ｂ、および４ａを参照すると、プロファイラ４００が、Ｘ８６モードにおいて実行されているプログラムの実行をモニタし、実行のプロファイルを表すデータのストリームをストアしていることが示されている。通常はＸ８６インストラクション・テキストが既製の市販バイナリであることから、プロファイラ４００は、Ｘ８６バイナリを修正することなく、あるいはソース・コードを専用のプロファイル可能なＸ８６インストラクション・テキストにリコンパイルすることなく動作する。プロファイラ４００に関する実行規則は、正しい情報が正しいタイミングで取り込まれるように適合されている。ホット・スポット・ディテクタ１２２は、プロファイル・データに基づいてプログラム内のホット・スポットを識別する。プロファイラ４００によって収集されたデータは、インストラクション・テキストに対するそれ以上の参照を必要とせずに、効果的なヒューリスティックの応用によりプロファイル・データのみからホット・スポットの決定を可能にする充分な記述性を有する。より詳しく述べれば、このプロファイル情報は、フェッチされ、実行されたＸ８６オブジェクト・コードのすべてのバイトを示し、推断を要する非シーケンシャル・フローを残さない。さらに、プロファイル・データは、充分に詳細であり、Ｘ８６インストラクション・テキストとの組み合わせにおいて、Ｘ８６インストラクション・テキストのプロファイル済みの任意の範囲のバイナリ翻訳を可能にする。プロファイル情報は、Ｘ８６インストラクションのデータ−コンテキスト依存もしくはマシン‐コンテキスト依存によって誘導されるあいまい性を含めて、Ｘ８６オブジェクト・テキストにおけるすべてのあいまい性を解決するための、充分に好ましい注釈をＸ８６テキストに付する。プロファイラ４００は、Ｘ８６バイナリを修正することなく、あるいはソース・コードを専用のプロファイル可能なＸ８６バイナリにリコンパイルすることなく動作する。
【０２６０】
そのもっとも一般的な動作モードにおいて、プロファイラ４００は、２段階トリガ信号（図５ａの５１６、５２２）を待ってサンプリング・イベントを開始し、続いて従来のプロファイラとは対照的に、すなわちｎ番目のイベントごとに記録を行うか、あるいはｎマイクロ秒ごとに単一のイベントの記録を行う従来のプロファイラとは対照的に、稠密なシーケンスにおいて、それが停止するまで（たとえば、プロファイル情報を収集しているバッファを使い切るまで）発生したプロファイル可能な各イベントを含めて、プロファイル可能な各イベント４１６の記録を行う。プロファイル情報は、ほとんどのコントロール・フローの移動におけるソース・アドレスならびにディスティネーション・アドレスの両方を記録する。個別のイベントを記述するエントリは、マシンの汎用レジスタ・ファイル内に収集され、その後、プロファイル・パケットとしてブロック内にストアされる。このイベントのブロック化は、メモリ・アクセスのトラフィックおよび実行のオーバーヘッドを抑える。
【０２６１】
再度図１ａおよび１ｂを参照すると、プロファイラ４００は、仮想アドレスではなく、物理アドレスによってイベントを追跡している。つまりプロファイル可能なイベント４１６は、２つの連続するインストラクションが物理的なページの境界によって分離されるとき、あるいは単一のインストラクションが仮想ページの境界をまたぐとき、仮想アドレス空間内における「直線的な」フローによって誘導されることがあり得る。（この分野において周知のように、仮想アドレス空間内において連続する２つのページは、物理メモリ内において互いに引き離されてストアされることがある。）Ｘ８６ページを物理アドレス空間内においてマネージすることによって、『タペストリー』は、エミュレートされているＸ８６ハードウエアのレベルで動作する。つまり、『タペストリー』とＸ８６オペレーティング・システムの間のインターフェースは、Ｘ８６アーキテクチャ自体と同程度に明確かつ安定している。このことは、オペレーティング・システムによってマネージされているあらゆるポリシーないしは特徴をエミュレートもしくは考慮する必要性を回避する。たとえば、『タペストリー』は、各種の仮想メモリ・ポリシー、プロセスもしくはスレッド・マネジメント、または論理リソースと物理リソースの間のマッピングを考慮する必要なく、またオペレーティング・システムの修正をまったく必要とすることなく、Ｘ８６オペレーティング・システム（あらゆるバージョンのＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）（マイクロソフト・ウィンドウズ（登録商標））、Ｍｉｃｒｏｓｏｆｔ  ＮＴ（マイクロソフトＮＴ）、もしくはＩＢＭ  ＯＳ／２、またはその他のオペレーティング・システム）を動作させることができる。第２に、Ｘ８６オペレーティング・システムが、複数のＸ８６プロセッサの間において同一の物理ページを共有している場合に、仮想ページが異なる場合であっても、そのページが自動的に共有される。したがって、単一のページが存在することになる。第３に、解放されたページがアドレス空間から削除され、その後、再利用される前に再マッピングされ、別の使用に割り当てられるという利点がある。
【０２６２】
図４ｂを参照すると、イベントが極めて細かい分類法に従って約３０のクラスに分類されている。記録されるイベントには、ジャンプ、サブプログラムＣＡＬＬ（呼び出し）およびリターン、割り込み、例外、カーネル内へのトラップ、インストラクションの解釈を変えるプロセッサ状態の変化、およびページ境界をクロスするシーケンシャル・フローが含まれる。順方向ジャンプと逆方向ジャンプ、条件付きジャンプと無条件ジャンプ、および「近い」ジャンプと「遠い」ジャンプも区別されている。
【０２６３】
図４ｇおよび４ｈを参照すると、プロファイラ４００は、プロファイリングの精密なコントロールを可能にする多数の特徴を有しており、その結果、プロファイリングのオーバーヘッドを、プロファイル解析が望まれる実行モードのみに制限できることが示されている。
【０２６４】
図５ａおよび５ｂを参照すると、各Ｘ８６インストラクションがコンバータ（図１ｃの１３６）によってデコードされるとき、プロファイル・エントリが６４ビットのプロセッサ・レジスタ５９４内に構築されることが示されている。インストラクションの実行間は、レジスタ５９４が修正され、上書きされることがあり、特にインストラクションが『タペストリー』オペレーティング・システム３１２内にトラップしている場合にはそれが見られる。インストラクションの完了時には、プロファイラ４００が、プロファイル・エントリ・プロセッサ・レジスタの内容を汎用レジスタ内に取り込むことを選択する場合もある。
【０２６５】
ホット・スポット・ディテクタ１２２は、プロファイル・パケットのセット内において頻繁に繰り返されるアドレスを認識する。ホット・スポットが認識されると、プロファイル内のそれを囲むエントリが、繰り返し発生するアドレスとの相関において、頻繁に実行されるコードの領域および物理ページを通るパスを（物理アドレスによって）示す。ホット・スポット・ディテクタ１２２は、この情報をＴＡＸｉトランスレータ１２４に渡し、それにおいてこのバイナリの翻訳が行なわれる。
【０２６６】
Ｂ．プロファイル可能事象および事象コード
図４ｂを参照すると、プロファイラ４００は、表内にリストした約３０のイベントのクラスを認識する。各イベントのクラスは、５ビットの数として表された、０から３１までの番号に対応するコード４０２を有している。イベントのクラスは、設計をサポートするために必要な最少情報、および厳密に言えば必要ないが、ホット・スポット・ディテクタ１２２がより好ましい結果に到達できる追加のヒントをもたらす追加の情報をともに提供するべく選択されている。
【０２６７】
この表の上側半分４１０は、（一実施態様においては）ソフトウエアによって生じるイベントをリストしており、下側半分４０４は、ハードウエアによって生じるイベントを含んでいる。下側半分についてまず説明する。
【０２６８】
表の下側半分４０４に含まれる、その最上位ビットを「１」とする１６のエントリは、コンバータ１３６によって惹き起こされるイベントである。各Ｘ８６インストラクションがデコードされ実行されると、それに従って下側半分４０４に列挙されているイベントが認識される。これらのイベント４０４が生じたときにプロファイラ４００がアクティブであれば、プロファイル・エントリが汎用レジスタ内に記録される。表の下側半分に含まれるイベントは、２つのクラスに分けられる：すなわち、コンバータ１３６内によって実行されるコントロールの「近い」移動、および物理ページ・フレームの境界をまたぐ実行のシーケンシャル・フローである。
【０２６９】
プロファイラ４００は、ＩＰ相対移動、サブルーチン呼び出しならびにリターン、ポインタを介したジャンプ、および多くの割り込みによって誘導される移動を含め、コントロールの移動を捕捉する。プロファイラ４００が、その物理アドレス空間においてマシンを見ている場合であっても、Ｘ８６インストラクション内のＰＣ相対変位の符号ビットを観察することによって、ＰＣ相対ジャンプに関して順方向と逆方向のジャンプの間を区別することは可能である。ブランチが分類されると、そのブランチ用のプロファイル・エントリ内にストアされたイベント・コード４０２を用いてその分類がエンコーディングされる。イベント・コード１．００００、１．０００１、１．００１０、１．００１１、１．０１００、１．０１０１、および１．０１１１によって示したように、順方向条件付きブランチ、逆方向条件付きブランチ、３つに分けられた条件付きジャンプの述部等を個別に分類するイベント・コード４０２が存在する。
【０２７０】
イベント・コード１．１１００については、セクションＶＩＩＩ．Ｂにおいて説明する。
イベント・コード１．１１１０（４０６）は、注目すべき事項を伴わない単純なシーケンシャル・インストラクションを示す。イベント・コード１．１１１１（４０８）は、物理ページの最後のバイト内で終わっているか、あるいは仮想アドレス空間内のページの境界をまたいでいる（かつ、物理アドレス空間内において２つの離れた部分に分けられている可能性のある）インストラクションを示している。
【０２７１】
表の上側半分４１０の、最上位ビットを「０」とする上位１６のエントリは、ソフトウエア・エミュレータ３１６内において扱われるイベントであり、エミュレーション・ハンドラの完了時に『タペストリー』ＲＥＦ（例外からのリターン）インストラクションの実行間に記録される。ＲＦＥは、同期例外、（たとえばページ違反またはＮａＮ生成浮動小数点例外）、非同期外部割り込み、あるいはハードウエア・コンバータ１３６内においてインプリメントされない極めて複雑なＸ８６インストラクションのシミュレーションのためのオペレーティング・システム内へのトラップの後に、『タペストリー』オペレーティング・システム３１２からユーザ・プログラムにリターンする『タペストリー』インストラクションである。概して表の上側半分に含まれるイベントは４つのクラスに分けられる：すなわち（１）エミュレータ３１６内において実行される「遠い」コントロール移動インストラクション、（２）エミュレータ３１６において実行されたＸ８６実行コンテキスト（たとえばＦＲＳＴＯＲ）を更新するインストラクション、（３）Ｘ８６内部の、同期割り込みの引き渡し、および（４）Ｘ８６外部の、非同期割り込みの引き渡しである。一般に、上側半分のイベント・コードは、ソフトウエアに対してのみ知らされる。
【０２７２】
各ＲＦＥインストラクションは４ビットのイミディエート・フィールド（図５ｂの５８８）を有しており、その中にリターン元のハンドラを呼び出したイベントに関連付けされたイベント・コード４０２の下位４ビットがストアされる。ＲＦＥイベント・クラスの５番目のビットは、「０」として再構成（後述のセクションＶ．Ｇを参照されたい）されるが、「０」が明示的にストアされることはない。ＲＦＥが実行されるとき、ＲＦＥからＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）（図４ｈおよび５ｂの４８６、４８７）およびプロファイル情報（後述するセクションＶ．Ｆを参照されたい）を収集する一時プロセッサ・レジスタ（図５ｂの５９４）にイベント・コードがコピーされ、ハードウエア・コンバータ１３６によって供給されたイベント・コードが上書きされる。プロファイル・エントリを収集する場合には、このイベント・コードがレジスタ５９４から汎用レジスタにコピーされる。このメカニズムによって、ソフトウエアからプロファイラ４００のハードウエア５１０に対して、ソフトウエア・エミュレータ３１６内においてプロファイル可能なインストラクションが実行されたこと、あるいはソフトウエア・エミュレータ３１６内において実行されたプロファイル可能でないインストラクションがページ・クロスを生じ、その理由に関してプロファイリングするべきであることを通知することができる。（Ｘ８６の重要度を伴わないＲＦＥは、このフィールドをゼロにセットし、それによってハードウエアによるプロファイル・エントリのストアが防止される；後述するコード０．００００の説明を参照されたい。）
【０２７３】
「プロファイル可能」列（図４ｂの４１６）は、そのイベント・コードをプロファイル・パケットに含めるべきか否かを指定する。プロファイル可能でないイベントは、それが生じてもプロファイラ４００がなにもアクションを取らないだけに過ぎない。「開始パケット」列４１８は、このイベント・コード（図４ｂの４０２）のイベントによる新しいプロファイル・パケットの収集の開始が可能か否か、あるいはこのイベント・クラスが最初のエントリより後に限り記録されることになるかについての指定を行う。「開始パケット」４１８については、後述するセクションＶ．ＦおよびＶ．Ｇにおいて、図４ｃのＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ、および図５ａのプロファイラ状態マシン５１０との関連から詳細に説明する。「プローブ可能イベント」列６１０および「プローブ・イベント・ビット」列６１２は、後述するセクションＶＩ「プロービング」との関連から説明する。「開始パケット」４１８、「プロファイル可能イベント」４１６、および「プローブ可能イベント」６１０のプロパティは、ＰＬＡ（プログラマブル・ロジック・アレイ）６５０によって演算され、それについては後述のセクションＶＩ．ＣおよびＶＩ．Ｄにおいて説明する。
【０２７４】
イベント・コード０．００００、０．０００１、０．００１０、および０．００１１については、数パラグラフ後に説明する。
イベント・コード０．０１００は、ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）（図４ｈおよび５ｂの４８６、４８７）のカレント値の上から単純にストアされ、マシンのカレント状態に、それ以上の効果がもたらされることはない。この上書きの効果は、以前にストアされたイベント・コードのクリアであり、ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）４８６、４８７の現在の内容によってトリガされる効果の可能性をまったく伴うことなく、コンバータ１３６がリスタートできることを保証する。たとえば、コンバータ１３６がプローブ例外を取り（後述のセクションＶＩを参照されたい）、かつ翻訳済みＴＡＸｉコードの最初のインストラクションが、（翻訳済みＴＡＸｉコード内における実行の再開を可能にするのではなく）コントロールをコンバータ１３６に返すことによって処理されるべき例外を生成する場合、例外ハンドラは、イベント・コードのイミディエート・フィールドが０．０１００となっているＲＦＥを返すことになる。これは、コンバータ１３６が、ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）４８６、４８７内に保留されている、最初にプローブ例外をトリガしたイベント・コードを伴ってリスタートしないことを確実にする。
【０２７５】
イベント・コード０．０１０１は、エミュレーションが、それにより実行コンテキストを変化、たとえば浮動小数点レジスタもしくは浮動小数点スタックのトップの満／空状態を変化させるインストラクションを完了したことを示す。これは、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ（図４ｃの４３０および後述するセクションＶ．Ｃを参照されたい）の記録にこの状態を強制的に取り込ませる。
【０２７６】
イベント・コード０．０１１０、０．０１１１、０．１０００、０．１００１のイベントは、コントロール移動インストラクションであり、「遠い」呼び出し、「遠い」ジャンプ、「遠い」リターン、およびＸ８６割り込みリターン等のように、ハードウエア・コンバータ１３４、１３６に代えて、エミュレーション・ソフトウエアにおいてインプリメントする方が有利なインストラクションである。これらの「遠い」移動に関するイベント・コード分類は、ＩＰ相対の「近い」ジャンプ（イベント・コード１．００００〜１．０１０１）とは対照的に、順方向と逆方向のジャンプを区別しない。
【０２７７】
イベント・コード０．１０１０を伴うＲＦＥは、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｓｐｅｃｉａｌ＿ｏｐｃｏｄｅ（ＴＡＸｉ＿コントロール．特殊＿オペコード）４７４（ビット＜５０：４４＞）を、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ（図４ｃの４３０）のｓｐｅｃｉａｌ＿ｏｐｃｏｄｅ（特殊＿オペコード）４３４フィールド（図４ｃのビット＜５０：４３＞）に取り込ませる。これは、ソフトウエアによって完全にマネージすることができる新しい７ビットのイベント・コードのスペースを開始する。
【０２７８】
イベント・コード０．１０１１は、例外ハンドラからのＲＦＥに使用され、カレント・プロファイル・パケットを強制的に中止させる。『タペストリー』ハードウエアは、ＲＦＥイミディエート・フィールド内のこのイベント・コードを認識し、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）（図４ｈおよび５ａの４８２）をクリアすることによってこのプロファイル・パケットを中止する。たとえば、ＴＡＸｉコードに対するプローブのＲＦＥが成功した後にこのイベント・コードを使用して、進行中のすべてのパケットを中止することができる。これは、ＴＡＸｉコードがプロファイル・パケットのシーケンシャル区間におけるブレークを表しているからであり、そのパケットを継続することが、不良な態様を招く結果になるからである。同様に、Ｘ８６シングル−ステップ・モードがイネーブルのとき、エミュレータ３１６からのＲＦＥは、イベント・コード０．１０１１を使用して進行中のパケットを中止する。プロファイリングは、次のプロファイル・タイマのタイムアウトから再開する。
【０２７９】
イベント・コード０．１１００、０．１１０１、０．１１１０、および０．１１１１は、Ｘ８６エミュレータ３１６からのＸ８６例外の引き渡しに関連する２組のＲＦＥイベント・コードを提供する。これによってソフトウエアは、ＴＡＸｉの使用に関する異なるカテゴリに例外をグループ化することができる。割り込みを２グループに分類することによって、さらに、プローブ可能なイベントとプローブ可能でないイベント（後述のセクションＶＩを参照されたい）に分類することによって、これらの４つのイベント・コードは、ソフトウエアに関する基礎とするコントロール・フレームワークを提供する。この分類は、Ｘ８６が、単一の統一された「割り込み」メカニズムを通じてすべての例外、外部割り込み、およびトラップを一箇所に集中させるという事実を利用している。
【０２８０】
イベント・コード０．００００、０．０００１、０．００１０、および０．００１１（４１２）のオペコードは、上側半分４１０内の残りといくぶん異なり、それが「再使用イベント・コード」列４１４に現れている。これらのクラスに含まれるイベント（つまり、イベント・コードのイミディエート・フィールド内にこれらの４ビットのコードを有するＲＦＥインストラクション）は、ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）（図４ｈの４８６、４８７）および関連する信号の更新を行わない；単純に、次のＸ８６インストラクションに関しても、以前にラッチしたイベント・コードの存続が許可される。たとえば、イベント・コード０．００００は、「トランスペアレントな」例外、すなわちプロファイル内に記録されない例外用である。具体的な例を述べれば、ＴＬＢミス例外、純粋に『タペストリー』割り込みに関する割り込みサービス・ルーチン、およびＸ８６プログラムの進行と無関係なその他の例外に関するハンドラのエンドにおいてＲＦＥは、イベント・コード０．００００（イミディエート・フィールド内の明示的な４つのゼロ、および想定される上位桁のゼロ）を有し、それによってハードウエアが、プロファイル・エントリのストアを伴うことなく割り込みのあったロケーションにおいて再開される。これらのイベントは、アーキテクチャ上、現在実行中のプロセスに対して不可視に維持され、そのプロセス内のいずれのホット・スポットにも相関されず、したがってイベントの記録についても意識上の存在となる。
【０２８１】
イベント・コード０．０００１は、ソフトウエアＸ８６エミュレータ３１６内において使用される。ハードウエア・コンバータ１３６内においてインプリメントされない非常に複雑なＸ８６のＣＩＳＣインストラクションは、それに代えて、当該インストラクションがエミュレートされるソフトウエアへのトラップとしてインプリメントされる。Ｘ８６エミュレータ３１６がこのインストラクションを完了すると、それがイベント・コード０．０００１を伴うＲＦＥを使用してリターンし、「ここでは何も特別なことが生じなかった」という内容を示し、その結果、プロファイル・エントリの収集は行なわれない（エミュレートされたインストラクションがページをまたいでいた場合を除く）。
【０２８２】
列４１４に示す「再使用イベント・コード」特徴の別の用途は、複雑なインストラクション、すなわち、ソフトウエアにおいてエミュレートされ、コントロール・フローに影響をまったく及ぼさない、たとえば文字列を比較するインストラクション等のインストラクションの場合を考えることによって説明することができる。この種の複雑なインストラクションが現れたとき、コンバータ１３６、セクションＶ．Ｆにおいて後述する図５ｂの非イベント回路５７８、およびＭＵＸ
５８０は、予備的にインストラクションのデコードを行い、予備的なイベント・コード（図５ｂの５８２、５９２）：すなわち、そのインストラクションがページ・ブレークをまたいでいるか否かによって、デフォルトのイベント・コード１．１１１０（４０６）もしくは新規ページのイベント・コード１．１１１１（４０８）を供給する。（一部の実施態様においては、コンバータ１３６が、それに加えて「遠い」コントロール移動、「遠い」ＣＡＬＬ（呼び出し）に関するイベント・コード、すなわちコード０．１０００；「遠い」ＪＭＰ（ジャンプ）、すなわちコード０．１００１；「遠い」ＲＥＴ（リターン）、すなわちコード０．０１１０；ＩＲＥＴ、すなわちコード０．０１１１を供給する。）この予備的なイベント・コード５８２、５９２は、ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）４８６、４８７内に、Ｘ８６エミュレータ３１６へのトラップの一部としてラッチされる。Ｘ８６エミュレータ３１６がこの複雑なインストラクションを完了し、ＲＦＥによりコンバータ１３６に戻るとき、ＲＦＥは、そのイベント・コードのイミディエート・フィールド（図５ｂの５８８）として単純なＸ８６インストラクション完了イベント・コード０．０００１を有することになる。イベント・コード０．０００１は「再使用イベント・コード」プロパティ４１４を有していることから、ＲＦＥのイミディエート・フィールドからのこのイベント・コードは、単純に破棄され、ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）４８６、４８７内の予備的なイベント・コード５８２、５９２はそのまま残される。その後、例外からのリターン時に、この予備的なイベント・コードを伴うイベントがプロファイル・パケットに追加される。
【０２８３】
イベント・コード０．００１０および０．００１１は、プローブ例外ハンドラ（後述のセクションＶＩを参照されたい）からのＲＦＥ内において使用される。プローブが失敗すると、プローブのそのクラスがディセーブルになる。プロービングおよびプロファイリングが相互に排他であることから（後述のセクションＶＩ．Ｇを参照されたい）、プローブ例外が存在するとき、プロファイリングはアクティブではない。つまり、これらのイベント・コードは、プロファイル・パケット内にストアされることはないが、後述するセクションＶＩ．Ｄに示すように、プローバ６００をコントロールするために存在する。
【０２８４】
Ｃ．プロファイル済みイベントに関するストレージ・フォーム
図４ａ、４ｃ、および４ｄを参照すると、プロファイル・イベントがパケット４２０と呼ばれるグループ内に収集され、ストアされることが示されている。各プロファイル・パケット４２０は、当初レジスタＲ１６〜Ｒ３１に収集され、その後メモリ内にストアされる、エントリのプログラム可能な番号を保持している。通常の使用においては、１パケット当たり１６のエントリがあり、６４ビットのタイムスタンプから始まり、１４のイベント・エントリ４３０、４４０が続き、タイムスタンプで終了する。それぞれのイベントは、６４ビットのエントリとして記述され、次に示す２つのフォームのいずれかとなる：すなわち、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０、またはＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０になる。パケットの最初のエントリは、常にＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０になり、それによって、プロファイリングが開始したポイント、すなわち概念的に２つのＸ８６インストラクションの間となるポイントにおけるプロセッサ・コンテキストの比較的完全なスナップショットが与えられる。続くエントリは、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）フォームもしくはＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）フォームのいずれにもなり得る。Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０は、セグメント間（つまり「近い」）コントロール移動を記述し、移動のソースおよびディスティネーションを提供する。Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０においては、Ｘ８６のプロセッサ・コンテキストの残部を、もっとも最近のＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０にから開始してプロセッサ・コンテキストを推論することによって、つまり当該Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）とＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）移動の間に介在するインストラクションを解釈することによって決定することができる。プロファイル内には充分な情報が存在し、その結果、バイナリ・トランスレータ１２４は、それらのインストラクションによって消費ないしは操作がなされた実際のデータについての知識を必要とすることなく、介在するこれらのインストラクションのオペコードのみを参照することによって、そのコンテキストを推論することができる。Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０を発行するための規則は、この不変系を保存する：すなわち、プロセッサ・コンテキストは、プロファイルと介在するインストラクションのオペコードの組み合わせから推論され、当該インストラクションによって消費され、あるいは操作されたデータに対する参照を必要としない。Ｘ８６インストラクションの実行が、Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０内に現れない形でプロセッサ・コンテキスト・ビットもしくはメモリ・データに依存する場合には、プロファイラ４００は、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０を発行する。つまり、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリは、ＴＡＸｉバイナリ・トランスレータ１２４が、ネイティブ『タペストリー』コードを生成するためにＸ８６インストラクション・ストリームにおけるあいまい性を解決する上で充分な情報を有することを保証する。
【０２８５】
図４ｃを参照すると、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０は、Ｘ８６インストラクション境界のコンテキストのスナップショットを記述し、事実上、Ｘ８６インストラクションの実行としてコンテキストが開始されようとしていることが示されている。
【０２８６】
Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０のビット＜６３：６０＞４３１は、オール・ゼロであり、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０とＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０を区別している。（ｄｏｎｅ＿ｌｅｎｇｔｈ（終了＿長さ）４４１の説明の中で示すように、後述する図４ｄのビット＜６３：６０＞、すなわちＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０内の最初の４ビットは、インストラクションの長さを記録し、長さゼロのインストラクションは存在しない。つまり、フィールド４３１内のゼロ値は、明確にＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０であることを示している。）
【０２８７】
ビット＜５９：５１＞４３２、４３３、およびビット＜４２：３２＞４３５は、インストラクションの境界において（ｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）４３８およびｎｅｘｔ＿ｂｙｔｅ（次の＿バイト）４３９、すなわちビット＜２７：００＞に記述されているインストラクションの開始の前に）、Ｘ８６のプロセッサ・モードのコンテキストを取り込む。Ｘ８６インストラクションのビットは、インストラクションのアクションを完全には指定しない；Ｘ８６アーキテクチャが、プロセッサ・コンテキストおよびインストラクションのオペレーションを定義する多数の状態ビットを定義している。これらのビットは、オペランドのサイズ（与えられた幅のフォームのインストラクションが動作するビット数は１６ビットか、あるいは３２ビットか）、スタック・サイズ（ＰＵＳＨ（プッシュ）またはＰＯＰ（ポップ）インストラクションが更新するスタック・ポインタは１６ビットか、あるいは３２ビットか）、アドレス・サイズ（アドレスは１６ビットか、あるいは３２ビットか）、プロセッサはＶ８６モードか否か、物理的アドレシングまたは仮想アドレシングのいずれかといったことについての決定、および浮動小数点スタック・ポインタ、ならびに浮動小数点レジスタの満／空状態についての決定を行う。Ｘ８６は、これらのビットをコードならびにスタック・セグメント記述子の場所の周囲、ＥＦＬＡＧＳレジスタ、浮動小数点ステータス・ワード、浮動小数点タグ・ワード、およびその他の場所に分散させる。『タペストリー』マシンは、これらのビットを、実際にマシンをコントロールするＸ８６構造の類似物にストアする；Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０が取り込まれると、これらのビットのスナップショットが、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０のビット＜５９：５１＞４３２、４３３および＜４２：３２＞４３５に取り込まれる。
【０２８８】
ビット＜５９：５６＞４３２は、オペランド−サイズ／アドレス−サイズ・モード（Ｘ８６コード・セグメント記述子のＤビット内にエンコードされている）およびスタック・アドレス・サイズ（スタック・セグメント記述子のＢビット内にエンコードされている）のカレント状態を示す。ビット＜５９＞、すなわち「ｃ１ｓ１」は、Ｘ８６が３２ビット−コード／３２ビット−スタック・モードであることを示す。ビット＜５８＞、すなわち「ｃ１ｓ０」は、Ｘ８６が３２ビット−コード／１６ビット‐スタック・モードであることを示す。ビット＜５７＞、すなわち「ｃ０ｓ１」は、Ｘ８６が１６ビット−コード／３２ビット−スタック・モードであることを示す。ビット＜５６＞、すなわち「ｃ０ｓ０」は、Ｘ８６が１６ビット−コード／１６ビット−スタック・モードであることを示す。（ＤおよびＢビットは、Ｘ８６インストラクション・セットにあいまい性をもたらす。たとえば、インストラクション・ストリームの所定の９バイトのシーケンスは、ＤおよびＢビットの値に応じて、１つの実行に関する単一のインストラクションとして、また次の完全に異なる３つのインストラクションとしての解釈が可能である。このあいまい性を共有するアーキテクチャはほとんどない。）このように、ＤおよびＢモードによって可能になる４つの組み合わせのうちの任意の１つの組み合わせをプロファイルするか否かは、個別にコントロールすることができる。
【０２８９】
フィールド４３３内のビット＜５５＞、すなわち「ｐｎｚ」は、Ｘ８６が非リング−ゼロ（特権のない）モードにあることを示す。ビット＜５４＞、すなわち「ｐｅｚ」は、Ｘ８６がリング‐ゼロ（特権のある）モードにあることを示す。ビット＜５３＞、＜５２＞、および＜５１＞、すなわち「ｖ８６」「ｒｅａｌ」「ｓｍｍ」は、それぞれＸ８６が、Ｘ８６システム・フラグ・ビットによって示されるように、仮想８０８６、リアル、およびシステム・マネジメント実行モードにあることを示す。
【０２９０】
ビット＜５０：４３＞、すなわちｓｐｅｃｉａｌ＿ｏｐｃｏｄｅ（特殊＿オペコード）４３４は、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリが生成されると必ず、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｓｐｅｃｉａｌ＿ｏｐｃｏｄｅ（ＴＡＸｉ＿コントロール．特殊＿オペコード）４７４から満たされる。これらのビットは、イベント・コード０．１０１０と特に関係がある。
【０２９１】
フィールド４３５内のビット＜４２：４０＞は、浮動小数点スタックのトップのスタック・ポインタである。ビット＜３９：３２＞は、浮動小数点レジスタの満／空ビットである。
【０２９２】
ｅｖｅｎｔ＿ｃｏｄｅ（イベント・コード）フィールド４３６、すなわちビット＜３１：２８＞は、もっとも最近実行されたＲＦＥまたはコンバータ・イベント・コードから（図４ｂから）のイベント・コード４０２の下位４ビットを含む。Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）のｅｖｅｎｔ＿ｃｏｄｅ（イベント・コード）４３６の４ビットは、図４ｂに示したイベント・コード４０２の下位４ビットである。上位ビットは、これらの４ビットから、後述するセクションＶ．Ｇに説明する方法によって導かれる。それにおいて詳細を説明するようにＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０は、図４ｂに示した表の上側半分４１０に含まれる１６のイベントの任意の１つ、あるいは当該表に含まれる「開始パケット」プロパティ４１８を含む任意のイベントを記述することができる。
【０２９３】
ビット＜２７：００＞は、次のＸ８６インストラクション、すなわちＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）コンテキストがスナップショットされた時点において実行されようとしていたインストラクションを記述する。ｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）フィールド４３８、すなわちビット＜２７：１２＞は、物理的なページ・フレーム番号を、ｎｅｘｔ＿ｂｙｔｅ（次の＿バイト）フィールド４３９、すなわちビット＜１１：００＞は、当該ページ内における１２ビットのオフセットをそれぞれ提供する。
【０２９４】
図４ｄを参照すると、Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０が完全なＸ８６セグメント間の「近い」コントロール移動インストラクションを記述していることが示されている。Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０のビット＜６３：６０＞４４１は、この移動インストラクションの長さを記述する。長さ４４１の値は、１から１５までとなる（もっとも短いＸ８６インストラクションは１バイトであり、もっとも長いインストラクションは１５バイトである）。長さゼロを生じることがあり得ないことから、これらの４ビット４３１が、Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０とＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０を明確に区別する。
【０２９５】
Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）移動のソース・エンドにおけるインストラクションは、インストラクションが開始するページ・フレーム番号、インストラクションが終了するページ・フレーム番号、インストラクションが開始するページ内のバイト・オフセット、およびインストラクションの長さによって記述される。インストラクションの開始に対応するページ・フレーム番号は、Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０内に明示的に表されないが、プロファイル・パケット内の直前のエントリからのｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）４３８、４４８として継承される（プロファイル・パケットが常にＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０を伴って開始し、Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０が最初のエントリとならなかったことを想起されたい）。インストラクションの最後のバイトがあるページ・フレームは、ｄｏｎｅ＿ｆｒａｍｅ（終了＿フレーム）フィールド４４４内、すなわちビット＜５９：４４＞に表される。これら２つのページ・フレーム番号は、インストラクションがページ境界をまたぐ場合には異なったものとなる。インストラクションが開始するページ内のバイト・オフセットは、ｄｏｎｅ＿ｂｙｔｅ（終了＿バイト）フィールド４４５内、すなわちビット＜４３：３２＞に表される。長さはｄｏｎｅ＿ｌｅｎｇｔｈ（終了＿長さ）フィールド４４１内、すなわちビット＜６３：６０＞に記録される。したがって、ソース・インストラクションのエンドは、（（（ｄｏｎｅ＿ｂｙｔｅ（終了＿バイト）４４５＋ｄｏｎｅ＿ｌｅｎｇｔｈ（終了＿長さ）４４１）−１）ｍｏｄ  ４０９６）を演算することによって得られるバイトから知ることができる（Ｘ８６ページのサイズが４０９６であることからこの値が用いられている）。
【０２９６】
Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）移動のディスティネーションは、前述したＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０におけるｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）フィールド４３８およびｎｅｘｔ＿ｂｙｔｅ（次の＿バイト）フィールド４３９、すなわちビット＜２７：００＞と同じ態様に従って、ビット＜２７：００＞のｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）フィールド４４８およびｎｅｘｔ＿ｂｙｔｅ（次の＿バイト）フィールド４４９によって記述される。
【０２９７】
ｅｖｅｎｔ＿ｃｏｄｅ（イベント・コード）フィールド４４６、すなわちビット＜３１：２８＞は、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０のｅｖｅｎｔ＿ｃｏｄｅ（イベント・コード）４３６に相当するイベント・コードを含んでいる。Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）のｅｖｅｎｔ＿ｃｏｄｅ（イベント・コード）４４６は、図４ｂに示した表の下側半分の下位４ビットである；先行「１」が仮定されている。（つまり、Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０は図４ｂの表の下側半分４０４に含まれる１６のイベントだけを記述することができる。）
【０２９８】
以上のように、すべての物理ページは、その実行順序に従って、連続するプロファイル・エントリ内に記述される。明示的なブランチを理由として実行が１つの物理ページから別のページにクロスする場合には、そのブランチがＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０によって示される。ページの境界をまたぐ仮想アドレス空間内におけるシーケンシャルな実行を原因として実行が１つの物理ページから別のページにクロスする場合には、ページのエンドにおいて終了するインストラクションと次に開始するインストラクションの間、あるいはページ・ブレークをまたぐインストラクションと次のページの最初の完全なインストラクションの間のいずれかにおいてＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０が生成される。それとは異なり、コントロールがＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）イベントを伴わずにページに入った場合には、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ４３０がそのページへの到達を記述する。ともにこれらに規則は、バイナリ・テキストを参照することなく、実行のフローの再トレース、およびホット・スポットの検出を可能にする充分な情報がプロファイル・エントリ内にあることを保証する。ホット・スポット・ディテクタがインストラクション・テキストを調べることなく動作可能になることは、キャッシュのポーリングを必要とすることなくそれが動作できることを意味する。さらに、すべての物理ページが記述されるという保証は、Ｘ８６が仮想アドレス空間からそのインストラクションを実行している場合であっても、物理メモリ内に存在するものとしてプログラムのプロファイリングを可能にする。この保証は、プログラム・テキストを調べて、隣接関係を推測することを必要とせずに、物理メモリを介してコントロール・フローをトレースできることを保証する。
【０２９９】
Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０に関しては、Ｘ８６プロセッサ・コンテキストを、ディスティネーション・インストラクションへの到達時に、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）４３０内にエンコーディングされたコンテキスト４３２、４３３、４３５から開始し、介在するインストラクションのオペコードを通って順方向のトレースを行い、更新を取り込むことによって、直前のＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０のフィールド４３２、４３３（ビット＜５９：５１＞）および４３５（ビット＜４２：３２＞）から推断することができる。
【０３００】
Ｄ．特定の例示事象（ページトラッドル）のために収集されたプロファイル情報
図４ｅおよび４ｆを参照して、インストラクションがページの境界をまたぐ２つのケースについて考える。図４ｅおよび４ｆは仮想アドレス空間を表しているが、プロファイラ４００は、物理アドレス空間内において動作する。
【０３０１】
図４ｅにおけるインストラクション４５０は、ページ４５２と４５３の間のページ境界４５１をまたぐが、コントロールを移動するインストラクションではない。ページ‐クロッシングは、シーケンシャル・イベント・コード、すなわちコード１．１１１０（図４ｂの４０６）を伴うＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０、４５４によって記述される。このインストラクションは、直前のプロファイル・エントリ４５５がＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）４３０もしくはＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４４０のいずれであるかによらず、そのエントリのｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）ビット（ビット＜２７：１２＞）４３８、４４８、４５２ａによって識別されるページ４５２内において始まる。インストラクションは、カレントＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４５４のｄｏｎｅ＿ｂｙｔｅ（終了＿バイト）４４５（ビット＜４３：３２＞）によって示されるオフセット・バイトから始まる。このインストラクションの長さは、カレントＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４５４のｄｏｎｅ＿ｌｅｎｇｔｈ（終了＿長さ）４４１（ビット＜６３：６０＞）によって示される。またこのインストラクションの最後のバイトは、カレントＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４５４のｄｏｎｅ＿ｆｒａｍｅ（終了＿フレーム）４４４、４５３ａによって示されるページ４５３内となる。インストラクションのこの最後のバイトは、バイト（（（ｄｏｎｅ＿ｂｙｔｅ（終了＿バイト）４４５（ビット＜４３：３２＞）＋ｄｏｎｅ＿ｌｅｎｇｔｈ（終了＿長さ）４４１（ビット＜６３：６０＞）−１）ｍｏｄ  ４０９６））となり、これは必然的に（（ｎｅｘｔ＿ｂｙｔｅ（次の＿バイト）４４９（ビット＜１１：００＞）−１）ｍｏｄ  ４０９６）に一致する。次のシーケンシャル・インストラクション４５６は、カレントＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４４０、４５４のｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）４４８、４５６ａ（ビット＜２７：１２＞）に示されるようにページ４５３内となり、ｎｅｘｔ＿ｂｙｔｅ（次の＿バイト）４４９（ビット＜１１：００＞）から始まる。インストラクションの最大長４４１（１５バイト）がページの長さより短いことから、図４ｅに示したインストラクションがページをまたぐ場合においては、直前のプロファイル・エントリ４５５のｄｏｎｅ＿ｆｒａｍｅ（終了＿フレーム）４５３ａが、必然的にカレントＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４５４のＮｅｘｔ＿Ｆｒａｍｅ（次の＿フレーム）４５６ａに等しくなる。
【０３０２】
インストラクション４５０がページ４５２内に完全に含まれ、ページ境界４５１の直上において終了し、かつそれがコントロールの移動でない場合（またはシーケンシャルに失敗したコントロールの移動である場合）には、ｄｏｎｅ＿ｆｒａｍｅ（終了＿フレーム）４５３ａがページ４５２をポイントし、ｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）４５６ａが続くページをポイントするＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４４０、４５４が生成される。
【０３０３】
図４ｆを参照し、別のインストラクション、すなわちソース・インストラクション自体がコーディングされた２つのページ４５２、４５３、およびディスティネーション・インストラクション４５７が始まるページ４５８の３つのページにわたる、ページをまたぎ、コントロールの移動のあるインストラクション４５０について考える。カレントＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４５４のイベント・コード４４６は、コントロール移動の特性、すなわちコード１．００００〜１．１１００（図４ｂ）を記録する。図４ｅに示したシーケンス・フローの場合と同様に、この移動のあるインストラクション４５０も、直前のプロファイル・エントリ４５５のｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）フィールド４３８、４４８、４５２ａによって示されるようにページ４５２内において、カレント・プロファイル・エントリ４５５のｎｅｘｔ＿ｂｙｔｅ（次の＿バイト）４３９（ビット＜４３：３２＞）によって示されるバイト・オフセットから始まる。インストラクション４５０の長さは、カレントＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４５４のｄｏｎｅ＿ｌｅｎｇｔｈ（終了＿長さ）４４１内に示されている。インストラクション４５０は、カレントＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０、４５４のｄｏｎｅ＿ｆｒａｍｅ（終了＿フレーム）（ビット＜５９：４４＞）フィールド４４４、４５３ａによって示されるように、ページ４５３内の、それぞれカレントＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０、４５４から得られたバイト（（ｄｏｎｅ＿ｂｙｔｅ（終了＿バイト）４４５（ビット＜４３：３２＞）＋ｄｏｎｅ＿ｌｅｎｇｔｈ（終了＿長さ）４４１（ビット＜６３：６０＞）−１）ｍｏｄ  ４０９６）において終了する。ディスティネーション・インストラクション４５７は、カレントＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４５４のｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）４４８、４５８ａ（ビット＜２７：１２＞）によって示されるようにページ４５８において、ｎｅｘｔ＿ｂｙｔｅ（次の＿バイト）４４９（ビット＜１１：００＞）から始まる。この場合、ページをまたぐブランチ４５０については、カレントＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４５４のｄｏｎｅ＿ｆｒａｍｅ（終了＿フレーム）４４４、４５３ａ（ビット＜５９：４４＞）が、ページの渡りがあることから直前のエントリのｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）４３８、４４８と一致しない。
【０３０４】
プロファイル・パケットがコントロール移動インストラクション上において開始された場合、最初のエントリは、その移動インストラクションのターゲットをポイントするＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０になる。
【０３０５】
図４ａを参照すると、Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０およびＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０が、もっとも複雑なコントロール・フローにおいても、コンパクトかつ効果的な記述を提供し、ホット・スポット・ディテクタ１２２およびＴＡＸｉバイナリ・トランスレータ１２４に対して、それら２つのタスクに有用でない過剰な情報により圧倒することなく、その機能を可能にする充分な情報を提供している。ここで、ホット・スポット・ディテクタ１２２およびＴＡＸｉバイナリ・トランスレータ１２４の要件がいくぶん異なり、そのためプロファイル内の情報がこれら２つの要件のスーパーセットを構成するべく設計されていることに注意されたい。
【０３０６】
一部の実施態様においては、最初のインストラクションの最初のバイトから最後のインストラクションの最後のバイトまでを範囲として記録すると望ましいことがある。この方法における範囲の記録は、特にアーキテクチャが固定長のインストラクションを有している場合に望ましい。
【０３０７】
Ｅ．プロファイラを制御する制御レジスタ
図４ｇを参照すると、ＴＡＸｉハードウエア・システムは、ＴＡＸｉコントロール４６０と呼ばれる６４ビットのレジスタによってコントロールされる。このシステムの多くがプロファイルによってドライブされることから、プロファイリングに関する精密なコントロールは、ＴＡＸｉシステム全体の精密なコントロールを提供することになる。各種のビットが、ＴＡＸｉメカニズムの個別の部分のイネーブルならびにディセーブル、特定の評価基準に一致もしくは不一致のコードに関するプロファイリングのイネーブルならびにディセーブル、および特定のイベントのレートをコントロールするタイマ・コントロールを可能にする。プロファイリングがディセーブルされるあらゆるコード領域においては、ＴＡＸｉリソースが静止し、オーバーヘッドがもたらされない。
【０３０８】
典型的な実施態様においては、ＴＡＸｉコントロール・レジスタ４６０に、システムの初期化の間に１度、出荷前のシステム調整によって決定された値が書き込まれる。別の実施態様においては、オン‐ザ‐フライでこの値を操作し、特定のシステム使用パターンに適合させることができる。１つの例外は、ｓｐｅｃｉａｌ＿ｏｐｃｏｄｅ（特殊＿オペコード）フィールド４３４であり、それについては後述する。
【０３０９】
ビット＜６３＞、すなわちｐｒｏｂｅ（プローブ）６７６は、プローブ例外のイネーブルまたはディセーブルに使用され、後述のセクションＶＩにおいてプロービングとの関連から詳細を説明する。ビット＜６２＞、すなわちＰｒｏｆｉｌｅ＿Ｅｎａｂｌｅ（プロファイル＿イネーブル）４６４または「ｐｒｏｆ」は、プロファイル・トレースのパケット収集およびプロファイル・トレース‐パケット完了例外の引き渡しのイネーブルおよびディセーブルを行う。ｐｒｏｂｅ（プローブ）６７６およびＰｒｏｆｉｌｅ＿Ｅｎａｂｌｅ（プロファイル＿イネーブル）４６４のビットは、通常、ハードウエア・デバッギング・リソースがアクティブのとき、ＴＡＸｉオペレーションを常時ディセーブルするために操作される。
【０３１０】
ビット＜６１＞、すなわちｔｉｏ  ８２０は、ＴＡＸｉ  Ｉ／Ｏ例外を間接的にコントロールし、前述のセクションＩ．Ｄにおいて紹介したセーフティ・ネットをインプリメントするガードの１つを提供するが、それについては後述のセクションＶＩＩＩ．Ａにおいてさらに詳しく説明する。
【０３１１】
ビット＜６０＞、すなわちｕｎｐｒ  ４６８は、前述のセクションＩ．Ｆにおいて論じた保護なし例外をディセーブルする。保護なし例外は、保護されていないページ上におけるプロファイリング時にのみ生じる。
【０３１２】
フィールド４７０、すなわちビット＜５９：５６＞は、プロファイルされることになるコード・セグメント／スタック・セグメントのサイズの組み合わせをコントロールする。ビット＜５９＞、すなわち「ｃ１ｓ１」は、Ｘ８６コード・セグメントが３２ビットのデフォルトのオペランド‐サイズ／アドレス‐サイズのビットをセットしているプログラムの部分に関するプロファイリングをイネーブルし、かつ３２ビット・スタックのビットをセットしているセグメント内のスタックを使用する。ビット＜５８＞、すなわち「ｃ１ｓ０」は、３２ビットのオペランド／アドレスに関するプロファイリングをイネーブルし、１６ビットのスタック・セグメントを使用する。ビット＜５７＞、すなわち「ｃ０ｓ１」は、１６ビットのオペランド／アドレスに関するプロファイリングをイネーブルし、３２ビットのスタック・セグメントを使用する。ビット＜５６＞、すなわち「ｃ０ｓ０」は、１６ビットのオペランド／アドレスに関するプロファイリングをイネーブルし、１６ビットのスタック・セグメントを使用する。
【０３１３】
ビット＜５５＞、すなわち「ｐｎｚ」は、（「０」ではない）特権リング「１」「２」および「３」のコードに関するプロファイリングをイネーブルする。
ビット＜５４＞、すなわち「ｐｅｚ」は、（ゼロに等しい）特権リング「０」のコードに関するプロファイリングをイネーブルする。
【０３１４】
ビット＜５３＞、＜５２＞、および＜５１＞、すなわち「ｖ８６」「ｒｅａｌ」「ｓｍｍ」（ビット＜５９：５４＞のサイズおよびモード・コントロールとともに、集合的にＧｌｏｂａｌ＿ＴＡＸｉ＿Ｅｎａｂｌｅｓ（グローバル＿ＴＡＸｉ＿イネーブルズ）ビット４７０、４７２と呼ばれる）は、Ｘ８６の仮想８０８６、リアル、およびシステム・マネジメント実行モードにあるコードに関するプロファイリングをイネーブルする（これらの実行モードは、Ｘ８６のＥＦＬＡＧＳレジスタ内のシステム・フラグおよびＩＯＰＬフィールドによって示される）。与えられたＸ８６実行モードがＴＡＸｉによってサポートされていない場合（つまり、そのＸ８６モードのコードに関してＴＡＸｉが翻訳済み『タペストリー』バイナリの生成を試みないことを意味する）、システムは、そのモードにオーバーヘッドをまったくもたらさないように設計されている。したがって、あるモードに関してＧｌｏｂａｌ＿ＴＡＸｉ＿Ｅｎａｂｌｅｓ（グローバル＿ＴＡＸｉ＿イネーブルズ）４７０、４７２のビットがゼロであり、仮想Ｘ８６  ３１０がそのモードを実行しているときには、実行のプロファイリングが行なわれず、プロファイル・タイマ（図４ｉの４９２）が動作せず、さらにプロファイル例外、保護なし例外、およびプローブ例外がすべて禁止される。
【０３１５】
ビット＜５０：４４＞、すなわちｓｐｅｃｉａｌ＿ｏｐｃｏｄｅ（特殊＿オペコード）４７４は、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ４３０の内容をセットするために使用される。Ｘ８６エミュレータ３１６は、ｓｐｅｃｉａｌ＿ｏｐｃｏｄｅ（特殊＿オペコード）４７４を所望の値にセットする。イベント・コード０．１０１０（図４ｂ）を伴うＲＦＥが続いて実行される場合には、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｓｐｅｃｉａｌ＿ｏｐｃｏｄｅ（ＴＡＸｉ＿コントロール．特殊＿オペコード）４７４が、修正されることなくＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）イベント４３０のｓｐｅｃｉａｌ＿ｏｐｃｏｄｅ（特殊＿オペコード）フィールド４３４（ビット＜５０：４４＞）内にコピーされる。
【０３１６】
ビット＜４３：３８＞、すなわちＰａｃｋｅｔ＿Ｒｅｇ＿Ｆｉｒｓｔ（パケット＿レジスタ＿先頭）４７６、およびビット＜３７：３２＞、すなわちＰａｃｋｅｔ＿Ｒｅｇ＿Ｌａｓｔ（パケット＿レジスタ＿末尾）４７８は、プロファイル・トレース・パケットを蓄積するために使用する汎用レジスタの範囲を指定する。パケットの最初のＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０は、Ｐａｃｋｅｔ＿Ｒｅｇ＿Ｆｉｒｓｔ（パケット＿レジスタ＿先頭）４７６によってポイントされるレジスタ内にストアされ、その次のエントリがＰａｃｋｅｔ＿Ｒｅｇ＿Ｆｉｒｓｔ（パケット＿レジスタ＿先頭）＋１に、さらに同様に続いて最後のエントリがＰａｃｋｅｔ＿Ｒｅｇ＿Ｌａｓｔ（パケット＿レジスタ＿末尾）４７８にストアされる。その後「プロファイル・フル」例外が生じ（図５ａの５３６、５４８）、その結果、プロファイル・レジスタをメモリに移すことができる。表１に示したように、通常はＰａｃｋｅｔ＿Ｒｅｇ＿Ｆｉｒｓｔ（パケット＿レジスタ＿先頭）４７６が１７にセットされ、Ｐａｃｋｅｔ＿Ｒｅｇ＿Ｌａｓｔ（パケット＿レジスタ＿末尾）４７８が３１にセットされる。
【０３１７】
ビット＜３１：１６＞、すなわちＰｒｏｆｉｌｅ＿Ｔｉｍｅｒ＿Ｒｅｌｏａｄ＿Ｃｏｎｓｔａｎｔ（プロファイル＿タイマ＿再ロード＿定数）４９４、およびビット＜１５：００＞、すなわちＰｒｏｖｅ＿Ｔｉｍｅｒ＿Ｒｅｌｏａｄ＿Ｃｏｎｓｔａｎｔ（プローブ＿タイマ＿再ロード＿定数）６３２（ビット＜１５：００＞）は、それぞれプロファイル・トレース‐パケット収集のレートおよびプロービングのコントロールに使用される。これについては、ＴＡＸｉ＿Ｔｉｍｅｒｓ（ＴＡＸｉ＿タイマ）レジスタ（図４ｉの４９０、６３０；後述の図４ｉに関する説明およびセクションＶＩ．ＣならびにＶＩ．Ｄにおける説明を参照されたい）との関連からさらに詳細を説明する。
【０３１８】
図４ｈを参照するとわかるが、ＴＡＸｉシステムの内部状態は、ＴＡＸｉ＿Ｓｔａｔｅ（ＴＡＸｉ＿状態）４８０と呼ばれるレジスタを観察することによって知ることができる。システムの通常の動作においては、ＴＡＸｉ＿Ｓｔａｔｅ（ＴＡＸｉ＿状態）レジスタ４８０が読み出し専用となっているが、コンテキスト切り替え、あるいは設計検証の間においては読み出しおよび書き込みが可能になる。
【０３１９】
ビット＜１５＞、すなわち「ｐｒｅｑ」または「Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（プロファイル＿要求）」４８４は、プロファイル・タイマ４９２がタイムアウトし、別のパケットを収集する要求を発したが、パケットを開始するイベントがまだ発生していないか、あるいは１つのパケットの収集が実際に行なわれている間にプロファイル・タイマ４９２がタイムアウトしたことを示す。
【０３２０】
ビット＜３１＞、すなわち「ｐａｃｔ」または「Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（プロファイル＿アクティブ）」４８２は、「ｐｒｅｑ」または「Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（プロファイル＿要求）」４８４がセットされ、「開始パケット」イベント（図４ｂの４１８）が発生し、プロファイル・パケットが初期化されて進行中であるが、プロファイル・レジスタがまだ満たされていないことを示す。
【０３２１】
このレジスタ内の使用されないビットは、「ゼロにしなければならない」ことを示す「ｍｂｚ」というラベルが付されている。
「Ｄｅｃｏｄｅｄ＿Ｐｒｏｂｅ＿Ｅｖｅｎｔ（デコード済み＿プローブ＿イベント）」フィールド６８０および「Ｐｒｏｂｅ＿Ｍａｓｋ（プローブ＿マスク）」フィールド６２０については、後述のセクションＶＩにおいて説明する。
【０３２２】
「Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（イベント＿コード＿ラッチ）」フィールド４８６、４８７、すなわちビット＜１２：０８＞は、５ビットのイベント・コード（図４ｂのイベント・コード、または図４ｃのＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０もしくは図４ｄのＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）プロファイル・エントリ４４０の４ビット・イベント）を、コンバータ１３６内において生成されたか、あるいはＲＦＥインストラクション（図５ｂの５８８）内のイミディエート・フィールドとしてエンコーディングされた最後のイベントの逆方向ビューとして記録する。Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（イベント＿コード＿ラッチ）４８６、４８７は、このプロセスの次の論理サイクルになるまでの、イベント・コードのログに対するアーキテクチャ的に可視の場所として機能する。その４つの下位ビット４８６は、ＲＦＥのイミディエート・フィールド５８８によって供給されるか、あるいはコンバータ１３６からの４ビット（図５ｂの５８２）が供給される。上位ビット４８７は、コンテキストによって供給され、コンバータ１３６からのイベントに関しては「１」、ＲＦＥからのイベントに関しては「０」となる。
【０３２３】
「Ｐａｃｋｅｔ＿Ｒｅｇ（パケット＿レジスタ）」フィールド４８９、すなわち＜０５：００＞は、レジスタ・ファイル内のポスト−インクリメントの直接アドレスとして次のプロファイル・エントリが書き込まれるレジスタの数を提供する。ＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）４８９がＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐａｃｋｅｔ＿Ｒｅｇ＿Ｌａｓｔ（ＴＡＸｉ＿コントロール．パケット＿レジスタ＿末尾）４７８を超えるときには、プロファイル収集が終了され、「プロファイル・パケット完了」例外が発生し、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）の値がＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐａｃｋｅｔ＿Ｒｅｇ＿Ｆｉｒｓｔ（ＴＡＸｉ＿コントロール．パケット＿レジスタ＿先頭）４７６にリセットされる。
【０３２４】
図４ｉを参照すると、ＴＡＸｉ＿Ｔｉｍｅｒｓ（ＴＡＸｉ＿タイマ）レジスタ４９０が、２つの１６ビットのカウント・ダウン・タイマ４９２、６３０を有していることが示されている。
【０３２５】
ＴＡＸｉ＿Ｔｉｍｅｒｓ．Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ（ＴＡＸｉ＿タイマ．プロファイル＿タイマ）４９２（ビット＜３１：１６＞）は、次のパラグラフに説明するように、プロファイル収集がイネーブルされているとき、ＣＰＵのクロック周波数でカウント・ダウンする。Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ（プロファイル＿タイマ）４９２は、符号なしの値であり、ゼロまでカウント・ダウンする。タイムアウト時には、ハードウエアがＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ＿Ｒｅｌｏａｄ＿Ｃｏｎｓｔａｎｔ（ＴＡＸｉ＿コントロール．プロファイル＿タイマ＿再ロード＿定数）（図４ｇの４９４）をタイマ４９２に再ロードする。Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ（プロファイル＿タイマ）４９２は、カウント・ダウンおよび再ロードを継続的に繰り返す。ゼロへの遷移は、プロファイル例外状態図（図５ａ）に定義されるように、タイマのタイムアウトとしてデコードされる。
【０３２６】
次に示す５つの条件が満たされると、プロファイル収集がイネーブルされ、プロファイル・タイマ４９２が起動される：すなわち（１）ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐｒｏｆｉｌｅ＿Ｅｎａｂｌｅ（ＴＡＸｉ＿コントロール．プロファイル・イネーブル）４６４が「１」であること、（２）コンバータ１３６がアクティブであること（ＰＳＡ．ＩＳＡビット１９４がＸ８６を示している；前述のセクションＩＩを参照されたい）、（３）カレント・インストラクションのすべてのバイトが４ＫのページＩ−ＴＬＢエントリを有していること、（４）カレント・インストラクションのすべてのバイトが良好な振る舞いを有するメモリ（Ｄ−ＴＬＢ．ＡＳＩ＝０を伴うアドレス空間ゼロは良好な振る舞いを有するメモリであり、そのほかのアドレス空間は良好な振る舞いを有していないメモリと見なされる）内にＩ−ＴＬＢページ属性を有していること、および（５）マシンが現在、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｇｌｏｂａｌ＿ＴＡＸｉ＿Ｅｎａｂｌｅｓ（ＴＡＸｉ＿コントロール．グローバル＿ＴＡＸｉ＿イネーブルズ）ビット４７０、４７２（ビット＜５９：５１＞）内においてイネーブルされているモードにおいて実行しているという条件である。Ｘ８６デバッギングもしくはシングル‐ステップ・オペレーションが要求されると、ソフトウエアはＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐｒｏｆｉｌｅ＿Ｅｎａｂｌｅ（ＴＡＸｉ＿コントロール．プロファイル・イネーブル）４６４をクリアしてプロファイル収集をディセーブルする。
【０３２７】
ＴＡＸｉ＿Ｔｉｍｅｒｓ．Ｐｒｏｂｅ＿Ｔｉｍｅｒ（ＴＡＸｉ＿タイマ．プローブ＿タイマ）６３０（ビット＜１５：００＞）については、後述のセクションＶＩ．ＣおよびＶＩ．Ｄにおいて説明する。
【０３２８】
Ｆ．プロファイラ状態機械およびプロファイラの動作
図５ａを参照すると、プロファイラ４００が状態マシン５１０に従って動作することが示されている。状態マシン５１０の４つの状態５１２、５１８、５３０、５４２は、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）ビット４８２およびＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿要求）ビット４８４によって識別される。ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）ビット４８２およびＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿要求）ビット４８４の遷移、したがって状態マシン５１０の遷移は、タイマのタイムアウト、プロファイル可能なイベント、およびパケットの中止によってトリガされる。イベント「ｐｅ」は、Ｘ８６プログラムの実行におけるプロファイル可能なイベント、すなわち図４ｂに示した表内において「プロファイル可能」４１６としてエミュレートされたイベントの１つが完了したことを示す。タイマのタイムアウトは、図４ｉとの関連から前述したように、ＴＡＸｉ＿Ｔｉｍｅｒｓ．Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ（ＴＡＸｉ＿タイマ．プロファイル＿タイマ）４９２のゼロまでのカウント・ダウンおよびリセットである。中止については後述する。
【０３２９】
状態５１２は初期状態であり、Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（プロファイル＿アクティブ）４８２（ＰＡ）およびＰｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（プロファイル＿要求）４８４（ＰＲ）がともにゼロに等しい。状態５１２においては、「ｐｅ，ａｐ」としてラベル付けされたループ遷移５１４によって示されるように、プロファイル可能なイベント４１６および中止イベントが無視される。プロファイル・タイマ４９２がタイムアウトすると、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿要求）４８４が「１」にセットされ、状態マシン５１０を状態５１８に遷移（５１６）させる。
【０３３０】
状態５１８においては、Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（プロファイル＿要求）４８４が「１」、Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（プロファイル＿アクティブ）４８２が「０」であり、Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ（プロファイル＿タイマ）４９２がタイムアウトしたことを示すとともに、プロファイラ４００を起動してプロファイル・パケットの収集を開始させる。しかしながら、最初のプロファイル可能なイベント４１６、４１８がまだ発生していないことから、プロファイリングは、まだ実際に進行していない。状態５１８においては、その後のタイマのタイムアウトがキューされるというよりは無視される（ループ遷移５２０）。また、中止するプロファイル・パケットの内容が存在しないことから、中止についても無視される（ループ遷移５２０）。
【０３３１】
プロファイル・パケット内の最初のエントリは、必ず「開始パケット」プロパティ（図４ｂの４１８）を伴うイベントになる。状態５１８は、最初の「開始パケット」ｐｅｉｎｉｔイベント４１８が発生するまで待機した後、遷移５２２を開始する。ループ遷移５２０上のラベル「ｐｅｉｎｉｔ」によって示した「開始パケット」イベント（図４ｂの４１８）でないプロファイル可能なイベント（図４ｂの４１６）は無視される。遷移５２２においては、いくつかのアクション５２４が開始される。ＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）フィールド４８９が、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐａｃｋｅｔ＿Ｒｅｇ＿Ｆｉｒｓｔ（ＴＡＸｉ＿コントロール．パケット＿レジスタ＿先頭）４７６から初期化される。ハードウエアがＧｌｏｂａｌ＿Ｔｉｍｅｓｔａｍｐ（グローバル＿タイムスタンプ）プロセッサ・レジスタからＰａｃｋｅｔ＿Ｔｉｍｅｓｔａｍｐ（パケット＿タイムスタンプ）コントロール・レジスタ内に（あるいは、別の実施態様においては、最初のプロファイル・イベント取り込みレジスタに先行する汎用レジスタ内に）タイムスタンプを取り込む。Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０がＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）４８９によって示される汎用レジスタ内に取り込まれる。判断ボックス５２６においては、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）４８９がインクリメントされ、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐａｃｋｅｔ＿Ｒｅｇ＿Ｌａｓｔ（ＴＡＸｉ＿コントロール．パケット＿レジスタ＿末尾）４７８と比較が行なわれる。最初のプロファイル・エントリの場合は、パケット・レジスタがフルになることはなく、したがってコントロールがパス５２８に沿って移動する。ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２が「１」にセットされ、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿要求）４８４が「０」にクリアされ、状態マシン５１０が状態５３０に入る。
【０３３２】
パケット内のこの最初のエントリは、コンバータ１３６によるＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０の生成を可能にする環境に過ぎない。プロファイル・パケット内の２番目およびそれ以降のエントリについては、コンバータ１３６がＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０のみを生成する。パケット内のその後のＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０は、すべてＲＦＥメカニズムによって生成される。
【０３３３】
状態５３０においては、Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（プロファイル＿要求）４８４が「０」であり、Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（プロファイル＿アクティブ）４８２が「１」である。少なくとも１つのプロファイル可能なイベント（図４ｂの４１６）が認識されて記録され、プロファイル・パケット４２０が進められ、プロファイラ４００は、次のプロファイル可能なイベント４１６を待機する。次のプロファイル可能なイベント４１６が発生すると（５３２）、そのプロファイル可能なイベントがＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）４８９によって示される汎用レジスタ内に記録される（５３４）。ＴＡＸｉインストラクションによってイベントが取り込まれると（後述する図５ｂの説明を参照されたい）、コントロールが判断ボックス５２６に到達する。プロファイル・レジスタの範囲がフルでなければ（（ＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）４８９＋＋＜ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐａｃｋｅｔ＿Ｒｅｇ＿Ｌａｓｔ（ＴＡＸｉ＿コントロール．パケット＿レジスタ＿末尾）４７８−ＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）フィールド４８９の古い値）が吟味された後、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）４８９がインクリメントされる）、コントロールが状態５３０に戻り（５２８）、プロファイル可能なイベント４１６の収集をさらに続ける。プロファイル・レジスタがフルの場合（ＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）４８９がＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐａｃｋｅｔ＿Ｒｅｇ＿Ｌａｓｔ（ＴＡＸｉ＿コントロール．パケット＿レジスタ＿末尾）４７８に等しい）、マシンは、プロファイル例外５３６を取る。ＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）４８９は、比較の後にインクリメントされる。プロファイル例外ハンドラは、収集したプロファイルを、アクション５２４において取り込まれたタイムスタンプとともにメモリ内のリング・バッファ内にストアする。リング・バッファ内の次のロケーションをポイントするリング・バッファの書き込みポインタは、Ｒ１５（表１のＲｉｎｇＢｕｆ」）によって示されるロケーションにストアされる。Ｒ１５が示すロケーションに収集済みプロファイルがストアされた後、Ｒ１５は、プロファイル・パケットのサイズを用いてポスト‐インクリメントされる。ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２およびＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿要求）４８４がともに「０」にクリアされコントロールが開始状態５１２に戻る（５３８）。
【０３３４】
状態マシン５１０が状態５３０にある間に、つまりプロファイル・パケットの進行中にＴＡＸｉ＿Ｔｉｍｅｒｓ．Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ（ＴＡＸｉ＿タイマ．プロファイル＿タイマ）４９２がタイムアウトすると状態マシン５１０がＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２およびＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿要求）４８４をともに「１」にセットし、状態５４２に遷移する（５４０）。
【０３３５】
状態５４２の振る舞いは、おおむね状態５３０に類似であり、部分的に完成したパケットが進行され、新しいプロファイル可能なイベント４１６が生じるとそのログ（５４４）が行なわれる。状態５３０と状態５４２の違いは、パケットが完成したときに現れる。状態５４２からのプロファイル・レジスタ−フル例外５４８は、プロファイル例外５３６と同様にプロファイル・レジスタをメモリに移すが、遷移５４６の一部として、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿要求）４８４を「１」にセットして状態５１８に遷移する点が、それを「０」にセットして状態５１２に遷移し、次のタイムアウト（５１６）を待機する遷移５３８とは異なる。状態５１８からは、次のタイムアウト（５１６）を待機することなく、直ちに次の「開始パケット」イベント４１８に応答して次のパケットの収集を開始することができる。これは、保留されているタイムアウトの、１レベルのキューイングをもたらす。
【０３３６】
プロファイル・パケットの収集は、多くのイベントによって、パケットの途中で中止されることがある（５５０、５５２）。たとえば、中止パケット・イベント・コードが与えられることがある（図４ｂの行０．１０１１）−−このイベント・コードを伴うＲＦＥは、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２をクリアし、続いてそれがカレント・プロファイル・パケットを破棄し、少なくとも次のプロファイル・タイマのタイムアウトまで、プロファイル収集を中止する。プロファイリングのイネーブルに関する述部（前述のセクションＶ．ＥにおけるＴＡＸｉ＿Ｃｏｎｔｒｏｌ（ＴＡＸｉ＿コントロール）４６０の説明から）が満たされなくなる場合には、パケットが中止される。たとえば、良好な振る舞いを有していないメモリのページ（たとえばＩ／Ｏバス上のページ）にコントロールが渡った場合、あるいは４ＫのページＩ−ＴＬＢエントリを有していないページ上にインストラクションのバイトがある場合、またはＸ８６実行モードが、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｇｌｏｂａｌ＿ＴＡＸｉ＿Ｅｎａｂｌｅｓ（ＴＡＸｉ＿コントロール．グローバル＿ＴＡＸｉ＿イネーブルズ）ビット４７０、４７２においてプロファイリングがイネーブルされていないモードに遷移した場合には、パケットが中止されることになる。この中止プロトコル（５５０、５５２）は、ホット・スポット・ディテクタ１２２に対して、脱漏を招くことなく、各パケットがＸ８６マシンの実際の実行パスを記述することを保証する。
【０３３７】
Ｘ８６コードから『タペストリー』コードへの遷移は（たとえば、プローブ例外の成功；後述のセクションＶＩを参照されたい）、中止（５５０、５５２）イベントとなることがある。プロファイラ４００は、その構成から、中止したパケットを完全に破棄するか、あるいはパディング後に部分的なパケットを、中止（５５０、５５２）が発生する前にリング・バッファに移すかを選択することができる。この選択は、Ｘ８６−『タペストリー』遷移ハンドラ３２０のコード内にインプリメントされている。
【０３３８】
図５ｂは、プロファイラ４００の一部の、プロファイル・エントリ４３０、４４０をプロセッサ・レジスタ内に収集し、フォーマットを行うロジック５５４を示したブロック図である。ロジック５５４に対する入力には、ＴＡＸｉ＿Ｓｔａｔｅ（ＴＡＸｉ＿状態）レジスタ４８０、およびコンバータ１３６内においてＸ８６インストラクション・デコード・ロジック５５６によって生成された多数のラインが含まれる。ロジック５５４の出力は、レジスタ５９４内のプロファイル・エントリである。ロジック５５４は、全体的にはプロセッサのパイプラインに類似であり、パイプライン・ステージが図５ｂの水平の帯状に表され、プロセッシングが図の上から下に向かう。各ステージは、Ｘ８６のインストラクション境界５６６によってクロックされる。ここで、前述の図１ｃの説明から、整列ステージ１３０がＸ８６インストラクション・ストリームをパーズし、完全なＸ８６インストラクションおよびストアされた形式の空間的な境界を識別していたことを想起されたい。変換ステージ１３４、１３６は、さらにＸ８６インストラクションをデコードし、複雑なＸ８６  ＣＩＳＣを『タペストリー』パイプライン１２０による実行のための単純なＲＩＳＣインストラクションに分解する。Ｘ８６インストラクションの間の時間分割は、コンバータ１３６から発行された構成上の『タペストリー』インストラクションのレシピの最後のインストラクション上におけるタグ５６６によってマークされる。Ｘ８６インストラクションの間の時間境界は、『タペストリー』ＰＳＷのビット、ＰＳＷ．Ｘ８６＿Ｃｏｍｐｌｅｔｅｄ（ＰＳＷ．Ｘ８６＿完了）５６６内にフラグ設定される。コンバータ・レシピ内の最初のネイティブ・インストラクション（『タペストリー』インストラクションとなることもある）は、ＰＳＷ．Ｘ８６＿Ｃｏｍｐｌｅｔｅｄ（ＰＳＷ．Ｘ８６＿完了）５６６を「０」にリセットする。コンバータ・レシピ内の最後のネイティブ・インストラクションは、ＰＳＷ．Ｘ８６＿Ｃｏｍｐｌｅｔｅｄ（ＰＳＷ．Ｘ８６＿完了）５６６を「１」にセットする。コンバータ・レシピが含んでいるネイティブ・インストラクションが１つだけである場合には、ＰＳＷ．Ｘ８６＿Ｃｏｍｐｌｅｔｅｄ（ＰＳＷ．Ｘ８６＿完了）５６６が「１」にセットされる。エミュレータ・トラップが、コンバータ・レシピの最後のインストラクションになることが保証されているため、エミュレートされたインストラクション・レシピの正常な完了に応答して、ＰＳＷ．Ｘ８６＿Ｃｏｍｐｌｅｔｅｄ（ＰＳＷ．Ｘ８６＿完了）５６６が「１」にセットされる。
【０３３９】
『タペストリー』プロセッサは、プロセッサ・レジスタ５９４から汎用レジスタ内にプロファイル・エントリを取り込むための特殊なインストラクションを提供する。この特殊なインストラクションは、「ＴＡＸｉインストラクション」と呼ばれる。ＴＡＸｉインストラクションは、プロファイル・エントリの取り込みがなされようとしているときに『タペストリー』パイプライン内に差し込まれる。ここで、前述の図１ｃの説明から、コンバータ１３６が各Ｘ８６インストラクションをＸ８６インストラクションに関する「レシピ」に従って１ないしは複数の『タペストリー』インストラクションに分解していたことを想起されたい。ＴＡＸｉインストラクションは、プロファイラ４００およびコンバータ１３６の協働の下にパイプライン内に差し込まれるもう１つの『タペストリー』インストラクションに過ぎない。つまり、プロファイル生成は、基本的な『タペストリー』インストラクション実行サイクルの統合された一部である。ＴＡＸｉインストラクションは、通常、コントロールの移動のディスティネーションにおけるインストラクションに関するレシピの開始時にパイプライン内に差し込まれる。ハードウエアをインプリメントする側の選択肢として、ＴＡＸｉインストラクションを『タペストリー』インストラクション・セット内にエンコーディング可能でない特殊な移動インストラクションとするか、プロセッサ・レジスタから移動可能であるとすることができる。インプリメンテーション上の選択に応じて、インストラクションを「レジスタ５９４から汎用レジスタＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）フィールド４８９に移動」の形式とすることも可能であり、またコンバータ１３６がレジスタ５９４の内容を抽出し、この６４ビットのデータのムーブ‐イミディエート（イミディエートを移動）を、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）４８９によって指定されるプロファイル収集汎用レジスタに差し込むこともできる。
【０３４０】
整列および変換のパイプライン・ステージ（図１ｃの１３０、１３４、１３６）のインストラクション・デコード・ロジック５５６は、カレント・インストラクションおよび各インストラクションの特定の他のプロファイル可能なプロパティを記述する信号５５８〜５６２を生成し、この記述がラッチされる。生成される情報には、インストラクションの長さ５５８（インストラクションがプロファイル可能なＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）イベント４１６を生成する場合には、Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０のｄｏｎｅ＿ｌｅｎｇｔｈ（終了＿長さ）４４１（ビット＜６４：６１＞）になる）、インストラクションの最後のバイトに関するページ・フレーム５５９（Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０のｄｏｎｅ＿ｂｙｔｅ（終了＿バイト）４４５（ビット５９：４４＞））、および次のインストラクションの最初のバイトのページ・フレーム５６０およびバイトのオフセット５６１（Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）４４０またはＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）４３０のビット＜２７：００＞、すなわちｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）４３８、４４８およびｎｅｘｔ＿ｂｙｔｅ（次の＿バイト）４３９、４４９）。さらにデコード・ロジック５５６によって生成されるものの中には、コンバータ１３６がそのインストラクションを実行するときにＸ８６インストラクションに関連付けされる生のイベント・コード５６２、そのインストラクションがページ境界上で終了するか、あるいはそれをまたぐかの表示５６３、そのインストラクションがコントロールの移動であるか（条件付きまたは条件なし）の表示５８４、ＰＣ相対ブランチが順方向か逆方向かの表示、およびコンバータ１３６は現在アクティブか否かの表示（続いてそれがＰＳＷからコピーされる）５９０がある。
【０３４１】
次のＸ８６インストラクションの境界５６６において、完了直後のインストラクションからの情報が信号５５８、５５９、５６１からレジスタ５６８、５６９、５７０にクロックされる。レジスタ５６８、５６９、５７０は、Ｘ８６インストラクションに関する時間的にシフトする情報を、プロファイル・エントリの取り込みが行なわれる場合に、次のインストラクションの間において使用できるようにするための単なるバッファである。ネイティブのコントロール移動インストラクションが必ず、Ｘ８６移動インストラクションに関するレシピの最後のインストラクションになることから、移動のディスティネーションのアドレスの仮想‐物理アドレス変換は（特に、ＴＬＢミスの場合）、移動インストラクション自体が完了するまで得られない。イベントの取り込みが行なわれようとしている場合には、ＴＡＸｉプロファイル取り込みインストラクションが、ディスティネーション・インストラクションのレシピ内における最初のインストラクションとしてパイプライン内に差し込まれる。このように、時間的なシフトは、ディスティネーションのアドレス変換が解決されるまでプロファイル・エントリの取り込みを遅延させる。レジスタ５６９、５７０は、ともにＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）プロファイル・エントリ４３０の「ｄｏｎｅ（終了）」部分（ビット＜５９：３２＞）を用いて、２８ビットのバス５７２をドライブする。
【０３４２】
同時に、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４４０のビット＜５９：３２＞に相当する形式のカレントＸ８６インストラクションに関するＸ８６プロセッサ・コンテキストが、２８ビットのバス５７４において使用可能になる。
【０３４３】
イベント・コードは回路５７６、５９１によって生成され、以下に説明するようにプロファイル・エントリの取り込みをコントロールするために使用される。
【０３４４】
Ｘ８６インストラクション・デコード・ロジック５５６が、各Ｘ８６インストラクションに関する新しい生のイベント・コード５６２を生成する。このイベント・コードは、コントロール移動インストラクション（図４ｂのイベント・コード１．００００〜１．１０１１）、ページ・フレームの最後のバイトをまたぐか、その上で終了するインストラクション（図４ｂのコード１．１１１１（４０８））、あるいはそのほかすべてのケースに関するデフォルトのコンバータ・イベント・コード（図４ｂの１．１１１０（４０６））を指定する。（エミュレータ３１６内において実行されるインストラクションに関しては、コンバータ１３６によるそのインストラクションのパーズに従って、ロジック５７６、５７８がデフォルトのイベント・コード１．１１１０（４０６）またはページ渡りを示すイベント・コード１．１１１１（４０８）を生成し、その後この生のイベント・コード５６２が、Ｘ８６インストラクションのエミュレーション・ルーチンの最後にＲＦＥインストラクションのイベント・コード・イミディエート・フィールド５８８によって上書きされるか、選択される。）
【０３４５】
インストラクションがコントロール移動インストラクションでない場合には、回路５７８が「ページ境界をまたぐ」信号５６３を使用して下位ビットをセットすることにより、２つの特殊な「非イベント」イベント・コード１．１１１０（４０６）および１．１１１１（４０８）（シーケンシャル・フローまたはページの渡り）を作る。
【０３４６】
ＭＵＸ  ５８０は、インストラクション・デコード・ロジック５５６によって生成された生のイベント・コード５６２、および回路５７８からの１．１１１ｘ「非イベント」イベント・コード４０６、４０８の中から、次に示すメカニズムにより選択を行って最終的なコンバータ・イベント・コード５８２を生成する。カレント・インストラクションがライン５８４によって示されるような「コントロール移動」（条件なしまたは条件付きの移動）であるか、あるいはブランチの予測子によってブランチが行なわれると予測（５８６）されている場合、ＭＵＸ
５８０がデコード・ロジック５５６によって生成された生のイベント・コード５６２を選択するが、それ以外の場合には、ＭＵＸ  ５８０が１．１１１ｘ回路５７８からの「非イベント」イベント・コードを選択する。
【０３４７】
ブランチが行なわれると予測（５８６）されている場合には、ＭＵＸ  ５８０が、インストラクションに関連付けされている生の条件付きブランチ・イベント・コード５６２を選択する。ブランチが行なわれないと予測（５８６）されている場合には、ＭＵＸ  ５８０が、回路５７８から１．１１１ｘ「非イベント」イベント・コード（ページ境界イベント・コード１．１１１１（４０８）もしくはデフォルトのイベント・コード１．１１１０（４０６）のいずれか）を選択する。ここで、ネイティブのコントロール移動インストラクションが、必ず、Ｘ８６移動インストラクションに関するレシピの最後のインストラクションになり、ＴＡＸｉプロファイル取り込みインストラクションが、プロファイル可能な移動のディスティネーションレシピ内の最初のインストラクションとしてパイプライン内に差し込またことを想起されたい。つまり、ブランチの予測５８６が正しくないとわかった場合には、レジスタ５９４の内容をＴＡＸｉ＿Ｓｔａｔｅ．Ｐａｃｋｅｔ＿Ｒｅｇ（ＴＡＸｉ＿状態．パケット＿レジスタ）４８９によってポイントされる次の汎用レジスタの内容を取り込むＴＡＸｉインストラクションも含めて、コンバータ１３６から下流の全パイプライン（図１ｃの１２０）がフラッシュされる。（これは、そのＴＡＸｉインストラクションが、Ｘ８６レシピの末尾になるネイティブ・ブランチ・インストラクションに続くパイプラインに差し込まれることによる。）インストラクション・ストリームが、予測誤りのブランチからリターンされる。このリターンに応答して、ブランチ予測ライン５８６に正しい予測値が表明され、それによりＭＵＸ  ５８０が正しいイベント・コードを選択し、ＴＡＸｉインストラクションが正しく差し込まれるか、あるいは差し込まれないことになる。このイベント・コードの解決によって、プロファイル・パケットは、ページ境界をまたぐ（もしくは境界上で終わる）、採用されたブランチもしくは採用された条件付きブランチを適正に記録し、かつページ境界をクロスしない、採用されなかったブランチを適正に除外することが可能になる。
【０３４８】
エミュレートされたインストラクションの場合、コンバータ１３６が、デフォルトまたは新規ページのイベント・コード５７８のいずれかになるイベント・コード５８２を常に供給する。コンバータ１３６が完全にすべてのインストラクションをデコードすることから、それによりデフォルトまたは新規ページのイベント・コード５７８に代えて、「遠い」コントロール移動インストラクション（「遠い」ＣＡＬＬ（呼び出し）、「遠い」ＪＭＰ（ジャンプ）、「遠い」ＲＥＴ（リターン）またはＩＲＥＴ）に対応するイベント・コードを供給することができる。このイベント・コードは、エミュレータ・トラップ・レシピの一部としてラッチされる。エミュレータ３１６がページ・フレームをまたぐインストラクションを完了し、単純なＸ８６インストラクション完了イベント・コード０．０００１を伴って、コンバータ１３６に戻るＲＦＥを行ったとき、Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（イベント＿コード＿ラッチ）（４８６、４８７；図４ｉのビット＜４４：４０＞）内の新規ページのイベント・コード１．１１１１（４０８）が使用されることになる。上位ビットがセットされていることから、再使用イベント・コード４１４のＲＦＥによって、Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）プロファイル・エントリが取り込まれる；このＲＦＥが、Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）を必要とするデータ依存のコンテキスト変更を含意しないことからこれは誤りではない。エミュレータ３１６が、Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（イベント＿コード＿ラッチ）を再利用（４１４）しないＲＦＥイベント・コードを供給する場合には、ＲＦＥイベント・コード５８８がラッチされる。この規約によって、プロファイル・パケットは、ページ・フレームをまたぐ、注目しているエミュレートされたインストラクションまたは単純なエミュレートされたインストラクションを記録することができる。
【０３４９】
同様に、Ｘ８６インストラクションが失敗し、リスタートしなければならない場合には、そのインストラクションに関するプロファイル情報５５８、５５９、５６０、５６１、５６２、５６３、５８４が再生成され、そのインストラクションと並行してパイプライン５５４に流れ込む。たとえば、ＴＬＢ内においてインストラクションのフェッチのミスが生じた場合には、ＴＬＢミス・ルーチンが起動してＴＬＢを更新し、プロファイル・パイプライン内において、再生成されたプロファイル情報とともにインストラクションがリスタートされる。
【０３５０】
ＲＦＥインストラクションのイミディエート・フィールド（図４ｂの４１０）からイベント・コード５８８が到来する場合、Ｃｏｎｖｅｒｔｅｒ＿Ａｃｔｉｖｅ（コンバータ＿アクティブ）ライン５９０が、下位４ビットに関してコンバータ・イベント・コード５８２とＲＦＥイミディエート・イベント・コード５８８の間を選択する選択ライン５９０ａとしてＭＵＸ  ５９１に供給されるとともに、イベント・コード４０２の上位ビット５９０ｂとして供給され、５ビットのイベント・コード５９２が形成される。このイベント・コード５９２は、ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）（４８６、４８７；図４ｉのビット＜４４：４０＞）内にラッチされる。（ここで、ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）４８６、４８７を、レジスタ５６８、５６９、５７０によって定義されるパイプライン・ステージの一部として捕らえてもよい。）図５ｂには示していないものに、図４ｂの「再使用イベント・コード」４１４の効果がある：すなわち、ＲＦＥインストラクションが「再使用イベント・コード」イベント・コード・イミディエート（０．００００〜０．００１１）を伴って完了した場合には、ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）４８６、４８７の更新が抑圧され、古いイベント・コードがそのまま残される。
【０３５１】
各Ｘ８６インストラクションは、６４ビットのレジスタ５９４内において、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０もしくはＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０のいずれかを具体化する。２つの可能性のあるビットのセット５６８、５７２、５７４が、ＭＵＸ  ５９６ａ、５９６ｂに渡され、それらの中からビットＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）＜４＞４８７が選択を行う。ここで、たとえばアンド・ゲート５９８から「１」を出力させてＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０を生成するためには、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２が真でなければ（図５ａに示した状態５３０および５４２）ならないことに注意する必要がある。；これは、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０が必ずＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０に先行しなければならないという規則を順守させることになる。つまり、ＴＡＸｉインストラクションが発行されたとき、Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（プロファイル＿アクティブ）４８２が「０」であれば（図５ａに示した状態５１２および５１８）、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリは、必ずフォース・アウトされる。
【０３５２】
プロファイラ４００によって、レジスタ５９４内のエントリを実際にプロファイル内に取り込む必要があると判断されると、コンバータ１３６がレジスタ５９４からプロファイル情報を取り込むために、『タペストリー』パイプライン１２０内の、プロファイル済みのＸ８６インストラクションと次のＸ８６インストラクションの境界５６６にＴＡＸｉプロファイル取り込みインストラクションを差し込む。
【０３５３】
実施態様によっては、複数のＴＡＸｉインストラクションを差し込んで種類の異なるプロファイル情報を取り込むと望ましいことがある。たとえば、複数のＴＡＸｉインストラクションにより、タイムスタンプ、コンテキスト（Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０に類似）、コントロール・フロー・イベント（Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０に類似）を取り込むことが可能であり、またある１つの差し込まれたインストラクションが所望の情報を演算し、それに続くインストラクションがその情報をメモリにストアするということもできる。一時的にプロファイル情報をアーキテクチャ上アドレス可能でないレジスタ内に収集し、ストレージ・リソースのコンテンションを抑えると望ましいことがある。この一時的なレジスタに対するアクセスをスケジュールするためにレジスタ・コンフリクト・スケジューリング・ハードウエアを使用しなければならない一方、このレジスタの追加は、プロファイラ４００のオペレーションをプロセッサの残りの部分から分離する。
【０３５４】
ＴＡＸｉインストラクションは、次に示す条件がすべて満たされたとき差し込まれる（かつ、図５ａの状態マシン５１０において「ｐｅ」イベント４１６が移動をトリガする）：すなわち、（１）現在マシンがＴＡＸｉ＿Ｃｏｎｔｒｏｌ（ＴＡＸｉ＿コントロール）ビット＜５３：５１＞内においてイネーブルされているモードで実行中であること（つまり、カレントＸ８６インストラクション・コンテキストおよびＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｇｌｏｂａｌ＿ＴＡＸｉ＿Ｅｎａｂｌｅｓ（ＴＡＸｉ＿コントロール．グローバル＿ＴＡＸｉ＿イネーブルズ）４７０、４７２のＡＮＤ（論理積）がゼロでないこと）、（２）マシンがＸ８６インストラクションの境界にあること、（３）カレント・インストラクションのすべてのバイトが４ＫのページＩ−ＴＬＢエントリを有していること、（４）カレント・インストラクションのすべてのバイトが良好な振る舞いの（アドレス空間ゼロの）メモリＩ−ＴＬＢエントリを有していること、および（５）次のうちの少なくとも１つが真であること：（ａ）プロファイル収集がイネーブル（ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２が「１」）されており、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿要求）４８４が「１」であり、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２が「０」であり、およびＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）４８６、４８７に現在ラッチされているイベント・コードが「開始パケット」プロパティ（図４ｂの４１８）を有していること、あるいは（ｂ）ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２が「１」であり、ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）４８６、４８７が「プロファイル可能」（図４ｂの４１６）であること、あるいは（ｃ）ＴＡＸｉプローブ例外が生成されること（これは従属的なプロファイリングであるが、プロービングをコントロールするためのむしろ都合の良いメカニズムである；後述のセクションＶＩ．ＣおよびＶＩ．Ｄを参照されたい）である。
【０３５５】
マシンは、Ｘ８６インストラクションの規則に従った実行の割り込みの間に、たとえばＴＬＢミス、ページ違反、ディスク割り込み、またはその他の非同期割り込みの間に、Ｘ８６コンバータ１３６にクエリを行い、ネイティブ実行に切り替える。ネイティブ実行の間は、Ｘ８６インストラクション境界のクロック５６６が停止される。Ｘ８６クロック５６６が停止されていることから、Ｘ８６インストラクションのＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）状態が、Ｘ８６の実行再開までレジスタ５６８、５６９、５７０内に保持される。
【０３５６】
ここで、図５ｂの実施態様において、プロファイリングがＸ８６の実行間に限ってアクティブになることに注意されたい。別の実施態様においては、ＴＡＸｉトランスレータ１２４によってＸ８６から翻訳されたネイティブ『タペストリー』インストラクションの実行間にプロファイラ４００がアクティブになり、その結果、プロファイラ４００によって生成された情報を次の翻訳にフィードバックして、その部分が次回翻訳されるときの最適化を向上させることができる。『タペストリー』プログラムによるレジスタの使用は、コンパイラによって制限されており、そのため残りのレジスタに対して、プロファイル・エントリのストアを行うことができる。
【０３５７】
この方法を用いて、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ＿Ｒｅｌｏａｄ＿Ｃｏｎｓｔａｎｔ（ＴＡＸｉ＿コントロール．プロファイル＿タイマ＿再ロード＿定数）（図４ｇの４９４）を調整することができる。ホット・スポット・ディテクタ１２２によって、プログラムのワーキング・セットが緩やかに変化している（つまり、ホット・スポットの大部分が以前に検出したホット・スポットとオーバーラップしている）ことが示される場合、プロファイラ４００が非常に高い頻度で起動される。その場合には、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ＿Ｒｅｌｏａｄ＿Ｃｏｎｓｔａｎｔ（ＴＡＸｉ＿コントロール．プロファイル＿タイマ＿再ロード＿定数）４９４が増加されて、プロファイリングの頻度が抑えられる。同様に、ホット・スポット・ディテクタ１２２が、ホット・スポット・ディテクタの起動と起動の間においてワーキング・セット内に大きな変化があることを検出したとき、それに応じてＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ＿Ｒｅｌｏａｄ＿Ｃｏｎｓｔａｎｔ（ＴＡＸｉ＿コントロール．プロファイル＿タイマ＿再ロード＿定数）４９４を下げることができる。
【０３５８】
ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ＿Ｒｅｌｏａｄ＿Ｃｏｎｓｔａｎｔ（ＴＡＸｉ＿コントロール．プロファイル＿タイマ＿再ロード＿定数）４９４に関する別の調整方法においては、バッファのオーバーランが重視される。プロファイル収集レジスタの範囲がフルになると、プロファイル・レジスタがメモリ内のリング・バッファに移される（図５ａの５３６および５４８）。ホット・スポット・ディテクタ１２２は、このリング・バッファからのプロファイル情報を消費する。プロファイラ４００がホット・スポット・ディテクタ１２２をオーバーランし、リング・バッファがオーバーフローすると、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐｒｏｆｉｌｅ＿Ｔｉｍｅｒ＿Ｒｅｌｏａｄ＿Ｃｏｎｓｔａｎｔ（ＴＡＸｉ＿コントロール．プロファイル＿タイマ＿再ロード＿定数）４９４が増加され、プロファイル情報の収集が行なわれる頻度が下げられる。それに対して、バッファがオーバーランしているときには、ホット・スポット・ディテクタ１２２が起動される頻度を高くすることができる。
【０３５９】
Ｇ．４ビット記憶形式からの５ビット事象コードの決定
再度図４ｂ、４ｃ、および４ｄを参照すると、プロファイル・エントリ（Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０またはＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０）内のイベント・コード・フィールド４３６、４４６は４ビットである。４ビットを用いてエンコーディングできる値が１６しかなく、図４ｂに分類されたイベントのクラスが３２であることから、上位ビットを以下のようにして回復する。
【０３６０】
Ｎｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０がパケット内の最初のエントリになることはない。その省略された上位ビットは、必ず「１」になり、したがってＮｅａｒ＿Ｅｄｇｅ（ニア＿エッジ）エントリ４４０は、常に図４ｂの下側半分４０４に含まれるイベントを記録する。このイベントは、常にコンバータ１３６（または１．１１１ｘ非イベント回路５７８）によって生成され、図５ｂのライン５８２において具体化される。
【０３６１】
Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）４３０がパケット内の最初のエントリでない場合、省略された上位ビットは、必ず、図４ｂの上側半分４１０に含まれるイベントであることを反映した「０」になる。これらの非開始Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０は、常にＲＦＥイベントによって生成される。
【０３６２】
各パケットは、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）エントリ４３０を伴って開始し、その場合のＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）は、「開始パケット」プロパティ（図４ｂの４１８）を伴うイベントである。イベント・コード４０２は、慎重に割り当てが行なわれ、その結果、１組のＲＦＥイベント・コード（図４ｂの下側半分４０４）およびコンバータ・イベント・コード（図４ｂの上側半分４１０）だけがともに同一の下位４ビットを共有し、かつ「開始パケット」プロパティ４１８を有する。それらは、イベント・コード０．０１１０および１．０１１０、すなわち「近い」ＲＥＴ（リターン）および「遠い」ＲＥＴ（リターン）である。つまり、上位の５番目のビットは、パケット内の最初のイベントの４ビットのイベント・コード４３６、４４６を用いてルックアップを行うことによって、次に示すように回復することができる。
【０３６３】
００００  −＞  １      １０００  −＞  ０
０００１  −＞  １      １００１  −＞  ０
００１０  −＞  １      １０１０  −＞  １
００１１  −＞  １      １０１１  −＞  １
０１００  −＞  １      １１００  −＞  ０
０１０１  −＞  １      １１０１  −＞  ０
０１１０  −＞  ＊      １１１０  −＞  ０
０１１１  −＞  １      １１１１  −＞  ０
【０３６４】
「近い」リターンおよび「遠い」リターン（０．０１１０および１．０１１０）は、同一の下位４ビットを共有するが、そのいずれもパケットの開始において現れることがある。１つのインプリメンテーションにおいては、「０」または「１」のいずれかを選ぶことができる。このあいまい性による精度の低下は、許容可能範囲である。
【０３６５】
Ｈ．プロファイラ、例外およびＸＰ保護／非保護のページプロパティの対話
例外は、いくつかの形でプロファイル収集と相互作用する。
例外の第１のクラスは、『タペストリー』オペレーティング・システム（図３ａの３１２）によって完全に扱われる。これには、ＴＬＢ、ＰＴＥ、およびＰＤＥの例外およびすべてのネイティブ固有の例外が含まれる。例外の処理の後は、収集されたプロファイル・エントリを伴わずに実行が再開される。これらの例外ハンドラのエンドにあるＲＦＥインストラクションは、シーケンシャルの０．００００変更なしイベント・コードを使用する。
【０３６６】
第２のクラスは、プロファイル・レジスタ・フル例外および保護なし例外（前述のセクションＩ．Ｆを参照されたい）を含めたＴＡＸｉプロファイリング例外を包含する。この第２のクラスの例外は、ＴＡＸｉ環境によって定義される特殊な副次効果を有している。これらの例外は、インストラクションの実行を再開し、特殊なＲＦＥイベント・コードを使用してプロファイリング環境をコントロールする。
【０３６７】
第３のクラスは、Ｘ８６インストラクションのエミュレーションに関するコンバータ１３６からのすべてのエミュレータ・トラップを包含する。第３のカテゴリに含まれる例外は、追加のプロファイル情報を提供する。エミュレータ３１６は、常に、非ゼロＲＦＥイベント・コードを使用してコンバータのオペレーションを再開する。
【０３６８】
第４のクラスは、ハードウエア割り込み、ページ違反、ブレークポイント、シングル・ステップ、あるいはコンバータ１３６もしくはエミュレータ３１６内において検出された、Ｘ８６仮想マシンにとって明らかでなければならないその他のあらゆるＸ８６例外からのコントロールの、非同期のＸ８６移動を含む。この第４のクラスの例外は、特殊な機能を有する。エミュレータ３１６は、Ｘ８６  ＩＤＴを介してコントロール・フローの変更を行おうとするとき、ＲＦＥ内における４つのソフトウエア定義イベント・コードのうちの１つを使用する。これらのイベント・コードは、２つのカテゴリに分けることができる。一方のカテゴリは、プロファイリングだけに使用され、他方は、エミュレータ３１６による任意のＸ８６コード・ページ上の翻訳済みコードに関するチェックの強制を可能にするために使用される。エミュレータ３１６はプライベート・データ構造を維持しており、特定のＩＳＲアドレスに関してプローブ・チェックの生成を行うべきか否かを吟味する。
【０３６９】
「保護なし」例外（前述のセクションＩ．Ｆを参照されたい）とプロファイラ４００の相互作用は次のようになる。保護なし例外の効果の１つは、ＴＡＸｉインストラクションを発行して新しいプロファイル・パケットを開始することである。ここで、Ｘ８６インストラクションが保護されていないプロファイル可能なページからフェッチされたとき、保護なし例外がトリガされたことを想起されたい。
【０３７０】
ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ  ４８２＝＝１    ／／プロファイリング
（ＴＡＸｉ＿状態．プロファイル＿アクティブ）
ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｕｎｐｒ  ４６８＝＝１    ／／例外のイネーブル
（ＴＡＸｉ＿コントロール．ｕｎｐｒ）
ページのＩ−ＴＬＢ．ＩＳＡ  １８２＝＝１  かつ  ＸＰ  １８６＝＝０    ／／保護なし
フェッチ・ページは４ＫＢ    ／／中止なし．．．
フェッチ・ページはＡＳＩ＝＝０    ／／中止なし．．．
【０３７１】
ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２は、「開始パケット」（図４ｂの４１８）イベントが認識されたとき、そのサイクルのパケットの収集を準備するためにセットされる。ＴＡＸｉインストラクションは、変換済みのフェッチ・アドレスが既知となり、次のインストラクションのフェッチに成功した後に、パイプの下流に送られて次のサイクルにおけるＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２を更新する。ＴＡＸｉインストラクションは、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２がクリアされ、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿要求）４８４がセットされ、かつＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）４８６、４８７が、Ｉｎｉｔｉａｔｅ＿Ｐａｃｋｅｔ（開始パケット）４１８が真になるｅｖｅｎｔ＿ｃｏｄｅ（イベント・コード）を含んでいるか、あるいはコンバータ・レシピ内の最初のインストラクションが発行され、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）４８２がセットされる場合に発行される。保護なし例外ハンドラにおいては、保護されていないページに対する検出されない書き込みが正しくないプロファイル・データベースをもたらす可能性があることから、その種のページに関するプロファイル収集が安全ではないことを念頭に置いた上で、カレント・プロファイル・パケットを保存するか、あるいはそれを破棄するかを選択することができる。ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｕｎｐｒ（ＴＡＸｉ＿コントロール．ｕｎｐｒ）４６８がクリアされると、例外が生成されなくなり、ＴＡＸｉソフトウエアが、プロファイル・パケットの確認および「保護あり」ページ属性のセットを引き受ける。
【０３７２】
プロファイル・パケット内において参照されるすべてのページは保護されていなければならないという規則に対して、２つの狭い例外が存在する−−すなわち、パケットの開始および終了における境界のケースである。プロファイル・パケット（たとえば、図４ａの４２０）がコントロール移動インストラクションを伴って終了していた場合、その移動インストラクションの最後のバイト、したがってその移動のソース（ｄｏｎｅ＿ｆｒａｍｅ（終了＿フレーム）メンバ４４４）は保護されたページ上になければならないが、移動のディスティネーション（エントリのｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）メンバ４３８、４４８）にはその必要がない。同様に、パケットがコントロール移動インストラクション（図４ｂの「開始パケット」プロパティ４１８を有する）を伴って開始する場合、移動のディスティネーション（ｎｅｘｔ＿ｆｒａｍｅ（次の＿フレーム）４３８、４４８）は保護されたページ上になければならないが、ソースにはその必要がない。後者の場合、パケットがＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）（図４ｃの４３０）を伴って開始しなければならないが、それがイベントのソースを記述しないことから、当然のことながらプロファイル・パケット内におけるソースは、記述を免れることになる。
【０３７３】
Ｉ．代替実施例
楽観的な順不同コードをいつ生成するか、また保守的な順序どおりコードをいつ生成するかということに関して良好なヒューリスティックを提供するために、プロファイル・エントリは良好な振る舞いを有しないＩ／Ｏ空間に対する参照を記録することができる。１つのメカニズムは、後述のＶＩＩＩ．Ｂにおいて説明するコンバータ・イベント・コード１．１１００であり、Ｉ／Ｏ空間に対するアクセスを記録する。別の実施態様においては、Ｘ８６コード・ページからの実行中（ＰＳＷ．ＩＳＡビット１９４が「１」に等しく、Ｘ８６  ＩＳＡであることを示しているとき）であり、かつＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）（図４ｈの４８２）が「１」であれば、「プロファイルＩ／Ｏ参照」例外がＩ／Ｏ空間の参照時に『タペストリー』オペレーティング・システム３１２をトラップする。例外ハンドラの完了時に、ＲＦＥイミディエート・フィールド（図５ｂの５８８）がイベント・コード１．１１００を伴うプロファイル・エントリを供給し、Ｉ／Ｏ空間の参照を示す。
【０３７４】
プロファイル・コントロール・レジスタを使用すれば、よりきめ細いレベルにおいてプロファイリングをコントロールすることができる。たとえば、３２ビットを有するレジスタを用いて、各ビット・イネーブルもしくはディセーブルを図４ｂに示したイベント・クラスの１つに対応させる。プロファイリングに関するこのほかのコントロールについては、ＰＬＡ  ６５０との関連から説明を後述する。
【０３７５】
ＶＩ．変換を求めるためのプロービング
Ａ．プロービングの概要
プロファイラ４００は、Ｘ８６プログラムのプロファイルを生成する。このプロファイルをホット・スポット・ディテクタ１２２が解析して、実行頻度の高いコードのセクション、すなわちホット・スポットを識別する。ＴＡＸｉバイナリ・トランスレータ１２４は、ホット・スポットをＸ８６からＴＡＸｉコード（ＴＡＸｉバイナリ・トランスレータ１２４によって生成される『タペストリー』ネイティブ・コード；機能的にはＸ８６バイナリと等価）に翻訳する。Ｘ８６バイナリが変更されずに残されることから、それが、ＴＡＸｉコードにコントロールを移動する明示的なコントロール・フロー・インストラクションを含むことはない。「プロービング」は、対応するＴＡＸｉコードに入る有効なエントリ・ポイントを有するＸ８６バイナリ内のポイントに到達したことを認識し、Ｘ８６バイナリからコントロールを奪い、コントロールをＴＡＸｉコードに移動するプロセスである。
【０３７６】
一実施態様においては、各インストラクション・フェッチ・サイクルがテーブルのクエリを行う。このテーブルの各エントリは、Ｘ８６の物理ＩＰ値をＴＡＸｉコードのエントリ・ポイントのアドレスにマップする。たとえば、大きな連想メモリにより、Ｘ８６の物理ＩＰ値をＴＡＸｉコード・セグメントへのエントリ・ポイントにマップすることができる。ＴＡＸｉコードのセグメント数は、通常、多くとも数百の規模となり、ＴＡＸｉコード・セグメントのトップにおいてのみ実行が入ることが可能であり、それが途中からとなることはない。このようにこのマッピング内には、たかだか数百のエントリのみが、任意の時点で任意のポイントにおいて有効になっている。このように希薄なマッピングは、概略でキャッシュの１つのサイズに等しい連想メモリ内にインプリメントすることが可能である。その反面、このテーブル内においてヒットが得られるレートは極めて低い。概念的なことを述べれば、後述する別の実施態様においては、少ないチップ・リソースを使用してこの種の連想メモリのエミュレーションに努めている。
【０３７７】
別の実施態様においては、Ｘ８６物理ＩＰ値から『タペストリー』エントリ・ポイントへのマッピングがテーブル内のメモリにストアされ、ＴＬＢと同様に、このマッピング・テーブルにおけるもっともアクセス頻度の高い部分がキャッシュ内に維持される。このマッピング・テーブル内の各エントリは、付随するエントリが有効であるか否かを示す有効ビットを有している。各インストラクション・フェッチ・サイクルの間は、このテーブルのキャッシュ済みコピーに対してクエリが行なわれる。この場合にも、このテーブル内においてヒットが得られるレートは極めて低くなる。
【０３７８】
さらに別の実施態様においては、ビット・ベクトルが各バイト（または、可能性のある各インストラクションの開始もしくは各基本ブロック）対応するビット、すなわちＸ８６インストラクション空間のそのバイトに対応するＴＡＸｉコードに対するエントリ・ポイントの有無を示すビットを有している。マッピング・テーブル内の各エントリは、Ｘ８６マシン状態の仮定を示す、当該エントリに関連付けされたＴＡＸｉコード内にコーディングされるマシン状態の述部、およびＴＡＸｉエントリ・ポイントに関するアドレスを含んでいる。この実施態様においては、プロービングが３ステップのプロセスとしてインプリメントされる：すなわち、ビット・ベクトルのクエリを行い、翻訳のマッピングの有無を調べ、存在する場合にはマッピング・テーブル内を探し、それが見つかると、Ｘ８６マシンのカレント状態がそのテーブルのエントリ内にリストされている前提条件を満たすか否かを検証する。このビット・ベクトルは極めて大きく、全メモリの１／９に達する可能性がある。さらにビット・ベクトルおよびテーブルのクエリは、キャッシュを改ざんする傾向がある。この実施態様においては、ビット・ベクトルのクエリが成功した後に例外が生じ、テーブルのクエリが例外ハンドラ・ソフトウエアによって実行される；したがって例外は、ビット・ベクトル内の対応するビットをセットしているアドレス、すなわち有効なＴＡＸｉコード・エントリ・ポイントを有しているアドレスに関してのみ例外が生じる。
【０３７９】
さらに別の実施態様においては、ビット・ベクトル内の各ビットがＸ８６コードのページに対応する。対応する翻訳とともに、ページ上のいずれかの場所にＸ８６インストラクションが存在する場合には、そのビット・ベクトル内の対応するビットがセットされる。その後、ＴＡＸｉコード・セグメントに対するエントリが続く可能性のある各イベントにおいて、マッピング・テーブルがプローブされてその種の翻訳の有無が調べられる。つまり、このインプリメンテーションは、前のパラグラフの実施態様よりビット・ベクトルの保持に使用するメモリが少ないが、対応するＴＡＸｉエントリ・ポイントを有するインストラクションだけでなく、テーブルにクエリを行うそのページからのインストラクションのフェッチごとに例外を生成する。この実施態様は、翻訳が比較的少数のあまり頻繁でないイベント、たとえばサブルーチンのエントリ、あるいはループのトップに限られる場合に極めて良好に機能する。
【０３８０】
ページに関連付けされたビットは、ほかのページ・プロパティ１８０、１８６と同様に、ＴＬＢ内にキャッシュすることができる。
次のセクションで詳細に論じている実施態様においては、ＴＡＸｉが、スペース（ページ）、時間（プローブ・タイマを使用）、およびイベント・コード（プロファイリングに使用したイベント・コード４０２に同じ）によって可能性のあるイベント空間を分割する。
【０３８１】
Ｂ．統計学的プロービングの概要
ＴＡＸｉプローバ６００は、統計学的ヒューリスティックのセットを、いつＴＡＸｉ翻訳がＴＡＸｉコード・バッファ内に存在する可能性が極めて高くなるかということに関する、有益な選択肢のセットを作る上での補助として使用する。１つのイベントが発生するごとに、たとえばそれぞれのルーチン呼び出しごとに翻訳をプローブするのではなく、ＴＡＸｉプローバ６００は、単純なコントロールの移動、条件付きジャンプ、「近い」呼び出し、「遠い」呼び出し、およびＸ８６割り込みの引き渡しを含めた、より大きなイベントのクラス上においてプローブを行い、膨大な数のクラス上のプローブ数を成功の可能性のある数まで絞り込む統計学的メカニズムを使用する。統計学的プローブ・メカニズムは、プローブ例外とＴＡＸｉコードを実行する実際の機会の間に高い相関が得られるように設計されている。
【０３８２】
ＴＡＸｉは、可能性のあるプログラム・イベントの空間を空間的、論理的、かつ時間的に分割し、それによりＸ８６コード空間／ロジック／時間の間における、必ずしも常に正しくはないが、ＴＡＸｉコードの存在と良好な相関を見せる統計学的結合を形成する。セクションＶＩ．Ａにおいて述べた実施態様におけるように、テーブルがＸ８６物理ＩＰ値をＴＡＸｉコード・セグメント内のエントリ・ポイントにマップする。このテーブルは、ＰＩＰＭ（物理ＩＰマップ）６０２と呼ばれる。各物理ページは、関連付けされたプロパティを有する。このプロパティは、いくつかの論理的イベント・クラス（図４ｂに示したイベントのサブセット６１２；前述のセクションＶ．Ｂにおいて説明）に関連付けされている。バイナリ・トランスレータ１２４は、ＰＦＡＴ（ページ・フレーム属性テーブル）１７２内のページごとにプロパティの５ビット６２４を維持する−−バイナリ翻訳が生成されるとき、そのエントリ・イベントに対応するビット６２４が、Ｘ８６ページのＰＦＡＴエントリ１７４内において、翻訳の存在を示すべくセットされ、ＰＩＰＭ  ６０２内に、Ｘ８６物理ＩＰアドレスをＴＡＸｉコード・セグメントのアドレスにマップするエントリが作られる。５つのＰＦＡＴビットは、ＴＬＢ  １１６に、ページ・テーブルからのページ翻訳とともにロードされる。これらのビットにクエリを行う機能のイネーブルは、時間的に変化するプローブ・マスクによってゲートされるが、そのビットは、５つのＰＦＡＴ／ＴＬＢビットに対応する。
【０３８３】
プローブは、図６ｃとの関連から詳細を説明するように、複数の段階において生じる。１つの段階が失敗すると、残りのプローブが途中放棄される。第１段階は、Ｘ８６インストラクションが実行された、そのインストラクションがプローブ可能なイベント・コードの１つであるイベント・コードを生成し、かつ、そのページに関する対応するプローブ・プロパティがイネーブルであり、かつ、カレント・プローブ・マスク内の対応するビットがイネーブルであるとき、トリガされる。この第１段階は、基本的には前述の実施態様に関して説明した連想メモリ・サーチのインプリメンテーションであるが、メモリ・ページの細分性に関して異なる。この第１段階は、例外を生成し、その結果ソフトウエアが実際にＰＩＰＭ  ６０２をプローブできるようなることが有益となり得るか否かということに関して、妥当であるが不完全な評価を提供する。ソフトウエア例外ハンドラは、ＰＩＰＭ  ６０２をプローブし、カレントＩＰ値のカレント翻訳があるか否かを明らかにし、その翻訳のアドレスを探し出す。
【０３８４】
このインプリメンテーションは、『タペストリー』マイクロプロセッサ・チップ上において大きなハードウエア構造をまったく使用しない；たとえば、大きな連想メモリの使用を回避している。このインプリメンテーションは、成功が得られないＰＩＰＭ  ６０２のプローブに関連するオーバーヘッドを抑え、その一方、Ｘ８６プログラムのホット・スポットに置き変わる翻訳であるＴＡＸｉコードに実行が移動する高い尤度を提供する。
【０３８５】
ここで、プロービングが最小正当性に関する条件ではなく、最適化であったことを想起されたい。プローバ６００が生成するプローブ例外が多すぎる場合には、コントロールを移動する翻訳が存在しないことからＰＩＰＭ  ６０２の過剰なプローブが失敗し、コンバータ（図１ａおよび１ｃの１３６）内において適正な実行が再開される。このエラーによって、プローブ例外ハンドラの実行が１つ無駄になる。メカニズムが生成するプローブが少なすぎる場合には、コントロールがＴＡＸｉコードに移動しなくなり、例外が単純にコンバータ１３６内において継続される。このエラーの代償は、（例外の省略の代償にも満たない）機会の看過である。これらのエラーが演算結果における変化を導くことがないため、ヒューリスティックな、必ずしも常に正しくないアプローチが、アーキテクチャ上の正当性の評価基準を侵害することはない。この目標を、イベントの時間、空間、およびクラスを分割し、良好に相関されたインジケータ・ビットとそれぞれのスライスを関連付けするきめ細かい方法を探し出すことによって達成する。
【０３８６】
Ｃ．統計学的プロービングのためのハードウエアおよびソフトウエア構造
前述のセクションＶにおいて、プロファイリングに関して説明した多くの構造は、プロービングにも使用される。
【０３８７】
図４ｂを再度参照するが、プロファイリングに関するイベント・コード分類４０２は、プロービングにも使用される。列６１０は、「プローブ可能」として多数のイベントを指定する。プローブ可能として指定されたイベントは、すべて、Ｘ８６インストラクションまたは割り込みによるコントロールの移動である。移動のディスティネーションにおけるコードは、プローブに関する候補となる。ホット・スポット・ディテクタ１２２は、プローブ可能なイベント・クラスの知識を伴って設計され、検出されたＸ８６ホット・スポットを、そのホット・スポットに到達したコントロール移動が、プローブ可能なイベント６１０の１つである場合に限って翻訳する。つまり、Ｘ８６プログラムがコントロールの移動を実行したとき、その移動がプローブ可能な（６１０）移動の１つであれば、少なくとも理論的にＴＡＸｉコードが存在する可能性があり、プローブ回路の残部がアクティブ化される。
【０３８８】
プローブ可能なイベント６１０は、列６１２において、さらに６つのクラスに分けられる。これら６つのクラスは、「遠い呼び出し」、「エミュレータ・プローブ」、「ｊｎｚ」、「条件付きジャンプ」、「近いジャンプ」、および「近い呼び出し」である。
【０３８９】
再度図４ｈを参照するが、プローブ・マスク６２０は、６ビットの集合からなり、各１ビットは図４ｂに示した６つのプローブ可能なクラス６１２の１つに対応している。プローブ・マスクが「１」のとき、対応するクラス６１２に関するプローブがイネーブルになる−−そのクラスのイベントが発生すると（かつ、その他特定の条件が満たされると；後述する図６ａ〜６ｃの説明を参照されたい）、ハードウエアがプローブ例外をトリガし、ＰＩＰＭ  ６０２のプローブが行なわれる。プローブ・マスク６２０が「０」であれば、対応するクラス６１２のプローブがディセーブルされる−−そのイベントのディスティネーションに関する翻訳が存在する場合であっても、ハードウエアが、翻訳を見つけ出すためのＰＩＰＭ  ６０２のプローブを開始することはない。
【０３９０】
再度図１ｄを参照するが、ＰＦＡＴエントリ１７４は、各物理ページに関するプロパティの５ビット６２４を有している。これらの５ビット６２４は、「遠い呼び出し」、「ｊｎｚ」、「条件付きジャンプ」、「近いジャンプ」、および「近い呼び出し」である（図４ｂの６１２、図４ｈおよび６ｂの６２０、および図６ｂの６６０、６６１、６６２、６６３、６６４−−「エミュレータ・プローブ」プローブは、ページごとのベースで維持されるのではなく、ソフトウエアにより発生される）。ＰＦＡＴプローブ・プロパティ６２４の対応するビットは、ホット・スポット・ディテクタ１２２がホット・スポットを検出し、バイナリ・トランスレータ１２４がネイティブ『タペストリー』翻訳を生成したとき「１」にセットされ、その翻訳に関するプロファイルは、検出され、翻訳されたＸ８６ホット・スポットのエントリを導いたイベントのクラスを表す。所定のページのＰＦＡＴエントリの５ビット６２４は、図６ｂ〜６ｃとの関連から後述するように、プローブ・マスク６２０の対応する５ビットとの論理積が演算され、プローブするべきか否かの決定が行われる。
【０３９１】
図４ｇ、４ｈ、および４ｉを再度参照すると、ＴＡＸｉ＿Ｔｉｍｅｒｓ．Ｐｒｏｂｅ＿Ｔｉｍｅｒ（ＴＡＸｉ＿タイマ．プローブ＿タイマ）６３０は、ＣＰＵクロック周波数によりカウント・ダウンを行う符号なし整数のカウント・ダウン・タイマであり、イベント・クラスごとのベースにおいて、失敗したプローブ例外の平均レートをコントロールするために使用される。Ｐｒｏｂｅ＿Ｔｉｍｅｒ（プローブ＿タイマ）６３０がゼロまでカウント・ダウンすると、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｂｅ＿Ｍａｓｋ（ＴＡＸｉ＿状態．プローブ・マスク）６２０がすべて「１」にリセットされ、Ｐｒｏｂｅ＿Ｔｉｍｅｒ（プローブ＿タイマ）６３０がＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐｒｏｖｅ＿Ｔｉｍｅｒ＿Ｒｅｌｏａｄ＿Ｃｏｎｓｔａｎｔ（ＴＡＸｉ＿コントロール．プローブ＿タイマ＿再ロード＿定数）６３２の値にリセットされる。イベント・コード０．００１１を伴うＲＦＥは、Ｐｒｏｖｅ＿Ｔｉｍｅｒ＿Ｒｅｌｏａｄ＿Ｃｏｎｓｔａｎｔ（プローブ＿タイマ＿再ロード＿定数）６３２からのＰｒｏｂｅ＿Ｔｉｍｅｒ（プローブ＿タイマ）６３０の早期リセットを強制する。
【０３９２】
Ｐｒｏｂｅ＿Ｍａｓｋ（プローブ＿マスク）６２０およびＰｒｏｂｅ＿Ｔｉｍｅｒ（プローブ＿タイマ）６３０は、ともに次に示す振る舞いをもたらす。クラス６１２のプローブが成功している限り、マシンはそのクラスのプローブを継続する。プローブが失敗すると、失敗したプローブのクラス６１２が、Ｐｒｏｂｅ＿Ｍａｓｋ（プローブ＿マスク）６２０内のそのクラスのビットを「０」にセットすることによって、すべてのページに関してディセーブルされる。次にＰｒｏｂｅ＿Ｔｉｍｅｒ（プローブ＿タイマ）６３０がタイムアウトするとき、すべてのクラスが再びイネーブルされる。
【０３９３】
ここで、ホット・スポット・ディテクタ１２２によってホット・スポットが検出された後にＴＡＸｉコード・セグメントがＸ８６バイナリの実行と非同期で作成されたことを想起されたい。翻訳済みコード・セグメントは、不使用となると引き込められる。ＴＡＸｉネイティブ・コード・セグメントは、ラウンド‐ロビン・ベースで、遷移状態にあるとしてマークされ、再利用に使用可能であるとしてキューに入れられる。このコード・セグメントは、遷移状態にある間、すべてのアドレス空間から削除される。ＴＡＸｉコード・セグメントが遷移状態にある間に呼び出されると、遷移キューから出され、呼び出されたアドレス空間にマップされ、アクティブ状態に再セットされる。遷移状態にある間にＴＡＸｉコード・セグメントの呼び出しがなければ、そのセグメントがキューの末尾に到達したとき、ストレージが再利用される。この再利用ポリシーは、Ｄｉｇｉｔａｌ（ディジタル）のＶＡＸ／ＶＭＳ仮想メモリ・システムに類似である。このように再利用ポリシーがいくぶんレイジーであることから、ＰＦＡＴ  １７２は、多少古いことがある。
【０３９４】
図６ａを、図１ｃ、１ｄ、３ａ、および４ｂとともに参照するが、ＰＩＰＭ  ６０２は、ＰＩＰＭエントリ６４０のテーブルである。各ＰＩＰＭエントリ６４０は、３クラスの情報を有している：すなわち、翻訳済みホット・スポットへのエントリ・ポイントとして機能するＸ８６物理アドレス６４２、以前の実行時に有効であり、現在は翻訳済みＴＡＸｉコード・セグメントに対する前提条件として機能しているＸ８６マシン・コンテキスト情報６４６、６４８、および翻訳済みＴＡＸｉコード・セグメントのアドレス６４４である。コンテキスト情報の整数のサイズおよびモード部分６４６は、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ（図４ｃの４３０）内に取り込まれるフォーム、およびＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｇｌｏｂａｌ＿ＴＡＸｉ＿Ｅｎａｂｌｅｓ（ＴＡＸｉ＿コントロール．グローバル＿ＴＡＸｉ＿イネーブルズ）ビット（図４ｇの４７０、４７２）に使用されるフォームに類似するフォームでストアされる。仮想Ｘ８６  ３１０のカレント・サイズおよびモードが、ＰＩＰＭエントリ６４０のサイズおよびモード部分６４６に保存されている状態と一致しない場合には、プローブが失敗する。ＰＩＰＭエントリ６４０の浮動小数点部分６４８は、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ４３０に取り込まれる浮動小数点状態４３５に相当する。これを除けば成功することになるプローブの終結時において、仮想Ｘ８６  ３１０の浮動小数点状態がＰＩＰＭエントリ６４０の浮動小数点部分６４８に保存されている状態と一致しないときには、浮動小数点状態が操作されてＰＩＰＭエントリ６４０の６４８に保存されている状態に一致させられるか、プローブが失敗する。
【０３９５】
図１ｂとの関連から図６ａを参照すると、ＰＩＰＭ  ６０２が最新に維持されて、翻訳のカレント・カタログが使用可能なことを反映し、ＴＡＸｉコード翻訳の追跡がそれらの作成時になされ、再利用に関してマークされ、かつ実際に再利用され無効化されることが示されている。ＰＦＡＴ  １７２内のプローブ・ビットは、わずかに遅れることがあり、ＴＬＢ  １１６内のプローブ・ビットは、さらに遅れることが許容されている。また、ＴＬＢ  １１６内のプローブ・ビットは、ページの細分性に対する情報だけを運ぶ。つまり、ＴＬＢ  １１６内のプローブ・ビットは、最近のある時点において、このページ上にそのエントリ・ポイント・クラスを伴うＴＡＸｉコードがあったことを示す。ＴＬＢ  １１６内のゼロ・ビットは、その種のエントリ・ポイントが存在せず、このイベント・コードに関するＰＩＰＭ  ６０２のプローブは失敗する可能性が高く、したがって試みるべきではないことを示す。「１」は、成功する確率が高いことを示唆する。この「１」は、ある意味で新鮮ではなく、しかもその後に無効化され、再利用されたＴＡＸｉコード翻訳の存在を示している。ＰＩＰＭ  ６０２のプローブにおいては、ＴＬＢ  １１６内におけるヒットの後に、再利用されたＴＡＸｉコード・セグメントに関するＰＩＰＭエントリ６４０がＴＡＸｉセグメントの無効性を示すこと、たとえばアドレス６４４内の「０」によってそれがわかる。
【０３９６】
前述のセクションＶ．Ｇの説明から、ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ（ＴＡＸｉ＿状態．イベント＿コード＿ラッチ）フィールド４８６、４８７およびＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ４３０内にストアされている４ビットのイベント・コードを明確にするためには、５ビットが必要であったことを想起されたい。図４ｂのイベント・コード４０２は、プローブ可能な（６１０）ＲＦＥイベント・コード（上側半分４１０）とプローブ可能な（６１０）コンバータ・イベント・コード（下側半分４０４）が下位４ビットを共有しないように慎重に割り当てられている。プローブ可能な（６１０）ＲＦＥイベント４１０は必ず偶数になり、プローブ可能な（６１０）コンバータ・イベント４０４は必ず奇数になる。このように、カレント・イベント・コードの下位４ビットがプローブ・イベントを固有識別することから、プローブ例外ハンドラは、そのプローブ・イベントがＲＦＥインストラクションから到来したか、あるいはコンバータの実行からもたらされたかを確実に決定することができる。（プローブ可能なイベント６１０にオーバーラップがないことは、前述のセクションＶ．Ｇにおいて説明した「開始パケット」イベント・コード４１８がオーバーラップを有していないことの上に置かれる追加の制約である。）
【０３９７】
再度図６ｂを参照すると、プロービングは、ＰＬＡ（プログラマブル・ロジック・アレイ）６５０およびアンド・ゲートによってコントロールされることがわかる。ＰＬＡ  ６５０は、イベント・コード・ラッチ４８６、４８７からイベント・コード５９２の論理関数をいくつか生成する。ＰＬＡ  ６５０は、図４ｂに示したような「開始パケット」４１８、「プロファイル可能なイベント」４１６、および「プローブ可能なイベント」６１０プロパティを計算する。それに加えて、プローブ可能なイベント・コードが、図４ｂの列６１２に示したように単一の信号にデコーディングされる。たとえば、図１ｄのプローブ・プロパティ６２４のビット＜０＞に対応する「ｊｎｚ」ビット６６０が、イベント・コード１．０００１に割り当てられる。プローブ・プロパティ６２４のビット＜１＞に対応する「条件付きジャンプ」ビット６６１は、イベント・コード１．００１１に割り当てられる。プローブ・プロパティ６２４のビット＜２＞に対応する「近いジャンプ」ビット６６２は、イベント・コード１．０１０１に割り当てられる。プローブ・プロパティ６２４のビット＜３＞に対応する「近い呼び出し」ビット６６３は、イベント・コード１．０１１１および１．１０１１に割り当てられる。プローブ・プロパティ６２４のビット＜４＞に対応する「遠いジャンプ」ビット６６４は、イベント・コード０．１０００に割り当てられる。「エミュレータ・プローブ」ビット６６５は、イベント・コード０．１１００および０．１１１０に割り当てられる。
【０３９８】
Ｄ．統計プロービングの動作
図６ｂおよび６ｃを参照するが、Ｘ８６のコントロール移動インストラクション（コンバータ１３６内において実行される単純なインストラクションもしくはエミュレータ３１６において実行される複雑なインストラクション）に関して、移動ターゲットのインストラクションのフェッチが、そのターゲット・インストラクションのページに関するカレント・プローブ・ページ・プロパティ６２４を伴うＰＦＡＴ  １７２からＴＬＢ  １１６が更新されることを保証している−−情報はすでにＴＬＢ  １１６内においてカレントとなっているか、あるいはインストラクションのフェッチによって導かれたＩ−ＴＬＢミスの一部として補充される。つまり、インストラクションのフェッチの一部として、ＴＬＢが、ターゲット・インストラクションに関するアドレス変換およびプローブ・ページ・プロパティ６２４をともに提供する（ただし、前述のセクションＶＩ．Ｃにおいて説明したが、ＴＬＢ  １１６内のＰＦＡＴプローブ・プロパティは、多少古いことがある）。
【０３９９】
さらに、これらのコントロール移動インストラクションは、前述のセクションＶ．Ｆにおいて説明したように、イベント・コード４０２を生成する。インストラクションの終結時において、コンバータ１３６またはＲＦＥインストラクションが５ビットのイベント・コード５９２を生成する。このイベント・コードは、ラッチ４８６、４８７にストアされる。ターゲット・インストラクションがフェッチされるか、実行が開始すると、ラッチ４８６、４８７のイベント・コードがＰＬＡ  ６５０に供給される。
【０４００】
６つの３入力アンド・ゲート６７０は、プローブ可能なイベント信号６６０、６６１、６６２、６６３、６６４、６６５と、ＴＬＢ（図１ｄの６２４）からの対応するページ・プロパティの論理積を演算してＰｒｏｂｅ＿Ｍａｓｋ（プローブ＿マスク）６２０のカレント値を求める。これら６つの論理積の項は、オア・ゲート６７２において論理和が取られる。つまり、オア・ゲート６７２の出力は、カレント・インストラクションがイベント５９２を生成し、そのイベントのカレントＰｒｏｂｅ＿Ｍａｓｋ（プローブ＿マスク）６２０が「１」であり、かつカレント・ページに関するそのイベントのプローブ・プロパティ・ビット６２４が「１」である場合に限って「１」となる。「エミュレータ・プローブ」信号６６５は、図４ｂの「エミュレータ・プローブ」列６１２によって示されるように、ＲＦＥイベント・コードが０．１１００または０．１１１０に等しいとき、ＰＬＡ  ６５０によって生成される。このプローブのクラスは、エミュレータ３１６によってプローブの成功の可能性が高いと判断され、かつプローブ・マスク６２０のエミュレータ・プローブ・ビット（ビット＜５＞）が「１」となるときに生じる。
【０４０１】
オア・ゲート６７２の出力は、アンド・ゲート６７４においてさらにいくつかの項との論理積が取られる。プロービングは、全体としてＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｐｒｏｂｅ（ＴＡＸｉ＿コントロール．プローブ）６７６（併せて図４ｇを参照されたい）によってコントロールされる；このビットが「０」であれば、プロービングはディセーブルされる。基礎となるＸ８６コードが翻訳の生成以降に修正を受けていないＴＡＸｉコードに対してのみコントロールが移動されることを保証するために、プロービングは、そのページに関するＸＰビット１８４、１８６によるコントロールに従って、Ｘ８６インストラクション・テキストの保護されたページにおいてのみ可能になる（併せて図１ｄ、前述のセクションＩ．Ｆ、および後述のセクションＶＩＩＩを参照されたい）；ＸＰビット１８４、１８６が「０」であれば、そのページに関するプロービングは行なわれない。プロービングは、ＴＡＸｉシステムのコントロール・ソフトウエアによってセットされるＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｇｌｏｂａｌ＿ＴＡＸｉ＿Ｅｎａｂｌｅｓ．ｓｉｚｅ（ＴＡＸｉ＿コントロール．グローバル＿ＴＡＸｉ＿イネーブルズ．サイズ）ビット４７０および．ｍｏｄｅ（．モード）ビット４７２によって、Ｘ８６コンテキストに関してコントロールされる。また、プロービングは、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｇｌｏｂａｌ＿ＴＡＸｉ＿Ｅｎａｂｌｅｓ（ＴＡＸｉ＿コントロール．グローバル＿ＴＡＸｉ＿イネーブルズ）４７０、４７２が「１」にセットされているカレントＸ８６モードに関してのみイネーブルされる。プロービングおよびプロファイリングは、相互に排他である（後述のセクションＶＩ．Ｇを参照されたい）；したがって、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿状態．プロファイル＿アクティブ）が「１」にセットされているときにはプロービングがディセーブルされる（図４ｈの４８２、図５ａの状態５３０および５４２；前述のセクションＶ．ＥおよびＶ．Ｆを参照されたい）。アンド・ゲート６７４の出力６７８が「１」であれば、プロセッサは、ＰＩＰＭ  ６０２のプローブを行うか否かを決定する次のステップに進むが、それについてはさらに詳細を後述する。
【０４０２】
ＴＡＸｉが準備されていないモード、たとえばＸ８６のデバッギング、シングル‐ステップ、あるいは浮動小数点エラー条件にＸ８６プロセッサが入ると、ソフトウエアによってＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｐｒｏｂｅ（ＴＡＸｉ＿コントロール．プローブ）６７６が「０」にされる。「ページ・プロパティ処理ディセーブル」モード（ＰＲＯＣ＿ＣＴＲＬ．ＰＰ＿Ｅｎａｂｌｅ（ＰＲＯＣ＿ＣＴＲＬ．ＰＰ＿イネーブル）の表明解除を伴う；前述のセクションＩ．Ａを参照されたい）において動作しているとき、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｐｒｏｂｅ（ＴＡＸｉ＿コントロール．プローブ）６７６は、表明が解除される。
【０４０３】
アンド・ゲート６７４の出力６７８は、プローブ・イベント・クラスの単一のビットをＤｅｃｏｄｅｄ＿Ｐｒｏｂｅ＿Ｅｖｅｎｔ（デコード済み＿プローブ＿イベント）ラッチ６８０内にラッチする。
中間ステップ６９０は、ハードウエア内において実行され、オプションとしてここで実行することができるが、その詳細については後述するセクションＶＩ．Ｅにおいて説明する。
【０４０４】
以上のすべてのハードウエア・チェックにパスすると、プロセッサは、コントロール移動のターゲットにおけるインストラクションの実行を完了する前に、プローブ例外を取る。このプローブ例外は、コントロールをソフトウエアに移動し、それにおいてコントロールをＴＡＸｉコードに移動するべきか否かについて、さらに吟味が行なわれる。
【０４０５】
プローブ例外の生成の一部として、コンバータ１３６（ステップ６８２）は、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ（図４ｃの４３０）をプロファイル収集用に定義されたＴＡＸｉ＿Ｃｏｎｔｒｏｌ．Ｐａｃｋｅｔ＿Ｒｅｇ＿Ｆｉｒｓｔ（ＴＡＸｉ＿コントロール．パケット＿レジスタ＿先頭）（図４ｇの４７６）によって示されるレジスタ内に書き込む。（さらに詳細を後述のセクションＶＩ．Ｇにおいて説明するが、プロファイリングおよびプロービングは、相互に排他であり、Ｘ８６がプロファイル・レジスタを使用することはなく、したがってこの用法が衝突を招くことはない。）プロファイル・エントリ４３０のイベント・コード（図４ｃの４３６）は、カレント・イベント・コード（図５ｂの５９２）の下位４ビットにセットされる。
【０４０６】
プローブ例外ハンドラに入る時点で、次に示す情報がコンバータから得られている。
・  下位半分４３８、４３９にＸ８６物理ＩＰ（ページ・フレーム番号およびページ・オフセット）を含むＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ４３０
・  Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）４３０の上位半分４３２、４３３、４３５からのＸ８６実行コンテキスト
・  Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）４３０のイベント・コード・フィールド４３６内のプローブ・イベント・コード
・  ＥＰＣ．ＥＩＰからのＸ８６仮想ＩＰ（ＣＳセグメント内のオフセット）
【０４０７】
例外ハンドラは、ＰＩＰＭ  ６０２を調べる。ＰＩＰＭ  ６０２は、Ｘ８６インストラクション・アドレス（それらの物理アドレス；アドレス変換後）をＴＡＸｉコード・セグメントにマップするテーブルである。ＰＩＰＭ内のテーブル・エントリは、Ｘ８６物理アドレスによってインデクスされ、通常は従来のハッシング・テクニックもしくはその他のテーブル・ルックアップ・テクニックを使用する。プローブ例外ハンドラは、物理ＩＰ−ＴＡＸｉコード・エントリ・ポイント・マップ（ＰＩＰＭ）６０２内のターゲット・インストラクションの物理アドレスをルックアップする。
【０４０８】
Ｘ８６アドレスに一致するＰＩＰＭエントリ６４０が見つからなかった場合には、後述する結果を伴ってプローブが失敗する。
アドレスが一致するテーブル・エントリが見つかった場合にも、カレントＸ８６モードによってさらに翻訳の適否を判断する必要がある。ここで、Ｘ８６インストラクションの完全な実行セマンティクスが、インストラクション自体のビットによって完全に指定されていなかったことを想起されたい；実行セマンティクスは、プロセッサがＶ８６モードにあるか否か、物理アドレスであるか仮想アドレスであるか、浮動小数スタック・ポインタ、および浮動小数点レジスタの満／空状態といったことに依存し、オペランド・サイズはセグメント記述子、ＥＦＬＡＧＳレジスタ、浮動小数点ステータス・ワード、浮動小数点タグ・ワード等にエンコーディングされている。『タペストリー』ネイティブ・コードへの翻訳は、これらのステータス・ビットに関する仮定を埋め込んでいる。これらのステータス・ビットは、当初、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ４３０のビット＜５９：５１＞に取り込まれた後（前述のセクションＶ．Ｃを参照されたい）、ホット・スポット・ディテクタ１２２およびバイナリ・トランスレータ１２４がモード・ビットのプロファイル済みの値に基づいて翻訳を生成する。翻訳に対応するＰＩＰＭエントリ６４０は、ＴＡＸｉコード・セグメントの作成に用いられたモード・ビットの仮定を記録している。このため、ＰＩＰＭエントリ６４０が見つかった後、ＰＩＰＭエントリ６４０内にストアされているＸ８６モードとカレントＸ８６モードを比較する。
【０４０９】
例外ハンドラがＰＩＰＭ  ６０２内のモード情報について行うチェックには、３つの包括的なクラスがある。
第１に、カレント実行モードと、ＴＡＸｉトランスレータ１２４によって仮定されたＣＳ．Ｄ（コードおよびオペランドのサイズ）およびＳＳ．Ｄ（スタック・セグメント・サイズ）ビットの値に互換性がなければならない。これは、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）引数からのデコーディング済み「ｓｉｚｅｓ（サイズ）」情報４３２とＰＩＰＭエントリ６４０の６４６内に提供されている許容可能コンテキストのマスクを比較することによって決定される。
【０４１０】
カレント浮動小数点状態がＰＩＰＭエントリ６４０内の浮動小数点状態６４８に一致しないときには、プローブが失敗する。場合によっては、不一致を解決することができる：すなわち、浮動小数点ユニットのアンロードおよび再ロードを行い、ＰＩＰＭエントリ６４０内の浮動小数点状態に適合させ、たとえば、カレントＸ８６浮動小数点マップによって指定される規範的なロケーションに浮動小数点レジスタを入れる。浮動小数点レジスタ・スタックの高さがＰＩＰＭエントリ６４０内のスタックの高さに一致しないとき、あるいは疑似浮動小数点タグ・ワードが一致しないとき、もしくは浮動小数点コントロール・ワード（精度および丸めモード）が一致しないときには、プローブが失敗する。不一致が浮動小数点タグ・マップのマッピング（Ｘ８６スタック‐ベースのレジスタ・モデルからレジスタ・アドレス『タペストリー』モデルへのマッビング）だけである場合は、ソフトウエアが浮動小数点状態を再構成してプローブを成功させることができる。
【０４１１】
実行コントロールがＴＡＸｉコードに渡される。モードが一致しなければ、プローブが失敗する。
第２に、このＴＡＸｉフラグメントの起動によって到達可能なＴＡＸｉコード・ポイントの過渡的な閉止（の保守的な近似）が、ＣＳリミット例外をトリガしないようなカレント仮想ＩＰ値としなければならない。これは、例外の時点における仮想ＩＰおよび正規化されたＣＳリミットから決定され、それらをＰＩＰＭエントリ６４０にストアされている値と比較することによって判断される。
【０４１２】
第３に、ＸＰビットのＴＬＢコピー１８６がＸＰビットのＰＦＡＴコピー１８４よりわずかに古くなることから、ＰＦＡＴ  １７２内のＸＰビット１８４のマスタ・コピーをチェックし、そのＸ８６ページに関連付けされたすべてのキャッシュ済みの情報が（プロファイルおよびＴＡＸｉコード）まだ有効であることを確認する。
【０４１３】
第４として挙げるのであれば、そのＸ８６ページがＤＭＡ書き込みによって無効化されていないことを確認するために、ＤＭＵ  ７００（後述のセクションＶＩＩを参照されたい）に対するクエリが行なわれることがある。
カレントＸ８６モードがこれらのモード・チェックを満足するとき、プローブは成功である。ＰＩＰＭエントリ６４０が、プローブ例外が生じたＸ８６コードのアドレスに対応するＴＡＸｉコードのアドレスを有していることになる。なおモードが不一致であれば、プローブは失敗である。
【０４１４】
プローブ例外が成功すると、ハンドラは、ＥＰＣ．ＴＡＸｉ＿Ａｃｔｉｖｅ（ＥＰＣ．ＴＡＸｉ＿アクティブ）４８２をセットし、ＥＰＣ．ＩＳＡ（ネイティブ『タペストリー』モード）をゼロにし、ＥＰＣ．ＥＩＰをＴＡＸｉコードのアドレスにセットし、かつＥＰＣ．ＥＳＥＧを特殊ＴＡＸｉコード・セグメントにセットすることによってＥＰＣを修正する。ＲＦＥインストラクションが、このＥＰＣを実際のプロセッサＰＳＷにロードすることによって、ＴＡＸｉコードに対する実行の移動を完了する。プローブが成功すれば、Ｐｒｏｂｅ＿Ｍａｓｋ（プローブ＿マスク）６２０は変更されない。つまり、プローブ可能なイベントのクラスは、そのクラスのプローブが成功している間は、イネーブルのまま維持される。
【０４１５】
ＥＰＣ．ＥＩＰをリセットしてＴＡＸｉ翻訳済みコードをポイントさせることによって、ＲＦＥインストラクションは、プローブ例外ハンドラのエンドにおいてＴＡＸｉコードへの遷移をもたらす。ＴＡＸｉコードは、Ｘ８６コードから翻訳されていることからＸ８６規約に従い、そのため遷移例外ハンドラによって実行されることになっていた引数のコピー（前述のセクションＩＩ、ＩＩＩ、およびＩＶを参照されたい）は必要なくなる。さらに、プローブ例外ハンドラおよびＴＡＸｉコードがともに『タペストリー』ＩＳＡであることから、この最終的な遷移においてはプローブ例外が発生しない。
【０４１６】
プローブ例外がトリガされたが、ソフトウエア・プローブが翻訳を見つけられなかった場合には、いくつかのステップが取られる。プローブをトリガしたイベントに対応するＰｒｏｂｅ＿Ｍａｓｋ（プローブ＿マスク）６２０内のビットが「０」にクリアされ、次のＰｒｏｂｅ＿Ｔｉｍｅｒ（プローブ＿タイマ）６３０のライムアウトまで、イベントのこのクラスに関するプローブがディセーブルされる。これは、Ｐｒｏｂｅ＿Ｆａｉｌｅｄ（プローブ＿失敗）ＲＦＥ信号およびＤｅｃｏｄｅｄ＿Ｐｒｏｂｅ＿Ｅｖｅｎｔ（デコード済み＿プローブ＿イベント）ラッチ６８０によって達成される。割り込みサービス・ルーチンは、図４ｂの２つの特殊な「プローブ失敗」イベント・コードの１つを伴うＲＦＥを使用する。イベント・コード０．００１１は、ＴＡＸｉ＿Ｔｉｍｅｒｓ．Ｐｒｏｂｅ＿Ｔｉｍｅｒ（ＴＡＸｉ＿タイマ．プローブ＿タイマ）６３０に、Ｐｒｏｖｅ＿Ｔｉｍｅｒ＿Ｒｅｌｏａｄ＿Ｃｏｎｓｔａｎｔ（プローブ＿タイマ＿再ロード＿定数）６３２を強制的に再ロードする。イベント・コード０．００１０は、Ｐｒｏｂｅ＿Ｔｉｍｅｒ（プローブ＿タイマ）６３０に対する副次的な効果を有していない。逆方向ブランチに関するプローブが失敗したときには、それ以上のプローブ例外を伴うことなく、完全なタイマ値にわたってループの実行を可能にするためにイベント・コード０．００１１のＲＦＥを用いてプローブ例外からリターンすることによりＰｒｏｂｅ＿Ｔｉｍｅｒ（プローブ＿タイマ）６３０をリセットすることが期待される。それに対して、「近い呼び出し」に関するプローブが失敗した場合には、Ｐｒｏｂｅ＿Ｔｉｍｅｒ（プローブ＿タイマ）６３０のタイムアウトの直後に同一のページからのほかの「近い」呼び出しの吟味が可能になることが期待され、したがってこのプローブ例外は、イベント・コード０．００１０を伴ってリターンすることになる。このＲＦＥはプローブ例外のポイントにリターンし、コンバータ１３６内において実行が再開される。
【０４１７】
プローブ・タイマのタイムアウトによるＰｒｏｂｅ＿Ｍａｓｋ（プローブ＿マスク）６２０のリセットと同時に、Ｐｒｏｂｅ＿Ｍａｓｋ（プローブ＿マスク）６２０を修正するＲＦＥインストラクションの実行がある場合、ＲＦＥアクションの方が優先順位が高いことから、リセット要求が破棄される。
【０４１８】
Ｅ．その他のプロービングの特徴
中間ステップ６９０については、先に簡単に触れたが、これにおいてはビットのビット・ベクトルを調べ、翻訳が、ＰＦＡＴプローブ・ビット内にエンコーディングされたページ・レベルよりいくぶん細かいコード範囲にわたって存在する場合が明らかにされる。プローブ可能なイベントが発生し、そのイベントのクラスが、ＰＦＡＴプローブ・ビットおよびプローブ・マスクに対してスクリーニングされると、プローブ例外を実際に発生してコントロールをソフトウエア割り込みハンドラに移す前に、ハードウエアが（ページ翻訳テーブルの場合と多少類似するオペレーションにおいて）ビット・ベクトルの吟味を行う。
【０４１９】
実際にソフトウエアによってインスタンスが作られるのは、ゼロでないＰＦＡＴプローブ・ビットを伴うページに対応するビット・ベクトルのスライスだけであり、それにおいても完全なページ・テーブル・ツリーの関連部分に限り、仮想メモリ・システムによってインスタンスが作られる場合との類似が見られる。ビット・ベクトル自体はＸ８６アドレス空間から隠されており、プローブ・ビット・ベクトルならびにＸ８６仮想マシンをマネージするためのそのほかの構造用に予約されているアドレス空間内にある。このビット・ベクトルは、ｄ−キャッシュ内にキャッシュすることができる−−これより以前のステップによって提供されるフィルタリングによって、プローブ・ビット・ベクトルのクエリが失敗する回数が比較的小さくなる。
【０４２０】
ビット・ベクトルの密度は、システムのオペレーションに関して調整することが可能である。一部の実施態様においては、物理メモリ・システム内の各バイトごとに１ビットが用意される。別の実施態様においては、たとえば物理メモリの２、４、８、１６、あるいは３２バイトごとに１ビットといった形で、２のべき乗の小さい値ごとに１ビットを持つようにしても、ビット・ベクトルの有効性が、可能性としてはほとんどわずかしか失われない。ビット・ベクトルの各ビットによってガードされるブロック・サイズは、ソフトウエア構成可能とすることもできる。
【０４２１】
つまり、ＰＦＡＴ  １７２内のプローブ・プロパティ６２４は、イベント・コード（プローブ可能な５つのイベント・クラス）によってきめ細かいフィルタリングを提供するが、空間的には粗く（ページ・ベース）、それに対してビット・ベクトルは、イベント・コードに関しては粗いマップを提供するが（単一ビット内にすべてのイベントがグループ化される）、空間的にはきめが細かい（数バイト）ものとなる。
【０４２２】
ビット・ベクトル内のビットが「１」であることは、翻訳が存在し、かつアクティブ化されることを保証するものではない。ＰＦＡＴプローブ・ビットの場合と同様に、ビット・ベクトルもいくぶん過度に楽観的なヒューリスティックであり、実際の翻訳済みコード・セグメントの母集団に遅れていることもある。ビット・ベクトルの吟味の後においても、ＰＩＰＭ  ６０２内のモード述部の検証を行うべきである。
【０４２３】
テーブルのサーチに使用される疑似マイクロコードを用いたハードウエアは、容易に修正可能であり、それによりビット・ベクトルの適切なスライスをフェッチするようにメモリに対するロードを発することができる。
【０４２４】
ＰＬＡ  ６５０のロジックは、少なくとも当初の製造間においてプログラム可能である。再プログラミングは、図４ｂの列４１４、４１６、４１８、６１０、６１２の内容の変更を招くことがある。コンバータ１３６によって生成される５ビットのコードは、比較的固定されてはいるが、これらのビットに与えられている解釈は、プロファイルであるかプローブであるかによらず、ＰＬＡ  ６５０内において再構成することができる。別の実施態様においては、図４ｂに示した列の内容を変更することによって、プロファイリングおよびプロービングのオペレーションをコントロールできるように、ＰＬＡ  ６５０がランタイムにおいてプログラム可能となる。ＰＬＡ  ６５０に対する５ビットの入力（イベント・コード・ラッチ４８６、４８７）から、２５＝３２の可能性のある入力が得られる。一方、出力は９ビットである（プローブ可能なイベントの信号６６０、６６１、６６２、６６３、６６４、６６５、プロファイル可能なイベント４１６、開始パケット４１８、およびプローブ可能なイベント６１０）。したがって、ＰＬＡ  ６５０を３２％９のＲＡＭによって置き換えることが可能であり、それによりＰＬＡ  ６５０の出力が完全にソフトウエア構成可能になる。その種のプログラム可能性を用いれば、プロファイリング（前述のセクションＶ）およびプロービング（このセクションＶＩ）がともに完全に構成可能になる。プログラム可能とする実施態様においては、プロファイリングならびにプロービングのオーバーヘッドをコントロールし、ストラテジを経験に適応させることができる。
【０４２５】
プローブに求められる属性のほとんどは、ページに関連付けされているか（ＰＦＡＴおよびＴＬＢ内にストアされる）、あるいは個別に翻訳されるコード・セグメントに関連付けされており（ＰＩＰＭ  ６０２内にストアされる）、単純なＸ８６インストラクションとしてコンバータ１３６によるクエリが行なわれる構造は、ハードウエアにおいて実行される。エミュレータ（図３ａの３１６）において実行される複雑なインストラクションについては、プローブを行うか否かの決定がソフトウエア内においてなされる。アドレス変換ページ・テーブルに対する注釈サイド・テーブルとしてＰＦＡＴがあるように、Ｘ８６  ＩＶＴ（割り込みベクトル・テーブル）にプローブの属性を注釈するサイド・テーブルがある。Ｘ８６インストラクションのエミュレーションの後、エミュレータ３１６は、ＩＶＴサイド・テーブルに対してクエリを行い、エミュレーションの間に決定されたマシン状態とともにこれらのビットを分析する。このクエリに基づいて、エミュレータ３１６は、プローブを導いたイベント・コードを伴うＲＦＥを使用してコンバータ１３６にリターンするか、あるいはそれ以外のイベント・コードを伴うＲＦＥを使用してリターンするかを決定する。イベント・コード０．１１００および０．１１１０はプローブを誘導し（図４ｂの列６１０を参照されたい）、イベント・コード０．１１０１および０．１１１１は誘導しない。
【０４２６】
Ｆ．ＴＡＸｉコードの実行完了およびＸ８６コードへのリターン
プローブ例外がＸ８６プロセス内において何らかの翻訳済みＴＡＸｉコードをアクティブ化した後に、ＴＡＸｉコードを離れる方法は次の３つしか存在しない：すなわち、翻訳済みセグメントのボトムにおける正常な終了、コード・セグメントの外へのコントロールの移動、および例外を介した非同期終了である。
【０４２７】
ボトムから離脱するケースは、ＴＡＸｉトランスレータ１２４によって生成されるエピローグ・コードによって処理される。ＴＡＸｉコードは、すべてのＸ８６マシン状態を復帰し、トラップ・インストラクションを発行することによってコントロールをコンバータに返す。このトラップ・インストラクションは、ＴＡＸｉ＿ＥＸＩＴ（ＴＡＸｉ＿終了）例外に関する例外ハンドラにコントロールを移動する。ＴＡＸｉコードを終了するためのトラップ・ハンドラは、ＩＳＡをＸ８６にセットし、翻訳済みのホット・スポットに続くＸ８６コード内のポイントにコントロールを戻す。セクションＩＶに述べた別の実施態様においては、エピローグ・コードがデータをそれらのＸ８６ホームに返し、翻訳されたＸ８６コードの部分の末尾に続くポイントをＩＰがポイントするようにセットする。
【０４２８】
コントロールを移動するケースは、前述のセクションＩＩＩにおいて説明した状態保存メカニズムによって、あるいは上記のエピローグ・コードと基本的に類似するコードによって処理することができる。いずれの場合においても『タペストリー』システムは、Ｘ８６マシン状態を再構成する明確なアクションを取る。
【０４２９】
非同期終了は、前述のセクションＩ．Ｄにおいて紹介したセーフティ・ネット・メカニズムを使用して処理され、それについては後述のセクションＶＩＩＩにおいて、より詳細に説明する。ＴＡＸｉコード内において例外が発生し、例外ハンドラが、Ｘ８６仮想マシン内においてその例外を具体化しなければならないと判断すると、Ｘ８６状態のセットを担うエミュレータ３１６内の共通のエントリにジャンプする−−これにより、割り込みスタック・フレームが設定され、ＩＤＴがアクセスされ、コントロールの移動が行われる。この機能は、呼び出されたとき、まずＰＳＷ．ＴＡＸｉ＿Ａｃｔｉｖｅ（ＰＳＷ．ＴＡＸｉアクティブ）１９８を調べることによってＴＡＸｉコードが実行されていたか否かを決定しなければならず、実行されていた場合には、Ｘ８６マシン状態を再構成するＴＡＸｉ機能にジャンプし、続いてコンバータ内において、同一の例外を誘発するＸ８６インストラクションを再実行する。このＸ８６インストラクションの再実行は、正しいＸ８６例外状態を確立するために必要となる。Ｘ８６インストラクションの再実行のためにコンバータが開始された場合には、例外ハンドラが必ず、プローブの失敗とともにＲＦＥを使用し、プローブ・タイマ・イベント・コードを再ロードして、再帰的なプローブ例外の発生を回避する。
【０４３０】
Ｘ８６の世界で具体化されない例外は、ネイティブ『タペストリー』コードによって完全に実行される例外だけであり、たとえばページ違反を伴わずに満足されるＴＬＢミス、マスクされていないＸ８６浮動小数点例外を伴わないＦＰ不備等がある。
【０４３１】
Ｇ．プロービングとプロファイリングの対話
プロービングとプロファイリングは、相互に排他的である。プローブは、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿コントロール．プロファイル＿アクティブ）（図４ｈおよび５ａの４８２）が「０」となっている間にプローブ可能なイベント（図４ｂの列６１０）があるときに限って起こり得る。この制約は、図６ｂのアンド・ゲート６７４によって強制される。これに対してプロファイリングは、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿コントロール．プロファイル＿アクティブ）４８２が「１」でなければイネーブルされない。このように、プロセッサがプローブ例外を取るときには、相互排他によってプロファイリングによって使用されるリソースが活動しないことが保証される。より詳細に述べれば、プロファイル・パケットが蓄積される汎用レジスタを例外サービスに使用できることが保証されるということになる。
【０４３２】
各プローブ可能なイベント６１０は、「開始パケット」イベント４１８でもある。このことは、実用的な設計上の考慮事項を反映している：すなわち、プローブ可能なイベント６１０のクラスは、プログラムのフローの中でもっとも重要なイベントであり、「開始パケット」イベント４１８は、その重要なイベントを多少広げたセットである。プローブがイネーブルされているクラスにおいてプローブ可能なイベント６１０が発生し、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿コントロール．プロファイル＿アクティブ）（図４ｈおよび５ａの４８２）が「０」であれば、そのイベントは「開始パケット」イベント４１８にもなる。さらに、ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿要求）４８４が「１」であれば、プロファイラ４００が、自動的にＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ（ＴＡＸｉ＿コントロール．プロファイル＿アクティブ）（図４ｈおよび５ａの４８２）およびＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ｒｅｑｕｅｓｔ（ＴＡＸｉ＿状態．プロファイル＿要求）４８４の遷移、つまり図５ａの遷移５２２をトリガする。これは、相互排他を侵害することになる。しかしながら、プローブ例外は、プロファイラ４００のすべてのアクティビティより優先度が高い。したがって、プローブの成功に応答してコントロールがＴＡＸｉコードに移され、あらゆるプロファイラのアクションが抑圧される。このプローブが失敗すれば、プローブのクラスがディセーブルされ、プロファイラ４００に、図５ａならびに５ｂ、および前述のセクションＶ．Ｆにおいて示したような正常な進路を取ることが許される。
【０４３３】
プロファイル・パケットの内容、特にＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ（図４ｃの４３０）は、ホット・スポット・ディテクタ１２２によって要求される情報を効率的に表現するため（頻繁に実行されるインストラクションがストアされているアドレスの範囲を正確に識別するため）に調整され、かつＴＡＸｉトランスレータ１２４用に効率的に調整され（コード・テキスト自体の中には現れていないＸ８６のセマンティック・モード情報を捕捉するため）、かつＴＡＸｉプローバ６００用に効率的に調整される（プロービングの適否を判断し、ＴＡＸｉコードにコントロールを移動する前に、バイナリが翻訳されたセマンティック・モードの仮定がカレントＸ８６セマンティック・モードに適合することを確認するために必要な情報）。その表現は、これら３つのいずれか１つに最適であるということはないが、３つのいずれに対しても極めて良好である。別の実施態様においては、上記３つのうちの１つの効率をほかよりも助長するため、あるいは１つの恩典だけのために表現を調整することができる。
【０４３４】
プローブ可能なイベント６１０が「開始パケット」イベント４１８のサブセットであるという事実は、さらに望ましい副次的な効果を有する：すなわち、パケット内の最初のプロファイル・エントリ４３０を取り込むハードウエアが、プローブ例外ハンドラによって必要な情報の捕捉に再使用可能になる。プローブ例外を引き渡すハードウエアに関して決定がなされるとき、例外ハンドラに対して、コントロールが渡された物理アドレスならびにマシンのコンテキストに関する情報が提供される。プローブ例外に関する情報は、Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ４３０内に取り込まれるフォームを反映するフォームで図５ｂのレジスタ５９４内に集められる。ハードウエア内においてプローブ例外を生成するプロセスもしくはソフトウエア内においてサービスするプロセスのいずれにおいても、レジスタ５９４の内容が汎用レジスタの中に取り込まれる。この取り込みは（Ｘ８６セグメント記述子レジスタ内にストアされているＣＳリミット（コード・セグメント長）が補われたとき）、プローブ例外ハンドラによって必要とされる情報を提供する：すなわち、ＰＩＰＭ  ６０２をインデクスし、可能性のあるエントリの候補を見つけるために使用される次のインストラクションの物理アドレス、およびそのエントリの適否を判断するために必要なＸ８６モード情報である。Ｃｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）４３０に取り込まれるアドレスは、ＰＩＰＭ  ６０２へのインデクスに直ちに使用できる物理ページ番号を有している。すべてのプローブ可能なイベントが「開始パケット」イベントであることから、モード情報は、ホット・スポットを識別するパケットを開始したＣｏｎｔｅｘｔ＿Ａｔ＿Ｐｏｉｎｔ（コンテキスト＿アット＿ポイント）プロファイル・エントリ４３０内において容易に得られる。また、適切なビットの論理積を求めることにより、互換性に関して各種のスナップショットを互いに比較することができる。
【０４３５】
周期的なサンプリングによって運用されるプロファイル収集とは異なり、プロービングは、コンバータがアクティブであり、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｐｒｏｂｅ（ＴＡＸｉ＿コントロール．プローブ）フラグが「１」であり、かつプローブ・マスクの少なくとも１つのビットが「１」である限り、常にイネーブルされる。
【０４３６】
Ｈ．  適応便宜的統計技法の代替使用
セクションＶＩ．Ａ〜ＶＩ．Ｅにおいて説明した適応型日和見的実行ポリシーは、ＣＰＵ設計における多数のセッティングに使用することができる。
【０４３７】
一実施例においては、ＣＰＵが浮動小数点ユニットを通る高速パスおよび低速パスを有し、それにおいて高速パスは、ＩＥＥＥ−７５４の浮動小数点の無限大、逆正規化数（「ｄｅｎｏｒｍｓ（デノルム）」）およびＮａＮの完全なインプリメンテーションを省略し、低速パスは、完全なハードウエア・インプリメンテーションを提供する。無限大、デノルム、およびＮａＮは、頻繁に発生する傾向にないが、生成されると逐次より多くの演算に伝播される傾向にあることから、デノルムもしくはＮａＮが生じないという楽観的な仮定の下に開始し、高速パスを使用するべくＣＰＵを構成することは有利である。無限大、デノルムもしくはＮａＮが検出されると、ＣＰＵは、低速パスに戻ることができる。タイマをセットして起動し、それがタイムアウトしたとき、ＣＰＵは、高速パスの再開を試みる。
【０４３８】
別の実施態様においては、類似の適応型日和見的テクニックをキャッシュ・システムに使用することができる。たとえば、マルチ‐プロセッサのキャッシュは、プロセッサ間バスの監視によってキャッシュ内の多くのデータが共有されていることが示されるときはライト‐スルー、共有データがメッセージ・ボードとして集中的に使用されていることが示されるときはライト‐イン、バスの監視によってデータがほとんど共有されていないことが示されるときはライト‐バックという形でキャッシング・ポリシーを切り替えることができる。キャッシュ・ラインのフラッシュまたは無効化は、よりコストの高いポリシーに実行を戻さなければならないことを通知する「失敗」であり、それに対してよりコストの低いポリシーにおいて書き込みに成功すると、「成功」によってよりコストの低いポリシーの継続的な使用が可能になる。この適応は、アドレス範囲を基準に、明確なアドレス範囲に関して維持される成功および失敗の記録を用いて管理することができる。モード間の切り替えのマネージには、多くのテクニックを使用することができる。たとえば、カウンタを用いて、キャッシュが別のモードにあればより効率的に処理されたと見られる連続的なメモリ・アクセスの数をカウントする。そのカウンタの数がスレッショルド値に達すると、キャッシュを別のモードに切り替える。あるいは、タイマによりキャッシュをより楽観的なモードにセットし、その楽観性の仮定を侵害するアクセスがあると、キャッシュをより楽観的でないモードにセットすることも考えられる。
【０４３９】
日和見的ポリシーは、ブランチの予測、キャッシュのプリフェッチ、あるいはキャッシュのイネーブルにも使用することができる。たとえば、キャッシュのプリフェッチを、プリフェッチが成功している限り機能させる。あるいはプリフェッチが継続的に成功している限り、ループ内の特定のＬＯＡＤ（ロード）インストラクションを、キャッシュのプリフェッチのための候補として識別してもよい。プリフェッチが失敗したときに、プリフェッチをディセーブルする。
【０４４０】
楽観的な仮定の下にマルチ−プロセッサのキャッシュが特定のデータをキャッシュし、その後、プロセッサ間のキャッシュのトラッシュによってそれらのデータをキャッシュすることが有益でないと示されたとき、それらのデータをキャッシュ可能でないとしてマークすることも考えられる。
【０４４１】
また日和見的ポリシーは、オブジェクト指向メモリ・システムにおいてメモリのあいまい性を除去する上でも役立つと見られる。たとえば、コンパイラが１つのソース構成に対して２つの代替コーディングを生成し、一方は共通の元を持たないと仮定し、他方はオーバーラップがあると仮定する。共通元を持たないとする楽観的なコードは、楽観的な仮定が維持されている限り使用するが、それが維持されなくなったとき、コントロールが楽観的でないコードに戻る。
【０４４２】
ＶＩＩ  変換された命令の確認と無効化
ＴＡＸｉシステムは複雑キャッシュ(complex cache)と相似であり、プロファイルデータおよびＴＡＸｉコードはＸ８６の命令テキストのページと共に現行のままであるが、Ｘ８６の命令テキストが修正された時には無効にされなければならない。Ｘ８６命令テキストを修正する可能性を有する原因として、ＣＰＵによるメモリの書込みおよびＤＭＡデバイスからの書込みという２つの原因がある。上記のセクションＩ．Ｆで論じられたように、ＣＰＵからの書込みはＸＰ保護ビット１８４、１８６によって保護され、上記のセクションＶＩ．ＣおよびセクションＶＩ．Ｄで論じられたように、ＰＩＰＭ６０２内で有効性をチェックする。このセクションＶＩＩでは、キャッシュされた情報を、ＤＭＡの書込みによるＸ８６命令テキストの修正に対して保護することについて論じる。
【０４４３】
図７ａを参照すると、ＤＭＵ７００（ＤＭＡ監視ユニット）はＡＳＩゼロ（アドレス空間ゼロ、「挙動の正しい」(well−behaved)非Ｉ／Ｏ空間）へのＤＭＡ書込みを監視し、ページフレーム修正の形跡を圧縮して提供する。ＤＭＵ７００は過剰なオーバーヘッドを必要とせずにこの監視を実行する。ＤＭＵ７００は、主プロセッサバス（Ｇバス）上で直接実装されるのではなく、Ｉ／Ｏゲートウェイ内でＩ／Ｏデバイスとして実装される。このためＤＭＵ７００には、物理メモリ内のＸ８６コードページに関する、すべての非プロセッサの更新を検出する可視性が与えられる（書戻しキャッシュの挙動によってマスキングされている、プロセッサ自体によって開始された更新は除く）。
【０４４４】
Ａ．単純化されたＤＭＵモデル
簡単なＤＭＵは、システム内の各物理ページフレームに関して、修正されたページフレーム（ＭＰＦ）ビットを提供する。ゼロのＭＰＦビットは修正が発生しなかったことを示し、ＤＭＡ移動(transfer)を対応するページフレームに書き込む場合、修正イベントをそのページフレームに対して報告する必要がある。１のＭＰＦビットは、対応するページフレームへのＤＭＡ書込みは報告せずに通過すべきであることを示す。
【０４４５】
この簡単なＤＭＵは、すべてのＭＰＦビットをゼロにすることによって開始される。ついで、各ＤＭＡ書込みに関して、関連するＭＰＦビットがチェックされる。そのＭＰＦビットがすでに１である場合、次の処理は発生しない。ＭＰＦビットがゼロのままである場合、そのビットは１に設定され、たとえばＦＩＦＯ内に項目を作成することによって、修正されたページフレームの識別(identity)が報告される。ページフレームのＭＰＦビットが１になり修正が報告されると、そのページフレームへさらにＤＭＡ書込みがあっても、別の修正レポートが生成されることはない。
【０４４６】
この簡単なＤＭＵは、ページの修正の報告を非常に圧縮する。事実、これによって、生成される修正レポートの数はおそらく最小になる。ＤＭＵ７００自体はどのＭＰＦビットもゼロにすることはなく、1に設定するだけだという事実から証明される。修正レポートの可能な数はＭＰＦビットの数、または同じ意味であるが、ページフレームの数によって制限される。ほとんどのＤＭＡ書込みは「データ」Ｉ／Ｏに関するバッファページへの書込みであるが、監視されるべき重要な書込みはＸ８６命令テキストのページへの書込みであり、この書込みはそれほど頻繁には発生しないので、この挙動はオーバーヘッドを低減し、正しい挙動を維持する。
【０４４７】
ページフレームのＭＰＦビットがゼロである限り、ＴＡＸｉシステムは、ＭＰＦビットが最後にゼロに消去されてからはＤＭＡ修正が発生していないことが確認される。このように、プロファイラ４００がＸ８６ページをプロファイルしようとする時、ＴＡＸｉ変換を生成しようとする時、ＴＡＸｉ変換を実行しようとする時はいつでも（そのページに関する情報をキャッシュするまたはキャッシュされた情報を使用する動作）、そのページのＭＰＦビットはゼロにされ、保留中の修正レポートを含む可能性のある任意の待ち行列またはＦＩＦＯはフラッシュされる。次に、ページからのプロファイルまたは変換情報がエンキャッシュ(encache)される可能性がある。ページフレームの修正が報告される時はいつでも、そのページに関する任意のエンキャッシュされた情報が放棄される。一度キャッシュされた情報がパージされると、そのページに関するＭＰＦビットはゼロにリセットすることが可能であり、そのページに関する情報は再びキャッシュされる場合がある。
【０４４８】
Ｂ．少メモリ使用設計のデバイス概要
上記のセクションＶＩＩ．Ａに説明された簡単な設計は正しく実行され、割込みオーバーヘッドがほとんどないが、メモリを多く消費しすぎる場合がある。２８ビットの物理アドレス空間および４ＫＢのページフレームを伴うシステム上には、６５Ｋのページフレームがある。これは、８ＫＢ（または２５６  ２５６ビットキャッシュ線）に相当し、ちょうどＭＰＦビットを保持する。これらのビットはメモリ内にストアされる場合もあるが、各ＤＭＡ書込みサイクルに応答して、このようなメモリに基づいた構造のＤＭＡを読み取ることは不可能なので、ＤＭＵ７００は所定の種類のキャッシュ化機構を含む必要がある。
【０４４９】
このセクションで説明する設計は、セクションＶＩＩ．Ａの簡単なモデルに非常に似ている。以下に論ずる実施形態では、全ＭＰＦアレイの、小さな、規則的な、自然に配置されるスライスが必要に応じてインスタンス化され、物理アドレス空間の対応する範囲を監視する。この設計は任意の所与の瞬間に、全物理アドレス空間のサブセットのみを監視する。アイドルの監視リソースが利用されて異なる物理アドレスを監視する時、このＤＭＵ７００に関する設計は、監視対象の範囲内に、そのページフレームに対して修正が報告されているページフレームがないという保守的な(conservative)仮定を行う。この保守的な仮定により、過去の一定の時点ですでに修正が報告されているページフレームに対して、修正が冗長に報告されるという結果が生まれる。
【０４５０】
Ｃ．セクタ監視レジスタ
図７ａを参照すると、ＤＭＵ７００は、典型的には４〜８であるいくつかのセクタ監視レジスタ（ＳＭＲ）７０７を有する。ここで論じられる例としての実施形態では、ＳＭＲファイル内に４つのＳＭＲ７０７があると仮定されている。各ＳＭＲ７０７はセクタ、ページフレームの数の２乗である(a power of 2 number
of page frames)自然に配置された領域を監視する。図７ａの実施形態では、セクタは自然に配置された１２８ＫＢ範囲の、Ｇバス物理メモリアドレス空間であり、または、自然に配置された３２４ＫＢのページフレームのグループである。各ＳＭＲ７０７はコンテンツでアドレス指定可能なセクタ(content addressable
sector)ＣＡＭ（ＴＬＢアドレスタグと類似した、コンテンツでアドレス指定可能なメモリ）７０８、ＭＰＦ（修正したページフレーム）ビットのアレイ７１０、有効ビット７１１、および少量の論理から成る。セクタＣＡＭアドレスタグ７０８は、２８ビットの物理アドレス空間（ページ内のバイトアドレスより１２ビット少ない２８、セクタごとに３２ページに関して５ビット少ない。図７ａを参照のこと）に対して１１ビットである。ＭＰＦアレイ７１０は３２ビットを有し、セクタ内のページフレームごとに１ビットである。各ＭＰＦアレイは本質的には、セクションＶＩＩ．Ａで説明された、３２ビットスライスの大きなＭＰＦビットアレイである（大きなＤＭＡ移動を使用するチャンスを最大限にするために、現代のオペレーティングシステムは物理メモリ内でシーケンシャルなクラスタでシーケンシャルな仮想ページを維持する傾向があるので、ＭＰＦアレイ７１０内のページをクラスタ化すると、少ないアドレスタグ一致オーバヘッドで、異なるＭＰＦビットの利点のほとんどが提供される）。ＳＭＲ７０７が最後に読み取られてから、ＭＰＦビット７１０のゼロから１の遷移が少なくとも1回あった場合には、ＳＭＲ．Ａｃｔｉｖｅビット７１１は１に設定される。このようにして、ＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０を介してＳＭＲ７０７が最後に読み込まれた時から、ゼロから１に遷移したＭＰＦビット７１０が少なくとも１つ含まれる時に、ＳＭＲ７０７は有効７１１である（次の、セクションＶＩＩ．Ｇを参照のこと）。ＤＭＵ７００は、有効なＳＭＲ７００を割り当て直して、異なるセクタを監視することはない。
【０４５１】
ＤＭＵ割込みは、１つまたは複数のページフレームが修正された時、すなわち、ＭＰＦビットがゼロから１に遷移した時に代入(assert)される。ＤＭＵ割込みのためのハンドラは、修正されたページフレーム（複数可）を識別する。修正されたページがＸ８６テキストである場合、任意の変換されたＴＡＸｉコード、およびページを記述する任意のプロファイル情報がパージされ、対応するＰＩＰＭ項目６４０がリリースされる。
【０４５２】
図７ａを参照すると、物理アドレス空間は従来の方法で４Ｋのページに分割される。ページはセクタと呼ばれる隣接するブロックにグループ化される。図７ａの実施形態では、３２の、隣接する、自然に配置されるページが１つのセクタを形成する。最大で２５６ＭＢの物理メモリを可能にするこの実施形態では、ビット＜２７：１７＞７０２がセクタを示す。別の実施形態では、セクタを示すビット７０２の数を拡大することにより、より大きな物理メモリに対応することが可能である。
ビット＜１６：１２＞７０４は、セクタ７０２内のページ番号を示す。ビット＜１１：００＞は、ページ内のバイトを示す。
【０４５３】
Ｄ．インタフェースと状態レジスタ（status register)
図７ｂは、ＤＭＵインタフェースを示す。ＤＭＵ＿Ｃｏｍｍａｎｄレジスタ７９０へ書き込むと、セクタアドレス７０２およびページアドレス７０４（ページアドレス７０４は、ＳＭＲ７０７内のページのＭＰＦビットに関するビットアドレスである）、およびＤＭＵ７００コマンドをＧバスデータから提供する。ＤＭＵ＿Ｃｏｍｍａｎｄレジスタ７９０に書き込まれるデータのうち、下位の６つのビットがコマンドを示す。コマンド部分の６つのビットは、Ｄ、Ｅ、Ｒ、Ａ、ＭおよびＸ  ７９１ａ〜７９６ａと示されている。（これらのビットの意味は、次のセクションＶＩＩ．Ｈに詳細に論じられる）。ＤＭＡデバイスがメモリへの書込みを発行すると、コマンド値は、ゼロに等しいＤ、Ｅ、Ｒ、および、1に等しいＡ、Ｍ、Ｘになる。Ｄ信号、Ｅ信号、Ａ信号、Ｍ信号、Ｘ信号およびＲ信号から、いくつかの述部(predicate)が導出される。イネーブル信号７１４は、ＤＭＵが現在作動状態であることを意味する。割りつけ信号７１５は、メモリがＤＭＡデバイスから書き込まれたバストランザクション上に代入され、したがって、ＳＭＲレジスタは一致するか、または新しく割りつけられて書込みをトラッキングしなければならない。ＭＰＦ修正信号７１６は、コマンドビットの設定によってＭＰＦビット７１０の内容が書き込まれるべきことが指定された時に代入される。ＭＰＦデータ信号７１７は、ＭＰＦ修正７１６が代入された時に、ＭＰＦビット７１０に書き込まれるべきデータを搬送する。Ｒリセットコマンド７９４ａがバス上に代入された時に、リセット信号７１８が代入される。読取り信号７１９は、Ｇバスの異なる線として代入される。図７ｂはまた、イネーブルフリップフロップおよびオーバーランフリップフロップ、また、割込み生成論理を示す。６つのコマンドビット７９１ａ〜７９６ａの意味は、次に図７ｉおよび図７ｊと共に、さらに詳細に論じられる。
【０４５４】
ＤＭＵ７００が作動状態にされた７１４である時、ＤＭＵ７００は、そのＳＭＲ．Ａｃｔｉｖｅビット７１１が１であるＳＭＲ７０７が少なくとも１つある時、またはＤＭＵオーバーランフラグ７２８が設定された時はいつでも、割込みを要求する。有効な７１１ＳＭＲ７０７は、ＤＭＵ＿Ｓｔａｔｕｓレジスタ７０２内にさらされる(expose)。
【０４５５】
図７ｃを参照すると、ＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０は６４ビットの広さである。セクタビットは、物理アドレス内の自然な位置、ビット＜３０：１７＞にあり、最大で２ＢＧの物理メモリでの実装を許可する。ＤＭＵ＿Ｓｔａｔｕｓ．Ａｃｔｉｖｅビット７２３（ビット＜３１＞）は、すべてのＳＭＲの７０７が無効であって、有効７１１ＳＭＲ７０７が選択され、ゼロである時に、１である。修正したページフレームの最下位ビット（ＳＭＲ＜３２＞）７２４は、セクタ内のもっとも低いアドレスのページフレームに対応する。これに続くＭＰＦビット７１０は、順次高いページフレームに対応する。ＤＭＵ＿Ｓｔａｔｕｓ．Ａｃｔｉｖｅビット７２３が１の場合、ＳＭＲ＃フィールド７２５（ＳＭＲ＜０２：００＞）の値は、戻されているＳＭＲ７０７を識別する。ＤＭＵ＿Ｓｔａｔｕｓ．Ａｃｔｉｖｅビット７２３がゼロの場合、修正したページフレームのビット７１０、セクタビット７２２、およびＳＭＲ＃７２５は、すべてゼロである。
【０４５６】
イネーブルビット７２７およびオーバーランビット７２８は、実際には特定のＳＭＲ７０７の一部ではない。これらは、ＤＭＵ７００および、すべてのＳＭＲの７０７（all SMR's 707)の全体的な状態をある程度まとめる。ＤＭＵイネーブル７１４が設定されている時のみ、ＤＭＡアクティビティが監視される（ＤＭＵ＿Ｓｔａｔｕｓ.Ｅｎａｂｌｅ７２７は、ＤＭＵイネーブル７１４の値を反映し、ＤＭＵイネーブル７１４の値はＤＭＵ＿Ｃｏｍｍａｎｄ．Ｅｎａｂｌｅ７９５へ書き込むことによって設定される。図７ｉおよび図７ｊを参照されたい）。オーバーランビット７２８は、ＳＭＲ７０７が読み取られている時に提供され、破壊的なオーバーラン状態に対応してＤＭＵ７００がシャットダウンされた場合を認識することを可能にする。ビット＜１５＞としてのオーバーランビット７２８の位置は（ＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０の１６ビットセグメントの符号ビット）、そのテストを簡単にする。
ＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０は、図７ｈに関してセクションＶＩＩ．Ｇでさらに論じられる。
【０４５７】
Ｅ．動作
図７ｄを参照すると、ＤＭＡ書込みトランザクションごとに次のステップが発生する。ステップ７３０では、ＤＭＵイネーブル７１４、７２７がテストされる。ＤＭＵが使用不可になると、次の処理は発生しない。ステップ７３１では、ＤＭＡバストランザクションのターゲットの物理アドレスがＤＭＵ＿Ｃｏｍｍａｎｄレジスタ７９０内にキャプチャされる。図７ａに示されるように、ターゲットアドレスのビット＜２７：１７＞７０２は、セクタ番号としてキャプチャされ、ビット＜１７：１２＞７０４はページ番号インデックスとして、３２ＭＰＦビット７１０のＳＭＲ内にキャプチャされる。ステップ７４０では、ＳＭＲセクタＣＡＭアドレスタグ７０８は、セクタ番号を使用して連合して検索される（この検索は、セクションＶＩＩ．Ｆの図７ｅの論議の中でさらに詳述される）。検索が成功すると（矢印７３２）、制御はステップ７３７にスキップする。どのセクタＣＡＭアドレスタグ７０８とも一致しない場合（矢印７３３）、ステップ７５０では、無効なＳＭＲ７０７（ＳＭＲ．Ａｃｔｉｖｅビット７１１がゼロであるＳＭＲ)が割りつけられる。(割りつけはさらに、図７ｆに関して論じられる）。無効なＳＭＲ７０７が使用可能でない場合、破壊的なオーバーフロが発生しており、ステップ７３４で、ＤＭＵオーバーラン７２８が設定される。オーバーラン７２８でＴＡＸｉ処理が中断され、すべての変換されたコードセグメントはパージされる。（オーバーラン７２８の原因となったＤＭＡ書込みは、ＴＡＸｉコードに対応していたＸ８６コードのページを上書きしてしまっている場合があることが知られているが、そのページの識別を特定することは不可能であるので、ＴＡＸｉコードのすべてのページが疑わしいとされる）。ＴＡＸｉ「キャッシュ」がパージされると、ＴＡＸｉ動作は再開が可能になる。無効なＳＭＲ７０７の位置が突き止められた場合（矢印７３５）、次のステップ７３６では、割りつけられたＳＭＲ７０７の中ですべてのＭＰＦビット７１０がゼロにされる。割りつけられたＳＭＲ７０７のセクタＣＡＭアドレスタグ７０８は、検索キーであるセクタ番号７０２と共にロードされる。このようにしてＳＭＲ７０７が割りつけられ、設定されると、連合検索の基準に達し、ステップ７４０の検索が正常に終了された時のように、制御はステップ７３７に流れる。
【０４５８】
ステップ７３７では、マッチングＳＭＲ７０７の中で、修正されたページフレームに対応するＭＰＦビット７１０がテストされる。ＭＰＦビット７１０がすでに１に設定されている場合（矢印７３８）、これ以上の処理は必要ではない。１に設定されていない場合（矢印７３９）、ステップ７６０、７７８で、適切なＭＰＦビット７１０およびＳＭＲ.Ａｃｔｉｖｅビット７１１が１に設定される（有効ビット７１１はすでに設定されている場合もある）。
【０４５９】
Ｆ．回路
図７ｅを参照すると、セクタマッチハードウェア７４０は、セクタＣＡＭアドレスタグ７０８の連合検索を実行し、現行のＤＭＵ書込みトランザクションのセクタ７０２がすでに、ＳＭＲ７０７を関連させているかどうかを決定する。セクタ比較回路７４１は同時に、ＤＭＵ＿Ｃｏｍｍａｎｄレジスタ７９０からのセクタアドレス７０２と、ＳＭＲファイル内の４つのＳＭＲ７０７の４つのＣＡＭアドレスタグ値７０８の各々を比較する。セクタ比較回路７４１はこの比較の結果を、４つのビットバス７４２上に置き、対応するＳＭＲアドレスタグ７０８がバスセクタアドレス７０２に一致する場合、バス７４２の各線は１に設定される。バス７４２の４本の線のうち任意の１本が１である場合、一致があったということであり、ＯＲゲート７４３は４本の線を共にＯＲ処理して、一致が発生したかどうかを決定する。無効なＳＭＲ７０７内のセクタ値が定義されないので、複数のＳＭＲ７０７が入力セクタアドレス７０２に一致している可能性がある。単一(unary)優先順位機能７４５は、バス７４２から代入された４本の線のうち多くても１本を決定論的に選択することによって、このあいまいさを解決する。したがって、「一致したＳＭＲ」４ビットバス７４６では常に、１に設定される線は多くても１本である。
【０４６０】
図７ｆを参照すると、ＳＭＲ割当てハードウェア７５０は、現行のＳＭＲのアドレスタグ７０８のうちセクタアドレス７０２に一致するものがない場合、書込み用のプールから、無効なＳＭＲ７０７のうち１つを割りつける。無効なＳＭＲ機能７５１は、無効なＳＭＲ７０７のうち１つでも使用可能なものがある場合は、それを選択する（ＳＭＲ．Ａｃｔｉｖｅビット７１１がゼロであるもの）。現行のバストランザクションが、対応するアドレスタグ７０８を伴うＳＭＲ７０７を有しないメモリセクタ７０２に書き込んでいる場合（一致した７４４がゼロであることによって示される）、および、書込みを受け入れる無効な７１１であるＳＭＲ７０７がない場合（割りつけ７１５が１であることによって示される）、オーバーラン７２８状態が発生している。そうでない場合は、書き込むＳＭＲマスク（SMR−to−write mask)７５３（４ビットバスであり、書き込まれるべきＳＭＲレジスタに対応する1つの線が代入されている）が、読み取るＳＭＲマスク(SMR−to−read mask)７８７（４ビットバスであり、読み取られるべきＳＭＲレジスタに対応する1つの線が代入されている）、一致したＳＭＲマスク７４６（４ビットのバスであり、ＣＡＭセクタアドレスタグがバスアドレスセクタ７０２に一致する、ＳＭＲレジスタに対応する1つの線が代入されている）、および、無効なＳＭＲマスク７５４（４つのＳＭＲレジスタ７０７の４つのＳＭＲ.Ａｃｔｉｖｅビット７１１の補数(complement)）から生成される。
セクタ一致回路７４０または割りつけ回路７５０がＳＭＲ７０７を選択すると、ＭＰＦ更新論理７６０、７７２、７７８は、適切なＭＰＦビット７１０およびＳＭＲ．Ａｌｌｏｃａｔｅビット７１１を、選択されたＳＭＲ７０７の中で更新する。（ＭＰＦ更新論理７６０の一部、ＳＭＲアドレスタグ７０８およびＳＭＲ．Ａｃｔｉｖｅビット７１１を更新する部分７７２、７７８は、図７ｅおよび図７ｆに示され、図７ｇからは除かれている）。修正するＭＰＦビット７１０はＭＵＸ７６１によって選択され、この選択は、書き込むＳＭＲマスク７５３である。セクタアドレス７０２がＳＭＲ７０７のアドレスタグ７０８のどれとも一致していない場合７４４、これは新しく割りつけられた空のＳＭＲ７０７であり、ＡＮＤゲート７６２は、新しいＳＭＲ７０７のすべてのＭＰＦビット７１０がゼロになるように、すべてゼロを生成する。ＭＰＦビット更新機能７６３は、選択されたＳＭＲ７０７のＭＰＦ部分７１０に関して、新しい３２ビット値７６４を生成する。ＭＰＦビット更新機能７６３への入力は、セクタ７０２内の５ビットのページアドレス７０４（これらの５ビットは、ＭＰＦの３２＝２5ビットのうち１つを選択する）、ＭＰＦ７１０の古い内容、およびＭＰＦ修正信号７１６である。ＭＰＦビット更新機能７６３の出力７６４、７６６は、表７６５にしたがって選択される。古いＭＰＦビット７１０の値がゼロであり、新しいビット７１０の値が１である場合、ゼロから１のＭＰＦ遷移７６６信号（Zero−to−One MPF transition signal)が代入される。３２ビットの新しいＭＰＦ値７６４は共にＯＲ処理されて、ＭＰＦすべてゼロ信号(MPF−all−Zeros signal)７６７を生成する。書込み論理７６８は、入力としてリセット信号７１８、割りつけ信号７１５、一致した信号７４４、ＭＰＦ修正信号７１６、および書込みＳＭＲ信号７５３を使用して、更新するＭＰＦビット７１０を決定する。書込み論理７６８の出力７７０、７７１は、表７６９にしたがって選択される。列７７０が１である場合、書込みＳＭＲマスク７５３によって選択されたＳＭＲ７０７のＭＰＦビット７１０は３２ビット値７６４で書き込まれる。列７７１が１である場合、他のＳＭＲの７０７も同時に書き込まれる。このように、表７６９の最後の線は、リセット７１８が、ＡＮＤゲート７６２によって生成されたすべてゼロの値をすべてのＭＰＦレジスタ７１０に書き込むことを示す。
【０４６１】
再び図７ｆを参照すると、書込み論理７７２は、表７７３にしたがって新しいＳＭＲ．Ａｃｔｉｖｅビット７１１値を書き込むことを決定する。書込み論理７７２への入力は、読取り７１９、ＭＰＦすべてゼロ信号７６７、およびゼロから１へのＭＰＦ遷移信号７６６である。列７７４は、書込み論理７７２へのデータ入力が列７１９、７６７、７６６に一致する時、書込みＳＭＲ７５３に選択されたＳＭＲ７０７のＳＭＲ．Ａｃｔｉｖｅビット７１１に書き込むかどうかを伝える。列７７４が１である場合、列７７５は、そのＳＭＲ．Ａｃｔｉｖｅビット７１１に書き込むデータ値を伝える。
同様に、列７７６は、選択されないＳＭＲレジスタのＳＭＲ．Ａｃｔｉｖｅビット７１１に書き込むか否かを伝え、列７７７は書き込むデータ値を伝える。
【０４６２】
再び図７ｅを参照すると、新しく割りつけられた７５０ＳＭＲ７０７のセクタタグ７０８は、書込み論理７７８によって決定されたように書き込まれる（書込み論理７７８は論理７６８、７７２に織り込まれ、ここでは解説のために示されている）。書込み論理７７８は、入力として割りつけ信号７１５および一致した信号７７４を受け入れ、その出力を表７７９にしたがって計算する。表の中央の行によって示されているように、空のＳＭＲが割りつけ論理７５０によって割りつけられると（新しい割りつけは、１である割りつけ７１５によって示され、空であることは、一致済み７４４がゼロであることによって示される）、書込みＳＭＲマスク７５３によって示されるＳＭＲのセクタアドレスタグ７０８が書き込まれる。そうでない場合は、表７７９の上と下の行によって示されるように、ＳＭＲ７０７は書き込まれない。
【０４６３】
図７ｄ〜図７ｇは、１つの実施形態の例に過ぎない。一般的に、連合キャッシュまたはＴＬＢアドレスタグ一致、キャッシュ線配置方針、プロセッサ間の修正されたビットおよびダーティビットに関する既知の技法を適用し、ＳＭＲ７０７を管理することが可能である（１つの違いを指摘しなければならない。ソフトウェアで管理されたＴＬＢ内では、ＴＬＢミス上で(on a TLB miss)メモリ内のＰＴＥが更新され、ついでＰＴＥはＴＬＢにコピーされる。したがって、ＴＬＢの信頼できるバッキングコピーが常に存在する。ここで示されたＤＭＵ設計では、ＳＭＲレジスタ７０７に関するバッキングメモリはない）。
【０４６４】
図７ｄの代替の実施形態では、追加のステップがステップ７４０と並列に実施される。ＴＬＢ１１６が調べられて、書き込まれているページに関して、ＩＳＡビット１８２および、ＸＰビット１８４、１８６を決定する。ＩＳＡビット１８２、およびＸＰビット１８４、１８６が両方とも１でない限り（保護されたＸ８６コードのページを示す）、ＤＭＵの残りのすべてはバイパスすることが可能である。ＤＭＵは、元のＸ８６コードに対して、ＴＡＸｉコード「キャッシュ」の有効性をトラッキングするためにのみ存在し、このようなＴＡＸｉコードが存在する可能性がない場合、残りの機能は省略することが可能である。
【０４６５】
ＭＰＦビットがゼロから１へ遷移する時、すなわち、１つまたは複数のページフレームが修正されている時はいつでも、ＤＭＵ割り込みが生じる。ＤＭＵ割り込みのためのハンドラは、すべての有効な７１１ＳＭＲの７０７の状態を検索することによって、修正されたページフレーム（複数可）を特定する。有効なＳＭＲ７０７に関する検索は、次に説明するようにハードウェア内で実行される。
Ｇ．ＤＭＵ＿状態レジスタ
【０４６６】
図７ｃと共に図７ｈを参照すると、ＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０はＧバス上の６４ビットレジスタである。これは通常のＴＡＸｉ動作で使用されるＤＭＵ情報の唯一のソースである。ＤＭＵイネーブル７１４（ＤＭＵ＿Ｓｔａｔｕｓ．Ｅｎａｂｌｅ７２７内に反映され、ＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０のビット＜１４＞である）がゼロである場合、ＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０のすべての読取りは、完全にゼロである結果を戻す。このような読取りは、ＤＭＵ７００を再び作動状態にすることはない。ＤＭＵを再び作動状態にするには、再初期化をしなければならない。ＤＭＵイネーブル７１４が１であり、有効な７１１であるＳＭＲ７０７がない場合、ＤＭＵ＿Ｓｔａｔｕｓ７２０のすべての読取りは、ＤＭＵ＿Ｓｔａｔｕｓ．Ｅｎａｂｌｅビット７２７の１を除いては、完全にゼロである結果を戻す。ＤＭＵイネーブル７１４が１であり、ＳＭＲ．Ａｃｔｉｖｅビット７１１が1である少なくとも1つのＳＭＲ７０７が存在する場合、読取りＤＭＵ＿Ｓｔａｔｕｓ７２０は有効な７１１ＳＭＲの７０７のうち１つのスナップショットを戻す。このスナップショットは少なくとも１つのＭＰＦビット７１０セット、ＤＭＵ＿Ｓｔａｔｕｓ．Ａｃｔｉｖｅビット７２３セット（ＳＭＲ７０７のＳＭＲ．Ａｃｔｉｖｅビット７１１を反映する）、およびＤＭＵ＿Ｓｔａｔｕｓ．Ｅｎａｂｌｅビット７２７セットを有する。ＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０の読取りは、現在ＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０内に反映されているＳＭＲ７０７のＳＭＲ．Ａｃｔｉｖｅビット７１１をゼロにするという副次的な作用を有し、ＳＭＲ７０７を再割りつけ７５０可能な状態にするが、アドレスタグ７０８およびＭＰＦビット７１０はそのままである。したがって、同じページに対してさらにＤＭＡ書込みが行われても、新しいゼロから１への遷移は起らず、強力なＩ／ＯからＩ／Ｏバッファによって引き起される割込みオーバヘッドを低減する。このＳＭＲ７０７は、ＳＭＲ７０７が再割当てされた７５０になった場合、またはＭＰＦビット７１０がゼロであるページフレームへの書込みをＳＭＲ７０７が監視するセクタ７０２内でＤＭＡ書込みが発生する時のみ、再び有効な７１１になる。同様に、ＤＭＵ割り込みは、そのページに関するＭＰＦビットが明示的に消去される場合のみ、そのページに関して生じる（Ｍコマンドビットが１であり、他のコマンドビットがゼロであるコマンドを使用する。セクションＶＩＩ．Ｈに論じられるコマンドを参照されたい）。
【０４６７】
ＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０は、ＳＭＲの７０７のファイルからの入力によって駆動される。ＳＭＲ選択機能７８２は、ＳＭＲ．Ａｃｔｉｖｅビット７１１が１であるＳＭＲ７０７を選択する。有効なＳＭＲの選択７８３を使用して、対応するセクタタグ７０８および選択されたＳＭＲ７０７のＭＰＦビット７１０部分を選択する７８４。有効な７１１ＳＭＲ７０７がない場合（ＯＲゲート７８５によって計算される）、またはＤＭＵが使用不可である場合７１４、ＡＮＤゲート７８６はすべての出力がゼロであるようにする。選択７８３はＡＮＤゲートによってゲーティングされて、読取りＳＭＲ信号７８７を生成し、これは図７ｆ内で使用されて読み取られるべき１つのＳＭＲレジスタを選択する。
【０４６８】
割込みハンドラソフトウェアの動作に戻ると、ＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０を読み取る行為は、暗示的な通知の確認としてＤＭＵ７００によって行われ、したがって、関係するＳＭＲ（複数可）７０７の符号を再割当てすることが可能である。ＤＭＵ割込みハンドラは、ページに関してＩＳＡビット１８０、１８２、およびＸＰビット１８４、１８６をチェックし、ＤＭＵ書込みによって書き込まれたページが保護されたＸ８６ページであるかどうかを確認する（これをハードウェアまたはソフトウェア内で実行してから、割込みを発生させることが可能である）。そのページが保護されたＸ８６ページである場合、割込みハンドラはＰＩＰＭ６０２を調べて、修正されたページに対応する変換されたＴＡＸｉコードが存在するかどうか、また、修正されたページを記述するプロファイル情報４３０、４４０が存在するかどうかを確認する。ＴＡＸｉコードが発見された場合、ＴＡＸｉコードがリリースされ、ＰＩＰＭ６０２は更新されて解放を反映する。プロファイル情報が発見された場合、プロファイル情報がリリースされる。
【０４６９】
ＤＭＵ割込みはプローブ例外（probe exception)よりも高い優先順位を有するので、プローブ（probe)は最近無効にされたページに制御を移動しない。
Ｈ．ＤＭＵ＿コマンドレジスタ
【０４７０】
図７ｂと共に図７ｉ、図７ｊおよび表５を参照すると、ソフトウェアはＤＭＵ＿Ｃｏｍｍａｎｄレジスタ７９０を介してＤＭＵ７００を制御する。ビット＜０５：００＞７９１〜７９６はＤＭＵ７００の初期化を制御し、オーバーランの後に対応して、修正がすでに報告されているページフレームに対して行われた修正を再び報告できるようにし、ＤＭＵトラフィックをシミュレートする。ビット７９１の機能は次の表５にまとめられている。
【０４７１】
【表５】
0005427742.tif 000008
【０４７２】
Ｄコマンドビット７９６ａ、７９６ｂ、７９６ｃは、ＤＭＵイネーブル７１４、７２７をゼロにし、これによって、ＤＭＵトラフィックによって生じるＳＭＲ７０７のこれ以降の変更を使用不可にする。ＤＭＵイネーブル７１４、７２７がすでにゼロである場合、Ｄビット７９６は効果を有しない。
【０４７３】
Ｅイネーブルコマンドビット７９５ａ、７９５ｂ、７９５ｃは、ＤＭＵイネーブル７１４、７２７を１に設定し、これによって、将来のＤＭＵトラフィックおよびＤＭＵ割込みの監視を使用可能にする。ＤＭＵイネーブル７１４、７２７がすでに設定されている場合、Ｅビット７９５は効果を有しない。
【０４７４】
Ｒコマンドビット７９４ａ、７９４ｂ、７９４ｃはＤＭＵ７００をリセットする。これは、各ＳＭＲ７０７にあるＳＭＲ．Ａｃｔｉｖｅビット７１１およびすべてのＭＰＦビット７１０をゼロにし、さらにＤＭＵオーバーランフラグ７２８をゼロにすることによってリセットを行う。Ｒコマンドビット７９４は、セクタアドレスＣＡＭアドレスタグ７０８内の値に影響を有しない。Ｒコマンド７９４はＡコマンド７９３、Ｍコマンド７９２、およびＸコマンド７９１より優先され、ＤＭＵ７００が使用可能になっているかどうか、ＤＭＵ７００をリセットする。
【０４７５】
ＤＭＵ＿Ｃｏｍｍａｎｄレジスタ７９０の高いオーダのビット（ビット＜２７：１２＞）７９７はページフレームを識別する。書込みがＤＭＵ＿Ｃｏｍｍａｎｄレジスタ７９０に対して発生するといつでも、ページフレームアドレス７９７がＳＭＲセクタＣＡＭアドレスタグ７０８に与えられる。Ａコマンドビット７９３、Ｍコマンドビット７９２、およびＸコマンドビット７９１は種々の状況の下で起きたことを制御する。
【０４７６】
１．セクタ一致ハードウェア（図７ｅの７４０）がマッチ７４４を発見できず、Ａコマンドビット７９３がゼロであった場合、なにもしない。マッチ７４４がなく、Ａコマンドビット７９３が１である場合、図７ｄおよび図７ｆに関して説明されたように正常な割りつけ７５０が実行される。（この正常な割りつけ７５０はオーバーラン状態７２８につながり、さらにＤＭＵ割込みにつながる可能性があることを思い出されたい）。
【０４７７】
２．セクタマッチング７４０またはセクタ割りつけ７５０のいずれかが成功した場合、Ｍコマンドビット７９２およびＸコマンドビット７９１は、表６にしたがって３つの可能なアクションを定義する。
【０４７８】
【表６】
0005427742.tif 000009
【０４７９】
"１"に設定されたＭコマンドビット７９２でＤＭＵ＿Ｃｏｍｍａｎｄレジスタ７９０にページフレームアドレス７０２、７０４、７９７を書き込むと、"０"に設定された残りのコマンドビット７９１、７９３〜７９６は、一致するセクタＣＡＭアドレスタグ７０８を検索する。マッチ７４４が発見されると、対応するＭＰＦビット７１０がゼロにされる（Ｍビット７９２は１であり、Ｘビット７９１はゼロであり、表６の第２の線に一致しているため）。これは、ＴＡＸｉが、ＩＳＡビット１８０、１８２が１であり、ＸＰビット１８４、１８６がゼロである（保護されていないＸ８６コード）ページから、ＸＰビット１８４、１８６が１であるページ（保護されたＸ８６コード）へ変わる直前のページの監視を可能にする方法である。このようなコマンドによって消去されたＭＰＦビット７１０がＳＭＲ７０７内に設定された唯一のＭＰＦビット７１０であった場合、ＳＭＲ７０７は無効な７１１に戻り、再割りつけされて７５０、異なるセクタを監視することが可能になる。ＳＭＲ．Ａｃｔｉｖｅビット７１１は、ゼロから１へのＭＰＦ遷移、または１からゼロへの最後のＭＰＦビットの遷移によってのみ影響を受ける。そうでない場合は、ＳＭＲ．Ａｃｔｉｖｅビット７１１は、ＭＰＦビット７１０への変化からは影響を受けない。
【０４８０】
セクタＣＡＭアドレスタグ７０８が互いに異なる値を含むようになるまで、ＤＭＵ７００を使用可能にしないのはソフトウェアの責任である。オーバーラン７２８が発生すると、この状態は確実でなくなる。したがって、オーバーランへの最も安全な対応は再初期化である。
【０４８１】
【数１】
0005427742.tif 000010
【０４８２】
正しく初期化されないとＤＭＵ７００の挙動は定義されず、チップに損害を与えないことと、セキュリティホールが持ち込まれないことのみが保証される。
【０４８３】
代替の実施形態では、ＤＭＵ７００はＴＬＢ１１６とさらに密接に統合されている。これらの実施形態では、ＤＭＵ７００はＩＳＡビット１８２およびＸＰビット１８６にアクセスを有し（上記のセクションＩ．Ｆを参照されたい）、保護されたＸ８６ページが書き込まれた時にのみ、または書き込まれたページがＴＬＢ１１６中に項目を有しない時にのみ、割込みを発生させる。
ＶＩＩＩ  順序の正しくない効果を管理する
【０４８４】
すべてのメモリリファレンス（メモリロード、メモリストア、命令フェッチ）を正しい順序にし、最適化しないことが必要とされると、ＴＡＸｉによって達成可能な速度の上昇が制限される。最適化の唯一の障害はしばしば、ロードが、正しく挙動するメモリまたは所定のメモリ状ではないオブジェクトを参照するか否かを知っていることである。ＴＡＸｉ変換プログラムによる順序化の変更および最適化をせずに、副次的な作用の元の秩序を復元し、完全なＸ８６挙動を保存することがセクションＶＩＩＩで論じられる。
【０４８５】
Ａ．最適化変換により再順序づけされた事象の順序正しいハンドリングの保証
Ｘ８６の完全なエミュレーションというＴＡＸｉ実行モデルは副次的な作用の順序を維持するが、バイナリ変換プログラム１２４では、例外または他の副次的な作用を生成する可能性のある、浮動小数点命令、整数分割または他の命令などメモリ読取り命令の順序を変更するコード最適化技法を使用することが許可されている。（「副次的な作用」は、メモリの書込み、Ｘ８６／ウィンドウズ（登録商標）アーキテクチャがアプリケーションプログラムにさらされる例外など、状態の永久的な変更である。したがって、メモリの書込みおよびゼロによる除算は各々、他の副次的な作用に対して順序が保護される副次的な作用である）。たとえば、すべてのメモリリファレンス（メモリの読取り、メモリの書込み、命令のフェッチ）は、「正しく挙動」しており、例外もなく隠れた副次的な作用もない。すべての副次的な作用はたがいに対して順序づけられている。副次的な作用が非可逆的にコミットされる前に、この楽観的な仮定に対して違反があれば捕まえることによって、正い実行が確実になる。
【０４８６】
プロファイル情報（セクションＶを参照のこと）がＴＡＸｉ変換プログラム１２４に、たとえば、Ｉ／Ｏ空間への読取りなど（次のセクションＶＩＩＩ．Ｂを参照のこと）メモリの読取りが副次的な作用を有する可能性があると伝えると、Ｘ８６コードは、メモリリファレンスが最適化されて冗長なロードを除去するかまたは順序を変えられることを禁じるという、保守的な仮定を使用して変換される。この保守的なコードは、保守的な仮定の下で生成されたものとしてアノテートされる。保守的なコードがＩ／Ｏ空間にアクセスすると、アノテーションによって、コードが楽観的な仮定で生成されたものではないというランタイム環境が確認されるので、メモリリファレンスが終了することが可能になる。保守的なコードからの挙動の正しいメモリへのリファレンスは通常、それ以前の最適化をやめるだけで終了する。
【０４８７】
逆に、Ｉ／Ｏ空間リファレンスがプロファイル内に現れない場合、ＴＡＸｉコードはすべてのリファレンスが正しく挙動している（すなわち、ＡＳＩゼロ）メモリへのリファレンスであるという楽観的な仮定の下で最適化され、メモリ読取りは順序を変えられるか除去される可能性がある。コードは楽観的な仮定を記録するようにアノテートされる。正しく挙動するメモリへのすべてのリファレンスは、アノテーションがどのような値がであっても正常に終了する。楽観的なＴＡＸｉコードが実行され、楽観的なコードからＩ／Ｏ空間（ＡＳＩはゼロではない）をリファレンスすることによってメモリリファレンスが楽観的な仮定に違反した場合、リファレンスはＴＡＸｉＩ／Ｏ例外によって中断される。ＴＡＸｉコードでは、Ｉ／Ｏ空間へのリファレンスは、コードが保守的な仮定にしたがっているとアノテートされている場合のみ終了することが許可される。ＴＡＸｉＩ／Ｏ例外が発生すると、例外ハンドラはコンバータ内で実行が再開するように強制する。
【０４８８】
ＴＡＸｉ変換プログラム１２４がネイティブコードを生成すると、ＴＡＸｉ変換プログラムは、すべてのメモリリファレンスが、安全で正しい挙動のメモリへのリファレンスであり（ＡＳＩゼロ）、最適化することが可能であるという楽観的な仮定を行う場合がある。たとえば、ロードはストアの前に移動可能であること、メモリの位置が互いに重複しないと証明された場合にはそのメモリの読取りは互いに対して順序を変更したり副次的な作用を有する命令に対しても順序を変更することが可能であること、また、介入するストアがなければ同じ場所からの冗長なロードは互いにマージすることが可能であること（ＣＳＥ共通副次式（common sub−expression)）などの仮定である。ＴＡＸｉ変換プログラム１２４はすべてのメモリ書込みを保存し、メモリ書込みは最適化によって除去されることもなく、互いに対して順序を変えられることもない。しかし、Ｉ／Ｏ空間へのリファレンスは、読取りのみであっても、不明な副次的な作用を有する可能性がある（たとえば、連続的な読取りは異なる値を戻す場合もあり、および／またはＩ／Ｏデバイス内に別の副次的な作用をトリガする場合もある、たとえばセクションＶＩＩ．ＧからＤＭＵ＿Ｓｔａｔｕｓレジスタ７２０の読取りは、ＤＭＵ７００内の状態の変化を引き起し、次のＤＭＵ＿Ｓｔａｔｕｓ７２０の読取りは異なる結果を与えることを思い出されたい）。
【０４８９】
ＴＡＸｉ変換プログラム１２４は、挙動が正しくないＩ／Ｏ空間へのリファレンスを守るセイフティネットに依存する、すなわち、ランタイム時に、正しく挙動する変換時間の楽観的な仮定に違反が生じた時には介入する。ＴＡＸｉシステムは各メモリリファレンスのスタティックな性質を記録し、そのメモリリファレンス（具体的にはロード）がなんらかの方法で最適化されているかどうかをアノテートする。
【０４９０】
ＴＡＸｉ変換プログラム１２４は、メモリリファレンスが最適な仮定を含むか否かをハードウェアに伝える。楽観的でない仮定を含まないこれらのリファレンスは常に、終了することが許可されている。リファレンスのターゲットが正しく挙動するメモリであるという楽観的な仮定を含むリファレンスは、実行するごとにこの仮定を確認され、仮定が正しいと保証できない場合には中断される。
【０４９１】
１実施形態では、特定のロードまたはストアが最適化されたか否かをアノテートするために、各ロード命令またはストア命令の１つのビット（または、単一の命令が多数のロードまたはストアを行う場合には、命令内の各メモリオペランド記述子の１ビット）が保持される。
次の実施形態は、この目的のために１つの命令オペコードを専用化する必要を除去する。
楽観的／保守的なアノテーションは、セグメント記述子の「ＴＡＸｉ最適化済みロード」ビット８１０内に記録される。
【０４９２】
各Ｘ８６ロードはセグメントレジスタから離れたところに基づいている（based off）ので（セグメントレジスタへのリファレンスは、ロード動作において明示的に符号化される場合もあり、命令の定義の中に暗示的である場合もある）、また、各セグメントはセグメント記述子を有するので、セグメント記述子は最適化されたプロパティをアノテートし、メモリリファレンスを監視する有用な場所である。各Ｘ８６ロード動作がミクロオプス（micro−ops）に復号化されてタペストリパイプラインの下に送る（send down）ので、セグメントレジスタは明示的にミクロオプの中に具体化される。
【０４９３】
ＴＡＸｉコードが実行されており（すなわち，ＰＳＷ．ＴＡＸｉ＿Ａｃｔｉｖｅ  １９８が代入されている時）、ＴＡＸｉ変換済みコードの中でロードが他のメモリリファレンスに対して順序どおりに発生している時、そのロードによってリファレンスされているメモリの性質がなんであっても、効果は元のＸ８６命令ストリームと同一である。メモリリファレンスが順序を変えられていない時には、例外が生じないように、ＴＡＸｉ最適化済みロード８１０ゼロセグメントが使用されることが望ましい。
【０４９４】
図８ａを参照すると、タペストリセグメントレジスタ８００はＸ８６セグメント記述子内に符号化された機能のスーパーセットを符号化し、少数の追加機能のビットを追加する。タペストリセグメントレジスタ８００のビット＜６１＞は「ＴＡＸｉ最適化済みロードビット」８１０である。（セグメント記述子ＴＡＸｉ最適化済みロードビット８１０はＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏビット８２０とは異なる）。セグメント記述子ＴＡＸｉ最適化済みロードビット８１０が１の時、このセグメントレジスタから離れたすべてのメモリリファレンスは、楽観的な仮定の下で最適化されていると考えられる。メモリリファレンスが、ＴＡＸｉ最適化済みロードビット８１０が１であるセグメント記述子を調べ、リファレンスによって正しくない挙動のメモリであると決定され（Ｄ−ＴＬＢ．ＡＳＩ、アドレス空間ＩＤ、ゼロに等しくない）、ＰＳＷ．ＴＡＸｉ＿Ａｃｔｉｖｅ１９８が真である場合、ＴＡＸｉ  Ｉ／Ｏ例外が生じる。ＴＡＸｉ  Ｉ／Ｏ例外のためのハンドラは実行コンテキストをセイフティネットの最後のチェックポイントにロールバックし、コンバータ１３６内で実行を再開し、ここで元の最適化されないＸ８６命令が実行されて、元の形態と順序でメモリリファレンスを実行する。
【０４９５】
Ｘ８６は６つの、アーキテクチャでアクセス可能なセグメント記述子を有し、タペストリはこれらの６つをコンバータ１３６が使用するようにモデリングして、ネイティブのタペストリコードおよびＴＡＸｉコードにアクセス可能な追加の１０のセグメント記述子８００を提供する。Ｘ８６コードがセグメント記述子８００のうち１つを読み取る時または書き込む時に、６つの、Ｘ８６から見えるレジスタはエミュレータ３１６内の例外ハンドラによって管理され、例外ハンドラは、Ｘ８６のアーキテクチャで定義された管理と、タペストリの拡張機能の管理の両方を実行するように介入する。コンバータ１３６およびエミュレータ３１６は、セグメント記述子ＴＡＸｉ最適化済みロードビット８１０の値を無視し、コンバータ１３６内でＸ８６コードの実行されている間は、ビット８１０の値はランダムになる可能性がある。しかし、コンバータ１３６はＴＡＸｉのためにビット８２０を保持し、これらの６つのセグメント記述子の中ではセグメント記述子ＴＡＸｉ最適化済みロードビット８１０の値は常にＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏ（図４ｇの８２０）と一致する。
【０４９６】
タペストリのセグメントレジスタ８００のハードウェアのフォーマットは、Ｘ８６セグメントの記述子の、アーキテクチャで指定されたフォーマットとは異なる。特別な、Ｘ８６からタペストリへのハードウェアが提供され、１つの形態から別の形態へ変換する。Ｘ８６コードがセグメント記述子の値をセグメントレジスタに書き込むと、エミュレータ３１６はセグメント記述子の値をとり、それを特別なＸ８６からタペストリへの変換レジスタに書き込む。特別な変換レジスタの背後にあるハードウェアはシフティングおよびマスキングを実行してＸ８６形態からタペストリ形態へ変換し、Ｘ８６セグメントの記述子を異なるビット位置にコピーし、マシンの別のところから、タペストリ拡張ビットを集める。特に、複製されたセグメント記述子のＴＡＸｉ最適化済みロードビット８１０が、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏ８２０からコピーされる。エミュレータ３１６はついで、特別変換レジスタを読取り、その値はタペストリセグメントレジスタ８００のうち１つに書き込まれる。
【０４９７】
任意の特定のソフトウェアリリースにおいては、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏ８２０は常に同じ値に設定され、ＴＡＸｉ変換プログラム１２４はその値に依存して、Ｘ８６コードを変換する。
図８ｂおよび図８ｃを参照すると、セグメント記述子ＴＡＸｉ最適化済みロードビット８１０は、次のようにＴＡＸｉ変換プログラム１２４によって管理される。
【０４９８】
Ｘ８６から見える６つのセグメントレジスタに関し、ＴＡＸｉ最適化済みロード８１０のデフォルトの値は、実装者の裁量でプログラミング可能である。ＴＡＸｉ最適化済みロード８１０は、コンバータ１３６によって無視されることを思い出されたい。このため、コンバータ１３６がセグメント記述子レジスタをロードするごとに（実際にはエミュレータ３１６の中で実行される複雑な動作）、ＴＡＸｉ最適化ロードは任意に設定することが可能である。Ｘ８６フォーマットのセグメント記述子の値からタペストリの内部セグメント記述子フォーマットへの変換は、ハードウェアによって実行される。このハードウェアは所定の値をＴＡＸｉ最適化済みロードに提供しなければならない。タペストリシステムはその値をハードワイヤするのではなく、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏ８２０を介してＴＡＸｉ最適化済みロードビット８１０の値をプログラミング可能にする。
【０４９９】
システムの起動時に、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏ８２０は初期化され、現行のＴＡＸｉ変換プログラムによって送られる可能性がもっとも高いロードの形態を反映する。変換プログラム１２４が特に成熟していなく、ロードを最適化することがまれであるかまたはまったくない場合、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏ８２０はゼロに初期化される。これは、６つの、アーキテクチャで見えるＸ８６セグメントレジスタにマッピングされたセグメント記述子は常にＴＡＸｉ最適化済みロード８１０ゼロを有するという意味である。ついで、最適化されたロードが実際に生成される時に、プロログ内で生成される必要があるのは、記述子を複製するコードと、設定されたＴＡＸｉ最適化ロードのみである。
【０５００】
デフォルトのレジスタはすべてが、これらのレジスタがＴＡＸｉによって使用されることがデフォルトとなるように、より一般的な場合に選択された１つの状態にある。ＴＡＸｉが他の構文を必要とする時、ＴＡＸｉセグメントの最初において記述子を複製すると、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏ８２０のコピーを使用して、コンバータ１３６によって使用される記述子を、新しいセグメント記述子のＴＡＸｉ最適化済みロードビット８１０にコピーする。ビット８１０に対する反対の意味は、ソフトウェアによって明示的に設定される。たとえば、セグメント記述子のデフォルトの意味が、ＴＡＸｉ最適化済みロードがゼロであるという意味の場合（最適化を可能にする楽観的な仮定）、すべての最適化済みメモリリファレンスは、ＴＡＸｉコードによって複製された新しい記述子である、１に設定されたＴＡＸｉ最適化済みロードビット８１０を有するセグメント記述子を調べなければならない。この複製された記述子は、すべての他の記述子の例外、セグメントの限度を与え、他の効果はすべて、ロードに対するセイフティネットチェックの追加の機能とまったく同じになる。
【０５０１】
図８ｂを参照すると、ＴＡＸｉ最適化プログラム１２４がバイナリを変換すると、どのメモリロード動作が最適化されたか、デフォルトの最適化仮定に反する（counter）どのセグメント記述子がロードの間にリファレンスされたかを追跡する。図８ｂは、すべての最適化が終了したが新しいタペストリバイナリの最終的なエミッションの前、すなわち変換プログラム１２４の最後に近い通過の中でとられるアクションを示す。図８ｂの上半分８４０は、ＴＡＸｉ最適化プログラム１２４の比較的初期のリリースの場合をカバーし、副次的な作用の順序を変える最適化は規則ではなく例外である。下半分の８５０はその後の場合を反映し、最適化はより一般的であり、セグメントのＴＡＸｉ最適化済みロード８１０の値はデフォルトで１であり、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏ８２０を１に設定することによって制御される。正しく挙動し副次的な作用のないメモリのみがアドレス指定されるという（ステップ８４１、８５１）楽観的な仮定で順序を変えられ、共通化され、またはそのほかの方法で最適化されたメモリリファレンスに関して、ＴＡＸｉ変換プログラム１２４はメモリリファレンスに、ＴＡＸｉ最適化済みロード８１０の値が１であるセグメント記述子を調べるように強制する（ステップ８４３、８５２）。仮定に違反がある場合、すなわち、ランタイム時にＴＡＸｉ最適化済みロード８１０の１つのセグメントを介したメモリリファレンスがＩ／Ｏ空間にアクセスしていることが発見された場合、そのメモリリファレンスはＴＡＸｉ  Ｉ／Ｏ例外を発生させ、変換されたコードの実行はコンバータ１３６のセイフティネット内へ中断される。ＴＡＸｉ変換プログラム１２４が保守的な仮定を適用し、このメモリリファレンスを最適化するチャンスを無視しない場合（たとえば、セクションＶＩＩＩ．Ｂで論じられたように、プロファイルがこのロードがＩ／Ｏ空間をリファレンスしたことを示した場合）（ステップ８４４、８５３）、メモリリファレンスはＴＡＸｉ最適化済みロード８１０ビットがゼロであるセグメント記述子を調べ（ステップ８４５、８５５）、メモリが挙動が正しくないメモリであってもこのメモリリファレンスを終了させＴＡＸｉ  Ｉ／Ｏ例外を生成しないことを保証する。
【０５０２】
ステップ８４２および８５４では、ＴＡＸｉ変換プログラムは、デフォルト以外の方法で使用されたセグメント記述子を記録する。記述子を複製し、ＴＡＸｉ最適化済みロード８１０のデフォルト以外の値を設定するオーバーヘッドは、必要な場合のみ発生する。
【０５０３】
図８ｃを参照すると、ＴＡＸｉ変換プログラム１２４は変換されたホットスポット各々の始めで、ステップ８４２、８５４でデフォルト以外の方法で使用されたとマーキングされたセグメント記述子のうちいずれかの複製されたコピーを作成するコードを、１０の余分のセグメント記述子のうち１つに挿入する（ステップ８６８）。この複製された記述子は、変換済みコードによって行われた、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏ８２０の現行のリリースの値に埋め込まれた仮定に一致するメモリリファレンスの一部に使用される。プロログコードはセグメント記述子をコピーし（ステップ８６６）、ＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏ８２０の現在のリリースの値に埋め込まれた仮定と反対の仮定をとるメモリリファレンスによって使用されるように、ＴＡＸｉ最適化済みロードビット８１０をＴＡＸｉ＿Ｃｏｎｔｒｏｌ．ｔｉｏ８２０の値の反対の意味に設定する（ステップ８６８）。
【０５０４】
ＴＡＸｉ最適化済みロードビット８１０は次のランタイム挙動を有する。
コンバータ１３６が実行されている時（すなわち、ＰＳＷ．ＴＡＸｉ＿Ａｃｔｉｖｅビット１９８がゼロの時）、ＴＡＸｉ最適化済みロードビット８１０は効果を有しない。したがって、コンバータ１３６はＴＡＸｉ最適化済みロードビット８１０の値がなんであっても、セグメントを介してロードを発行することが可能である。ＴＡＸｉ最適化済みロードビット８１０の値がなんであっても、コンバータは任意の形態へメモリに対する任意のメモリリファレンスを実行することが許可されており、ＴＡＸｉ最適化済みロード例外は発生しない。
【０５０５】
ＰＳＷ．ＴＡＸｉ＿Ａｃｔｉｖｅ１９８が１である時、ＴＡＸｉ最適化済みロードビット８１０は、非ゼロＡＳＩ（すなわち、挙動が正しいことが知られていないメモリ）からのロードを終了させるべきか（ＴＡＸｉ最適化済みロードがゼロ）、中断するべきか（ＴＡＸｉ最適化済みロードが１）を決定する。ＴＡＸｉ
Ｉ／Ｏ例外は、次の３つのすべてが真である時に生じる。
【０５０６】
１．ＰＳＷ．ＴＡＸｉ＿Ａｃｔｉｖｅ１９８が１である
２．メモリリファレンスが、ＴＡＸｉ最適化済みロードビット８１０が１であるセグメントを調べる
３．メモリリファレンスがＩ／Ｏ空間に触れる、すなわち、ＡＳＩがゼロではない。
【０５０７】
所定のＸ８６コード内のＸ８６セグメントに関して言えば、ＴＡＸｉ変換プログラムは１のＴＡＸｉ最適化済みロードを伴う記述子を使用する場合もあり、ＴＡＸｉ最適化済みロード８１０ゼロを使用する場合もある。記述子レジスタファイル、および１つまたは複数のスペアのセグメント記述子の位置を読み取り書き込む能力に関して言えば、正しく構成された記述子は、元のＸ８６記述子の位置を読み取り、ＴＡＸｉ最適化済みロード８１０を適切に設定または消去することによって構成することが可能である。
【０５０８】
ＴＡＸｉ変換プログラムが楽観的な仮定を使用し、２つのロードを共にＣＳＥし、ＴＡＸｉ命令ストリーム内には１つだけのロード命令しか実際には存在しない例を考えてみる。実際に最適化されるロードは後者のロードであるが、そのロードは最適化された命令ストリームの中にはすでに存在しない。したがって、そのロード自体が他の副次的な作用に対して順序を変えられていない場合でも、残りのロードはアノテートされる。ロードがＴＡＸｉ最適化済みロード８１０セグメントを離れて実際にＩ／Ｏ空間に発生すると、実行は命令境界にロールバックされ、ここで拡張タペストリ状態が終了する。ＴＡＸｉコードは放棄され、元のｘ８６コードはコンバータ１３６内で実行される。コンバータ１３６からエミット（emit)されたストリームから落とされるロードがないように、コンバータ１３６は見た通りに正確にＸ８６命令を実行し、ロードのすべてを実行する（ＴＡＸｉ命令ストリームが最適化された場合でも、Ｘ８６命令ストリームは依然として元の最適化されない形態のままである）。
【０５０９】
ＴＡＸｉ  Ｉ／Ｏ障害は、命令の副次的な作用がコミットする前に認識される。
すべてのＴＡＸｉコードはワイヤードメモリ内に保持される。したがって、ＴＡＸｉコードの命令をフェッチする時にはページ不在は発生せず、どのページ不在も必ずデータリファレンスに関係しているはずである。
ＴＡＸｉコードがＸ８６テキストの１つのページから別のページに変換された領域から横切る（cross）時にＴＡＸｉコードが実行されると、ＴＡＸｉコードはＸ８６命令テキストの対応するページに「触れる」（結果を使用しないロード）。（元のＸ８６命令テキストのページ境界の横断は、セクションＶ．Ｄの図４ｅおよび図４ｆに関連して論じられた機構を使用してプロファイル内にメモされている）。これは元のＸ８６コード内にページ不在を発生させ、元のＸ８６コードの実行の忠実なエミュレーションを提供する。
【０５１０】
タペストリオペレーティングシステム３１２およびエミュレータ３１６内でＴＡＸｉ  Ｉ／Ｏ例外を処理した後、実行が再開される。簡単な実施形態では、Ｘ８６は以前のＸ８６命令境界に復元され、再開は常にＸ８６命令境界にある。したがって、単一のＸ８６命令が２つのロードを有する場合、変換プログラム１２４は、（１）どちらのロードも最適化できない、または（２）両方のロードが最適化されたとアノテートされなければならない、という２つの戦略のうち１つをとらなければならなくなる。これは、第１のロードが挙動の正しくないメモリであるため、第２のロードがＴＡＸｉ  Ｉ／Ｏ例外を発生させた場合に第１のロードを再実行しなければならないという状況を避ける。
【０５１１】
Ｂ．良好に動作しないメモリへの参照をプロファイルリング
図４ｂを再び参照すると、アドレス空間ＩＤ（ＡＳＩ）ゼロ以外に向けられたメモリロードは、イベントコードが１．１１００であるプロファイル項目と共に実行プロファイルの中に記録される（上記のセクションＶを参照のこと）。上記のセクションＩ．Ｄで論じられたように、ＡＳＩ非ゼロリファレンスは典型的にはＩ／Ｏ空間、すなわち挙動の正しくないメモリに向けられている（また、保守的には挙動の正しくないメモリに向けられていると仮定される）。この指摘は、ＴＡＸｉ変換プログラム１２４によいヒューリスティック（heuristic）を提供して、積極的な最適化されたコードの生成と、保守的な順序どおりのコードの生成のいずれかを選択させる。
【０５１２】
最初の仮定は、すべてのメモリの読取りは、挙動の正しいメモリ（アドレス空間ゼロ）に向けられているということである。コンバータ１３６が実行され（ＰＳＷ．ＩＳＡがＸ８６モードを示す）、プロファイラ４００が有効である時（ＴＡＸｉ＿Ｓｔａｔｅ．Ｐｒｏｆｉｌｅ＿Ａｃｔｉｖｅ４８２は１である。次のセクションＶ．ＥおよびＶ．Ｆを参照のこと）、Ｉ／Ｏ空間（Ｄ−ＴＬＢ．ＡＳＩがゼロではない）へのロード命令が終了すると、「Ｉ／Ｏ空間ロード」プロファイル項目がレジスタ内にストアされる。ＴＡＸｉ変換プログラムはこのプロファイル項目を解釈して、楽観的な仮定があてはまらないことを示し、少なくともこのロードは悲観的な仮定の下で変換プログラム１２４によって処理されなければならないことを示し、上記のセクションＶＩＩＩ．Ａで論じられたセグメント記述子「ＴＡＸｉ最適化済みロード」ビットの「安全な」設定でマーキングすることが可能になる。
【０５１３】
この機能の実装は、ブランチ予測のために使用される機構といくぶん似ている。コンバータ１３４、１３６は、タペストリパイプライン１２０によって実行するために、各Ｘ８６命令を複数のネイティブタペストリＲＩＳＣ命令に分解することを思い出されたい。単一のＸ８６命令がいくつかのメモリリファレンスを有する時、各メモリリファレンスは離散タペストリ命令に分離される。ゼロ／非ゼロのＡＳＩ値がＤ−ＴＬＢ内に記録されており、したがってバスサイクルを実際に開始しなくても決定することが可能であるとしても、アドレス空間の決定はパイプライン内の比較的遅い時点で発生する。したがって、非ゼロＡＳＩへのリファレンスが検出された時、パイプライン内でロードに続くタペストリ命令はフラッシュされる。ＴＡＸｉ＿Ｓｔａｔｅ．Ｅｖｅｎｔ＿Ｃｏｄｅ＿Ｌａｔｃｈ４８６、４８７（次のセクションＶ．Ｅを参照のこと）は、図４ｂの特別なＩ／Ｏロードコンバータイベントコード１．１１００で更新される。Ｉ／Ｏ空間プロファイル項目を記録するＴＡＸｉ命令が注入され、ついで、通常のプロファイル収集ハードウェアが、上のセクションＶ．Ｆで図５ａおよび図５ｂに関連して論じられた方法で、「Ｉ／Ｏ空間ロード」プロファイル項目を記録する。このＴＡＸｉ命令は、セクションＶ．Ｆで論じられた他のＴＡＸｉ命令がＸ８６命令境界で注入され、単一のＸ８６命令のレシピ（recipe）の中間で注入される場合があることに注意されたい。通常のＸ８６命令実行がコンバータ１３６内で再開し、コンバータレシピ内の命令の残りは再開される。
【０５１４】
代替の実施形態は、他のクラスの命令を選択してプロファイル化することであり、典型的にはこれらの命令は、同時の例外を発生させる確率が高い命令であるかまたは、ホットスポット検出器１２２またはＴＡＸｉ変換プログラム１２４の、所定の他の目的のプロパティを有する命令である。このようなプロファイル化された命令の数は比較的少数に保たれ、ホットスポット検出器１２２またはＴＡＸｉ変換プログラム１２４に使用可能な情報の密度を大幅に低減しないようにする。
【０５１５】
Ｃ．精確な境界に到達するための規範的機会状態の調停
ＴＡＸｉ変換プログラム１２４によって生成されたコードは、Ｘ８６命令境界の復元を可能にする情報でアノテートされている。単一のＸ８６命令が多くのタペストリ命令に分解され、これらのタペストリ命令がＴＡＸｉ最適化プログラムによって順序を変えられる場合、アノテーションは特定のＸ８６命令の端を特定することを可能にする。ストアされた情報は、デバッガが使用するために最適化コンパイラによってエミットされた情報と同様である。ここで、単一のソースステートメントの命令がアノテートされ、ソースステートメントは復元できる。ＴＡＸｉでは、アノテーションによりタペストリ命令のもつれた網からＸ８６命令境界を復元することが可能である。したがって、同期例外が仮想Ｘ８６にさらされる時、ＴＡＸｉランタイムシステムはＸ８６命令境界で優勢であるシステム状態と等価なシステム状態を確立する。状態が正しい命令境界に復元されると、実行はコンバータ１３６に渡され、コンバータ１３６はその命令境界から実行を再開することが可能である。
【０５１６】
一部の例では、このアノテーション機構は大量の命令による実行をロールバックし、すべてのＸ８６命令がまだ開始していないと仮定されるか、完全に終了したと仮定されるかのいずれかである「安全な」状態を確立する。ロールバック機構は、単一の副次的な作用が２回適用される可能性のある状態から実行を再開することを避ける。
【０５１７】
コードはそれ自体が「チェックポイント」であり、データベースシステムといくらか似た方法で一貫した状態のスナップショットをキャプチャする場合がある。ついで、ＴＡＸｉコード内の障害の場合には、実行はチェックポイントにロールバックし、コンバータ１３６内で再開することが可能である。
【０５１８】
Ｄ．セーフティネット実行
ここ再び図３ｊを参照すると、１つの代替の実施形態では、非同期的な割込みである場合、ケース３５１またはケース３５４では、Ｘ８６エミュレータ３１６またはコンバータ１３６がそれぞれ、次のＸ８６命令境界に進んでから割込みを行うことが可能にする。状態がＸ８６境界で安定すると、ケース３５１のように実行はＸ８６オペレーティングシステム３０６の中を進行する。代替の実施形態では、ケース３５１、ケース３５３、およびケース３５４の非同期割り込みの場合、コードは次のセイフティネットチェックポイントに進んでから例外を行うことが可能である。すべてのタペストリ拡張コンテキストが終了して廃棄可能であり、順序がＸ８６アーキテクチャによって保証されないイベントだけが互いに関して順序を変えることが可能である安定したポイントで、仮想Ｘ８６  ３１０が「休止に持ち込まれる」というという点で、これらの各々は概念的には同様である。
【０５１９】
例外がＴＡＸｉコード内で発生し、例外ハンドラが、Ｘ８６仮想マシン内で例外を具体化しなければならないと決定した時、Ｘ８６の状態を設定する責任を持つエミュレータ３１６内の共通の項目にジャンプし、割込みスタックフレームを確立し、ＩＤＴにアクセスして制御の移動を実行する。この機能が起動されると、まず、ＰＳＷ．ＴＡＸｉ＿Ａｃｔｉｖｅを確認することによってＴＡＸｉコードが実行されたかどうかを決定しなければならず、実行されている場合にはＸ８６マシン状態を再構成し、コンバータ内でＸ８６命令を再実行して同じ例外を再び起動する、ＴＡＸｉ機能にジャンプする。Ｘ８６命令の再実行は正しいＸ８６例外状態を確立する。コンバータが開始してＸ８６命令を再実行するといつでも、例外ハンドラはプローブが失敗したＲＦＥを使用し、プローブタイマイベントコードを再ロードして、再帰的なプローブ例外が発生することを防ぐ。
【０５２０】
Ｘ８６にさらされない場合がある唯一の例外は、たとえば、ページ不在なしに満足されるＴＬＢミス、マスキングされないＸ８６浮動小数点例外は伴わないＦＰ不完全など、ネイティブなタペストリコードによって完全に実行できる例外である。
【０５２１】
ＩＸ．  コンバータ
Ａ．概要
１．パイプライン構造および変換レシピ
図１ｃに与えられたＸ８６ブランチおよびタペストリブランチの、ソフトウェアを中心とした図とは対象的に、図９ａは、パイプラインのＸ８６ブランチのハードウェアを中心とした図を示す。図１ｃと図９ａを共に参照すると、コンバータおよびタペストリパイプラインは２つの部分に分かれる。図１ｃの左側および図９ａの上側に示されるように、Ｃ段９０２およびＴ段９０３（集合的に１３４）、およびＬ段１１０は、パイプラインの上部１３４を形成する。Ｄ段１４０からＷ段１５０はパイプラインの下部１２０を形成する。
【０５２２】
下部１２０は４つの、比較的には従来型のＲＩＳＣパイプライン１５６、１５８、１６０、１６２を含み、このセクションＩＸを通じて詳述されるいくつかの追加の機能および制御を伴う。パイプラインの下部１２０は順序通りに命令を実行する。依存性はストールによって管理され、ソースオペランドが使用可能でない限り、命令がソースオペランドを有しているはずの段を超えて進むことは許可されていない。
【０５２３】
パイプラインの上部１３４では、命令がフェッチされる。ＰＳＷ．ＩＳＡ１９４（上のセクションＩＩを参照のこと）が現在ネイティブなタペストリモードを指定している場合、フェッチされた命令は下部１２０に直接送られる（図１ｃのパス１３８）。
【０５２４】
図９ａはだいたい、ＰＳＷ．ＩＳＡ１９４が現在Ｘ８６モードを指定し、各フェッチされたＸ８６命令が１から９のネイティブな命令のシーケンスに変換される場合に関する（図１ｃのパス１３６、図９ａの段１１０、９０２、９０３）。変換プロセスはＣ段９０２およびＴ段９０３の２つの段で実行される。Ｃ段９０２は部分的に各Ｘ８６命令を復号化し、それに関する有用な属性を確認する。
【０５２５】
変換自体はＴ段９０３で、タペストリ命令生成装置ＴＩＧ  ｉ１  ９０５およびＴＩＧ  ｉ２  ９０６という２つの同一のコピー内で発生する。ＴＩＧ  ｉ１
９０５およびｉ２  ９０６は、各Ｘ８６命令オペコードおよびアドレスモードビットを復号化して、この復号化に基づいて、生成されるべき命令の「レシピ」を選択する。レシピは１から９の命令長である可能性がある。２つのＴＩＧ  ９０５および９０６の各々は各サイクル内で２つの命令を生成することが可能である。したがって、各サイクル内でレシピの４つの命令が生成できる。たとえば、Ｘ８６命令が６つのネイティブな命令を生成する場合、ＴＩＧ  ｉ０  ９０５は第１のサイクルで最初の２つを生成し、ＴＩＧ  ｉ１  ９０６は第１のサイクルで第２の２つを生成し、ＴＩＧ  ｉ０  ９０５は第２のサイクルで最後の２つを生成する。命令生成装置ＴＩＧ  ｉ１  ９０５およびＴＩＧ  ｉ２  ９０６は命令間の依存性にかかわりなく命令を生成する。これらの依存性は発行バッファ９０７およびＤ段１４０によって管理される。すべての依存性が解決されるまで、命令は発行バッファ９０７内に保持される。
【０５２６】
上部１３４は、命令復号化および処理の次の部分を実行する。ブランチが予想される。Ｘ８６  ＩＰ（命令ポインタまたはプログラムカウンタ）が、生成されたネイティブの各命令に関連づけられる。ネイティブな命令はいくつかのタグを与えられ、これは次のセクションＩＸ．Ａ．３で論じられる。いくつかのタイミングクリティカルな例では、ネイティブな命令が部分的に復号化される。
【０５２７】
Ｄ段１４０は発行バッファ９０７を管理し、命令がインターロック考慮を満足させ、発行バッファ９０８からリリースできる時を決定する。Ｄ段１４０は、同じマシンサイクルの中で対にできる命令を分析する。Ｄ段１４０は、直線的な制御フローのセグメントのすべての命令が、連続的なシーケンシャルなストリームで低いパイプライン１２０に発行され、直線的なフローのセグメントを破壊するブランチは、ストリームの最後の命令としでなければパイプラインに入らないようにする。
【０５２８】
Ｒ段１４２は、レジスタファイルからレジスタオペランドを読み取る。
Ａ段１４４は多くの機能を実行する。メモリリファレンスネイティブ命令の場合、アドレスが計算され、キャッシュアクセスが開始される。「追加」または「ｏｒ処理」などの簡単な算術論理命令が第１のＡＬＵおよび第２のＡＬＵの中で実行される。第３のＡＬＵはＡ段１４４の中で作動する。整数の乗算、浮動小数点の加算および乗算がＡ段１４４の中で実行を開始し、Ｅ段１４８まで継続する。
【０５２９】
Ｍ段１４６では、キャッシュアクセスが終了しキャッシュの出力が配置（align)される。シフタは復号化作業を開始する。いくつかの簡単なシフトがＭ段１４６内で終了する。
Ｅ段１４８では、メモリロードの結果が使用可能になり、他のユニットにバイパスする。シフトが終了する。第４のＡＬＵはＥ段１４８で作動する。乗算が終了する。乗算に関連する任意の累積がＥ段１４８内で実行される。命令が乗算をコールしない時には、所定の簡単な算術命令および論理命令がＥ段１４８で実行される。
【０５３０】
次のセクションＩＸ．Ａ．５およびＩＸ．Ｃ．２で論じられるように、Ｗ段１５０は結果を書き込み、例外を認識し、フラク(frac)情報を収集する。例外を含む、すべてのアーキテクチャで見える副次的な作用はＷ段まで延期される。たとえば、キャッシュミスへのメモリアテンダントへのアクセスなど任意のバストランザクションはＷ段１５０まで延期される。パイプラインの初期に発生した例外（Ｅ段１４８で発生したゼロによる除算、またはＡ段で発生したページ不在など）は、認識されたときは発生せず、命令には例外を発生させたというタグが付けられる（次のセクションＩＸ．Ａ．３で論じられるようにサイドバンド（side−band）情報を使用して）。命令はパイプラインを下に進行してＷ段１５０に行くことが許可される。例外とされた命令がＷ段１５０に達すると、次のセクションＩＸ．Ａ．４で論じられるように、例外はレシピのすべての命令に渡って集められる場合もあり、すぐに発生させられる場合もある。
【０５３１】
パイプ制御９１０はいくつかの主な機能を実行する。パイプ制御９１０はソースオペランドが準備できていない時にパイプライン段をストールし、オペランドが準備できた時に段が進むことを許可する。パイプ制御９１０は、バイパスツリーの中でソースオペランドが使用可能な場所を決定するバイパスマルチプレクサを制御する。パイプ制御９１０は種々の実行段から例外に関する情報を集め、これらの例外に対する対応を調整する。これにはたとえば、予想が間違ったブランチを検出すること、予想の間違いが検出された時にパイプラインの適切な段をフラッシュすることなどが含まれる。例外はさらに、次のセクションＩＸ．Ａ．４で論じられる。
【０５３２】
２．エミュレータ
図９ａおよび図３ａと共に図９ｂを参照すると、ハードウェアコンバータ１３６およびソフトウェアエミュレータ３１６は共同して、Ｘ８６アーキテクチャの完全で信頼できる実装を生む。コンバータ１３６は簡単な命令を処理する。エミュレータ３１６はより複雑な命令、命令の間の複雑な相互作用、およびイベントと命令の間の複雑な相互作用を処理する。
【０５３３】
従来のプロセッサが例外をとる時、プロセッサの状態はスタックに保存され、例外が処理される。実行が例外とされたプロセスに戻る時、プロセッサの状態はメモリスタックから復元される。
【０５３４】
しかしＸ８６のタペストリエミュレーションでは、スタックはこの目的には使用不可であり、例外機構はＸ８６アーキテクチャで見える記憶域を使用することは許可されていない。すべての例外がＷ段１５０の開始によって検出され、Ｗ段１５０の間に発生させられるが、アーキテクチャで見える副次的な作用は、Ｗ段１５０の最後までコミットされず、例外に関して保存し復元しなければならない中間のパイプライン状態の量は非常に限られている。この情報は、エミュレータインタフェースレジスタ９１２と呼ばれる特別な目的のプロセッサレジスタの集合の中に保存され、復元される。エミュレータインタフェースレジスタ９１２はＸ８６命令に関する十分な情報を含み、必要であればエミュレータ３１６はＸ８６命令を再フェッチし、それ自体で復号化することが可能である。エミュレータインタフェースレジスタ９１２は複雑な命令のエミュレーションを起動するときにロードされ、一般的には他の例外に関しては意味がない。
【０５３５】
エミュレータインタフェースレジスタ９１２のほかに、ＥＰＣレジスタ９１４はマシンプログラムステータスワード（ＰＳＷ）およびＸ８６プログラムカウンタ（ＩＰ）の画像を含む。ＥＰＣレジスタ９１４は他の情報の中でも次のビットフラグを含む。
【０５３６】
【表７】
0005427742.tif 000011
【０５３７】
追加のエミュレータインタフェースレジスタ９１２は、Ｘ８６有効アドレスサイズ、メモリアドレス指定モードおよびセグメントに関する情報、命令ポインタ、ブランチ命令に関するディスプレイスメント（displacement）、イミディエイト（immediate）を伴う命令に関するイミディエイト、ハードウェア変換がターンオフされている命令の所定のクラス、命令長、オペコードおよび有効なオペランドサイズ、命令が関連するロックまたは反復接頭部を有していたかどうかを示すフラグ、ｍｏｄｒｍおよびＳＩＢバイトに関する情報などを使用可能にする。
【０５３８】
また、これらのエミュレータインタフェースレジスタ９１２およびＥＰＣ９１４は、１つの命令と同等な履歴的なコンテキストを提供する。これはプロセッサレジスタで実装される１つの深い例外スタックに対応する。次のセクションＩＸ．Ａ．３およびＩＸ．Ａ．５で論じられるように、命令内のＰＣ（「フラクビット９３０」）もＥＰＣレジスタ９１４内でキャプチャされる。Ｘ８６命令内で割り込みが発生した場合でも、例外は２つのタペストリ命令の間の正確な境界で発生する。例外が発生すると、従来は例外フレーム内のメモリスタックにあふれていた情報は、エミュレータインタフェースレジスタ９１２およびＥＰＣ９１４、タペストリ汎用レジスタ、およびＦＰ  ＩＰ／ＯＰ／ＤＰレジスタ内で、アーキテクチャでコミットされる（セクションＩＸ．Ｃ．２で論じられる）。したがって、ソフトウェア例外ハンドラは、まったくメモリ例外フレームによらないで、任意の部分的に実行されたＸ８６命令の、完全な中間状態へのアクセスを有し、割込み時点で命令を再開することが可能である。エミュレータはフラクビット９３０命令内ＰＣを確認することによって、Ｘ８６命令が割り込まれた場所を正確に決定し、したがって、どのタペストリレジスタがどのＸ８６オペランドに対応するかなどを決定することが可能である。エミュレータ／コンバータインタフェースは、エミュレータが、例外が知らされたレシピの場所を知る必要がないように設計されているが（わずかだが例外もある）、ＦＲＡＣビットはこの情報を使用可能にする。
【０５３９】
複雑なＣＩＳＣ命令は、基本的には他の例外と同じパイプラインおよびアーキテクチャ上のインフラストラクチャによって処理される。コンバータ１３６がエミュレータ３１６によって処理されるべき複雑な命令に遭遇すると、コンバータ１３６は情報をエミュレーションインタフェースレジスタ９１２およびＥＰＣ９１４の中に保存する。コンバータ１３６はついで、トラップ命令をパイプライン１２０に発行する。トラップ命令は引数と、実行されるべきハンドラを選択するトラップベクトル番号（たとえばエミュレータトラップベクトルのうち１つ）を有し、引数は特定の命令または主なマシンモードに依存する場合がある。トラップ命令は例外をエミュレータ３１６に移動する。トラップ引数はエミュレータ３１６内のルーチンを選択するために使用される。選択されたルーチンは、コンバータハードウェア１３６のために複雑な命令の作業を実行する。選択されたエミュレーションルーチンは、エミュレーションインタフェースレジスタ９１２およびＥＰＣ９１４の内容によって制御される。エミュレータ３１６の中の所定のハンドラは、エミュレーションインタフェースレジスタ９１２およびＥＰＣ９１４を読取り専用情報をして使用し、すべき動作を決定する。所定のハンドラは、結果をエミュレータインタフェースレジスタ９１２およびＥＰＣ９１４に書き込む。エミュレーションルーチンの最後に、ＲＦＥ命令は例外をコンバータ１３６に戻す。マシン状態はエミュレータインタフェースレジスタ９１２およびＥＰＣ９１４内の情報に基づいて再確立され、その情報は例外の時点でそこに置かれた情報である場合もあれば、ハンドラによって変更された情報である場合もある。
【０５４０】
パイプライン内のネイティブタペストリ命令は、これらがネイティブなタペストリバイナリからのものであるかどうかに関しても、これらが生成された元のＸ８６命令に関しても、また、Ｘ８６レシピの中における場所に関しても、コンテキストに依存しないことが望ましい。たとえばデバッギングなど所定のＸ８６の複雑さがあってもこのコンテキストからの独立性を推進するために、エミュレータ３１６は時々、レシピの中間でトリガされ、マシンの状態を１つのタペストリ命令から次の命令へ移動し、単一のＸ８６命令のすべての結果を収集する。
【０５４１】
メモリから汎用レジスタへの、Ｘ８６  ＭＯＶ命令の場合を考える。このＸ８６命令に関するレシピは単一のネイティブな命令、ロードである。メモリロードはＩ／Ｏ空間に向けられて、再試行されるとプロセッサの状態を変化させる場合があるので、メモリロード動作を発行するのは１度だけでなければならない。メモリロードはセグメント化およびページング（paging）変換ハードウェアを調べる。たとえばメモリロード上にＴＬＢミスがあった場合、ロードの実行は妨げられる。Ｘ８６  ＥＩＰ情報およびフラクビット９３０はストアされて、命令が再開されるコンテキストを保存する。（フラクビット９３０およびＸ８６命令の途中からの再開は、次のセクションＩＸ．Ａ．３およびＩＸ．Ａ．５でさらに詳細に論じられる）。実行はＴＬＢミスハンドラ（miss handler）に向けられる。最後に、実行がコンバータ内で再開される。レシピは単一の命令なので、レシピは最初から再開される。
【０５４２】
トラップと障害に関するパイプライン制御におけるハードウェア例外ベクトル化機構（vectoring mechanism）は、例外がエミュレータ３１６で処理されても、タペストリオペレーティングシステム（図３ａの３１２）で処理されても、またはＸ８６オペレーティングシステム３０６で処理されても、比較的均一である。したがって、ハードウェアはエミュレータ３１６またはその機能に関してほとんど知識を有せず、ハードウェアにとってはエミュレータ３１６は別の例外ハンドラに過ぎない。違いはソフトウェア自体の中にとどまっている。たとえば、エミュレータ３１６へ入ると、特別なハンドシェークがエミュレーションインタフェースレジスタ９１２およびＥＰＣ９１４を保護して、Ｘ８６コンバータ１３６の状態をキャプチャし、コンバータ１３６をターンオフしてネイティブモードに入る。ハードウェアの視点から見れば、エミュレータ３１６を起動して複雑な命令を処理することと、エミュレータ３１６または別の例外ハンドラを起動して、最初にコンバータ１３６によって処理された命令の中の例外を処理することの間にほとんど差はない。
【０５４３】
このセクションＩＸに記述された技法を組み合せると（セクションＩＸ．Ａ．３の命令ポインタおよびフラクビット９３０、セクションＩＸ．Ａ．２のエミュレータインタフェースレジスタ９１２およびＥＰＣ９１４、およびセクションＩＸ．Ｂ．１に論じられる一時レジスタを含む）、パイプライン状態をスタック上にダンプしなくても、例外に際してキャプチャする必要のあるすべてのコンテキストを、事実上使用可能にして検査できるようにする。その代わりに、従来のプロセッサではスタックにスナップショットされていたＸ８６の中間情報は、タペストリのアーキテクチャ上の状態にさらされる。エミュレータ３１６またはタペストリオペレーティングシステム３１２内でネイティブタペストリを実行しても、エミュレータインタフェースレジスタ９１２は更新されず、このコンテキスト情報はエミュレータ３１６によってキャプチャすることが可能である。これは、ＥＰＣ９１４が、たとえばＴＬＢミスなどすべての例外の間で共有されているためである。このようにして、エミュレータ３１６は他の例外が知らされている可能性がある場合、ＥＰＣ９１４をメモリへ書き込むことによってＥＰＣ９１４を保存する。一時レジスタおよびＸ８６エミュレータインタフェースレジスタは、上のセクションＩＩＩで論じられたコンテキスト管理技法を使用して、Ｘ８６プロセスの間で管理されている拡張コンテキストの一部である（Ｘ８６の視界の外にあるネイティブなタペストリコンテキスト）。Ｘ８６命令を再開するために必要な追加の情報は、保存された命令ポインタおよびフラクビット９３０から導出することが可能である。
【０５４４】
ＴＬＢミスハンドラの実行は、例外にされたＸ８６命令を命令キャッシュから追い出す場合がある。再開すると、命令フェッチは命令キャッシュの中で見失われる場合がある。キャッシュ可能なメモリ内にストアされた命令については、故意でない副次的な作用はない。キャッシュ不可能なメモリにストアされた命令に関しては、追加のメモリリファレンスが発生する場合がある。
【０５４５】
３．サイドバンド情報。ｆｒａｃビット、命令境界、割込み可能ポイントなど。
図９ａと共に図９ｃおよび図９ｄを参照すると、各命令がパイプの下の段階に降りていくと、ネイティブ命令へ変換する間に生じたいくつかのアノテーションおよび状態情報のビット９２０が付随する場合がある。これらの追加ビット９２０は「サイドバンド」情報と呼ばれる。サイドバンド情報はＸ８６命令に関して上部の１３４の中で作成され、ＴＩＧ９０５、９０６からパイプ制御９１０にフィードされた矢印９２２および、パイプ制御９１０からパイプラインの実行ユニットへフィードされた矢印９２３によって示されている。ネイティブモードの実行の間、サイドバンド情報はネイティブモードの復号器によって復号化された３２ビット命令としても生成される（図１ｃの１３２、１３８）。サイドバンドの補足９２０を伴う完全な命令は「フォーマット化された命令」と呼ばれる。
【０５４６】
アーキテクチャでさらされたネイティブな命令フォーマット（たとえば、アセンブリ言語プログラマに）、ロード／ストアディスプレイスメント、算術／論理イミディエイト、およびＰＣ関連のブランチのディスプレイスメントのために、６ビットのフィールドを有する。Ｘ８６は８ビット、１６ビットおよび３２ビットのイミディエイトおよびディスプレイスメントを提供する。ＴＩＧ９０５、９０６およびネイティブタペストリ命令復号器１３２、１３８は、これらのディスプレイスメントおよびイミディエイトを３２ビット９２４に拡張する。この拡張されたディスプレイスメントまたはイミディエイト９２４は、サイドバンド情報として、ネイティブインストラクションまでパイプラインの段を下へ降りていく。パイプラインの下部１２０の中の命令は、そのほかの点では、アーキテクチャにさらされたネイティブタペストリ命令と同じである。
【０５４７】
多数命令生成装置９０５、９０６は、一度に単一のＸ８６命令に関して動作し、共同して、そのＸ８６命令から最高で４つのネイティブタペストリ命令を生成することが可能である。各ネイティブな命令は、ネイティブな命令の元となったＸ８６命令に関するＩＰ値を示すマーカでタグを付けられている。簡単な１実施形態では、各命令は３２ビット値のＩＰおよび４つのフラクビット９３０を有する（フラクビット９３０はこのセクションＩＸ．Ａ．３の後半で説明される）。別の実施形態では、３２のＩＰ値レジスタの組が提供され（８つのパイプライン段に対して、４つのパイプラインをかける）、各々はＸ８６のＩＰ値を保持する。レシピの各ネイティブ命令は、ネイティブ命令が変換された元のＸ８６命令のＩＰ値を保持するＩＰ値レジスタを指すポインタを有する。レシピの最後の命令がリタイアすると、Ｘ８６命令に関するＩＰ値レジスタは解放される。Ｘ８６命令がコンバータに入ると、自由ＩＰ値レジスタのうち１つが割りつけられ、現行のＸ８６のＩＰ値でスタンプ（stamp）される。
【０５４８】
別の実施形態では、命令ポインタマーカは最適化され、命令がコンバータ１３６によって生成された順序に関する所定の制約を認識する。命令がパイプラインを下へ流れる時、命令は下から上、左から右の順序で維持される。ブランチはすべて、もっとも右側のパイプラインにある。したがって、パイプラインの水平のスライスの各々の中ではすべての命令が順序どおりであり、シーケンシャルな流れの部分を反映する。ブランチ命令はつねに、パイプライン段のもっとも若い命令である。したがって、所与の段の中にあるすべての命令に関するＩＰは、もっとも左のパイプライン内の命令のＩＰ値と、最高で４５を加算した値に等しい（各々が最高で１５バイト長の、３つの追加のシーケンシャルなＸ８６命令）。この実施形態では、各段１４０〜１５０は、最も左の命令のＩＰ値を有し（ＰＣ列９２５）、他の３つのパイプ内にある命令は、各々累積された命令長値を有する。その段に関するＰＣ９２５と累積された命令長の合計は、対応する命令にＩＰ値を与える。
【０５４９】
別の実施形態では、各命令は長さを有する。全体を読み取る間、レシピの終わりマーカでマーキングされた各命令の後で、ＩＰ値は長さカウントによってインクリメントされる（次に論じる）。４つのパイプライン１５６〜１６２を下へ移動するシーケンシャルなグループ（ｉ０〜ｉ３）の中の各命令は合わせて、ゼロから１５の命令長を有する。パイプ１３４の一番上で、Ｘ８６命令の長さは各Ｘ８６レシピの最後の命令の上にタグとして付けられ、最後でない／９２６ネイティブ命令は、その長さタグをゼロに設定する。
【０５５０】
パイプラインのＤ段からＷ段１４０〜１５０内のネイティブ命令は、マーカ９２６を有し、各Ｘ８６命令に関してレシピ内の最後の命令を示す。各命令上のレシピの最後マーカはＸ８６＿ＣＯＭＰＬＥＴＥＤ９２６と呼ばれる。セクションＩＸ．ＣからＩＸ．Ｅに論じられるように、この指示は、命令境界を示すために使用され、命令境界は、信号ステッピングを制御し、実行が割り込まれる可能性のあるポイントなどを示すために使用される。
【０５５１】
Ｘ８６は、所定の長い実行命令の部分的な実行の間、所定のポイントで割り込み可能である。たとえば、Ｘ８６文字列命令は、文字列の移動または比較の現在のバイトのアドレスなど、文字列のオペランドごとに一回変化するアーキテクチャで目に見える状態で、所定の反復境界において割り込むことが可能である。Ｘ８６は、このような命令が割り込みされたり、部分的に実行された命令内で単一ステップされたりした後、通常の目に見えるＸ８６状態を使用して再開されることを可能にする。パイプラインのＤ段からＷ段１４０〜１５０内のネイティブな命令は、これらの割込み可能なポイントを示すマーカ９９０を保持する。これらのレシピの終わりマーカ９２６および、割込み可能反復境界マーカ９９０はＷ段１５０内で使用され、次にセクションＩＸ．Ｃで論じられるように適切な時に割込みを発生させる。
【０５５２】
各タペストリ命令は例外タグ９２７を有する。命令が例外を発生させた場合、タグ９２７は最も高い優先順位の例外ベクトルの値を有する。各実行パイプラインおよび各パイプライン内の各段は例外タグ９２７を有する。各パイプラインはストアされた、異なる例外を検出する場合があるので、各パイプラインに特定のフォーマットが一意的にある。ほとんどのパイプラインは、ベクトル番号と同様な一意的な識別子をストアするだけである。この例外情報は命令と共にパイプラインを下へ流れる。Ｅ段１４８では、最後の例外情報が得られる。すべてのパイプラインに関するＥ段情報は、経過時間によって優先順位が付けられ、アクション可能な例外を伴う最も古い命令を選択する。この単一の命令に関する例外は再び、アーキテクチャ上の優先順位によって優先順位を付けられる。もっとも高い優先順位の例外が発生し、残りは待ち行列に加えられる。
【０５５３】
段に関するＡＰＣ列９２８は、「代替のＰＣ」、すなわちこの段のグループ内で最高で１つのブランチに関連づけられた代替のパスに関する命令ポインタを示す。あるブランチがとられていると予想される場合、代替のＰＣはシーケンシャルなＰＣであり、命令はブランチに従う。とられていないと予想されるブランチの場合には、ＡＰＣはブランチのターゲットである。（任意のパイプライン段には１つのブランチしかある可能性はなく、単一のＡＰＣで段の４つの命令を十分にカバーできることを思い出されたい）。いつでも、ブランチが間違って予想されたと決定された場合、パイプラインの若い命令はすべてフラッシュされ、実行はＡＰＣ９２８によって示された命令で再開する。
【０５５４】
サイドバンド９２０はまた、たとえば、レシピ内の特定のネイティブ命令がハードウェア割込みまたは、それに関連する単一ステップ例外を有するかどうかを示す、Ｘ８６命令制御情報に関連する情報も保持する。またサイドバンドは、たとえば浮動小数点スタックタグマップ、浮動小数点データポインタおよび命令ポインタ、および浮動小数点オペコード情報など、多くのＸ８６浮動小数点実装の機能を制御するためにも使用される。サイドバンド情報９２０はコンバータからの状態を含み、Ｘ８６浮動小数点スタックとネイティブなタペストリフラットレジスタファイルの間のマッピングも管理する。たとえば、命令がＸ８６浮動小数点スタック上に情報をプッシュするかそこからポップした場合、コンバータはサイドバンド情報を使用してそのマップへの変化を、パイプラインの上部１３４内で管理する。コンテキストが切り換えられた時または、マップを完全に変更する必要のあるエミュレートされた命令の間、新しいマップ情報はサイドバンド情報１２０を使用して実行ユニットとコンバータ１３４の間で通信される。
【０５５５】
各ネイティブタペストリ命令が、Ｔ段９０３の中の命令生成装置９０５、９０６によって発行バッファ９０８内に生成され、下パイプライン１２０で実行されると、命令は、ゼロから１５の４ビットのシーケンス番号でタグを付けられ、発生元のＸ８６命令に関してレシピ内のネイティブな命令のシーケンシャルな位置を示す。この４ビットのシーケンス番号は「フラクビット」９３０と呼ばれる。フラクビット９３０は次のセクションＩＸ．Ａ．５でさらに詳細に説明されるように、例外の後で、部分的に終了したＸ８６命令を再開させるために使用される。フラクレジスタ９３１は、各ネイティブ命令が生成されるとゼロからカウントアップし、Ｘ８６命令が終了するとゼロにリセットし、対応するネイティブ命令に関してフラクビット９３０を生成するカウンタである。フラク制御論理９３２は、フラクレジスタ９３１をインクリメントし、ネイティブな命令をカウントオフし、そのカウントを命令生成装置９０５、９０６へ供給する。命令生成装置９０５、９０６は、命令が発行バッファ９０７に供給されると、命令にフラク値９３０でタグを付ける。
【０５５６】
上方に流れるサイドバンド情報には、データおよび制御フローという２つのクラスがある。制御フローサイドバンド情報は、「パイプラインの下部がフラッシュされていること」、または「上部１３４を含めた全パイプラインがフラッシュされていること」、および実行を再開する新しいプログラムカウンタを示す。この上方に流れる制御フローの具体的な例は、次のセクションＩＸ．Ｂ．５およびＩＸ．Ｂ．６内で論じられる。
【０５５７】
追加のサイドバンド情報が図９ｄに示されている。サイドバンド９２０の２つの具体的な要素が次のセクションＩＸ．Ａ．６（ロードおよびストア命令に関する）および、ＩＸ．Ｃ．２（浮動小数点情報に関する）で論じられる。
４．割り込み、トラップ、および例外
【０５５８】
例外は、Ｘ８６命令の細分性または割込み可能なポイントの細分性で報告される。ネイティブな例外は（ハードウェアの割込み、実行障害およびトラップ）は、このネイティブな命令がＸ８６レシピの一部である場合でも、任意のネイティブ命令境界上で知らされる可能性がる。しかしＸ８６例外は、Ｘ８６プログラマにはＸ８６境界上で発生した時に見える。これは、レシピ内のすべてのネイティブ命令が完全に実行されることを必要としない。そのかわりに、レシピ内の後半の命令が終了しなくても、対応する障害が認識されるとＸ８６障害はすぐに表面化する。しかしＸ８６トラップは、レシピ内のネイティブ命令のすべてが終了するまで延期される（エミュレータによって）。このセクション４では主にＸ８６例外を扱う。
【０５５９】
例外には障害とトラップの２つの種類がある。例外に特有の副次的な作用以外では、障害はＸ８６命令の実行をアンワインドする。トラップは、Ｘ８６命令が終了するまで遅延される。障害およびトラップは、レシピの個別のネイティブ命令が発生すると知らせることが可能である。
【０５６０】
所定の障害クラスに関しては（たとえば、次のセクションＩＸ．Ｂ．５に論じられるＬＯＯＰ命令および、ページ不在に関する条件コードの復元など）、エミュレータ３１６は全Ｘ８６命令をアンワインドし、障害をＸ８６に表面化する。たとえばＴＬＢミスなど他の障害クラスに関しては、エミュレータ３１６がその障害を処理し、ついでレシピ内で継続し、障害を起こしたネイティブ命令を再試行し、フラクビット９３０を使用して再開すべきネイティブ命令を決定する。障害がＸ８６オペレーティングシステムに表面化されるべき時は、エミュレータ３１６はエラーコードを含めて（場合によっては）、Ｘ８６互換スタックフレーム情報を構築する。
【０５６１】
最終ではないネイティブ命令／９２６内のトラップは、概念的にはＸ８６命令の中間の例外に対応する。例外は、Ｘ８６命令境界９２６（または割り込み可能なポイント９９０）において、Ｘ８６環境の上方にしか知らされないので、レシピの残りの命令が終了してから（おそらくエミュレータ３１６内でハンドラを起動して）、例外がＸ８６環境に表面化する。たとえば、デバッグハードウェア内のアドレスの比較は、すぐにトラップをエミュレータ３１６内に生成し、そこでトラップハンドラは報告されるべき情報を収集する。ついで実行が再開し、通常はＸ８６命令の最後にトラップがＸ８６環境に表面化される。レシピの最終のネイティブ命令９２６のトラップは、典型的には、Ｘ８６環境に表面化される。たとえば、Ｘ８６単一ステップ例外は典型的には、レシピの最終のネイティブ命令９２６で発生する。
【０５６２】
例外とされた命令がその例外タグ９２７と共にＷ段１５０に到達すると、「フラク更新」制御論理９３３が応答する。例外が、タペストリ命令について即時の応答を必要とする場合（レシピの最終命令に関する任意の例外、または障害）、上のセクションＩＸ．Ａ．２に論じられたように、例外がすぐに生じ、障害を命令内で修復するために、実行はエミュレータ３１６の中にベクトルを向ける。例外がレシピの最後ではない命令／９２６上のトラップであった場合、ネイティブマシンはネイティブ命令境界上ですぐに例外に応答するが、エミュレータ３１６は次のＸ８６命令境界９２６または、Ｘ８６命令の次の割込み可能なポイントに応答をゆだねる。Ｘ８６例外（トラップ）がＸ８６命令の最後に到達するために多数のネイティブ命令を超えて遅延されなければならない場合、１実施形態ではエミュレータ３１６は、次のセクションＩＸ．Ｃで論じられる方法で、Ｘ８６単一ステップ機能を使用して遅延を実行する。別の実施形態では、例外はフラク更新論理９３３内に保留され、実行は現行の命令のレシピの最後まで、または次の割込み可能なポイントまで進むことが許可される。いずれの実施形態でも、この前進が現行のＸ８６命令の最後９２６まで進む場合、ＩＰ値はインクリメントされて次の命令を指し、フラクレジスタ９３１はゼロに消去されて次の命令の始めを示し、これによって、Ｘ８６によってさらされたＩＰ値をエミュレートする。収集された例外が発生し、例外はエミュレータ３１６内にトラップする。例外がエミュレータ３１６によって処理できる場合は、実行は継続する。エミュレータ３１６が例外を修正することが不可能な場合は、エミュレータ３１６はスタック上にＸ８６例外フレームを構築し、制御のベクトルをＸ８６オペレーティングシステムに向ける。
【０５６３】
所定の単一ステップ例外がコンバータによって導入され、エミュレータ３１６内の作業をトリガする。次のセクションＩＸ．Ｅに論じられるように、コンバータ１３６はエミュレータ３１６内にベクトルを向け、エミュレータ３１６は単一ステッピングを起動して次のＸ８６命令の後に制御を得るが、次の命令はコンバートされるかエミュレートされている可能性がある。最終的にレシピの最後９２６に到達すると、Ｘ８６単一ステップ例外はエミュレータ３１６にベクトルを向け、エミュレータ３１６はＸ８６命令の途中で生じた状態を処理する。この機構の特定の例は、次のセクションＩＸ．Ｃ．１およびＩＸ．Ｅ．２で論じられる。
【０５６４】
エミュレータはまた、他のインスタンスの中の例外によっても起動される。たとえば、Ｘ８６命令が割込みフラグの書込みを要求すると、コンバータは単一ステップのトラップをエミュレータ３１６内に生成する。エミュレータ３１６は割込みフラグ値をエミュレータインタフェースレジスタに書き込む。この値は、エミュレータ３１６ＲＦＥがコンバータに戻った時に、実際のプロセッサレジスタにロードされる。他の例は次のセクションＩＸ．Ｂ．５およびＩＸ．Ｂ．６に論じられる。
【０５６５】
５．ｆｒａｃビットおよびレシピの継続
上のセクションＩＸ．Ａ．３で詳細に論じたように図９ａおよび図９ｂを再び参照すると、レシピの個別のタペストリ命令はフラクビット９３０でタグを付けられ、Ｘ８６レシピ内のネイティブ命令のシーケンス番号を示す。したがって、命令の内部動作がコンテキストから独立していたとしても、フラクビット９３０はコンテキストスタンプとして機能し、レシピ内の命令が発生した元を特定する。
【０５６６】
典型的には、Ａ段１４４からＷ段１５０で命令が例外を発生させた時、命令の例外タグは例外の性質を反映するように設定され、タグはＷ段１５０内で認識される。例外を開始する一部として、命令を例外とするためのフラクビット９３０は、ＥＰＣ９１４に記録されるＰＳＷ／ＰＣ情報の残りと共に、ＥＰＣ．ｆｒａｃ９３４内に記録される（このエミュレータインタフェースレジスタ内にキャプチャされるエラープログラムカウンタおよびプログラム状態ワード情報のサンプルに関しては表７を参照のこと）。制御は例外ハンドラにベクトルを向けられ、マシンがコンバータ１３６内で実行している場合、ほとんどの例外はエミュレータ３１６の中で処理される（Ｘ８６に表面化しなければならない例外は、上のセクションＩＸ．Ａ．２で論じられたようにまずエミュレータ３１６によって処理される）。例外ハンドラはＲＦＥ（例外から戻る）命令を発行することによって終了する。
【０５６７】
Ｘ８６実行を再開するために、ＲＦＥ命令はＥＰＣプロセッサレジスタ９１４をオペレーティングＩＰ、ＰＳＷ、およびマシンのほかの状態制御論理内に再ロードする。Ｘ８６プログラムの変換中に例外が発生した場合、上のセクションＩＩで論じられたように、ＥＰＣ．ＩＳＡビット１９４はＸ８６  ＩＳＡを示す。ＥＰＣ．ＥＩＰおよびＥＰＣ．ｆｒａｃ９３４ビットは、例外が発生したＸ８６命令（Ｘ８６命令ポインタにより）およびレシピ内のネイティブ命令を特定する。ＥＰＣ．ｆｒａｃ９３４値はＴ段フラクレジスタ９３１内に復元される。パイプラインはフラッシュされる。例外とされたＸ８６命令はＣ段９０２によって再びフェッチされる。Ｔ段９０３はＸ８６命令を変換しなおすが、レシピが最初から発行バッファ９０８に再発行されるわけではない。その代わりに、レシピは、ＥＰＣ．ｆｒａｃ９３４値によって示されたレシピ内のネイティブ命令を始めとして、再発行される。したがって、Ｘ８６命令バイトまたは中間パイプライン状態のいずれも、エミュレータ３１６が起動しエミュレーションから戻る間の時間は、ハードウェア内に保存される必要はない。
【０５６８】
６．外部形態からフォーマット化された形式への拡張
図９ｃおよび図９ｄを参照すると、たとえばアセンブリ言語プログラマなど外部へさらされたネイティブ命令の形態から内部のネイティブ形態へ拡大することは、内部命令の明示的なビット（場合によっては所定の修正を伴う）から、フォーマット化された命令の類似のフィールドへコピーし、外部形態内に類似物を有しないフィールドにはデフォルトを提供するという、比較的つまらないプロセスである。サイドバンド情報９４０の一部はロード命令およびストア命令に特有であり、Ｘ８６形態からネイティブなフォーマット化された形態へ変換する間、コンバータ１３６によって作成される。
【０５６９】
すべてのＸ８６メモリリファレンスはセグメント記述子から離れたところに基づいているが、一部のＸ８６命令では、セグメントリファレンスは命令内に明示的にコード化されているのではなく、オペコード内に暗示されている。これらの命令に関しては、コンバータ１３６は、明示的なセグメント記述子を伴う、ネイティブモードのフォーマット化されたロード命令またはストア命令を作成する。
【０５７０】
たとえば、一部のネイティブタペストリロード／ストア命令はセグメントリファレンス、アドレス指定モードおよび自動インクリメントを指定するが、明示的なディスプレイスメントは指定しない。これらの命令に関しては、タペストリのネイティブ命令復号器１３２、１３８は、命令で明示的に述べられた部分を通過し、フォーマット化された命令の指定されない部分に関してデフォルトの値を作成することによって、フォーマット化された命令を作成する。この例は、図９ｃの上に示されたＬＤＡ／ＳＴＡ（自動インクリメント／デクリメントを伴うロードまたはストア）命令９４１である。この命令のフィールドは、宛先レジスタ（ＬＤＡに関して；ＳＴＡに関しては類似のフィールドはソースレジスタである）に関してはオペコード、２ビットのオペランドサイズ、６ビットの指定子であり、オフセットレジスタに関しては４ビットのセグメント指定子および６ビットの指定子であり、これらは共に、メモリリファレンスのためにセグメントおよびオフセットを指定し、３ビットはプレインクリメントまたはプレデクリメント、またはポストインクリメントおよびポストデクリメント、または修正なしモードを指定し、４ビット９４２はアドレスサイズおよびメモリ保護チェックを指定する。ＬＤＡに関して、４ビットのアドレスサイズ／保護によって生成される１６のアドレス指定モードは表８に説明されている。
【０５７１】
【表８−１】
0005427742.tif 000012
【０５７２】
【表８−２】
0005427742.tif 000013
【０５７３】
ＬＤＡ／ＳＴＡ命令９４１を外部にさらされた形態からフォーマット化された形態に拡張する時に、タペストリのネイティブな命令復号器（図１ｃの１３２、１３８）は、フィールドをコピーし、命令の中で明示的に設定されていないフィールドをデフォルトで埋めるなど、非常に簡単なプロセスを実行する。たとえば、命令の外部形態９４１の中にはロード／ストアディスプレイスメントは存在しないため、復号器１３２、１３８は３２の明示的なビットの、ゼロアドレス指定ディスプレイスメント９２４を供給する。インデックスレジスタフィールドはゼロに設定され、Ｒ０を指す。サイドバンド情報９２０の残りは、マシンの種々の場所から集められる。
【０５７４】
第２の例として、ＬＤＢ／ＳＴＢ命令は、宛先レジスタ（ＬＤＢに関して。ＳＴＢに関しては同様のフィールドはソースレジスタである）に関してはオペコードフィールド、２ビットのオペランドサイズ、６ビットの指定子を有し、オフセットレジスタに関しては４ビットのセグメント指定子および６ビットの指定子を有し、６ビットのディスプレイスメントと共にメモリリファレンスのためにセグメントおよびオフセットを指定し、２ビットはアドレスサイズおよびメモリ保護チェックを指定する。明示的に指定された命令の部分は、あまり変更されないままで通過される。６ビットのディスプレイスメントは３２ビットに符号拡張されてディスプレイスメント９２４を生成する。
【０５７５】
逆に、他の命令はメモリオフセットを指定するが、明示的なセグメント記述子は指定しない。これらの命令に関しては、タペストリのネイティブな命令復号器１３２、１３８は、再び命令の明示的に述べられた部分を通過し、フォーマット化された命令の他の部分に関してデフォルト値を生成することによって、フォーマット化された命令を作成する。たとえば、ＬＤＣ／ＳＴＣ命令は、宛先レジスタ（ＬＤＣに関して。ＳＴＣに関しては同様のフィールドはソースレジスタである）に関してはオペコードフィールド、２ビットのオペランドサイズフィールド、６ビットの指定子を有し、オフセットレジスタに関してはセグメント指定子はなく６ビットの指定子を有し、および１２ビットのディスプレイスメントは共にメモリリファレンスに関してセグメントおよびオフセットを指定し、２ビットはアドレスサイズおよびメモリ保護チェックを指定する。明示的に指定された命令の部分は、あまり変更されずに通過される。６ビットのディスプレイスメントは３２ビットに符号拡張される。アドレスサイズおよびメモリ保護チェックフィールドは自動的に生成されて通常のデフォルトを反映する。
【０５７６】
典型的にはＡＤＤおよび同様の算術命令のために使用される第４のネイティブタペストリフォーマットは、図９ｃの下の命令９４３によって例示されている。ここで、命令のもっとも右側にあるオペランド９４４は、６ビットのレジスタ指定子または６ビットのイミディエイトのいずれかである場合がある。オペコードが、フィールド９４４はイミディエイトとして解釈されるべきであると指定した場合、６ビット値９４４は３２ビットに符号拡張され、フォーマット化された命令のイミディエイト／ディスプレイスメントフィールド９２４になる。オペコードが、フィールド９４４はレジスタ指定子として解釈されるべきであると指定した場合、レジスタ値９４４はフォーマット化された命令の第２のレジスタソースフィールド９４５にコピーされ、フォーマット化された命令の３２ビットのイミディエイト／ディスプレイスメントフィールド９２４はゼロに設定される。
【０５７７】
一部の実施形態では、ＬＤＡ／ＳＴＡ命令の４ビットモードの指定子、ＬＤＢ／ＳＴＢの２ビットアドレスサイズおよびメモリ保護チェックフィールド、およびＬＤＣ／ＳＴＣの２ビットアドレスサイズおよびメモリ保護チェックフィールドは各々、フォーマット化された命令の少なくとも４ビットの共通の形態に変換され、すべてのケースはパイプラインの残り１２０によって同様に処理できるようになる。他の実施形態では、命令は修正されずに通過され、低いパイプライン１２０は命令オペコードを使用して命令の残りを復号化する。
【０５７８】
サイドバンド情報の動作は、ネイティブ命令のオペコードに完全に直交しているわけではない。たとえば、一部の命令では、サイドバンドの「イミディエイト／ディスプレイスメント」フィールド９２４は算術イミディエイト値（arithmetic immediate value）として扱われ、他の命令ではロードまたはストアディスプレイスメントとして扱われ、また他の命令では、セグメントに関連した（segment−relative）絶対ブランチディスプレイスメントまたはＰＣに関連した（PC−relative）ブランチディスプレイスメントとして扱われ、さらに他の命令では（たとえば、ロード／ストアの一部のアドレス指定モードでは）、フォーマット化された命令の３２ビットのイミディエイトは無視される。一部の命令では、イミディエイト／ディスプレイスメントフィールド９２４のうち８ビットまたは１６ビットのみが使用される。
【０５７９】
Ｂ．命令の個別のリタイアメント
命令をたがいに独立させるために、多くの異なる技法が使用される。その結果、ネイティブ命令が障害を起こすと、障害が処理される場合もあれば、Ｘ８６命令が障害を起こしたネイティブ命令から再開する場合もあれば、実行が終了する場合もある。すべての副次的な作用はコアトミック（co−atomically）状態でＸ８６でアーキテクチャされた状態にコミットされるか、なにもコミットされない。Ｘ８６命令の即時の結果をキャプチャし、これらの結果を保存して再開するために必要なのは、非常に少数の特殊目的のハードウェアだけである。部分的にコミットされたＸ８６命令のアンワインディングはほとんど必要とされない。コンバータ１３６は、アーキテクチャ的に一貫した状態で、命令または割込み境界において実行をＸ８６環境に提供する。
【０５８０】
１．一時レジスタのレシピ使用
表１から、タペストリネイティブマシンのレジスタの一部はＸ８６の特定のリソースにマッピングされ（浮動小数点レジスタへはＲ３２〜Ｒ４７、整数レジスタへはＲ４８〜Ｒ５５）、一部はコンバータ１３６が有効な間、タペストリ特有の使用に割り当てられ（Ｒ０は読取り専用で常にゼロであり、Ｒ１〜Ｒ３は例外ハンドラのために保存され、Ｒ４はアセンブラテンポラリ（assembler temporary）でアセンブラが一致したときに使用され、Ｒ１５〜Ｒ３１はプロファイラ４００によって使用されるように割り当てられる）、さらに一部は割り当てられない（たとえばＲ５６〜Ｒ６３）ことを思い出されたい。
【０５８１】
レジスタの中で特殊目的に割り当てられるのはＲ５〜Ｒ１４であり、表１では「コンバータテンポラリ」に関して「ＣＴ１」から「ＣＴ１０」と示されている。これらのレジスタはＸ８６命令の即時の結果を保持し（たとえば、複雑なアドレス指定モードから形成されたアドレス、またはメモリオペランド）、これらの即時の結果を１つのネイティブタペストリ命令から別の命令へ搬送する。コンバータはこれらのレジスタを、Ｘ８６命令から次の命令に値を搬送するためではなく、Ｘ８６命令内で値を搬送するためにのみ使用する。したがって、Ｘ８６命令境界上でトラップまたは他のコンテキストの切換えが発生すると、すべての有効なＸ８６状態はレジスタＲ３２〜５５の中にあることが知られ、レジスタＲ５〜１４およびＲ５６〜６３内の状態は放棄することが可能である。また、Ｒ５〜Ｒ１４内の一時的な値は、他の使用に抵触しないことが知られている。しかしこのマシン状態は通常のレジスタ内であるので、通常の状態を保存する技法はこれらの中間的な結果を保存する役割を果たす。このことは、中間の結果がマシンのアーキテクチャで定義されたリソースの外にあるので、Ｘ８６自体がメモリスタック上に中間の命令の結果を保存するために使用しなければならない特殊な機構とは対照的である。
【０５８２】
図９ｅを参照すると、一時レジスタは、Ｘ８６のアーキテクチャの定義によって、単一の命令を介して漸次的に変化する状態が求められるレシピの中で使用される。一時レジスタの使用の１つの例は、Ｘ８６  ＰＵＳＨＡＤ命令に関するレシピである（すべての汎用レジスタをスタックにプッシュする）。図の左の部分９５０は、ＩＮＴＥＬ  ＡＲＣＨＩＴＥＣＴＵＲＥ  ＳＯＦＴＷＡＲＥ  ＤＥＶＥＬＯＰＥＲ'Ｓ  ＭＡＮＵＡＬ，  ＶＯＬ．２の３〜３８８ページに示されたような命令の動作を示す。図の右側の部分は、これらの動作を実装するネイティブなタペストリレシピを示す。
【０５８３】
ＳＴＯＲＥＤＥＣ命令９５１は、タペストリＳＴＡ（自動インクリメント／デクリメントを伴うストア）の特定の変形例である（セクションＩＸ．Ａ．６のＳＴＡの論議を参照されたい）。「．Ｘ」オペコード拡張子は１６ビットまたは３２ビットのいずれかである可能性があり、第２のオペランドのサイズを示す。第１のオペランド９５２はオペコード拡張子によって解釈され、第２のオペランドおよび第３のオペランドによって示されたアドレスで、メモリにストアされる。第２のオペランドはセグメント記述子である。第３のオペランド９５３は、セグメントへのオフセットを含むレジスタである。第３のオペランドのレジスタは、オペコード拡張子のサイズによってあらかじめデクリメントされてから、第１のオペランド９５２が実際にストアされる。
【０５８４】
ネイティブレシピ９５０の第１のＭＯＶＥ命令９５４は、Ｘ８６スタックポインタＥＳＰを、表１のＲ５〜Ｒ１４のＣＴ１〜ＣＴ１０レジスタのうち１つである一時レジスタｔｍｐ＿ｄにコピーする。８つのＳＴＯＲＥＤＥＣ命令９５１は、８つの汎用レジスタＥＡＸ、ＥＣＸ、ＥＤＸ、ＥＢＸ、ＥＳＰ、ＥＢＰ、ＥＳＩ、ＥＣＩをスタック上にプッシュする。これらのプッシュの間、レジスタＥＳＰ内の実際のＸ８６スタックポインタは変更されないままであり、デクリメントはレジスタｔｍｐ＿ｄ上で実行される。最後に、レシピの最終命令９５５では、レジスタｔｍｐ＿ｄはＸ８６スタックポインタＥＳＰにコピーして戻される。
【０５８５】
セクションＩＸ．Ａ．２およびＩＸ．Ａ．４から、従来のマシンとは異なって、Ｘ８６エミュレーションの間の例外はメモリ内にスタックフレームを構築せず、必須のマシン状態はエミュレータインタフェースレジスタ９１２およびＥＰＣ９１４にさらされることを思い出されたい。エミュレータ３１６へ入ることおよびそこから出ることを含むエミュレータ３１６の実行は、エミュレーション自体を反映する状態の変化以外には、どのＸ８６のアーキテクチャで見える状態にも副次的な作用を有しない。したがって、ＰＵＳＨＡレシピの間に発生する任意の非同期的な割込みは、Ｘ８６で見える副次的な作用を発生せずに、タペストリオペレーティングシステム３１２またはエミュレータ３１６内で処理される。エミュレータ３１６内で割込みを「処理」することは、それが保留中であることを記録すること、コンバータ１３６に戻って現行のＸ８６命令を終了すること、ついで割込みを受入れそれをＸ８６に表面化することからなりたつ場合があり、割込みは命令境界でなければＸ８６には見えないことに注意されたい。
【０５８６】
命令を実行する間の同期例外は、時々、レシピの途中で知らされる場合がある。ＰＵＳＨＡの場合、命令中の同期例外が発生すると、Ｘ８６アーキテクチャは、メモリが部分的に修正されているが、スタックポインタは修正されないことを定義する。レシピ９５０の間に同期例外が発生すると、レシピ９５０はこの挙動をアーカイブし、アーキテクチャ上Ｘ８６で見えるスタックポインタレジスタは、最終的なＭＯＶ命令９５５まで変化しない。スタックポインタの中間デクリメント化を有するレジスタ、ｔｍｐ＿ｄは、Ｘ８６内では見えない。
【０５８７】
Ｘ８６で見える状態は最終のＭＯＶＥ命令９５５まで変更されないので、レシピ９５０が任意の時点で割り込まれる場合は、例外の時点から再開することが可能である。Ｘ８６環境は正しい命令境界でなければ状態を見ることができない。
【０５８８】
図９ｆは、一時レジスタを使用するレシピの代表的なカタログである。一般的な規則として、一時は、たとえば、単一のレジスタに多数の変更がある場合（図９ｅのＰＵＳＨＡ例における暗示的なスタックポインタ）、または複数のレジスタに変更がある場合など、Ｘ８６アーキテクチャの状態に複数の変更がある場合に、レシピ内で使用される。
【０５８９】
１つの例では、Ｘ８６定義は、浮動小数点動作の宛先レジスタがＩＥＥＥ−７５４非数字データ（ＩＥＥＥ−７５４  ＮａＮ'ｓ、無限大など）の所定の場合には修正されないままであることを要求する。タペストリは２つのピースでインテルの８０ビット浮動小数点レジスタを実装するので（１６ビット符号および指数、レジスタＲ３３、Ｒ３５、Ｒ３７．．．Ｒ４７（表１を参照のこと）、およびレジスタＲ３２、Ｒ３４、Ｒ３６．．．Ｒ４６内の６４ビット符号）、一部のロードおよびストアは２つの動作に分解され、ＩＥＥＥ−７５４チェックはすべてのビットが収集されるまで実行できない。浮動小数点値の２つの部分は、一対の一時レジスタにロードされる。ＩＥＥＥ−７５４チェックは一時の中で実行することが可能である。データが確認されると、浮動小数点値はＸ８６状態の一部である最終宛先レジスタ内にコピーされる。
【０５９０】
別の例では、反復される文字列命令の間の整数条件コードは一時レジスタ内に保存されて、ページ不在の間それを保護し、ページ不在から実行が再開された時にそのレジスタからロードしなおされる。
【０５９１】
どの場合でも、中間の結果は、例外に関するすべての可能性が評価されるまで、一時レジスタ内に保持される。データはすべての動作が終了できると保証されるようになった時にのみ、Ｘ８６で見えるリソースにコミットされる。このため、すでにリタイアされている若い命令から状態を記録する必要なく、レシピを任意の例外の時点から継続することを可能にする。
【０５９２】
２．異なる参照クラスに適した記憶保護検査をトリガするメモリ参照命令
図９ｇを参照すると、Ｘ８６の命令セットは、単一の命令が、たとえば「ＡＤＤメモリ、レジスタ」９６０（２つの加数はメモリの位置およびレジスタであり、合計はメモリの位置にストアして戻される）など、同じメモリ位置から読み取りまたそこへ書き込むことを可能にする。このような命令は「読取り修正書込み」命令と呼ばれる。Ｘ８６アーキテクチャの定義では、読取り修正書込みの読取りは、書込みが成功しなければ、Ｘ８６のＣＰＵをメモリシステムに発行できない。この制約は、メモリ位置がメモリがＩ／Ｏ空間内にあり、読取りがデバイスの状態を変化させる可能性があるので、読取りを１度以上発行してはならないという可能性を反映している。
【０５９３】
図９ｃ、図９ｇ、およびセクションＩＸ．Ａ．６の表８を参照すると、タペストリ命令セットは、３つの結果、すなわち、メモリチェックを実行して有効なアドレスから読取りが終了するようにするという結果、メモリ保護チェックを実行して同じアドレスへの書込みが終了するようにするという結果、および、オペランドをメモリからレジスタにロードするという結果を達成する命令を含む。このようなロードは「書込み意図の」ロードと呼ばれる。ロードチェックが失敗した場合、またはストアチェックが失敗した場合、ロードは失敗する。表８の中では、アドレス指定モード９４２で、ＬＤＡの、００１０、００１１、０１１０、１０１０、１０１１、１１００、１１０１および１１１０は、書込み意図を伴うロードであることを示していることに注意されたい。アドレス指定モード０１１１および１１１１は、実行意図を伴うロードを示す。
【０５９４】
評価されるべきメモリ保護の述部は、命令のオペコードのビットおよびアドレス指定モード９４２によって指定され、述部は、ロードまたはストアの有効なアドレスに関してＴＬＢ項目の保護ビットについて評価される。
【０５９５】
したがって、Ｘ８６読取り修正書込みＡＤＤ９６０に関するレシピ９６１内の第１の命令は、タペストリＬＤＡ命令９６２である。図９ｃに関連してセクションＩＸ．Ａ．６に論じられたように、ＬＤＡ命令９４１はアドレス指定モード９４２、セグメント、およびオフセットレジスタに関する明示的な指定子を有する。ＬＤＡ命令９６２はＴＩＧ'ｓ  ｉ０  ９０５およびｉ１  ９０６によって生成されるので、モードビット９４２は、ＬＤＡ９６２が書込み意図ロードであることを示すように設定される。レシピ９６１の中の第２の命令はＡＤＤ命令９６３であり、これは追加自体を実行する。レシピの第３の命令はＳＴＡ（Ｘ８６アドレスへのストア）９６４であり、ＬＤＡ９６２によってリファレンスされたアドレスと同じアドレスへストアする。ＳＴＡ９６４は、ＬＤＡ９６２によってすでに実行されたアドレス計算を反復し、また同じストア許可チェックを反復する。一部のチェックはすでにＬＤＡ９６２のモードビット９４２によって指定されているので、許可チェックは例外なしに成功することが保証されている。したがって、レシピ９６１では、ＬＤＡ９６２のみが例外を発生させ、ＡＤＤ９６３およびＳＴＡ９６４は終了することが保証されている。
【０５９６】
３．ターゲットリミットチェック命令
Ｘ８６のアーキテクチャの定義によって、修正／副次的な作用が同時に行われることが必要な時には、事前のチェックとテンポラリーを使用して、完全に実行されてから、設計された状態が修正される。
【０５９７】
Ｘ８６では、メモリアドレスは０と２31−１の間の数というのみならず、アドレスは形式的なものである（セグメント、オフセット）。ロード、ストア、命令フェッチでも、各メモリリファレンスはこのようなセグメントに基づいたアドレス指定を使用する。任意の時点でアクティブなセグメントは最高で８であり、命令がフェッチされる元のコードセグメント、メモリオペランドがそこからロードされ、また、その中にストアされる１から６の間のデータセグメント、およびＰＵＳＨ命令がその中にデータを書き込み、ＰＯＰ命令がそこからデータを読み取るスタックセグメントを含む。各セグメントには最大サイズを有し、セグメントの限度を超えたセグメントへのオフセットは無効である。さらに、各セグメントは許可の集合を有し、プログラムがそのセグメントから読みだすこと、そのセグメントに書き込むこと、実行することが許可されているかどうかを制御する。さらに、セグメントはメモリリファレンスのデフォルトサイズを制御するＤビットおよびＢビットを有し、「拡大アップ（expand up）」属性または「拡大ダウン（expand down）」属性を有する場合がある。各セグメントの属性はセグメント記述子の中にキャッシュされている。これはインテル社の、ＩＮＴＥＬ  ＡＲＣＨＩＴＥＣＴＵＲＥ  ＳＯＦＴＷＡＲＥ  ＤＥＶＥＬＯＰＥＲ'Ｓ  ＭＡＮＵＡＬ  ＶＯＬ．３（１９９７年）の第３章に説明されている。
したがって、各ロード、ストア、命令フェッチメモリリファレンスに関し、リファレンスのオフセットは関連するセグメントに関する限度と比較される。
【０５９８】
限度のチェックはコンテキスト依存である。次のサブセクションでは、ロード、ストア、命令フェッチおよび制御フローの移動のために実行される限度チェックの代表的な例について論じる。
【０５９９】
ａ．ＬＯＡＤ／ＳＴＯＲＥおよび分岐リミットチェック
図９ａを再び参照すると、限度チェックはハードウェア内の２つのポイントで実行される。シーケンシャルな命令フローおよび一部の制御移動命令に関しては、限度チェックはパイプラインの上部１３４で実行される。他のメモリリファレンスに関しては、限度チェックは、メモリリファレンス自体が実行されるＭ段１４６で実行される。
【０６００】
上限チェックは、Ｘ８６命令境界が特定された後、命令を復号化する間に使用可能な情報に完全に基づいて、宛先アドレスを計算することが可能である制御移動に関して実行される。このクラスは直線的なシーケンシャルフローおよびＩＰ関連のブランチを含む。限度チェックに必要な３つの情報は、現行の命令のＩＰ、現行の命令の長さ、および命令のブランチディスプレイスメントを含む。これらの３つの情報は、発行バッファ９０７の前にＴ段９０３で使用可能である。この情報が一度知られると、ブランチ宛先の３つの構成要素を合計し、コードセグメント限度と比較することが可能になる。
【０６０１】
下限チェックはＭ段１４６にある。アドレス形成のほとんどは、それ以前のレシピの中にある、異なる単一動作のＲＩＳＣ命令によって実行されている場合がある。最終的なロード、ストアまたはジャンプは、セグメント記述子からのセグメントベース、および、それ自体がイミディエイトディスプレイスメントと１つまたは２つのレジスタの合計として形成される場合のあるオフセットを合計することによって、ターゲットアドレスを形成する。アドレスはＡ段１４４のＡＬＵ内で形成され、ＡＬＵは通常の追加命令内で使用される。アドレス形成の後にＭ段１４６の中のキャッシュアクセスと並列に、オフセットはタペストリ命令によって指定されたセグメントに関するセグメント限度と比較される。
【０６０２】
Ｘ８６は限度チェック例外に関して次の挙動を定義する。ロード／ストアリファレンス内で、全リファレンスはセグメント限度内でフィットし、低いアドレスおよび高いアドレスの両方が限度チェックで役割を果たさなければならない。制御移動においては、宛先の第１のバイトだけがコードセグメント内にあればいいので、宛先アドレスの単一のバイトのみが限度に対して確認される。たとえば、ブランチターゲットの第１の命令が２バイト長であり、１バイトのみが限度内にある場合は、移動制御自体は正常に終了し、例外は移動制御自体ではなくターゲットにおいて命令フェッチを行う時に発行される。ターゲットの第１のバイトが限度内にない場合、移動制御は障害を起こし、命令はまったく実行されない。たとえば、第１のバイトが限度の外にあるターゲットへのコール命令に関しては、戻りアドレスがメモリ内に書き込まれず、スタックポインタは修正されず、例外ＩＰはターゲットではなくコール命令を指す。他方、第１のバイトは限度内にあるが第２のバイトは限度内にない場合、戻りアドレスはメモリにプッシュされ、宛先命令はページ不在またはセグメント障害となる。
【０６０３】
ロード／ストアおよび制御移動に関するＴ段の限度チェックとＭ段の限度チェックは異なっており、Ｘ８６のアーキテクチャで定義された挙動を実装する。次にいくつかの例を説明する。
【０６０４】
ｂ．ニアレジスタに関連ＣＡＬＬ（near register−relative）のターゲットリミットチェック
図９ｈを参照すると、ロード命令およびストア命令の意味のほとんどが、オペコードから推論されるのではなく、ネイティブ命令およびフォーマット化された命令の符号化の中に明示的にさらされているので、ロードは、データをメモリからロードすること（必須の限度チェックを伴う）、またロードアドレスに関して実行モードのチェックを実行することの両方であると定義することができる。このようなロード命令を使用して、Ｘ８６コール命令のレジスタ間接形態の宛先に関して限度チェックを実装することが可能である。この実装はセグメント限度障害を早く報告して、アーキテクチャで見える状態が修正されることを防ぎ、部分的に終了したＸ８６命令をバックアウトするために実行しなければならない作業の量を低減する。
【０６０５】
図９ｈの左部分９６７は、ＩＮＴＥＬ  ＡＲＣＨＩＴＥＣＴＵＲＥ  ＳＯＦＴＷＡＲＥ  ＤＥＶＥＬＯＰＥＲ'Ｓ  ＭＡＮＵＡＬ、ＶＯＬ．２の３〜４１ページに示されたＣＡＬＬ命令の動作の説明からの抜粋で、ターゲットアドレスが形成された後の時点から開始する例を示している。ＣＡＬＬ命令はまず、ブランチターゲットがコードセグメント限度内にあるかどうかについて９６８をチェックし、限度内にない場合、一般保護違反を知らせる。ＣＡＬＬ命令はついで、メモリスタックが戻りアドレスを受け入れる余地を有するかどうかについて９６９をチェックする。スタックチェックは限度チェックでもあるが、失敗は一般保護違反ではなくスタック違反によって示される。両方のチェックが成功したときのみ、コードセグメント（ＥＩＰ）への現行のオフセットはスタック上にプッシュされ、ついで制御は宛先に移動される。
【０６０６】
図９ｈの右側９７０は、コンバータのレシピの対応する部分を示す。Ｘ８６のＣＡＬＬがレジスタアドレスへ向けられているため、あるいは、レシピ９７０の以前のアドレス形成の抜粋がターゲットオフセットを一時レジスタｒｅｇ＿ｄ内に形成しているかのどちらかの理由によって、抜粋９７０はターゲットアドレスがすでにレジスタｒｅｇ＿ｄ内にあると仮定する。
【０６０７】
命令９７１
LOAD. Limit＿check rO, CS：reg＿d
は、左側の第１の限度チェック９６８を実行し、ターゲットアドレスをコードセグメント限度と比較する。ロード９７１の宛先はＲ０、すなわち常にゼロであるレジスタであるので、保護チェックのみが実行され、実際のメモリロードはまったく省略され、これによって偽のインターロックを防ぐ。「．ｌｉｍｉｔ＿ｃｈｅｃｋ」は、上記のセクションＩＸ．Ｂ．２で論じられているように、ＬＤＡ命令のアドレス指定モードビット９４２によって指定されたように、データロードチェックおよび命令フェッチ保護チェック（または別の実施形態では、データロードチェックの代わりに命令フェッチチェック）の両方に関してメモリ管理ハードウェアを問い合わせるべきであることを指定する。チェックするアドレスはコードセグメント内のｒｅｇ＿ｄ内のオフセットにある。ＬＯＡＤ．ｌｉｍｉｔ＿ｃｈｅｃｋ９７１が失敗した場合，レシピ９７０の残りは抑制され、ＳＴＯＲＥＤＥＣ９７２はＣＡＬＬ戻りアドレスをストアしない。第２の命令９７２、ＳＴＯＲＥＤＥＣは、スタックポインタＥＳＰによって指定されたオフセットにおいて、ＩＰ値をスタックセグメント（ＳＳ）上にプッシュする、プレデクリメント（pre−decrement）のストアである。ＳＴＯＲＥＤＥＣ９７２のメモリ書込みが開始すると、両方のセグメントチェックが続くことが知られており（コードセグメント限度に対するブランチ宛先のチェック９６８および、スタックセグメントのチェック９６９）、ブランチ宛先はＬＯＡＤ．ｌｉｍｉｔ＿ｃｈｅｃｋ命令９７１によってテストされ、スタックセグメントはＳＴＯＲＥＤＥＣ９７２自体によってテストされる。したがって、ＳＴＯＲＥＤＥＣ９７２の終了時に、３つの副次的な作用のすべてが続き（メモリ書込み、スタックポインタへの変更、およびＩＰへの変更）、ＣＡＬＬ戻りアドレスをストアする、アーキテクチャで見える副次的な作用がメモリにコミットされることが可能になる。ＪＲ命令９７３はｒｅｇ＿ｄによって指定されたアドレスにジャンプする。一般的な場合では、ＪＲの宛先レジスタは直前の命令によって計算されているので、ジャンプ宛先レジスタの内容（この場合はｒｅｇ＿ｄ）は、Ｔ段９０３の限度チェックハードウェアの中では限度チェックできない。したがって、ＪＲ命令は、Ｍ段１４６の中でセグメント限度チェックを実行するジャンプ命令のうちの１つである。しかし、レシピ９７０がこの宛先についてＬＯＡＤ．ｌｉｍｉｔ＿ｃｈｅｃｋ９７１をすでに実行しているので、ＪＲ９７３は成功が保証されている。
４．コアトミック実行を保証するための命令の特殊グループ化
【０６０８】
Ｘ８６のＩＰに関連する近接のＣＡＬＬ９７６（IP−relative near CALL)は、図９ｉの左側に説明されている。コールターゲットオフセットは、命令の位置自体、命令長および命令内のディスプレイスメントイミディエイトの合計として計算される。続く命令のアドレスはスタック上にプッシュされ、制御はコールターゲットに移動される。タペストリ実装は、命令の両方の部分を終了させるか、両方とも終了させない。
【０６０９】
１実施形態では、Ｘ８６のＩＰに関連する近接のＣＡＬＬ９７６は、上記のセクションＩＸ．Ｂ．３．ｂで説明されたレシピ９７０と同様に処理される。ＬＯＡＤ．ｌｉｍｉｔ＿ｃｈｅｃｋ命令（命令９７１と類似）は、コールターゲットを限度チェックし、現行のＩＰが命令の長さおよびディスプレイスメントに追加され、合計はコードセグメント限度と比較される。ＬＯＡＤ．ｌｉｍｉｔ＿ｃｈｅｃｋが失敗するとレシピの残りが打ちきられる。ついで（成功すると）、ＳＴＯＲＥＤＥＣ命令（９７２への命令と類似）は、戻りアドレスをプッシュする。ジャンプ命令はターゲットにジャンプする。
【０６１０】
図９ｉを参照すると、別の実施形態では、Ｘ８６のＩＰに関連する近接のＣＡＬＬ９７６は、ＳＴＯＲＥＤＥＣ（ＩＰ値のプレデクリメントＳＴＯＲＥ）９７７およびジャンプ命令９７８を含む。ハードウェアはこれらの２つの異なる命令９７７、９７８を監視して、これらが一緒に終了するようにする。コールターゲットオフセットを計算するために必要な情報のすべては（命令位置自体、命令長、命令の中のディスプレイスメントイミディエイト）、パイプラインの上部１３４内で使用可能なので、Ｔ段９０３の限度チェック回路内でターゲット限度チェックを行うことが可能である。命令が復号化されると、ターゲットアドレスを形成するために必要なすべての情報が使用可能になるので、限度チェックはストールなしで、命令の生成と共に実行することが可能である。ブランチターゲットハードウェアはパイプラインの上部１３４に提供されるので、ほとんどのＩＰ関連のブランチはパイプラインの初期でブランチターゲットを計算しこれらの限度チェックを行うことが可能であり、この回路はＩＰに関連するＣＡＬＬ９７６内ですぐに使用可能であり、コールターゲットを計算し、そのコールターゲットをコードセグメント限度と比較する。これは、ＩＰに関連する近接のＣＡＬＬ９７６が、セクションＩＸ．Ｂ．３．ｂで論じられたレジスタ宛先ＣＡＬＬに関して生成された３つの命令ではなく、２つのタペストリ命令９７７、９７８の中で符号化されることを可能にする。ＳＴＯＲＥＤＥＣ９７７およびジャンプ９７８は、コールターゲット限度チェックが終了するまで、発行機構内に保持される。コールターゲット限度チェックが失敗すると、ＳＴＯＲＥＤＥＣ９７７およびジャンプ９７８は両方ともヌル化され、メモリへの修正を防ぐ。ＣＡＬＬターゲット限度チェックが成功すると、両方の命令がリリースされる。ＳＴＯＲＥＤＥＣ９７７が失敗すると、Ｘ８６命令の全部が打ちきられる。ＳＴＯＲＥＤＥＣ９７７が一度終了すると、Ｔ段９０３内で限度チェックが実行されるため、ジャンプ９７８は成功することが保証される。
【０６１１】
機能は次のように実装される。
上部段１３４は、ジャンプ９７８のターゲットのセグメント限度がチェックされてからＳＴＯＲＥＤＥＣ９７７が発行されることを保証する。ＳＴＯＲＥＤＥＣ９７７がＣ段９０２を消去した後、Ｃ段９０２はジャンプ９７８のディスプレイスメントを使用してターゲットアドレスを計算する。Ｔ段９０３はターゲットに関して限度チェックを実行する。限度チェックの成功または失敗は、上部のパイプライン１３４の直前にあるＳＴＯＲＥＤＥＣ９７７にタグとして付けられる。このタグは、ＳＴＯＲＥＤＥＣ９７７がＤ段１４０および低いパイプライン１２０に移動すると、ＳＴＯＲＥＤＥＣ９７７と共に移動する。ジャンプターゲット限度チェックが失敗すると、ＳＴＯＲＥＤＥＣ９７７は障害とマーキングされてから、実行パイプライン１２０に発行される。
【０６１２】
別の実施形態では、命令が復号化されると、ＩＰに関連する近接のコールは特別なケースとして捕らえられる。ＴＩＧ９０５、９０６は、特別なマーカでＳＴＯＲＥＤＥＣ９７７をマーキングする。そのマーカを伴う命令は、ターゲットの形成および限度チェックがジャンプ９７８に関して終了するまで、上部１３４から実行パイプ１２０に移動することを許可されない（または別の実施形態では、発行バッファ９０７内に保持される）。パイプラインは、このチェックが早く実行され、ＳＴＯＲＥＤＥＣ９７７が通常はバブルなしに発行バッファ９０７からリリースされるように構成される。マーカは、上段１３４でのみ使用されるという点を除いては、低いパイプライン１２０を介して伝播するサイドバンド情報９２０にいくらか似ている。
【０６１３】
ＩＰに関連するＣＡＬＬ命令またはレジスタＣＡＬＬ命令９６７、９７６の別の実施形態では、Ｔ段９０３またはＭ段１４６は、ジャンプ命令９７３、９７８のターゲットについて限度エラーをチェックする。限度エラーがある場合、限度例外はＳＴＯＲＥＤＥＣ９７２、９７７上にタグとして付けられる。ＳＴＯＲＥＤＥＣ９７２、９７７についての例外は、次にＷ段１５０内で認識され、ＳＴＯＲＥＤＥＣ９７２、９７７は決してメモリにコミットしない。ＳＴＯＲＥＤＥＣ９７２、７７の中断は、ジャンプ９７３、９７８を打ちきる。ジャンプ９７３、９７８の限度チェックは終了して使用可能となり、パイプライン１２０を先に進み、例外をＳＴＯＲＥＤＥＣ９７２、９７７にタグを付けてから、ＳＴＯＲＥＤＥＣ９７２、９７７がＷ段１５０にコミットすることに間に合う。その理由は、２つの段は十分に離れているからという場合もあり、ＳＴＯＲＥＤＥＣ９７２、９７７は限度チェックが成功するまでコミットを遅延されるからという場合もある（命令の独立したリタイアメントという、一般的な設計目標に対する例外として）。
【０６１４】
５．ＬＯＯＰ命令のエミュレータにおける展開
図９ｊを参照すると、Ｘ８６アーキテクチャは複雑なＬＯＯＰ命令を定義する。図９ｊの左半分９８０は、より簡単な変形例のうち１つに関する動作を示す。ループに入る前に、プログラムはＥＣＸレジスタの中でループカウントを確立する。ＬＯＯＰ命令はループ本体の終了時に使用される。ＬＯＯＰ命令はループの反復ごとにＥＣＸレジスタをデクリメントする。ＥＣＸレジスタがゼロでない限り、ＬＯＯＰ命令は制御をループの一番上の命令に戻し、ループの次の反復を開始する。
【０６１５】
ＬＯＯＰ命令のこの変形例に関して、ネイティブタペストリレシピ９８１は、ＤＥＣ９８２の結果に基づいて、ＤＥＣデクリメント命令９８２およびＣＪＮＥ９８３（ゼロでない場合、条件付きのジャンプ）という２つの命令を生成する。ＤＥＣ命令９８２は、「．Ｘ」オペコード拡張子によって示される８ビット、１６ビット、または３２ビット広さのオペランドを有する場合がある。ＣＪＮＥ命令９８３は、ＥＣＸレジスタをｒ０（常にゼロであるレジスタ、表１を参照のこと）と比較し、これらが等しくない場合は分岐する。ＬＯＯＰ９８０またはＣＪＮＥ命令９８３への「ｉｍｍ８」引数はディスプレイスメントであり、Ｘ８６ＬＯＯＰ命令の中の８ビット、１６ビットまたは３２ビットであり、コンバータ１３６によってエミットされた、フォーマット化されたＣＪＮＥネイティブ命令９８３の中でも同様な広さである場合がある。
【０６１６】
他の任意の制御移動ターゲット同様、ＬＯＯＰ命令９８０のターゲットは、コードセグメント限度に対して限度チェックしなければならない。Ｘ８６内で限度チェックが実行されてから、ＥＣＸへの修正、ついで分岐が発生する。限度チェックが失敗すると、修正ＥＣＸはコミットされない。しかしレシピ９８１内でＤＥＣ命令９８２はブランチ９８３の前にあり、ＬＯＯＰ命令の頻度のため、限度チェックを行うためにだけに第３の命令を追加するのではなく、レシピ９８１を２つの命令に保持することが望ましい。
【０６１７】
１つの実施形態では、ＣＪＮＥ命令９８３は、限度チェックの失敗でマーキングされ、またＬＯＯＰレシピ内で命令としてサイドバンドマーキングされている。ＣＪＮＥ９８３がＷ段１５０に到達すると、ハードウェアはセグメント限度エラーを認識し、ＬＯＯＰサイドバンド情報をメモリ障害コードにストアする。セグメント限度エラーハンドラーは、メモリ障害コードを確認する。Ｘ８６  ＬＯＯＰビット（「メモリ障害コード」プロセッサレジスタのビット２５）が設定され、ついでＥＣＸ（またはＣＸ）が１ステップ、アンワインドされる。
別の実施形態では、Ｘ８６  ＬＯＯＰ命令は後の命令（ＣＪＮＥ９８３）がそれ以前の命令（ＤＥＣ９８２）の実行に影響を与えることが可能な、わずかなインスタンスのうち１つである。ＣＪＮＥ命令９８３は、Ｔ段９０３内で限度チェックされる。この限度チェックの結果は「Ｘ８６  ＬＯＯＰ．」と名付けられた１ビットのタグとして、サイドバンド情報９２０の中のＣＪＮＥ命令の上にタグを付けられる。Ｘ８６  ＬＯＯＰタグは，ＣＪＮＥ命令９８３に関する他のサイドバンド情報と共にパイプの段を下へ下りる。Ｗ段１５０が、限度チェックが失敗したことを示すＸ８６  ＬＯＯＰタグを伴う命令を検出すると、プロセッサはエミュレータ３１６内にトラップし、エミュレータ３１６はレジスタＥＣＸ（またはワード広さに関してはレジスタＣＸ）を１つインクリメントして、最後のＤＥＣ９８２によってデクリメントをアンワインドする。
【０６１８】
６．反復ストリングの命令
図９ｋを参照すると、Ｘ８６アーキテクチャはＲＥＰプレフィックスバイトを、たとえば「ＲＥＰＥ  ＣＭＰＳ」（比較文字列）、「ＲＥＰ  ＭＯＶＳ」（移動文字列）、および「ＲＥＰ  ＳＣＡ」（スキャン文字列）などの「ＲＥＰ」反復命令のセットを導出する所定の命令に定義する。これらの反復された文字列の命令の各々において、Ｘ８６は多くの反復に関して動作を反復する。反復のカウントはレジスタＥＣＸ（３２ビットモード）またはＣＸ（１６ビットモード）内で指定される。図９ｋに示された例９８６「ＲＥＰＮＺ  ＭＯＶＳ」では、Ｘ８６はレジスタＥＣＸをカウントレジスタとして使用し、バイトをソースメモリのオペランドから宛先メモリのオペランドへ移動する。繰り返しごとに、Ｘ８６は保留中の割り込みがある場合にはそれを受入れ、ついでＥＣＸをデクリメントして関連するＭＯＶＳ命令を実行する。反復命令自体はブランチ命令ではなく、終了条件が満たされてから次のシーケンシャル命令に失敗するまでその命令の実行を繰り返すようにＸ８６に命令する、別の命令に付けられた１バイトの接頭辞である。
【０６１９】
Ｔ段９０３はＲＥＰ命令を、直線命令９８７の無限にアンロールされたループにする。レシピの最初の近く（図９ｋに示された抜粋の前）は、ＥＣＸ内の反復カウントがゼロである場合、次のＸ８６命令にブランチするブランチ命令である。ついでループの第１の反復９８８に関してネイティブ命令が続く。ＲＥＰＮＺ
ＭＯＶＳの場合、ループの本体は、とられていないと予想されたロード、ストア、およびＪＮＺ命令である。この部分９８８は、反復されているＸ８６命令を反映するように変化する。
【０６２０】
各反復９８８の終わりに、Ｔ段９０３はとられていないと予想されたジャンプ命令９８９を次のＸ８６命令にエミットする。これらの反復間のブランチ命令９８９は、各々、「割り込み可能な反復境界」サイドバンドマーカによってマーキングされている（図９ｃの９９０）。Ｘ８６の挙動と並列に、反復間のブランチ命令９８９はＥＣＸのカウントダウンを反映する一時フラグをテストする。これらの一時フラグはＸ８６  ＥＦＬＡＧＳに相似しているが、Ｘ８６  ＥＦＬＡＧＳとは異なるので、ＥＦＬＡＧＳ自体は修正されない。
【０６２１】
ＥＣＸカウントが終了していない場合、反復間のブランチ９８９がＲ段１４２およびＡ段１４４に到達すると（ブランチが実際に実行される段）、予想どおりにブランチ９８９はとられない。反復された文字列命令に関するレシピはネスト反復本体９９１で継続する。反復カウントが終了すると、ブランチ条件が満たされ、ブランチの間違った予想回路が起動され、パイプライン１２０をフラッシュする。上部１３４は、反復された命令の反復の生成を中止する。実行は次のＸ８６命令で再開する。各命令間のブランチ９８９はレシピの終わりマーカＸ８６＿ＣＯＭＰＬＥＴＥＤ９２６でマーキングされ、命令が最終的に終了すると、正しい状態のすべてが更新され、たとえば、ＩＰがインクリメントされる。しかし、同じブランチ命令９８９上に代入されている反復境界マーカ９９０はハードウェアに対して、レシピの終了マーク９２６が条件付きであると知らせ、レシピの終了処理は、反復カウントが終了しなければ実行すべきでないと知らせる。
【０６２２】
Ｘ８６単一ステップモードでは、反復される命令の各反復はＸ８６単一ステップ例外をトリガする。Ｘ８６単一ステップおよびタペストリネイティブ単一ステップモードの両方が使用可能な場合、２つの間の反復はエミュレータ３１６内で解消される。
【０６２３】
Ｃ．単一Ｘ８６命令の複数の副作用をエミュレートするために複数のネイティブ命令の結果の収集
１．ロード／記憶アドレスデバッグ比較結果の収集とフィルタリング
Ｘ８６アーキテクチャはデバッグ機能を定義する。４つのデバッグレジスタがあり、各々は線形アドレスを保持する。各レジスタは読取り、書込み、または実行という、メモリリファレンスのクラスでタグを付けられる。各メモリリファレンスに関して、リファレンスのアドレスは４つのデバッグレジスタのアドレスおよびモードに対して比較される。マッチおよびモードが検出され、リファレンスがレジスタのクラスタグに一致すると、トラップがＸ８６命令の終了時に発生し、リファレンスのアドレスはデバッガソフトウェアが使用できるようになる。Ｘ８６命令が多数のメモリリファレンスを有する場合があるので、単一のＸ８６命令内にいくつかの一致があることが可能である。
【０６２４】
タペストリは、各々が監視されるべきアドレスを保持する同様なデバッグレジスタを提供する。タペストリのデバッグレジスタは、メモリリファレンスクラスに対して一致しない。次に論じられるように、クラス機能はソフトウェア内でエミュレートされ、監視するクラスはメモリ内に記録される。ハードウェアアドレス一致の細分性はかなり粗く、１６バイトに近い。アドレスがデバッグレジスタのうち１つの１６バイトウィンドウ内にあるようなメモリリファレンスが検出されると、プロセッサはエミュレータ３１６内にトラップする。エミュレータ３１６はエミュレータ３１６インタフェースプロセッサレジスタから情報をさらに収集して、アドレスがＸ８６アーキテクチャの定義によって必要とされる細分性に一致していたかどうかを決定する（オペランドの幅に応じて、もっとも近い１バイト、２バイトまたは４バイト）。エミュレータ３１６はまた、一致リファレンスがロードまたはストアのいずれであったかを決定し、この決定を、このレジスタ内のアドレスに関して監視されるべきメモリリファレンスのクラスと比較する。細分性およびメモリリファレンスクラスのフィルタリングを受けてもアドレス一致が残ると、エミュレータ３１６はどのデバッグレジスタが一致したかを記録し、Ｘ８６単一ステップモードをオンにする（Ｘ８６アーキテクチャは、実行が各命令の終了時にトラップされた単一ステップモードを定義するので、デバッガは起動できる。これはタペストリの中で、Ｘ８６＿ＣＯＭＰＬＥＴＥＤレシピの終わりタグ９２６を伴う各命令が単一ステップモードで実行されたときに発生するトラップとして実装される）。Ｘ８６命令の終了時に、単一ステップトラップはコンバータ１３６によって発生し、制御はエミュレータ３１６内にベクトルを向ける。単一の命令内で発生した１つまたは多数のデバッグレジスタが一致すると、エミュレータ３１６はこれらを集めて、適切であればＸ８６環境に表面化する。エミュレータ３１６の終了時に、単一ステッピングはオフにされる（単一の命令に関してエミュレータ３１６によってではなく、単一ステッピングがすべてのＸ８６命令に関してオンにされない限りである）。
このように、ロードおよびストアデバッグアドレスは個別のタペストリ命令に基づいて収集され、Ｘ８６命令の終了ごとにＸ８６上に表面化される。
【０６２５】
２．ＦＰ  ＤＰ／ＩＰ／ＯＰの延期
再び図９ａを参照すると、ＦＰ  ＤＰ／ＩＰ／ＯＰ回路９９３は浮動小数点データポインタ、命令ポインタおよびオペコード情報を、パイプラインの下の段に下げる。
Ｘ８６浮動小数点ユニット（ＦＰＵ）は、命令へのポインタおよび、最後の非制御浮動小数点（ＦＰ）命令（「制御命令」は、Ｉｎｔｅｌ  Ｘ８６アーキテクチャ内で定義された用語である）に関するデータオペランドを、２つの４８ビットレジスタであるＦＰＵ命令ポインタ（ＦＰ−ＩＰ）レジスタおよびＦＰＵオペランド（データ）ポインタ（ＦＰ−ＤＰ）レジスタ内にストアする。（ＦＰ−ＤＰ情報は単一のメモリオペランド命令に関してのみ更新され、メモリからメモリへの動作は非制御命令であるので、ＤＰポインタは多数ある必要はない）。Ｘ８６  ＦＰＵはまた、１１ビットのＦＰＵオペコードレジスタ（ＦＰ−ＯＰ）内に最後の非制御命令のオペコードをストアする。この情報は保存されて、例外ハンドラに関する状態情報を提供する。命令ポインタおよびデータポインタ、およびオペコード情報は、情報をメモリ内に現行のＸ８６モードに依存したフォーマットでストアするＸ８６の命令ＦＮＳＴＥＮＶおよび／またはＦＮＳＡＶＥを実行することによってアクセスされる。
【０６２６】
タペストリは、Ｘ８６のこの態様をモデリングする。レシピの実行中、情報はＸ８６フォーマットとはいくらか異なる内部フォーマットで保持される。情報はレシピ内で２つ以上の異なる命令によって生成される。コンバータがレシピの最後９２６に到達すると、情報はタペストリの内部フォーマットからＸ８６で定義されたフォーマットに変換され、ＦＰ−ＩＰ／ＯＰ、および、可能性としてはＦＰ−ＤＰを含む、アーキテクチャで見える副次的な作用がＸ８６  ＦＰ命令から同時にコミットされる。
【０６２７】
ＦＮＳＴＥＮＶ命令およびＦＮＳＡＶＥ命令は、ハードウェアコンバータ１３６ではなくエミュレータ３１６内で実行される。エミュレータ３１６は、ＦＮＳＴＥＮＶおよびＦＮＳＡＶＥが実行された時、タペストリハードウェア（１６ビットのセグメントセレクタおよび３２ビットのオフセット）によってストアされたポインタのカノニカルな形態を、現行のオペレーティングモードによって要求される特定のフォーマットに変換する。ＦＰ−ＩＰ、ＦＰ−ＯＰ、およびＦＰ−ＤＰ情報のＸ８６定義はいくらかコンテキストに依存するので、タペストリ変換はコンテキスト依存である。この同時性とコンテキスト依存の変換は、Ｘ８６の挙動を正しくモデリングするという結果を生む。
【０６２８】
Ｔ段９０３で、Ｘ８６浮動小数点命令がネイティブ命令に変換されると、ＦＰサイドバンド情報が生成され、パイプラインの段を下がる。このＦＰサイドバンド情報は、これが浮動小数点命令であることを示し、ＩＰ値（ＦＰ−ＩＰ）およびオペコード値（ＦＰ−ＯＰ）のスナップショットを含む。ＦＰ−ＩＰオペコード値およびＦＰ−ＯＰオペコード値はコンバータからパイプ制御９１０に渡され、パイプ制御９１０は情報をＤ段からＷ段１５０へ段を変える。データポインタＦＰ−ＤＰ、メモリリファレンスアドレスはＡ段１４４内で作成される。ＦＰ−ＩＰ情報、ＦＰ−ＯＰ情報、ＦＰ−ＯＰ情報、および例外情報はパイプ制御９１０を介してＷ段１５０内のＦＰ−ＩＰ／ＯＰ／ＤＰ論理９９３へ段を下りる。このサイドバンド情報は、図９ｃに示されたようにフォーマット化された命令に関して、モードから独立したカノニカルなフォーマットでパイプライン１２０の段を下りる。
【０６２９】
ＦＰ  ＩＰ／ＯＰ／ＤＰ論理９９３は、単一のＸ８６命令に関してネイティブな命令に渡って情報を累積する「スティッキ」レジスタ９９４を含む。たとえば、計算のメモリリファレンスがレシピ内の第１の命令内にあり、算術動作がレシピの最後のネイティブタペストリ命令であった場合、最終的にＦＰ−ＤＰ内に保存されるメモリリファレンス情報は、メモリリファレンスタペストリ命令でパイプライン制御論理を下へ流れる。レシピのすべての命令からのサイドバンド情報は、ＦＰ  ＩＰ／ＯＰ／ＤＰスティッキレジスタ９９４内に累積される。
【０６３０】
レシピの終わりマーカ９２６を伴う命令がＷ段１５０に到達すると、ＦＰ  ＩＰ／ＯＰ／ＤＰ論理９９３はレシピのすべてのネイティブ命令に渡って累積された例外状態を確認することによって反応する。スティッキレジスタ９９４からのデータはＸ８６で構築されたＦＰ−ＩＰレジスタ、ＦＰ−ＯＰレジスタおよびＦＰ−ＤＰレジスタに書き込まれる。スティッキレジスタ９９４はついで消去される。例外が発生しない場合、データの結果は適切な結果レジスタ（複数可）に書き込まれる（レジスタＲ３２〜Ｒ４７のうち１つまたは２つのレジスタ。表１を参照のこと）。
【０６３１】
シーケンスが正常に終了し、新しいＦＰ−ＩＰ／ＯＰ／ＤＰ状態にコミットすることが必要な場合、シーケンス内でネイティブ例外を処理する間に、妨害されないままで残されるＦＰ−ＩＰ／ＯＰ／ＤＰに関するシャドウ状態がある。Ｘ８６の処理は、常に命令境界において仮想化されているので、これは実際には困難ではない。ＦＰ−ＩＰ／ＯＰ／ＤＰはコンバータがオフである限りは保存される。シャドウレジスタ９９４はアーキテクチャ上アドレス指定不可能である。
【０６３２】
３．次の命令へのＳＴＩＳ（命令ストリーム内への記憶）フラッシュ境界
Ｘ８６は、「命令ストリームへのストア」（ＳＴＩＳ）としても知られる「自己修正コード」を可能にし、この場合、命令は後に実行されるメモリ内の場所へ値をストアする。特に、Ｘ８６は命令（命令ｉと呼ばれる）がメモリ内の直後の命令（命令ｉ＋１と呼ばれる）を修正することを可能にする。Ｘ８６アーキテクチャは、命令ｉ＋１に関するメモリ位置の古い内容がすでに、パイプライン１２０のほとんどの道を流れてしまった場合でも、命令ｉ＋１のメモリコピーのフェッチおよび実行が、命令ｉによって誘導された修正を反映することを要求する。命令ｉは簡単なストア命令である場合もあり、複雑な命令である場合もある。複雑な命令ｉは、修正自体が発生した後、さらに作業を実行する可能性がある。したがって、メモリへのストアごとに、パイプラインはＳＴＩＳ状態かどうかが確認される。確認は現行の命令の最後からパイプラインの上まで戻って広がり、続いて命令キャッシュへ戻り、メモリへの書込みがメモリシステム全体に十分に伝播するのに十分なほど広がっている。ＳＴＩＳ状態が検出されると、パイプラインおよび命令キャッシュの該当部分はフラッシュされる。
【０６３３】
次に図９ａを参照すると、Ｅ段１４８の中にＳＴＩＳ検出装置９９５がある。ＳＴＩＳ検出装置９９５は入力として、任意のストア動作のメモリアドレスを受け取る。ＳＴＩＳ検出装置９９５はストアアドレスを、パイプライン１２０、１３２内のＰＣ値９２５の、すべての若い命令に関してパイプライン１２０、１３４内のすべてのＰＣ値９２５と比較する、すなわち、Ｅ段１４８の若い命令と、Ｍ段１４６、Ａ段１４４のすべての命令と比較してから、フェッチ段１１０に戻る。ＳＴＩＳ状態が検出されると、現行のＸ８６命令は終了することが許可される。現行の命令が一度終了すると、パイプライン１２０は、次の命令からフラッシュされて、パイプラインの最初にあるフェッチ段１１０に戻る。別の実施形態では、フラッシュは一致する命令を戻すところからのみ発生し、ストアを生成する命令と修正した命令の間に介入する命令がある場合は、これらの介入する命令は終了することを許可される。ＳＴＩＳ検出およびパイプラインのフラッシュは、Ｘ８６命令に基づいて実行されることに注意されたい。
【０６３４】
データストアは従来の方法でデータキャッシュに影響を与え、また命令キャッシュを無効にする場合もある。命令フェッチが再開すると、命令キャッシュは見失われ、命令フェッチはメインメモリの最初まで戻る。
【０６３５】
Ｄ．  マイクロ命令セットとして外部にさらされたＲＩＳＣ  ＩＳＡ−第２の命令セットの変換を実装し、ユーザがアクセス可能な第１の命令セットで実装する１．外部マイクロコード
一部の機能はＸ８６コードの変換を介してでなければ使用できず、ネイティブなアセンブリ言語プログラマには使用できないことに注意されたい。
【０６３６】
サイドバンド９２０のほとんどは、Ｘ８６モードでなければ意味がない。たとえば、Ｘ８６命令境界情報の概念はネイティブな実行モードでは意味がない。
ネイティブ命令のイミディエイトフィールドは、６ビット広さまたは１２ビット広さのいずれかである。３２ビットイミディエイトおよびブランチディスプレイスメントは、Ｘ８６コンバータを介してでなければ使用できない。
【０６３７】
Ｘ８６では、メモリアドレスはセグメントベース、イミディエイトとして符号化された最高で３２ビットまでのオフセット、ベースレジスタ、インデックスレジスタ（２、４、または８でスケーリングされている場合がある）という４つの成分からなりたつ場合がある。ネイティブなタペストリ命令は３つの成分を指定することが可能であり、その３つとはセグメントベース、プラス、２つのレジスタ、またはセグメントベース、プラス、レジスタ、プラス、６ビットのイミディエイトのいずれかである。コンバータはＸ８６モードの間に４つの成分のアドレスを生成することが可能である。
【０６３８】
２．その他の特徴
タペストリのネイティブ命令セットには、アセンブリ言語プログラマにさらされた時に、主にＸ８６マイクロエンジンをサポートするために存在する多くの機能がある。
再び図９ｃを参照すると、ネイティブなタペストリＬＤＡ命令およびＳＴＡ命令は、Ｘ８６セグメント化のスーパーセットであるセグメント化機能を提供する。タペストリのページング挙動は、Ｘ８６によって提供されるページング機能のスーパーセットである。したがって、これらのネイティブなタペストリメモリリファレンス命令は、Ｘ８６メモリリファレンスの個別のピースすべてを実行する。
【０６３９】
ＬＤＡ命令およびＳＴＡ命令はプロキシ機構を提供する。リファレンスはＸ８６命令の意味に従う場合もあれば、それほど限定的でないネイティブな意味に従う場合もある。この機能はセグメント記述子内でタペストリ拡張ビットによって制御される。
【０６４０】
タペストリは、Ｘ８６  ＥＦＬＡＧＳの挙動を映す整数フラグおよび浮動小数点フラグ（条件コード）を含む。
一部の算術命令は、整数フラグが修正されたかされないかを決定するビットを有する。したがって、多数命令のレシピ内では、Ｘ８６フラグが基づいている、個別の結果を計算する１つの命令は整数フラグを設定し、レシピ内の他の命令はフラグを修正しないまま残しておく。
【０６４１】
タペストリは、ＲＩＳＣアーキテクチャの中では一般には発見されないいくつかの命令を提供して、同等なＸ８６命令の効率的な実装を提供する。これらは、バイトスワップ命令、所定のシフト命令および回転命令などを含む。
【０６４２】
Ｅ．再開可能な複合命令
１．ネイティブなシングルステップによるトミックＭＯＶ／ＰＯＰスタックセグメントペア
Ｘ８６では、すべてのメモリリファレンスはセグメント記述子およびセグメントへのオフセットから離れたところに基づいている。セグメントは１６ビットの記述子によって定義され、オフセットは１６ビットまたは３２ビットのいずれかである。したがって、Ｘ８６プログラムがスタックを変更すると、スタックセグメント記述子（ＳＳ）およびオフセットの両方を変更しなければならない場合がある。ＳＳを修正する命令とスタックオフセットをスタックポインタレジスタにロードする命令の間の境界で割込みが発生すると、スタックの一番上を共に定義するマシン状態の２つの部分が不一致になるため、例外フレームはメモリスタックの上にプッシュされない。このような境界において割込みがスタックを崩壊させるのを防ぐために、Ｘ８６アーキテクチャは、ＳＳへの移動またはポップと、それに続く命令の間の境界では例外が禁じられるように定義する。
【０６４３】
タペストリ実装内では、ＳＳへの移動またはポップは、エミュレータ３１６内で実行される。エミュレータ３１６はメモリ内に（ａ）ＳＳが修正されたため、単一ステップモードに入ったという事実、（ｂ）移動またはポップ命令の前に有効であった割り込みフラグ、および（ｃ）Ｘ８６単一ステッピングの現行の状態を記録する。エミュレータ３１６はついで、新しい値をＳＳ内に書き込む。移動命令またはポップ命令をエミュレートした後、Ｘ８６アーキテクチャの定義によって指定された通りにハードウェアの割込みは不可能になり、プロセッサは単一ステップモードになる。そうでなければ２つの命令の間で知らせられたであろうＸ８６の単一ステップの例外は抑制され、続く命令の命令区切り点も抑制される。したがって、ＳＳの修正とそれに続く命令の間の境界では、割り込みまたは例外が発生することは不可能である。ＲＦＥ命令は実行をコンバータに戻す。コンバータは、通常は、スタックポインタレジスタを設定する命令である次の命令を実行する。次の命令の終了時に、単一ステップ例外は制御をエミュレータ３１６にベクトルを向ける。単一ステップハンドラは、ＳＳが修正されたために例外が生じたことを観察し、これに応じてハードウェアの割込みと、単一ステップモードの前の状態を復元する。実行は、ＳＳへ初めて修正が行われる前に優勢であった実行モードでコンバータ内で再開される。
【０６４４】
２．ネイティブなシングルステップによるＩＦビット変更の禁止
Ｘ８６アーキテクチャは割込みフラグを定義する。マスキング可能な割り込みが代入された時、マスキング可能な割込みは命令の間に介入することが許可され、非同期的な例外を生成する。割込みフラグが代入を外されると、マスキング可能なハードウェア割込みは無視される。Ｘ８６  ＳＴＩ命令は割込みフラグを設定し、ＣＬＩ命令は割込みフラグを消去して割込みを抑制する。割込みフラグはＥＦＬＡＧＳビットの１つなので、ＥＦＬＡＧＳレジスタへのＰＯＰも割り込みフラグを変更する。
【０６４５】
Ｘ８６アーキテクチャは、直後に続く命令境界内で使用不能にされた割込みを維持し、そのまた次の命令の実行の終了後に割込みを可能にするものとして、ＳＴＩ命令を定義する。この定義は、典型的にはルーチンの終了時に使用される。ルーチンはＳＴＩ命令で終了し、ついでＲＥＴ命令で終了するので、戻り命令の終了まで割込みは不可能なままである。実行がコーリングコンテキスト内で再開した後でなければ、割込みを再開することは不可能である。
【０６４６】
タペストリ実装では、ＳＴＩ命令およびＣＬＩ命令はエミュレータ３１６内で実行される。ＳＴＩに関するエミュレーションルーチンの終了時に、ハードウェアの割込みは不可能になり、Ｘ８６単一ステップモードの現行の状態が保存され、Ｘ８６単一ステップモードが作動状態になり、記録はエミュレータのプライベートメモリ内に設定されて、次のＸ８６の単一ステップ例外が特別なハンドラで処理されるべきことを示す。エミュレータ３１６はコンバータにＲＦＥバック（RFE's back）する。次のＸ８６命令が実行される。次のＸ８６命令の終了時に、レシピの終わりＸ８６＿ＣＯＭＰＬＥＴＥＤサイドバンドビット９２６は単一ステップ例外をトリガする。単一ステップハンドラはプライベートメモリ内で記録を確認し、単一ステップ例外がＳＴＩ命令によって生じたことを発見する。ハンドラはハードウェア割込みを可能にし（次の命令がＣＬＩでない限り）、Ｘ８６単一ステップを以前の状態に復元する。エミュレータ３１６はコンバータにＲＦＥバックし、実行が再開する。
【０６４７】
ＳＴＩのすぐ次に第２のＳＴＩ命令が続く場合は、特別な挙動は第１のＳＴＩのみに適用される。割込みは第２のＳＴＩ命令の後に介入を許可される。
【０６４８】
Ｘ．割込み優先順位
ＴＡＸｉシステムは、５つの例外および１つのソフトウェアトラップを使用する。ＤＭＵ７００は１つの新しい割込みサブケースを導入する。これらの割込みは次の表７にまとめられている。表の第４の列は、相対的な割込み優先順位を示す。第５の列は、この明細書でそれぞれの割込みが論じられているセクションを示す。
【０６４９】
【表９】
0005427742.tif 000014
【０６５０】
パフォーマンスを達成するために、ＴＡＸｉコードはコンバータ１３６およびエミュレータ３１６がとるカノニカルな場所にＸ８６状態を保存しない。したがって、ＴＡＸｉコードが割り込まれる時、コンバータはＸ８６マシンの状態のカノニカルなピクチャを最初に復元しなければ、再開を許可されない。
【０６５１】
上記の例外戦略は、単純さを通じて正確さを達成することを目的としており、すべての例外を処理するための単一な共通戦略を有するものであり、ＴＡＸｉコード内で発生した例外がコンバータによって発生した例外とまったく同じコードで処理されるようにし、パフォーマンスを最大にして、例外をＸ８６に表面化させなければならないこと分かるまでＴＡＸｉコードの放棄を遅らせ、ＴＡＸｉコードがＸ８６ＦＰ例外状態の維持に先立つことを許可する。
【０６５２】
読者の便宜のために、この説明はすべての可能な実施形態のうち代表的な例、すなわち、本発明の原理を教示し、本発明を実行するために考えられる最良の実施形態を伝える例を中心としている。この説明は、すべての可能な変形例を網羅的に列挙することを目的としていない。さらに、説明されない代替の実施形態が可能である。これらの説明されない実施形態の多くは、文字どおり、続く請求項の範囲内にあり、他の実施形態も同等であることを理解されたい。
【０６５３】
次の書物が参照により本明細書に組み込まれている。ＩＮＴＥＬ  ＡＲＣＨＩＴＥＣＴＵＲＥ  ＳＯＦＴＷＡＲＥ  ＤＥＶＥＬＯＰＥＲ'Ｓ  ＭＡＮＵＡＬ，
ＶＯＬ．１〜３，Ｉｎｔｅｌ  Ｃｏｒｐ．（１９９７）；ＧＥＲＲＹ  ＫＡＮＥ，ＰＡ−ＲＩＳＣ２．０ＡＲＣＨＩＴＥＣＴＵＲＥ，Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ  Ｐｒｏｆｅｓｓｉｏｎａｌ  Ｂｏｏｋｓ，Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ（１９９６）；ＲＩＣＨＡＲＤ  Ｌ．ＳＩＴＥＳ  ＡＮＤ  ＲＩＣＨＡＲＤ  Ｔ．ＷＩＴＥＫ，ＴＨＥ  ＡＬＰＨＡ  ＡＸＰ  ＡＲＣＨＩＴＥＣＴＵＲＥ  ＲＥＦＥＲＥＮＣＥ  ＭＡＮＵＡＬ，２ｄ  ｅｄ．，Ｄｉｇｉａｌ  Ｐｒｅｓｓ，Ｂｏｓｔｏｎ（１９９５）；ＤＡＶＩＤ  Ａ．ＰＡＴＴＥＲＳＯＮ  ＡＮＤ  ＪＯＨＮ  Ｌ．ＨＥＮＮＥＳＳＥＹ，ＣＯＭＰＵＴＥＲ  ＡＲＣＨＩＴＥＣＴＵＲＥ：Ａ  ＱＵＡＮＴＩＴＡＴＩＶＥ  ＡＰＰＲＯＡＣＨ，Ｍｏｒｇａｎ  Ｋａｕｆｍａｎ  Ｐｕｂｌ．，Ｓａｎ  Ｍａｔｅｏ，ＣＡ（１９９０）；ＴＩＭＯＴＨＹ  ＬＥＯＮＡＲＤ，ＥＤ．，ＶＡＸ  ＡＲＣＨＩＴＥＣＴＵＲＥ  ＲＥＦＥＲＥＮＣＥ  ＭＡＮＵＡＬ，Ｄｉｇｉｔａｌ  Ｅｑｕｉｐｍｅｎｔ  Ｃｏｒｐ．（１９８７）；ＰＥＴＥＲ  Ｍ．ＫＯＧＧＥ，ＴＨＥ  ＡＲＣＨＩＴＥＣＴＵＲＥ
ＯＦ  ＰＩＰＥＬＩＮＥＤ  ＣＯＭＰＵＴＥＲＳ，Ｈｅｍｉｓｐｈｅｒｅ  Ｐｕｂｌ．，ＭｃＧｒａｗ  Ｈｉｌｌ（１９８１）；ＪＯＨＮ  ＭＩＣＫ  ＡＮＤ
ＪＡＭＥＳ  ＢＲＩＣＫ，  ＢＩＴ−ＳＬＩＣＥ  ＭＩＣＲＯＰＲＯＣＥＳＳＯＲ  ＤＥＳＩＧＮ，ＭｃＧｒａｗ−Ｈｉｌｌ（１９８０）
マイクロフィッシュの付録へのリファレンス
【０６５４】
１９９９年１月２８日に提出された米国特許出願番号０９／２３９、１９４号のファイルに見いだされる、マイクロフィッシュに記録された２８フレームの付録が、参照により本明細書に組み込まれている。
【０６５５】
本特許文書の開示の一部は、著作権によって保護された資料を含む。著作権の保持者は、本特許文書または特許の開示が、特許商標局のファイルまたは記録内に現れた形でファクシミリで再生することに反対するものではないが、それ以外の方法では、いかなる形でもすべての著作権を保持する。
【図１ａ】
0005427742.tif 000015
【図１ｂ】
0005427742.tif 000016
【図１ｃ】
0005427742.tif 000017
【図１ｄ】
0005427742.tif 000018
【図１ｅ】
0005427742.tif 000019
【図２ａ】
0005427742.tif 000020
【図２ｂ】
0005427742.tif 000021
【図２ｃ】
0005427742.tif 000022
【図３ａ】
0005427742.tif 000023
【図３ｂ】
0005427742.tif 000024
【図３ｃ】
0005427742.tif 000025
【図３ｄ】
0005427742.tif 000026
【図３ｅ】
0005427742.tif 000027
【図３ｆ】
0005427742.tif 000028
【図３ｇ】
0005427742.tif 000029
【図３ｈ】
0005427742.tif 000030
【図３ｉ】
0005427742.tif 000031
【図３ｊ】
0005427742.tif 000032
【図３ｋ】
0005427742.tif 000033
【図３ｌ】
0005427742.tif 000034
【図３ｍ】
0005427742.tif 000035
【図３ｎ】
0005427742.tif 000036
【図３ｏ】
0005427742.tif 000037
【図４ａ】
0005427742.tif 000038
【図４ｂ】
0005427742.tif 000039
【図４ｃ】
0005427742.tif 000040
【図４ｄ】
0005427742.tif 000041
【図４ｅ】
0005427742.tif 000042
【図４ｆ】
0005427742.tif 000043
【図４ｇ】
0005427742.tif 000044
【図４ｈ】
0005427742.tif 000045
【図４ｉ】
0005427742.tif 000046
【図５ａ】
0005427742.tif 000047
【図５ｂ】
0005427742.tif 000048
【図６ａ】
0005427742.tif 000049
【図６ｂ】
0005427742.tif 000050
【図６ｃ】
0005427742.tif 000051
【図７ａ】
0005427742.tif 000052
【図７ｂ】
0005427742.tif 000053
【図７ｃ】
0005427742.tif 000054
【図７ｄ】
0005427742.tif 000055
【図７ｅ】
0005427742.tif 000056
【図７ｆ】
0005427742.tif 000057
【図７ｇ】
0005427742.tif 000058
【図７ｈ】
0005427742.tif 000059
【図７ｉ】
0005427742.tif 000060
【図７ｊ】
0005427742.tif 000061
【図８ａ】
0005427742.tif 000062
【図８ｂ】
0005427742.tif 000063
【図８ｃ】
0005427742.tif 000064
【図９ａ】
0005427742.tif 000065
【図９ｂ】
0005427742.tif 000066
【図９ｃ】
0005427742.tif 000067
【図９ｄ】
0005427742.tif 000068
【図９ｅ】
0005427742.tif 000069
【図９ｆ】
0005427742.tif 000070
【図９ｇ】
0005427742.tif 000071
【図９ｈ】
0005427742.tif 000072
【図９ｉ】
0005427742.tif 000073
【図９ｊ】
0005427742.tif 000074
【図９ｋ】
0005427742.tif 000075