바이트 순서에 대한 설명 [호스트 바이트 순서, 네트워크 바이트 순서, 디버거를 통해 직접 관찰]

컴퓨터 분야의 역사적 이유로 형성된 특정 설계 습관은, 엉덩이 너비가 로켓 추진기 폭을 결정하는 논리와 똑같아서, 안에서 “장점”이나 “단점”을 굳이 분석할 필요 없이 순전히 역사적인 습관일 뿐입니다

원본 링크

작가: 북극 링크: https://www.zhihu.com/question/637413724/answer/3346032134 출처: 지식인 저작권은 저자에게 있습니다. 상업적 재판행 시에는 저자와 협의하여 허가를 받으시고, 비상업적 재판행 시에는 출처를 명시하십시오.

본문 재게시

현재의 빅엔디언과 릴리틀 엔디언 상황은 역사적 관습과 상업화의 결과이며, 기술 자체와는 크게 관련이 없습니다. ARM은 빅엔디언으로 설정할 수도 있고 리틀 엔디언으로 설정할 수도 있습니다. TCP/IP 헤더는 아직도 빅엔디언(네트워크 바이트 오더)입니다. 저장 분야에서도 많은 저장 프로토콜/규격들이 빅엔디언 방식으로 데이터를 저장합니다.

그래서 질문자의 세 가지 질문은, 오늘날에 와서 보면:

• 컴퓨터가 왜 널리 리틀 엔디안 저장 방식을 채택하는가? –> 틀렸습니다
• 효율이 더 높지 않습니다

현재 기술로 이 세 가지 문제를 논증하는 것은 화살을 쏘고 나서 표적을 그리는 것과 같습니다

하지만 빅 엔디언 또는 리틀 엔디언의 선택은 컴퓨터 역사에서 실제로 일정한 객관적인 요인이 있었습니다: 호스트 바이트 오더(리틀 엔디언)의 장점: 리틀 엔디언의 덧셈기는 비교적 쉽게 만들 수 있습니다. 8비트 * 4의 덧셈기를 만든다면, 8비트 덧셈기 하나만 있으면 되고, 낮은 비트부터 높은 비트로 순차적으로 모든 바이트를 더하면 됩니다. 이때 발생하는 자리 올림 회로는 매우 간단하지만, 빅 엔디언이라면 한 번에 32비를 로드해야 하며, 그렇지 않으면 계산을 수행할 수 없습니다. 지금 보면 한 번에 8비트 또는 32비를 로드하는 것의 차이는 크지 않지만, 몇십 년 전에는 메모리 가격이 비쌌기 때문에 가능한 한 간단한 것이 좋았고, 따라서 호스트 바이트 오더는 비용을 고려하여 리틀 엔디언으로 선택되었습니다. 네트워크 바이트 오더(빅 엔디언)의 장점: 초기 장치의 캐시가 작았기 때문에 높은 바이트를 먼저 받으면 패킷 정보를 빠르게 판단할 수 있었습니다: 버퍼 크기(얼마나 큰 버퍼를 준비해야 하는지), 주소 범위(IP 주소는 앞부터 뒤로 매칭됩니다). 초기 네트워크 장치의 캐시는 바이트 단위였고, 높은 바이트를 먼저 가져오는 것이 실제로 더 빨랐습니다. 따라서 네트워크 장치는 비용을 고려하여 빅 엔디언을 사용했습니다.

그래서, 바이트 오더의 선택은 역사적으로는 애플리케이션 시나리오와 비용을 더 고려하는 경향이 있었고(예: PPC/MIPS는 네트워크 장비에 더 적합), 이후 기술 발전 과정에서 호환성 때문에 빅 엔디언과 리틀 엔디언 설정이 지금까지 유지되고 있습니다

오늘날에는 이러한 장점은 완전히 사라졌고, 단지 과거의 습관일 뿐입니다