noocyte のプログラミング研究室 〜プログラムは楽しげに走らねばならない♪〜

データ型のアラインメントとは何か，なぜ必要なのか？

公開：2007/01/14(日)
最終更新：2010/02/04(木)

以前このサイトとブログに，何度かアラインメントに関する記事を書きました (サイト内関連ページ参照)． そのせいか「アラインメント」で検索して来てくれる人が多いので， 過去の記事に加筆修正してこのページを新たに作成しました．

加筆した点は次のとおりです．

たぶんこのページは，日本中で最も (もしかしたら唯一の？) 詳しくアラインメントを解説したページだと思います．
(2007/01/14(日) 現在)

このページの主な更新は Blog でお知らせします．


０．目次

  1. CPU に関する基礎知識
  2. アラインメントとは何か？
  3. アラインされていないデータへのアクセス
    1. アラインメントに寛容な CPU の場合
    2. アラインメントに厳格な CPU の場合
  4. アラインメントの基礎知識のまとめ
  5. 複合データ型 (配列，構造体，共用体) のアラインメント
    1. 複合データ型全体のアラインメント
    2. 複合データ型の各要素のオフセット
    3. 複合データ型のアラインメントのまとめ
    4. 構造体のアラインメントに関する誤解
  6. Ｃ言語におけるアラインメント
    1. sizeof とアラインメントの関係 (sizeof がアラインメントの倍数に切り上げって知ってます？)
    2. malloc() 等が返すアドレス (下位数ビットは常に０って知ってます？)
    3. アラインメントを取得するマクロと演算子
  7. CPU回路の単純化とアラインメントの関係
  8. 補足
    1. 共用体の全メンバのオフセットが０である理由
  9. サイト内関連ページ
  10. 外部へのリンク
  11. 更新履歴

１．CPU に関する基礎知識

以前某所で malloc() のアラインメントについて書いたとき， 「それはＣ言語の仕様なのか？」と訊かれたことがある． また「Ｃ言語 アラインメント」などで検索してここに来る人も多い． アラインメントを C/C++ の問題だと思っている人が多いようだが， 特定のプログラミング言語に起因する問題ではない． アラインメントは機能ではなく制約なので， わざわざそんなものを好きこのんで言語仕様に入れるメリットは何もない．

アラインメントは CPU のハードウェアに起因する問題であり， データのメモリアドレスに関する制約である． C/C++ (そしてアセンブラ) でそれが問題となる理由は， データのメモリアドレスがプログラマに見える (操作できる) 言語だからである．C/C++ のアラインメントに関する仕様は， CPU の制約を「追認 (または代弁)」しているにすぎない．

CPU が扱うデータ型は，基本的には整数型と浮動小数型だけである． 文字列は文字コード (整数型) の配列として表現される． 32ビット CPU では普通，扱える整数型のサイズは１，２，または４バイトである． これらはＣ言語ではそれぞれ，(signed または unsigned) char，short，int (または long) 型と呼ばれる． 浮動小数型には４バイト長の単精度型 (Ｃ言語の float 型) と， ８バイト長の倍精度型 (Ｃ言語の double 型) がある． (x86 ファミリーの中には，８バイト整数，16バイト整数， 10バイト拡張倍精度浮動小数を扱えるものもあるが，ここでは割愛する．)

最近のほとんどの CPU は，メモリ上のデータを１バイト単位で読み書きできる (バイトマシン)注１． つまりメモリは，巨大なバイト配列と考えることができる． １バイト整数をメモリに格納する場合，どれでもいいから１つの配列要素を選び， そこに格納すればよい．その配列要素の番号がメモリアドレスとなる． (Ｃ言語の配列と同じく，要素番号 (メモリアドレス) は０から始まる．)

２バイト以上の整数型や浮動小数型を格納するには複数の配列要素が必要なので， 例えば４バイト整数なら４つの連続する配列要素に格納する． この場合，最初の配列要素の番号が４バイト整数のメモリアドレスとなる． 注意すべき点は，１バイトデータの場合とは異なり， 複数バイトデータのメモリアドレスは好きなように決められるわけではないということである．次にこの点について説明する．


