ワードアドレス指定

コンピュータ アーキテクチャにおいて、ワード アドレッシングとは、コンピュータ上のメモリのアドレスがメモリのワードを一意に識別することを意味します。これは通常、アドレスがバイトを一意に識別するバイト アドレッシングと対比して使用されます。最近のコンピュータ アーキテクチャのほとんどすべてはバイト アドレッシングを使用しており、ワード アドレッシングは主に歴史的な関心の対象にすぎません。ワード アドレッシングを使用するコンピュータは、ワード マシンと呼ばれることもあります。

^{524,288 (2 19} ) ビットのメモリを備えたコンピュータを考えてみましょう。そのメモリが 8 ビット バイトを使用してバイト アドレス指定可能なフラット アドレス空間に配置されている場合、0 から 65,535 までの 65,536 (2 ^{16 ) 個の有効なアドレスがあり、それぞれが独立した 8 ビットのメモリを表します。代わりに、32 ビット ワードを使用してワード アドレス指定可能なフラット アドレス空間に配置されている場合は、0 から 16,383 までの 16,384 (2 14} ) 個の有効なアドレスがあり、それぞれが独立した 32 ビットを表します。

より一般的には、最小アドレス可能単位 (MAU) は特定のメモリ抽象化の特性です。コンピュータ内の異なる抽象化は、たとえそれらが同じ基礎メモリを表しているとしても、異なる MAU を使用する場合があります。たとえば、コンピュータは命令セットでバイト アドレス指定による 32 ビット アドレスを使用する場合がありますが、CPU のキャッシュ コヒーレンスシステムは 64 バイトキャッシュ ラインの粒度でのみメモリを操作し、特定のキャッシュ ラインを 26 ビット アドレスのみで識別できるようにして、キャッシュのオーバーヘッドを削減する場合があります。

仮想メモリによって行われるアドレス変換は、アドレス空間の構造と幅に影響を与えることがよくありますが、MAU は変更されません。

メモリの最小アドレス単位のサイズには、複雑なトレードオフがあります。より大きな MAU を使用すると、同じ量のメモリをより小さなアドレスでカバーできるため、プログラムのメモリ要件を大幅に削減できます。ただし、より小さな MAU を使用すると、小さなデータ項目を効率的に処理しやすくなります。

プログラムが西洋占星術の伝統的な 12 のサインの 1 つを保存したいとします。1 つのサインは 4 ビットで保存できます。サインを独自の MAU に保存すると、バイト アドレス指定では 4 ビットが無駄になり (効率 50%)、32 ビット ワード アドレス指定では 28 ビットが無駄になります (効率 12.5%)。サインが他のデータとともに MAU に「パック」されると、読み取りと書き込みのコストが比較的高くなる可能性があります。たとえば、他のデータがパックされている MAU に新しいサインを書き込むには、コンピューターは MAU の現在の値を読み取り、適切なビットだけを上書きしてから、新しい値を保存する必要があります。プログラムで他のスレッドが同時に MAU 内の他のデータを変更できるようにする必要がある場合は、特にコストが高くなります。

より一般的な例としては、テキストの文字列があります。UTF -8やASCIIなどの一般的な文字列形式では、文字列は 8 ビットのコード ポイントのシーケンスとして格納されます。バイト アドレス指定では、各コード ポイントをオーバーヘッドなしで、独立してアドレス指定可能な独自の MAU に配置できます。32 ビット ワード アドレス指定では、各コード ポイントを別の MAU に配置するとメモリ使用量が 300% 増加し、大量のテキストを処理するプログラムでは実行可能ではありません。隣接するコード ポイントを 1 つのワードにパックすると、このコストを回避できます。ただし、テキストを処理する多くのアルゴリズムでは、コード ポイントを独立してアドレス指定できることが望まれます。パックされたコード ポイントでこれを行うには、アルゴリズムは、ワード内の文字のオフセットも格納する「ワイド」アドレスを使用する必要があります。このワイド アドレスをプログラムのメモリ内の他の場所に格納する必要がある場合、通常のアドレスよりも多くのメモリが必要になることがあります。

