最近ビッグエンディアンとリトルエンディアンの戦いについて教えているときに、学生はそれが解決したかどうかを尋ねましたが、私は知らないことに気付きました。ウィキペディアの記事を見ると、現在最も人気のあるOS /アーキテクチャペアはリトルエンディアンを使用しているようですが、インターネットプロトコルはパケットヘッダーの数値を転送するためにビッグエンディアンを指定しています。それは現在の状況の良い要約でしょうか？現在のネットワークカードまたはCPUは、バイトオーダーの切り替えをハードウェアでサポートしていますか？
回答:
私は、それが問題になったほど勝ったわけではないと主張します。基本的にすべてのモバイル市場を構成するARMはバイエンディアンです（ああ、異端です！）。x86がデスクトップ市場で基本的に「勝った」という意味では、リトルエンディアンが勝ったと言えると思いますが、今日の多くのアプリケーションの全体的なコード深度（浅い）と抽象化（たくさん）を考えると、それは問題ではありません。それは従来。私のコンピュータアーキテクチャクラスでエンディアンが実際に浮かび上がったことは思い出せません。
私は、多くの開発者がエンディアンを認識していないか、それがなぜ重要なのかを疑っています。そのため、膨大な（とI平均のために広大な）多数それは日常の作業環境に全く無関係です。これは30年前とは異なり、画面上のテキストファイルを派手で劇的な方法で操作するのとは対照的に、誰もが金属にずっと近いところでコーディングしていました。
私の一般的な疑いは、オブジェクト指向プログラミングがエンディアンネスを気にする終わりの始まりだったということです。なぜなら、優れたオブジェクト指向システムのアクセスと抽象化の層は実装の詳細をユーザーから隠すからです。実装にはエンディアンが含まれるため、人々は明示的な要素ではないことに慣れました。
補遺：zxcdwは移植性が懸念されると述べました。しかし、過去20年間に復して何が起こったのでしょうか？仮想マシン上に構築されたプログラミング言語。確かに仮想マシンのエンディアンは重要かもしれませんが、その1つの言語について、基本的に問題にならない程度まで一貫性を保つことができます。VMの実装者だけが、移植性の観点からエンディアンを心配する必要さえあります。
x & 0xFFます- 値で関心のあるビットを指定しているため、エンディアンの順序に関係なく常に最下位バイトを提供します（バイトはそれぞれ8ビットと仮定）メモリ内の相対的な位置ではありません。
エンディアンは、バイナリデータシステムを転送する場合にのみ重要です。
プロセッサ速度の向上（およびストレージの大幅な低コスト化）に伴い、バイナリデータインターフェイスが希少になりつつあるため、アプリケーション層で気付かないようになっています。テキスト転送形式（XML / JSON）を使用しているか、翻訳を処理するデータレイヤー抽象化を使用しています（翻訳があることに気付かないように）。
しかし、バイナリデータレイヤーでコーディングしているときは気づきます。これは非常に重要です。たとえば、VERITAS（現在はシマンテック）で働いていたとき、25種類のハードウェアプラットフォーム（ビッグエンディアンだけでなく、他のタイプもあります）で構築されていたソフトウェアを構築していました。
(char) (x & 0xFF)、Cでは、バイトが8ビットのみであると仮定して、エンディアンの問題に関係なく最下位バイトを提供します。ソフトウェアが実行されるマシンを知らずにバイナリファイル形式を設計しました。基本的に、ハードウェアを気にせずにファイル形式のエンディアン順序を選択しました。
いいえ、誰も勝ちません。私たちは種として、バイトを保存する順序を標準化することに失敗しました。これは、書く方向と運転する通りの側面に沿っています。
結果として、ネットワークまたはファイルを介して2つの異なるシステム間でデータを転送する場合、環境内でデータダンプコードの妥当な初期バージョンが正しく動作する可能性は約50％です。 、顧客で働く可能性が50％あります。
これに対処するには、ヘッダーに「htonl」のような名前のプラットフォーム固有の関数を検索する必要があります。名前は明らかに「arpa / inet.h」のような70年代に遡ります。 。
コンセンサスはまだありません：
したがって、ハードウェアレベルでは、LEの方がはるかに一般的です。しかし：
両方の命令は、近い将来に私たちと一緒になるでしょう。