리틀 엔디안이 이겼어?

최근 Big vs. Little Endian 전투에 관해 가르 칠 때, 한 학생이 그 문제가 해결되었는지 물었고 나는 몰랐다는 것을 깨달았습니다. 상기 찾고 위키 백과 문서 , 가장 인기있는 현재의 OS / 아키텍처 쌍 리틀 엔디안을 사용하는 것 같다하지만 인터넷 프로토콜 지정 빅 엔디안 패킷 헤더에 숫자 값을 전송. 이것이 현재 상태에 대한 좋은 요약입니까? 현재 네트워크 카드 또는 CPU가 바이트 순서 전환을위한 하드웨어 지원을 제공합니까?

나는 그것이 그만두었을 정도로 그다지 승리하지 않았다고 주장했다. 기본적으로 모든 모바일 시장을 구성하는 ARM은 바이 엔디안입니다 (오, 이단!). x86이 기본적으로 데스크톱 시장을 "승리"한다는 의미에서 엔디안이 거의 없다고 말할 수 있지만 오늘날 많은 응용 프로그램의 전체 코드 깊이 (얕은) 및 추상화 (많은)를 고려할 때보 다 문제가 훨씬 적습니다. 예전에는 나는 컴퓨터 아키텍처 수업에서 실제로 나오는 엔디안을 기억하지 않습니다.

많은 개발자들이 엔디안을 모르거나 왜 중요한지 의심합니다. 방대한 (그리고 방대한 의미의 ) 대다수에게는 일상적인 작업 환경과 전혀 관련이 없기 때문입니다. 화려하고 극적인 방식으로 화면에서 텍스트 파일을 조작하는 대신 모든 사람이 금속에 훨씬 더 가까이 코딩 할 때 30 년 전과 다릅니다.

필자는 일반적인 OO 시스템의 액세스 및 추상화 계층이 사용자로부터 구현 세부 사항을 숨기므로 객체 지향 프로그래밍이 엔디안에 대한 관심의 시작의 시작이라고 생각합니다. 구현에는 엔디안이 포함되므로 사람들은 명시적인 요소가 아닌 익숙해졌습니다.

부록 : zxcdw는 이식성이 문제라고 언급했습니다. 그러나 지난 20 년 동안 복수와 함께 무슨 일이 있었습니까? 가상 머신에 구축 된 프로그래밍 언어. 가상 머신 엔디안은 중요 할 수 있지만 기본적으로 문제가 아닌 지점까지 해당 언어에 대해 매우 일관되게 만들 수 있습니다. 심지어 VM 구현 자만 이식성 관점에서 엔디안에 대해 걱정할 필요가있었습니다.

Endians는 바이너리 데이터 시스템을 전송할 때만 중요합니다.

프로세서 속도 (및 훨씬 더 낮은 스토리지 비용)가 향상됨에 따라 이진 데이터 인터페이스는 점점 더 희박 해 지므로 애플리케이션 계층에서는이를 알 수 없습니다. 텍스트 전송 형식 (XML / JSON)을 사용 중이거나 번역을 처리하는 데이터 계층 추상화를 사용하고 있습니다 (따라서 번역이 있음을 알지 못함).

그러나 이진 데이터 레이어에서 코딩 할 때는 매우 중요합니다. 예를 들어 VERITAS (현재 시만텍)에서 근무할 때 25 가지 하드웨어 플랫폼 (기타 / 작은 엔디안뿐만 아니라 다른 유형도 있음)에 구축 된 소프트웨어를 제작했습니다.

아니요, 아무도 이겼습니다. 우리는 종으로서 우리가 쓰는 방향과 우리가 운전하는 거리의 측면과 함께 바이트를 저장하는 순서를 표준화하지 못했습니다.

결과적으로, 네트워크 또는 파일을 통해 두 개의 서로 다른 시스템간에 데이터를 전송하려는 사람은 자신의 환경에서 데이터 덤프 코드의 합리적인 초기 버전이 올 바르고 작동하더라도 , 50 %의 확률로 고객의 업무를 수행합니다.

이 문제를 해결하려면 "arpa / inet.h"와 같이 70 년대로 거슬러 올라간 이름을 가진 헤더에서 "htonl"과 같은 이름의 플랫폼 별 기능을 찾아야합니다. .

여전히 합의가 없습니다.

• 대부분의 큰 컴퓨터 시스템 (서버 / 데스크톱 / 노트북)은 리틀 엔디안 아키텍처를 사용합니다.
• 소형 컴퓨터 (태블릿 / 전화)의 대부분은 엔디안 독립 프로세서 아키텍처를 사용하지만 리틀 엔디안 순서를 사용하는 운영 체제를 실행합니다.

따라서 하드웨어 수준에서 LE가 훨씬 일반적입니다. 그러나:

• 대부분의 컴퓨터 간 통신은 빅 엔디안 순서를 지정하는 프로토콜을 사용하여 수행됩니다.
• 전 세계 소프트웨어의 상당 부분이 데이터가 외부 스토리지에 기록 될 때마다 빅 엔디안 순서로 기본 설정되는 가상 플랫폼에서 실행됩니다.

두 주문 모두 가까운 미래에 우리와 함께 할 것입니다.