完全なプログラムでこれらの効果を評価するには、大きくて複雑なページを表示する Web ブラウザーを考えてみましょう。ブラウザーのメモリの一部は、画像やテキストなどの単純なデータを保存するために使用されます。ブラウザーは、このデータをできるだけ効率的に保存することを選択する可能性が高いため、MAU のサイズに関係なく、ほぼ同じ量のメモリを占有します。その他のメモリは、ページ上のさまざまなオブジェクトのブラウザー モデルを表し、これらのオブジェクトには、相互参照、画像やテキスト データへの参照など、多くの参照が含まれます。これらのオブジェクトを保存するために必要なメモリの量は、コンピューターのアドレス幅に大きく依存します。

プログラム内のすべてのアドレスが 32 ビットだった場合、この Web ページは約 10 ギガバイトのメモリを占有することになります。

• ウェブ ブラウザが 32 ビット アドレスとバイト アドレス指定可能なメモリを備えたコンピュータで実行されている場合、アドレス空間は 4 ギガバイトのメモリをカバーすることになりますが、これでは不十分です。ブラウザはこのページを表示できないか、データの一部を低速のストレージに適宜移動する必要があり、パフォーマンスが大幅に低下します。
• ウェブ ブラウザが 64 ビット アドレスとバイト アドレス指定可能なメモリを備えたコンピュータで実行されている場合、大きなアドレスを格納するために大幅に多くのメモリが必要になります。正確なオーバーヘッドは、10 ギガバイトのうちのどれだけが単純なデータで、どれだけがオブジェクトのような参照が密集しているかによって異なりますが、40% という数字はあり得ないものではなく、合計 14 ギガバイトが必要になります。もちろん、これは 64 ビット アドレス空間の能力の範囲内です。ただし、他の方法と同等のリソースを想定すると、ブラウザは一般に、コンピュータ内の局所性が低下し、コンピュータのメモリ キャッシュの使用率が低下します。
• ウェブ ブラウザーが 32 ビット アドレスと 32 ビット ワード アドレス指定可能なメモリを備えたコンピューターで実行されている場合、パッキングが最適ではないことと、いくつかのワイド アドレスが必要になることから、追加のメモリが必要になる可能性があります。ブラウザーはほとんどの重要な目的にパッキングと非ワイド アドレスを使用し、ブラウザーは最大アドレス指定可能な範囲である 16 ギガバイト内に快適に収まるため、この影響は比較的小さい可能性があります。ただし、画像やテキストにパックされたデータが広く使用されているため、実行時に大きなオーバーヘッドが発生する可能性があります。さらに重要なのは、16 ギガバイトは比較的低い制限であり、ウェブ ページが大幅に大きくなると、このコンピューターはアドレス空間を使い果たし、バイト アドレス指定のコンピューターと同じ問題がいくつか発生し始めることです。
• ウェブ ブラウザが 64 ビット アドレスと 32 ビット ワード アドレス指定可能なメモリを備えたコンピュータで実行されている場合、上記の両方の実行時オーバーヘッドが発生します。つまり、より大きな 64 ビット アドレスに対応するために大幅に多くのメモリが必要になり、局所性が損なわれるとともに、テキストとイメージ データの大規模なパッキングを処理する実行時オーバーヘッドも発生します。ワード アドレス指定とは、プログラムが理論上は 16 エクサバイトではなく最大 64 エクサバイトのメモリをアドレス指定できることを意味しますが、プログラムがこれほど多くのメモリを必要とすることはまずないため (実際には、実際のコンピュータでメモリを提供できるものはありません)、メリットはありません。

したがって、ワード アドレス指定により、コンピュータはアドレス幅を広げることなく、またそれに応じてメモリ使用量を大幅に増やすことなく、大幅に多くのメモリをアドレス指定できます。ただし、これはワーキング セット サイズの比較的狭い範囲内でのみ有効であり、アプリケーションによっては実行時に大きなオーバーヘッドが発生する可能性があります。画像、テキスト、ファイル、ネットワーク トラフィックなどのバイト指向のデータで比較的少ない作業を行うプログラムでは、最も大きなメリットが得られる可能性があります。

ワード アドレス指定を使用するコンピュータで実行されるプログラムは、より小さな単位へのアクセスをエミュレートすることで、より小さな単位のメモリでも動作できます。ロードの場合、囲んでいるワードをロードしてから、必要なビットを抽出する必要があります。ストアの場合、囲んでいるワードをロードし、新しい値を所定の位置にシフトし、必要なビットを上書きしてから、囲んでいるワードをストアする必要があります。

