エンディアンとデータアライメント ─ バイト順とアクセス境界

バイト順という規約

CPU レジスタの中では 32bit 整数 0x0A0B0C0D は単一の数として扱われ、バイトの「順序」という概念はありません。順序が問題になるのは、その値をバイト単位でアドレス付けされたメモリや伝送路へ展開する瞬間です。1ワードを構成する複数バイトを、どのアドレスへどの並びで置くかの規約がエンディアンです。

• リトルエンディアン: 最下位バイト（LSB）を最小アドレスに置く。0x0A0B0C0D はアドレス昇順に 0D 0C 0B 0A。x86/x86-64、Arm（既定）、RISC-V が採用。
• ビッグエンディアン: 最上位バイト（MSB）を最小アドレスに置く。同じ値が 0A 0B 0C 0D。SPARC や古い PowerPC、そして後述のネットワークバイト順がこれ。

値 0x0A0B0C0D を 4 バイトに展開
アドレス :  +0   +1   +2   +3
little   :  0D   0C   0B   0A   ← LSB が先頭
big      :  0A   0B   0C   0D   ← MSB が先頭

重要なのは、同じマシン内で処理が完結する限りエンディアンは見えないことです。書いた順と同じ順で読めば値は保たれます。問題が顕在化するのは、バイト列が別のエンディアン世界へ渡る境界、すなわちネットワーク通信、ファイル／バイナリ形式の交換、異種プロセッサ間の共有メモリです。

ネットワークバイト順とバイトスワップ

TCP/IP のヘッダ（ポート番号、IP アドレス、チェックサム等）はビッグエンディアンで符号化すると定められており、これをネットワークバイト順と呼びます。リトルエンディアンのホストはソケットに値を渡す前後で変換が必要で、htons/htonl（host to network）、ntohs/ntohl（network to host）がその橋渡しをします。リトルエンディアン機ではこれらは実質バイトスワップ、ビッグエンディアン機では恒等関数になります。

uint16_t swap16(uint16_t v) {
    return (v >> 8) | (v << 8);
}
uint32_t swap32(uint32_t v) {
    return  (v >> 24)
          | ((v >> 8)  & 0x0000FF00u)
          | ((v << 8)  & 0x00FF0000u)
          |  (v << 24);
}

実機ではこのシフト演算ではなく、専用命令（x86 の BSWAP／MOVBE、Arm の REV）にコンパイルされ 1 命令で済みます。コンパイラ組込みの __builtin_bswap32 などを使うのが定石です。

ミドルエンディアン（PDP-11 の 0B 0A 0D 0C のような語内入れ替え）も歴史的に存在しますが、現代の汎用 CPU はリトルかビッグの二択と考えて差し支えありません。

自然アライメントとアクセス境界

アライメントは、データを置くアドレスがそのサイズの倍数になっている性質です。N バイトの値がアドレス addr % N == 0 に置かれている状態を自然アライメントといいます。4 バイト整数はアドレス 0,4,8,… に、8 バイト値は 0,8,16,… に置くのが自然です。

なぜ境界が要るのか。メモリやキャッシュはワード（またはキャッシュライン）単位で読み出されます。自然整列していれば、1 つの値は必ず単一のワード／ライン内に収まり、1 回のアクセスで取得できます。境界をまたいで配置されると、2 つのワードを読み、両者から必要部分を切り出して結合する追加処理が要ります。

4Bワード境界 :  | w0:0-3 | w1:4-7 | w2:8-11 |
整列   addr=4 :         [int    ]            ← 1ワードに収まる
非整列 addr=6 :            [in][t  ]         ← w1とw2にまたがる

x86-64 は歴史的経緯から通常のロード／ストアで非整列を許しますが、無料ではありません。値がキャッシュラインをまたぐ（split access）と内部で 2 アクセスに分割され、レイテンシとスループットが落ちます。一方、整列を前提に最適化された SIMD 命令（古い MOVAPS など）は非整列アドレスで #GP 例外を出します。Arm では多くの通常アクセスが非整列を許容する一方、排他ロードやアトミックは整列を要求し、違反すると SIGBUS になります。

構造体パディングとパッキング

コンパイラは構造体の各メンバを自身の自然アライメント境界に置くため、必要に応じてメンバ間にパディング（詰め物）を挿入します。さらに、配列にしたとき各要素の先頭が整列するよう、構造体全体のサイズを最大メンバのアライメントの倍数へ切り上げます（末尾パディング）。

struct A {            // 1+3+4+1+7+8 = 24 バイト
    char  a;          // offset 0
    // 3 バイトのパディング
    int   b;          // offset 4 （4の倍数へ）
    char  c;          // offset 8
    double d;         // offset 16 （8の倍数へ。9-15はパディング）
};                    // 全体は8の倍数=24バイト

メンバの宣言順を変えるだけでサイズが変わります。大きい型から小さい型へ並べると隙間が詰まり、上の例も再配置すれば 24 → 16 バイトに縮みます。キャッシュ効率（フォルスシェアリングとライン競合）にも直結するため、ホットな構造体ではメンバ順序が性能を左右します。

packed はワイヤフォーマットやハードレジスタのマッピングに便利ですが、メンバが非整列に置かれるため、その値へのアクセスはコンパイラがバイト単位の読み書きに展開し（フォルトを避けるため）、整列時より遅くなります。「サイズは縮むがアクセスは遅くなる」というトレードオフを理解して使うべきです。

まとめ

• エンディアンは多バイト値をバイト列へ並べる規約で、LSB 先頭がリトル（x86/Arm 既定）、MSB 先頭がビッグ（ネットワークバイト順）。同一マシン内では不可視で、別エンディアンとの境界でだけバイトスワップが要る。
• 自然アライメント（サイズの倍数アドレス）はワード／ライン単位アクセスを 1 回で完結させる前提条件で、非整列はペナルティかフォルトを招く。char* の非整列キャストは未定義動作なので memcpy で取り出す。
• パディングは各メンバと構造体全体を境界へ整えるために挿入され、メンバ順序やサイズを左右する。packed はサイズを縮めるがアクセスを遅くし、エンディアン差は解決しない。

低レベルのデータ表現は上位の機構へ波及します。DMA や PCIe のディスクリプタ／レジスタは厳密なバイト順とアライメントを要求し（PCIeアーキテクチャ）、メモリコントローラのアクセス効率も境界配置に左右されます（メモリコントローラのスケジューリング）。ベクタ化された一括処理では整列ロードの可否がそのままスループットに効きます（SIMDとベクタ処理）。