2008/04/06(日) 追記
注１：このページの内容は， あくまでも CPU がバイトマシンであることが前提． ワードマシンの場合， そもそも「バイトアドレス」が存在しない機種もある． また Cray (１ワード＝８バイトのワードマシン) の場合， short 型の有効ビット数は32ビットだが，１ワードを占有してしまうらしい (リンク先ちゃんと読んでないけど)． この変数のアドレスはワードの先頭なのか，それとも有効な４バイトの先頭なのか？

このページの AOF32L(l) というマクロは，変数 l のアドレスを返すが，Cray の場合だけはそれより４バイト後ろのアドレスを返すらしい (マクロ定義は  こちら )．ということは，&l がワードの先頭で AOF32L(l) が有効な４バイトの先頭なのか？

Cray では，構造体の先頭メンバや共用体のメンバが short 型の場合， そのオフセットは４になるのかもしれない．


２．アラインメントは何か？

CPU とメモリの間は，データをやりとりするための電線の束で結ばれている． これをデータバスという．32ビット CPU では普通，この電線は32本あり (32ビット・データバス，下図)，CPU はメモリ上のデータを一度に32ビット (＝４バイト) 読み書きすることができる注２． このため，メモリの最初の４バイト (アドレス０〜３)，次の４バイト (アドレス４〜７)，更に次の４バイト (アドレス８〜11) … は，それぞれ一度で読み書きできる． 普通，このような４バイトをワード (word：語) と呼ぶ．
(注意：x86 など 8/16 ビットから進化してきた CPU シリーズでは，16ビット時代の名残で２バイトをワード， ４バイトをダブルワードなどと呼ぶものが多い． 逆に最初から32ビットとして登場した CPU シリーズでは， 32ビットをワード，16ビットをハーフワードと呼ぶものもある．)

          ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
          ┃                            ３２ビットＣＰＵ                          ┃
          ┗┯┯┯┯┯┯┯┯━┯┯┯┯┯┯┯┯━┯┯┯┯┯┯┯┯━┯┯┯┯┯┯┯┯┛
            ↑↑↑↑↑↑↑↑  ↑↑↑↑↑↑↑↑  ↑↑↑↑↑↑↑↑  ↑↑↑↑↑↑↑↑
データバス  ││││││││  ││││││││  ││││││││  ││││││││
            ↓↓↓↓↓↓↓↓  ↓↓↓↓↓↓↓↓  ↓↓↓↓↓↓↓↓  ↓↓↓↓↓↓↓↓
 アドレス ┏┷┷┷┷┷┷┷┷┳┷┷┷┷┷┷┷┷┳┷┷┷┷┷┷┷┷┳┷┷┷┷┷┷┷┷┓┐
0x00000000┃     バイト     ┃     バイト     ┃     バイト     ┃     バイト     ┃│
          ┠────────╂────────╂────────╂────────┨│
0x00000004┃                ┃                ┃                ┃                ┃│
          ┠────────╂────────╂────────╂────────┨│
0x00000008┃                ┃                ┃                ┃                ┃│
          ┠────────╂────────╂────────╂────────┨│
0x0000000C┃                ┃                ┃                ┃                ┃│メモリ
          ┠────────╂────────╂────────╂────────┨│
    ：    ：                ：                ：                ：                ：│
    ：    ：                ：                ：                ：                ：│
          ┠────────╂────────╂────────╂────────┨│
0xFFFFFFFC┃                ┃                ┃                ┃                ┃│
          ┗━━━━━━━━┻━━━━━━━━┻━━━━━━━━┻━━━━━━━━┛┘
(ワード内     ＋0x00000003      ＋0x00000002      ＋0x00000001      ＋0x00000000 ← リトルエンディアンの場合
 アドレス)    ＋0x00000000      ＋0x00000001      ＋0x00000002      ＋0x00000003 ← ビッグエンディアンの場合

           ←─────────────── ワード ───────────────→

したがって４バイト整数または４バイト浮動小数をメモリに格納する場合， 先頭アドレスが４の倍数になるようにすれば上図の１ワードに収まるため， １回のメモリアクセスで読み書きできる． このようにデータの先頭アドレスを４の倍数にすることを， 「４バイト境界にアライン (align：整列，位置合わせ) する」という．

注２：現実には，Ｎビット CPU のデータバス幅がＮビットであるとは限らない．x86 を例に取ると，32ビット CPU とは言いながら Pentium 以降は64ビット・データバスである． 古くは16ビット CPU 8086 の８ビット・データバス版 8088 というのもあった．

３．アラインされていないデータへのアクセス