UTF-8 文字列の連続する 4 つのコード ポイントを 32 ビットのワードにパックする必要があるとします。最初のコード ポイントはビット 0 ～ 7、2 番目はビット 8 ～ 15、3 番目はビット 16 ～ 23、4 番目はビット 24 ～ 31 を占める可能性があります (メモリがバイト アドレス指定可能な場合、これはリトルエンディアンバイト順序になります)。

特定のワード アドレス指定アーキテクチャに例をあまり密接に結び付けずに、サブワード アクセスに必要なコードを明確に説明するために、次の例ではMIPSアセンブリを使用します。実際には、MIPS は 8 ビットおよび 16 ビット値のロードと格納を直接サポートするバイト アドレス指定アーキテクチャですが、例では 32 ビットのロードと格納のみを提供し、32 ビット ワード内のオフセットはアドレスとは別に格納する必要があるものとします。MIPS が選択された理由は、これらの操作をより便利にする特殊な機能を持たない単純なアセンブリ言語であるためです。

プログラムが、r1レジスタ のアドレスにあるワードから3 番目のコード ポイントをレジスタに読み込もうとしているとしますr2。命令セットから他のサポートがない場合、プログラムはワード全体をロードし、16 だけ右シフトして最初の 2 つのコード ポイントを削除し、4 番目のコード ポイントをマスクする必要があります。

  ldw $r1, 0($r2) # 単語全体をロードする
  srl $r1, $r1, 16 # 16 右にシフト
  andi $r1, $r1, 0xFF # 他のコードポイントをマスクします

オフセットが静的にわかっておらず、代わりにビット オフセットがレジスタに格納されている場合はr3、もう少し複雑なアプローチが必要になります。

  ldw $r1, 0($r2) # 単語全体をロードする
  srlv $r1, $r1, $r3 # ビットオフセット分右にシフト
  andi $r1, $r1, 0xFF # 他のコードポイントをマスクします

代わりに、プログラムがレジスタのコード ポイントを、r1アドレスのワードの 3 番目のコード ポイントに割り当てたいとしますr2。命令セットから他のサポートがない場合、プログラムはワード全体をロードし、そのコード ポイントの古い値をマスクし、新しい値を所定の位置にシフトし、値をマージして、ワード全体を元に戻す必要があります。

  sll $r1, $r1, 16 # 新しい値を16左にシフトする
  lhi $r5, 0x00FF # 3番目のバイトを選択するための定数マスクを構築します
  nor $r5, $r5, $zero # マスクを反転して3番目のバイトをクリアする
  ldw $r4, 0($r2) # 単語全体をロードする
  そして$r4、$r5、$r4 # 単語から3番目のバイトをクリアする
  または $r4, $r4, $r1 # 新しい値を単語にマージします
  stw $r4, 0($r2) # 結果を完全な単語として保存する

ここでも、オフセットが に格納されている場合はr3、より複雑なアプローチが必要になります。

  sllv $r1, $r1, $r3 # 新しい値をビットオフセット分左にシフトする
  llo $r5, 0x00FF # バイトを選択するための定数マスクを構築します
  sllv $r5, $r5, $r3 # マスクをビットオフセット分左にシフトする
  nor $r5, $r5, $zero # マスクを反転して選択したバイトをクリアします
  ldw $r4, 0($r2) # 単語全体をロードする
  $r4、$r5、$r4 # ワードから選択されたバイトをクリアする
  または $r4, $r4, $r1 # 新しい値を単語にマージします
  stw $r4, 0($r2) # 結果を完全な単語として保存する

このコード シーケンスは、別のスレッドがワード内の他のバイトを同時に変更できないことを前提としています。同時変更が可能な場合、変更の 1 つが失われる可能性があります。この問題を解決するには、最後のいくつかの命令をアトミックな比較交換ループに変換して、同時変更によって新しい値で操作を繰り返すようにする必要があります。この場合、メモリ バリアは必要ありません。

ワード アドレスとワード内のオフセットのペアは、ワイド アドレス(ファット アドレスまたはファット ポインターとも呼ばれます) と呼ばれます (配列の境界など、他の種類の補足データを格納するためのワイド アドレスの他の用途と混同しないでください)。格納されるオフセットは、ビット オフセットまたはバイト オフセットのいずれかです。上記のコード シーケンスは、オフセットをシフト カウントとして使用するため、オフセットがビットで表されていることのメリットを享受しています。バイトの選択を直接サポートするアーキテクチャでは、バイト オフセットのみを格納する方が望ましい場合があります。

