問題タブ [memory-alignment]

バスのデータ幅に基づいてメモリを4バイトと8バイトに調整する必要がある理由を理解しました。しかし、次のステートメントは私を混乱させます

「IoDriveでは、O_DIRECTを使用してデバイスで実行されるすべてのI / Oが、512バイトにアラインされ、サイズが512バイトの倍数である必要があります。」

アドレスを512バイトに揃える必要は何ですか。

私はiccを使用してredhatシステムで作業しているソフトウェアをいくつか持っていますが、正常に動作しています。MIPSで実行されているIRIXシステムにコードを移植すると、値が確実に存在するはずのときに「nan」として出力される計算がいくつか得られます。

RedHat以外のシステムには優れたデバッガーがありませんが、配列の一部が散発的に「nan」になっているため、ドット積の計算が「nan」に戻っていることがわかりました。

デバッガーでは追跡できないので、memcpyに問題があるのではないかと考えています。動的に割り当てられた配列を持つMIPSコンパイラmemcpy（）関数に問題はありますか？私は基本的に使用しています

そして、私はそれを本当に証明することはできませんが、これが問題かもしれないと思います。いくつかの回避策はありますか？おそらく、smeデータがずれていますか？どうすれば修正できますか？

独自のアロケータを定義することにより、整列されたヒープメモリを割り当てるstd::vectorを割り当てることができます。declspec alignを使用して、スタックにcスタイルの配列を割り当てることができます。しかし、インデックス0の要素が整列されることを保証するtr1 :: arrayを宣言できますか？

gccは変数/フィールドの配置をどのように設定しますか

異なるgccバージョン/異なるプラットフォームはどうですか？

テストコード：

x86、gcc 3.4、4.1、4.3の場合、16を取得しました。

C /C++が構造体メンバーの配置をどのように処理するかを理解したと思いました。しかし、VisualStudio2008および2010の特定の配置で奇妙な結果が得られています。

具体的には、char、short、およびcharで構成される構造体は、4バイトまたは8バイトのパッキングが有効になっている場合でも、6バイトの構造体にコンパイルされることがわかりました。なぜそうなるのか途方に暮れています。4バイトの構造体が理解できます。おそらく8バイトの構造体を理解できたでしょう。しかし、4バイトのパッキングが有効になっている場合、6バイトの構造体は不可能だと思います。

問題を示すプログラムは次のとおりです。

出力は次のとおりです。

VCがこれらの各文字に追加のバイトをパディングしている理由を誰かが説明できますか？

アクセス効率を上げるためには、メモリ内でデータを適切に配置する必要があるとよく耳にします。CPU はワード境界でメモリにアクセスします。

したがって、次のシナリオでは、CPU は 1 つの単語を取得するために 2 つのメモリ アクセスを行う必要があります。

なぜこれが起こる必要がありますか？CPU がワード境界でしか読み取れない根本的な原因は何ですか?

CPU が 4 バイト ワード境界でしかアクセスできない場合、アドレス ラインは 32 ビット幅ではなく 30 ビットだけでよいはずです。CPU の目には、最後の 2 ビットが常に 0 であることが原因です。

追加 1

さらに、CPU がワード境界で読み取らなければならないことを認めた場合、境界を読み取りたい場所から開始できないのはなぜでしょうか? CPUの目には境界が固定されているようです。

追加 2

AnTによると、バウンダリ設定はハードウェア化されており、メモリ アクセス ハードウェアによってハードウェア化されているようです。これに関する限り、CPUは無実です。

それらを見て、これらのアドレスのどれがワード アラインされているかを判断できますか?

0x000AE430
0X00014432
0X000B0737
0X0E0D8844

また、glibc malloc() がこれを行うかどうかも知りたいです。

64 ビット UNIX OS を使用している場合、配列のサイズを 8 の倍数に定義する利点はありますか? この配列を使用して、共有メモリからデータをロードするつもりです。そのため、オペレーティング システムとページ サイズに依存関係が存在する可能性があります。

理論的には可能であるはずのメモリ最適化を実行しようとしていますが、arm-elf-gccの機能の範囲内にあるのではないかと疑っています。私が間違っていることを見せてください。

非常に少量のメインメモリと、さらに少量のバッテリバックアップnvramを備えた組み込みシステムがあります。チェックサム構成データをnvramに保存しているので、起動時にチェックサムを検証して前の実行を続行するか、チェックサムが無効な場合は新しい実行を開始できます。実行中に、この構成データのさまざまなサイズのさまざまなフィールドを更新します（後で再計算されるまで、チェックサムが無効になることは問題ありません）。

これらはすべて物理アドレス空間で実行されます。通常のsramはある場所にマップされ、nvramは別の場所にマップされます。これが摩擦です-nvramへのすべてのアクセスは32ビットワードで行われる必要があります。バイトまたはハーフワードアクセスは許可されていません（ただし、メインメモリでは明らかに問題ありません）。

したがって、a）すべての構成データの作業コピーをメインメモリに保存し、チェックサムを再計算するときにそれをnvramにmemcpyするか、b）nvramで直接操作しますが、どういうわけか、すべての構造体がパックされ、すべてのアクセスは32ビットで整列されるだけでなく、32ビット幅である必要があります。

オプションa）は貴重なメインメモリを浪費します。オプションb）を使用して、実行時のトレードオフを行い、それを保存します（ただし、コードサイズがデータサイズを節約するよりも無駄になる場合はありません）。

私はそれまたはそのいくつかのバリエーションがここで役立つことを望んでい__attribute__ ((packed, aligned(4)))ましたが、私がこれまでに行ったすべての読書と実験は私を失望させました。

これが私が扱っている種類の構成データのおもちゃの例です：

さまざまなスレッド（それぞれがFoo、Bar、Bazの機能を実行するため）が独自の構造を適切に更新し、ある時点で同期してチェックサムを再計算してスリープ状態になる時間を宣言することを想像できます。