では，４バイトデータが４バイト境界にアラインされていない (４バイト境界をまたぐ，ともいう) 場合はどうなるのか？
この場合，４バイトデータＸは下図の例のように複数ワードにまたがっている． (Ｙ，Ｚは別のデータ)

：                ：                ：                ：                ：
：                ：                ：                ：                ：
┠────────╂────────╂────────╂────────┨
┃       Ｙ       ┃       Ｙ       ┃       Ｙ       ┃       Ｘ       ┃
┠────────╂────────╂────────╂────────┨
┃       Ｘ       ┃       Ｘ       ┃       Ｘ       ┃       Ｚ       ┃
┠────────╂────────╂────────╂────────┨
：                ：                ：                ：                ：
：                ：                ：                ：                ：

３.１ アラインメントに寛容な CPU の場合

このようなＸを読み書きするように命令された CPU はどうするだろうか？  「２回に分けて読み書きする」と思うだろう．x86 は実際そのように動作する． 当然読み出しにはメモリアクセス１回分余計に時間がかかる． 最近の (キャッシュを持つ) CPU にとって，メモリアクセスは非常に時間のかかる処理である．さらに， アラインされていないデータがワード境界どころかキャッシュライン境界をもまたいでいた場合， もう一つのキャッシュライン (普通は32〜256バイトらしい) も読むはめになってしまう！

書き込みの場合はもっとメモリアクセス回数が増える場合もある． 仮に CPU が上図の２ワードに対して単純にＸを書き込んだらどうなるだろうか？  ＹとＺが巻き添えを食らって (無効な値に) 書き替えられてしまう． これを防ぐには，書き込み前に上図の２ワードを読み出しておかなければならない． つまり合計４回のメモリアクセスが必要になる．

ただし CPU がワードに書き込みを行う際， ワード内のどのバイトに書き込むかを選択できる回路がついていれば， そのような問題は発生しない． この場合のメモリアクセス回数は読み出しの場合と同じである．

３.２ アラインメントに厳格な CPU の場合

x86 以外の多くの CPU (特に RISC) は上記のようには動作せず，エラーとして処理する． つまり「不正アラインメント例外注３」を発生させる． このとき動いている OS が UNIX 系ならば， SIGBUS というシグナルが発生してコアダンプするというオチがつく ( HP-UX での実例 )． 他の OS でも同様だろう．

なぜエラー扱いするのかは CPU の設計者に聞いてみないとわからないが， まず間違いなく CPU の回路を単純にするためだろう． ワード境界をまたぐデータを２回に分けてアクセスするとなると， それだけ制御回路が複雑になる．

(そのうち暇ができれば， アラインメントと CPU 回路の単純化の関係について追記するつもり．)

ARM も RISC なので不正アラインメント例外を発生するが， ARM Linux カーネルは例外ハンドラで x86 と同様の「アラインされていないデータのアクセス」を実現しているらしい． ただしこれは x86 に比べて非常に遅いはず．

2007/10/25(木) 追記
CPU によっては，アラインメント例外を発生させる代わりに， アドレスの下位ビットを強制的に０と見なして処理するものもある (例：H8/300 シリーズ →  実験結果 )．

2009/05/30(土) 追記
参考：ハードウェアを意識したプログラミングの基礎（後編）
x86，ARM，PowerPC，MicroBlaze でアラインされていないデータにアクセスしてみる実験．
ARM v6 以降は寛容になったらしい．

注３： 呼び方は CPU によって異なる． ここでいう「例外」は C++ や Java 等のプログラミング言語でいう例外 (try 〜 catch で捕捉できるアレ) ではなく， CPU のハードウェアが発生させる割込みの一種である．

４．アラインメントの基礎知識のまとめ

何バイト境界にアラインすればよいか (これをアラインメント注４ (alignment) という) は，CPU とデータ型によって異なるが，一般には２の冪乗 (1，2，4，8，16，…) になる． 基本的なデータ型のアラインメントは，その型のサイズ (バイト数) に一致することが多い． つまり１バイト整数のアラインメントは１バイト， ２バイト整数のアラインメントは２バイト， ４バイト整数／単精度浮動小数のアラインメントは４バイト， ８バイト倍精度浮動小数のアラインメントは８バイトである．