これらのコード シーケンスでは、追加のオフセットをベース アドレスと一緒に保存する必要があり、アドレスの全体的なストレージ要件が実質的に 2 倍になります。これはワード マシンでは必ずしも当てはまりません。主な理由は、アドレス自体がアクセス効率を高めるために他のデータと一緒にパックされないことが多いためです。たとえば、Cray X1 は64 ビット ワードを使用しますが、アドレスは 32 ビットのみです。アドレスがメモリに保存されるときは、アドレスは独自のワードに保存されるため、バイト オフセットはワードの上位 32 ビットに配置できます。そのシステムでワイド アドレスを使用することの非効率性は、このオフセットを操作し、ワード内でバイトを抽出および挿入するための余分なロジックだけであり、メモリ使用には影響しません。

コンピュータの最小アドレス指定単位は、必ずしもコンピュータの命令セットの最小メモリ アクセス サイズと同じではありません。たとえば、コンピュータは、1 バイトを直接読み書きする命令を一切提供せずに、バイト アドレス指定を使用する場合があります。プログラムは、上記のサンプル コード シーケンスのように、ビット操作を使用してソフトウェアでこれらの操作をエミュレートすることが期待されます。これは、DEC AlphaやCray X1などの 32 ビット スーパーコンピュータまたはミニコンピュータの後継として設計された 64 ビット コンピュータ アーキテクチャでは比較的一般的です。

C標準では、ポインターは通常のアドレス表現を持つことが求められています。C では、ビット フィールドを除く任意のオブジェクトへのポインターを形成することもできます。これには、バイト配列の各要素が含まれます。ワード アドレス指定を使用するコンピューターの C コンパイラーは、多くの場合、サイズに応じて異なる型へのポインターに異なる表現を使用します。ワードを埋めるのに十分な大きさの型へのポインターはシンプル アドレスになりますが、 や などのポインターはchar*ワイドvoid*ポインターになります。ワイド ポインターとは、ワードのアドレスとそのワード内のバイトのオフセットのペアです。したがって、ポインター型間の変換は必ずしも簡単な操作ではなく、誤って行うと情報が失われる可能性があります。

C のサイズは、structその へのポインターの表現を決定するときに必ずしも既知ではないため、上記のルールを確実に適用することはできません。コンパイラーは、より効率的なポインター表現を使用できるように、 structの開始を揃える必要がある場合があります。struct

• ERA 1103 は、 36 ビット ワードによるワード アドレス指定を使用します。アドレス 0 ～ 1023 のみがランダム アクセス メモリを参照し、その他のアドレスはマップされていないか、ドラム メモリを参照します。
• PDP -10 は、 36 ビット ワードと 18 ビット アドレスによるワード アドレス指定を使用します。
• 1980 年代と 1990 年代のCrayスーパーコンピュータのほとんどは、 64 ビット ワードによるワード アドレス指定を使用しています。Cray -1とCray X-MP は24 ビット アドレスを使用し、その他のほとんどは 32 ビット アドレスを使用しています。
• Cray X1 は64 ビット アドレスのバイト アドレス指定を使用します。64 ビット未満のメモリ アクセスは直接サポートされていないため、このようなアクセスはソフトウェアでエミュレートする必要があります。X1 の C コンパイラは、16 ビット アクセスのエミュレーションをサポートする最初の Cray コンパイラでした。^[1]
• DEC Alphaは、 64ビットアドレスのバイトアドレッシングを使用しています。初期のAlphaプロセッサは、8ビットおよび16ビットのメモリアクセスを直接サポートしておらず、プログラムでは、たとえば、64ビットワードをロードしてバイトをロードし、次にバイトを個別に抽出する必要があります。Alphaはバイトアドレッシングを使用しているため、このオフセットは、（ワイドアドレスとして個別にではなく）アドレスの最下位ビットで表されます。また、Alphaは、それらのビットを無視して、単にアラインされたワードをロードおよびストアする、アラインされていないロードおよびストア命令（ldq_uおよびstq_u）を便利に提供しています。^[2] アーキテクチャへの後のバイトワード拡張（BWX）では、Alpha 21164aから、8ビットおよび16ビットのロードとストアが追加されました。^[3] 繰り返しになりますが、Alphaは常にバイトアドレッシングを使用していたため、この拡張は深刻なソフトウェアの非互換性なしに可能でした。

• バイトアドレッシング