問題タブ [memory-alignment]

OSAtomicDecrement (Mac 固有のアトミック操作) を使用するには、4 バイト アラインされた SInt32 を提供する必要があります。

この種の料理はうまくいきますか？アライメントの問題に対処する別の方法はありますか?

VirtualAllocによって返されるメモリブロックは常にページサイズに合わせられますか？言い換えると、モジュラスは常にVirtualAllocからの戻り値とページサイズのゼロになりますか？

JIT コンパイラでいくつかのオペコードを動的に生成しており、オペコードの配置に関するガイドラインを探しています。

1) 呼び出しの後に nops を追加することで、アライメントを簡単に「推奨」するコメントを読みました

2）並列処理のためにシーケンスを最適化するために nop を使用することについても読みました。

3) ops のアラインメントが「キャッシュ」のパフォーマンスに適していることを読みました

通常、これらのコメントは裏付けとなる参照を提供しません。ブログやコメントを読んで、「これを行うのは良い考えだ」と言うのと、特定の op シーケンスを実装するコンパイラを実際に書いて、オンラインのほとんどの資料、特にブログが役に立たないことに気付くのとは別のことです。実用化のために。だから私は自分で物事を見つけることを信じています（実際のアプリが何をするかを見るために逆アセンブルなど）。これは、外部情報が必要な 1 つのケースです。

コンパイラは通常、前の命令シーケンスの直後に奇数バイトの命令を開始することに気付きました。そのため、ほとんどの場合、コンパイラは特別な注意を払っていません。あちこちで「nop」を見かけますが、通常、nop は控えめに使用されているようです。オペコードのアライメントはどの程度重要ですか? 実際に実装に使える事例を参考にしていただけないでしょうか？ありがとう。

難しい方法ですが、少なくともboost::program_optionsコンパイラで構成された構造体メンバーの配置に依存していることがわかりました。

デフォルト設定を使用してブーストをビルドし、4 バイト アラインメント ( /Zp4) を使用してプロジェクトにリンクすると、実行時に失敗します (program_options で最小限のテストを行いました)。Boost は不適切な呼び出し規約の可能性を示すアサートを生成しますが、本当の理由は構造体メンバーの配置です。

これを防ぐ方法はありますか？アラインメントによってコードに互換性がなくなる場合、これをライブラリの命名に含めるべきではありませんか?

データを整列する必要がある理由 (およびパディングのようにそれを達成するために行われたすべての努力) を理解しているので、メモリアクセスの数を減らすことができますが、これは、プロセッサが 4 の倍数のアドレスをフェッチできることを前提としています (32 ビットを使用していると仮定します)。建築）。そして、その仮定のために、メモリを整列させる必要があります。

私の質問は
、4 の倍数のアドレス (効率、ハードウェアの制限、別のアドレス) にアクセスできるのはなぜですか?

これを行う利点はどれですか？利用可能なすべてのアドレスにアクセスできないのはなぜですか?

1つのプロジェクトを実行しているときに、メモリデータが「8バイト整列」されていることを確認しました。誰かがこれが何を意味するのか説明できますか？

次のコードを想定します。

いつもそうだと思いますs->a == 1, s->b == 2, s->c == 3か？
または、システムのエンディアンまたはメモリの配置に依存しますか？

型 T と、T 型の均一な要素のみを持つ構造体があるとします。

私は以下の方法でそれらにアクセスしたいと思います:

cpp_offsetofマクロ (正しいと見なされます) は次のとおりです。

C++ 標準はそれを保証していませんが、メンバーが固定オフセットによって離れており、上記が正しいクロスプラットフォーム ソリューションであると仮定できますか?

100% 互換性のあるソリューションは次のとおりです。

[編集]データ メンバーへのポインターを使用して、snk_kidによって標準準拠のより高速なバージョンが提示されました[/編集]
が、私が回避しようとしている追加のルックアップ テーブルが必要です。

//EDIT
そしてもう1つ。これらのフィールドにインデックスを付けるために配列と定数だけを使用することはできません。構造体のフィールドに名前を付ける必要があります (一部のマクロではそれが必要です)。

//EDIT2
なぜそれらは構造体の名前付きフィールドでなければならないのですか? マクロとは何ですか？より大きなプロジェクトの設定システムです。単純化すると、次のようになります。

繰り返しになりますが、100% 互換性のあるソリューションではなく、99% 互換性のあるソリューションを探しています。一部のコンパイラが均一なフィールド間に不均一なパディングを配置することを期待できるかどうかを尋ねています。

EXC_BAD_ACCESSデータのシリアル化を処理するコードに遭遇しました。コードはデバイス（iPhone）でのみ失敗し、シミュレーターでは失敗しません。また、特定のデータ型でのみ失敗します。

問題を再現するテストコードは次のとおりです。

メモリーアライメントの問題だと思い、徹底的に理解したいと思いました。私の（限定された）メモリアライメントの理解から、tmp2バイト進むと、アライメントが2バイトを超えるデータ型ではミスアライメントになります。

しかし、テストコードは他の人にとっては問題なく実行されintます！long long、、doubleおよびの場合にのみ失敗しますlong double。

各データ型のサイズと配置を調べると、失敗したデータ型は異なる値sizeofを持つものであることがわかりました。__alignof

（これらは、「C ++データアライメントと移植性」から印刷機能を実行した結果です）

誰かがエラーの原因を教えてもらえますか？違いは本当に原因EXC_BAD_ACCESSですか？もしそうなら、どのようなメカニズムで？

Visual Studio C++ 2008/2010 は_mm_malloc正式にサポートされていますか? で定義されてmalloc.hいますが、MSDN ライブラリでその説明が見つかりません。