ただし例外もある．例えばデータバス幅より大きい基本データ型をサポートする CPU では，データバス幅がアラインメントの上限になる場合もある (最初に書いたメモリアクセス回数の話からすれば当然)． 例えば16ビット CPU H8/300 シリーズは４バイト整数型をサポートするが，そのアラインメントは２バイトである． (H8 の他のシリーズは使ったことがないので未確認．)


●まとめ ●注意

プロセッサによっては， サイズが２の冪乗でない基本データ型 (24ビット整数や48ビット整数，80ビット浮動小数など) を持つものもある． それらのアラインメントについては個別に確認する必要がある． そのようなデータ型をＣ言語で扱う場合には注意が必要である． (後述の「sizeof とアラインメントの関係」を参照．)

注４： アライメント，境界整列，境界調整[数]などと呼ぶ人もいる．

５．複合データ型 (配列，構造体，共用体) のアラインメント

Warning修正中 (前提条件追記)

５.１ 複合データ型全体のアラインメント

ある複合データ型全体のアラインメントを求めるには， 次のように考えてみるとわかりやすいだろう．

複合データが，ある適切な (つまりアラインされた) アドレスに配置されている． このデータのアドレスを少し移動させたい場合， 何バイト単位で移動させることができるか？

複合データ型の変数 D に含まれる各要素データを Di，そのアラインメントを Ai とする (i＝1，2，…，n)． Di は Ai バイト単位でしか移動できないので， D もまた Ai バイト単位でしか移動できない． これをすべての Di について満たすためには， D は A1，A2，…，An の最小公倍数 LCM(A1，A2，…，An) バイト単位でしか移動できない．したがって D のアラインメントは LCM(A1，A2，…，An) である． アラインメントは２の冪乗でなければならないから， それらの最小公倍数は最大値に等しい．したがって D のアラインメントは Max(A1，A2，…，An) である．

つまり複合データ型のアラインメントは， それに含まれる要素のアラインメントの中で最も大きい (厳しい) ものに等しい． 特に配列の場合はすべての要素が同じ型なので， 配列のアラインメントは要素のアラインメントに等しい．

５.２ 複合データ型の各要素のオフセット

複合データ D のアドレスを Addr(D) と書くことにする． D の要素 Di の，D の先頭からのバイト・オフセットを Offset(Di) とすると，次式が成立する．

Addr(Di) ＝ Addr(D) ＋ Offset(Di)

D が構造体 (型名を D_t とする) の場合， 上の式をＣ言語の構文で書けば次のようになる．

(char*)&Di == (char*)&D ＋ offsetof(D_t, Di)

Di のアラインメントを Ai とすると， Addr(Di) は Ai の倍数である (アラインメントの定義)． また「複合データ型全体のアラインメント」 に書いたことから，Addr(D) も Ai の倍数である． したがって Offset(Di) もまた Ai の倍数でなければならない．つまり複合データ型の要素のオフセットは， その要素のアラインメントの倍数でなければならない．

「構造体メンバのオフセットは， そのメンバのアラインメントの倍数に切り上げられる (パディングが挿入される)」ということは， Ｃ言語を解説している本やサイトでよく見かけるが，その理由は上記のとおりである． これをちゃんと説明しているサイトはほとんどない． まして，複合データ型のアラインメントを解説しているサイトは全く見たことがない (本はどうだか知らないが)．

なお，共用体の場合はメンバのオフセットは常に０なので， このことを考慮する必要はない．

D が配列の場合，最初の要素はオフセット０なので何の問題もない． 要素のサイズがアラインメントの倍数の場合には， 次の要素は前の要素のすぐ後に続けて配置すればよい． そうでない場合には， 要素サイズをアラインメントの倍数に切り上げたオフセットに配置しなければならない． ３番目以降の要素も同様である．したがって配列要素の間隔 (stride) は， 要素の正味のサイズ注５ではなく， それをアラインメントの倍数に切り上げた値でなければならない．

普通の基本データ型ではサイズとアラインメントが同じなのでこの点は問題ないが， 構造体を配列にしようとすると問題になる可能性がある． 例えば次の構造体を配列にすることを考えよう．

typedef struct {
  int a;    // サイズ，アラインメントとも４バイトとする．
  char b;   // サイズ，アラインメントとも１バイト (Ｃの仕様)．
} S_t;

