問題: IBM の記事の抜粋にある数字 256 (2^8) を理解できません:
一方、ビッグエンディアン システムの場合、上位バイトは 1 で、x の値は 256 です。
配列の各要素が 4 バイトを消費すると仮定すると、プロセッサは何らかの方法で 1000 0000 を読み取る必要があります。エンディアンがバイト内のビットに影響しないため、ビッグ エンディアンの場合は 0001 0000 です。【2】記事の256に矛盾!?
質問:数値が 256_dec (=1000 0000_bin) であり、32_dec (=0001 0000_bin) ではないのはなぜですか?
[2] エンディアンの問題は、単一バイトのシーケンスには影響しません。これは、「バイト」がストレージの観点から原子単位と見なされるためです。
バイトは 4 ビットではなく 8 ビットであるため、unsigned int の 9 番目の最下位ビットの値は 2^(9-1)=256 になります。(最下位の値は 2^(1-1)=1)。
IBM の記事から:
unsigned char endian[2] = {1, 0};
short x;
x = *(short *) endian;
彼らは正しいです。値は、ビッグ エンディアンでは (short)256、リトル エンディアンでは (short)1 です。
ビットを書き出すと、{00000001_{base2}, 00000000_{base2}} の配列になります。ビッグ エンディアンは、ビット配列が左から右に読み取られると解釈します。リトルエンディアンは 2 バイトを交換します。
256 decは1000_0000binではなく、 0000_0001_0000_0000binです。
スワップされたバイト (1 バイト = 8 ビット)では、これは0000_0000_0000_0001binのように見えますが、これは 1 decです。
フォローアップの質問に答える: 簡単に言うと、ほとんどのプログラミング言語には「配列内の要素のデフォルト サイズ」はありません。
C (おそらく最も人気のあるプログラミング言語) では、配列要素のサイズ (実際には何でも) はその型に依存します。char の配列の場合、要素は通常1 バイトです。しかし、他の型の場合、各要素のサイズは sizeof() 演算子が与えるものです。たとえば、多くの C 実装では sizeof(short) == 2 が指定されるため、short の配列を作成すると、2*N バイトのメモリが占有されます。ここで、N は要素の数です。
多くの高水準言語では、配列の要素に必要なバイト数を見つけようとすることさえ思いとどまらせます。固定バイト数を指定すると、設計者は常にそのバイト数を使用する必要があります。これは、バイナリ表現に依存する透明性とコードには適していますが、何らかの理由で表現が変更されるたびに下位互換性が損なわれます。
それが役立つことを願っています。(これの最初のバージョンを書くまで、他のコメントは表示されませんでした。)