b は１バイト・アラインメントなので， アラインメント調整は必要なく，a と b の間にパディング (隙間) ができることもない．したがってこの構造体 S_t の正味のサイズは４＋１＝５バイト， アラインメントは最も厳しいメンバである a と同じ４バイトである． S_t を配列にする場合，要素間隔は正味の S_t のサイズ (５バイト) を S_t のアラインメント (４バイト) の倍数に切り上げた８バイトとなる． つまり b の後ろには３バイトのパディングが必要．

実は，Ｃ言語の sizeof 演算子が返すのは構造体の正味のサイズではなく， それを配列にしたときの要素間隔である．つまり sizeof(S_t) == 8 (「sizeof とアラインメントの関係」を参照)．

注５： ここでいう「要素の正味のサイズ」とは，その要素が構造体の場合， 「構造体の最後のメンバの後にパディングを含めない」という意味で用いる． したがってそれ以外 (つまりメンバ間) のパディングは「正味のサイズ」に含める．

５.３ 複合データ型のアラインメントのまとめ

５.４ 構造体のアラインメントに関する誤解

構造体のアラインメントに関して，次のように誤解 (中途半端に理解) している人を見かけたことがある．

誤解１：(32ビット CPU では) 構造体は常に４バイト境界に配置される．New!
　　　　 (別表現：構造体のサイズは常に４の倍数である．)

以前から「構造体 ４バイト(境界)」とか「構造体 ４の倍数」などの検索ワードが多かったので， (32ビット CPU では) 構造体のアラインメントは常に４バイトだと思い込んでいる人が多そうで不安になる． さらに悪いことに， 冒頭の図をみて「そうか，だから４バイトなのか！」と早トチリした人もいそうだ．(苦笑)

実際，(このページを読んでもまだ) この誤解をしている人をネット上で２，３人見かけた．
(ということは全国に少なくとも２〜３千人は隠れてるってことですね，わかります．)

身に覚えのある人は， 下記の構造体のサイズとアラインメントがいくつになるか， 自分が使っている処理系で確認して反省してください．(笑)

// ●前提 (char 以外については処理系依存)
// ・char のサイズおよびアラインメントは１バイト (Ｃの仕様)．
// ・short のサイズおよびアラインメントは２バイトとする．
// ・int，long，float のサイズおよびアラインメントは４バイトとする．
// ・long long，double のサイズおよびアラインメントは８バイトとする．

struct S1 {
  short s;
  unsigned char uc[3];
};

struct S2 {
  char string[10];
  unsigned char uc;
};

// x86 用 gcc では -malign-double オプションを指定すること．
// (デフォルトでは，double および long long のアラインメントが４バイトになっている．
//  これはデータバスが32ビットだった 386，486 との互換性のためだろう．)
struct S3 {
  double d;
  long long ll;
  char c;
};

上記の前提を満たす処理系ならば，結果は次のようになるべき．

sizeof(struct S1)＝6，AlignmentOf(struct S1)＝2．(２バイト境界に配置される．サイズは２の倍数．)
sizeof(struct S2)＝11，AlignmentOf(struct S2)＝1．(任意のアドレスに配置される．サイズはメンバのサイズの単純合計．)
sizeof(struct S3)＝24，AlignmentOf(struct S3)＝8．(８バイト境界に配置される．サイズは８の倍数．)

そうなる理由は「複合データ型のアラインメントのまとめ」を読めばわかるはず．

この項目は該当する人が多そうなので以前から追加しようと思っていたんだけど， 忙しいので後回しにしていた．
今回追加したきっかけは，同じ誤解をしているコンパイラ(！)を見つけたから．(↓)

[Armadillo:04936] Armadillo-210の構造体について

構造体の配列を共有メモリに展開するプログラムのデバック中に、実サイズより多くの領域を使用している事が解かり
以下のサンプル作りを実行すると、4バイトと表示しました。

struct test{
    char   ChNo[1];
}w_mem;

アラインメントを変更するコンパイル・オプションや #pragma などを指定せずにこうなっているのだとしたら，このコンパイラもまた， 構造体のアラインメントは常に４バイトだと誤解している可能性がある． double 型や long long 型のメンバが含まれている構造体のアラインメントを４バイトとして扱うと， 不正アラインメントエラーが発生する． こういう災厄を招く勘違いコンパイラは，即刻クビにするのが吉．

誤解２：構造体のサイズは， メンバの中で最大のサイズのものの整数倍である．
誤解３：構造体メンバのオフセットは， そのメンバのサイズの整数倍である．

正解はいずれも，「メンバのサイズ」ではなく「メンバのアラインメント」である． したがってこれらの誤解が「正しい」のは，「サイズ＝アラインメント」である場合， つまりメンバが (普通の) 基本データ型の場合に限られる． メンバが複合データ型や，普通でない (サイズが２の冪乗でない， あるいはアラインメントとサイズが一致しない) 基本データ型の場合には通用しない．
(アラインメントについて解説している他のサイトでも，上記のような記述を見かけた．)

誤解４：アラインメントなんて，普通は (Ｃコンパイラの) 最適化オプションで調整される
　　　　　(ので気にしなくていいと言いたいのかな？)

確かにＣコンパイラは，アラインメントの「調整」はしてくれるが， 普通は「最適化」はしない … というより，Ｃ言語の仕様上，してはいけない． ここでいう「調整」とは，上で書いたように 「メンバのオフセットをそのメンバのアラインメントの倍数に切り上げる」 ことで，Ｃコンパイラが普通に行っている．

一方「最適化」となると， 「構造体メンバの順序を入れ替えて，できるだけ隙間ができないようにする」 としか解釈できないが， Ｃ言語の仕様上，メンバの順序を入れ替えることは許されない．

参考：移植性のあるCプログラミング | 構造体メンバの配置

しかし，上の参考ページにも書いてあるが， Ｃコンパイラの中にはそういう最適化をしてくれる非標準拡張機能を持つものもあるらしい． その機能を ON にすると，Ｃの規格に違反することになるので普通じゃありません！

それから「(アラインメントを) 気にしなくていい」という点に関して言えば， 次のような場合 (とりあえず，今思いついたものだけ) には気にしないといけません．

最初の２つの場合に上記の「最適化オプション」を使うと， メンバの順序が勝手に変えられてとんでもないことになる． Memory Mapped I/O において， ハードウェアレジスタを構造体として記述している場合も同様．


●余談

構造体メンバの順序を入れ替えて隙間を最小にする最適化アルゴリズムは昔趣味で考えたことがあり， 仕事でも10年ほど前に使った．いずれこのサイトで公開しようと思って， トップページには開設当初から目次に (淡色表示で) 書いてあるが，いまだに公開していない…．(^^;)
このページへのアクセスが最近急増したので，そろそろ公開しようかな…．

「"構造体" "メンバの順序" "Ｃ言語"」で Google 検索してみたところ， ビットフィールドのメンバの順序を入れ替えて最適化を行うというコンパイラを見つけた． ↓これは違反じゃない … よね？

ルネサス テクノロジ - よくあるお問い合わせ検索結果

６．Ｃ言語におけるアラインメント

６.１ sizeof とアラインメントの関係 (sizeof がアラインメントの倍数に切り上げって知ってます？)

「複合データ型の各要素のオフセット」でも書いたとおり， sizeof(X) の値は，正味のXのサイズ (バイト数) ではなく， それをXのアラインメントの倍数に切り上げた値である．

なぜ sizeof がそういう仕様なのか，わかりますか？

Ｃ言語の規格では，ｎ個の要素からなる配列 array[] に関して， 

n == (sizeof(array) / sizeof(array[0]))
となることを要求している．この仕様は事実上次のことを意味する．

sizeof(X) が返す値は，X の正味のサイズではなく， X を配列要素にした場合の配置間隔 (stride) でなければならない．

両者が異なるのは，構造体型ではよくあることだが， サイズが２の冪乗でない基本データ型でも起こりうるので注意が必要．

余談：Ｃ言語の中・上級者向けのサイトのいくつかで， 著者が明らかに上記のことを理解して書いているとわかる記述を見たことがある． しかしなぜか上記のことを明言しているのを見たことがない．なんでだろう？

６.２ malloc() 等が返すアドレス (下位数ビットは常に０って知ってます？)

Ｃの標準ライブラリに含まれる malloc() (およびそのファミリーである calloc()，realloc()) が返すアドレスは， すべてのデータ型に適合するようにアラインされている (malloc() の仕様)．また，コンパイラが alloca() をサポートしていれば，それも同様のアドレスを返すはずである．

多くの32ビット CPU では，(標準的なＣがサポートするデータ型の中で) 最もアラインメントの厳しいデータ型は double 型 (８バイト・アラインメント) である (たぶん)． したがって多くの32ビット CPU 用の malloc() は， ８バイトの倍数のアドレスを返す．

この話題については，こちらのページもご覧ください．

６.３ アラインメントを取得するマクロと演算子

標準的なＣ言語では，データ型のサイズを取得する sizeof 演算子はあるものの， アラインメントを取得する演算子はない． そこで私は昔 (1993年)，アラインメントを取得するための処理系・OS 独立なマクロ AlignmentOf() を考案し， 今でもメモリ管理によく使っている．

Microsoft C では，同様の機能を持つ演算子 __alignof() という演算子があるが， これは実際のアラインメントと一致しない場合があるようである (現在調査中，バグというわけではなくそういう仕様らしい)．

GCC には __alignof__ という演算子があるが，これについては未調査．


７．CPU回路の単純化とアラインメントの関係

(そのうち暇ができれば書くつもり．)


８．補足

８.１ 共用体の全メンバのオフセットが０である理由

「複合データ型の各要素のオフセット」で 「共用体の場合はメンバのオフセットは常に０」と書いた点について， 「C/C++ の規格で保証されているのか？」という質問を受けたので追記． 私は C/C++ の規格には全然詳しくないし， 規格書も持っていないので， 規格に関する質問には直接回答できないことを最初にお断りしておきます． (詳しい方，教えてください． ところで IS って何？  Defect Report って何？  おいしいの？)

とりあえず手持ちの本などを調べてみると，次のような記述があった．


なお，C/C++ の規格書の文言に頼らず自分の頭で考えてみると次のようになる．

まず，共用体を本来の目的である「複数の変数が同じメモリ領域を共用する」 ためだけに使うのであれば， すべてのメンバのオフセットが同じである必要はない． 例えば次の共用体 (各メンバのアラインメントはサイズと同じとする) では， u32 のオフセットは０だが，u16 のオフセットは０または２，u8 のオフセットは０〜３のいずれでもよいはずである．

union {
  uint32_t u32;
  uint16_t u16;
  uint8_t  u8;
};

しかし現実には，共用体は昔から type punning (あるデータ型のバイト列を別の型として解釈する) のために多用されている． 例えば次のような共用体を用いて float 型のエンディアン変換を行ったり， 浮動小数演算ではなくビット演算だけで符号を高速判定したりすることができる．

union {
  float    f;
  uint32_t u32;
  uint8_t  u8[4];
};

このような使い方を規格が容認しているのであれば， すべてのメンバを同じオフセットに配置する必要がある． そしてそれは０以外にはない (共用体のサイズを無駄に大きくしない限り)． もし容認していないとすると， 低レベルプログラミング言語として必須の type punning ができなくなってしまう (もっとも，変数のアドレスを別の型のポインタにキャストするという代替手段もあるが)．


注意：この内容は， あくまでも CPU がバイトマシンであることが前提 (注１参照)．

９．サイト内関連ページ


１０．外部へのリンク


１１．更新履歴

このページの主な更新は Blog でお知らせします．

  1. 2007/01/13(土) 作成開始
  2. 2007/01/14(日) 公開
  3. 2007/01/15(月) 過去の記事へのリンクを削除．
  4. 2007/02/03(土)
  5. 2007/03/12(月) 記号の誤記訂正 (GCM → LCM)
  6. 2007/04/13(金) ここに書くまでもない，ほんの些細な追記，リンクを追加．
  7. 2007/09/30(日) 「サイズ＝アラインメント」の例外についてちょっと追記， リンクをいくつか追加，その他わずかな変更．
  8. 2008/04/06(日) 質問を受けたので，「共用体の全メンバのオフセットが０である理由」と注１を追加．
  9. 2008/04/08(火)「複合データ型 (配列，構造体，共用体) のアラインメント」修正中 (前提条件追記)．
  10. 2009/02/08(日) アラインメントが特定のプログラミング言語の仕様ではない点についてちょっと追記．
  11. 2010/02/04(木) 「構造体のアラインメントに関する誤解」に， 「(32ビット CPU では) 構造体は常に４バイト境界に配置される．
    (別表現：構造体のサイズは常に４の倍数である．)    」を追記．

Copyright © 2006-2010 noocyte, All rights reserved.
E-mail: relipmoced (a) yahoo.co.jp
  (" (a) " を半角のアットマークに書き替えてください．)
リンクはご自由に．
「noocyte のプログラミング研究室」トップページに戻る．

track feed noocyte