Little Endian đã thắng chưa?


34

Khi dạy gần đây về trận chiến Big vs Little Endian, một sinh viên hỏi liệu nó đã được giải quyết chưa, và tôi nhận ra mình không biết. Nhìn vào bài viết Wikipedia , có vẻ như các cặp kiến ​​trúc / hệ điều hành phổ biến nhất hiện nay sử dụng Little Endian nhưng Giao thức Internet chỉ định Big Endian để chuyển các giá trị số trong các tiêu đề gói. Đó sẽ là một bản tóm tắt tốt về tình trạng hiện tại? Các card mạng hoặc CPU hiện tại có cung cấp hỗ trợ phần cứng cho việc chuyển đổi thứ tự byte không?

Câu trả lời:


25

Tôi tranh luận rằng nó không thắng nhiều đến mức không còn quan trọng nữa. ARM tạo nên về cơ bản tất cả các thị trường di động là bi-endian (oh, dị giáo!). Theo nghĩa là x86 về cơ bản đã "chiến thắng" thị trường máy tính để bàn, tôi cho rằng bạn có thể nói rằng endian nhỏ đã thắng nhưng tôi nghĩ với độ sâu mã tổng thể (nông) và trừu tượng (rất nhiều) của nhiều ứng dụng ngày nay, nó ít gặp vấn đề hơn nó từng là. Tôi không nhớ sự tồn tại thực sự xuất hiện trong lớp Kiến trúc máy tính của tôi.

Tôi nghi ngờ rằng nhiều nhà phát triển thậm chí không biết về endian hoặc tại sao nó quan trọng. Bởi vì đối với đại đa số (và ý tôi là rộng lớn ), nó hoàn toàn không liên quan đến môi trường làm việc hàng ngày của họ. Điều này đã khác 30 năm trước khi mọi người đang mã hóa gần gũi hơn với kim loại, trái ngược với việc thao túng các tệp văn bản trên màn hình theo những cách lạ mắt và ấn tượng.

Sự nghi ngờ chung của tôi là Lập trình hướng đối tượng là khởi đầu của sự quan tâm đến tính cuối cùng vì các lớp truy cập và trừu tượng trong một hệ thống OO tốt che giấu các chi tiết triển khai từ người dùng. Vì việc thực hiện bao gồm sự chứng thực, mọi người đã quen với nó không phải là một yếu tố rõ ràng.

Phụ lục: zxcdw đề cập đến tính di động đang được quan tâm. Tuy nhiên, điều gì đã phát sinh với sự báo thù trong 20 năm qua? Ngôn ngữ lập trình được xây dựng trên các máy ảo. Chắc chắn rằng độ bền của máy ảo có thể có vấn đề nhưng nó có thể được thực hiện rất phù hợp với một ngôn ngữ đến mức về cơ bản nó không phải là vấn đề. Chỉ những người triển khai VM thậm chí sẽ phải lo lắng về tính cuối cùng từ quan điểm tính di động.


2
Vẫn còn nhiều tên miền rất phù hợp, ví dụ như khi viết bất kỳ dạng mã di động nào. Nguyên vẹn, nơi có lẽ không quan trọng là khi viết mã không di động được gắn với một nền tảng.
zxcdw

@zxcdw dẫn chúng ta trực tiếp đến đội quân ngôn ngữ máy ảo ngoài kia ... Tôi đã không nghĩ về điều đó.
Kỹ sư thế giới

Phụ lục của bạn không hoàn toàn đúng (và tôi cũng không đồng ý với @zxcdw): vấn đề về tuổi thọ chỉ xảy ra khi dịch giữa các số nguyên đa dòng và luồng byte và trở thành vấn đề khi nó được thực hiện ngầm và thay đổi giữa các nền tảng. Hầu hết các ngôn ngữ hiện đại (dù dựa trên VM hay không) đều đạt được tính di động bằng cách bạn hiếm khi làm điều đó (với số nguyên là kiểu dữ liệu mờ), và sau đó có tính xác thực độc lập của nền tảng hoặc được lập trình viên chọn rõ ràng.
Michael Borgwardt


2
@zxcdw - ngay cả trong trình biên dịch chương trình, bạn không cần phải luôn biết thứ tự về cuối. Các hằng số, chẳng hạn, không cần phải được chỉ định một byte tại một thời điểm. Tình huống có phần giống với một kiểu tuần tự hóa nhất định trong C - x & 0xFFluôn cung cấp cho bạn byte ít quan trọng nhất bất kể thứ tự endian (giả sử byte của bạn là 8 bit mỗi) vì bạn đã chỉ định các bit bạn quan tâm theo giá trị của chúng, không phải vị trí tương đối của họ trong bộ nhớ.
Steve314

4

Endian chỉ thực sự quan trọng khi bạn chuyển hệ thống dữ liệu nhị phân.

Với sự tiến bộ của tốc độ bộ xử lý (và chi phí lưu trữ thấp hơn nhiều), các giao diện dữ liệu nhị phân trở nên hiếm hơn, do đó bạn không chú ý đến chúng ở lớp ứng dụng. Bạn đang sử dụng định dạng chuyển văn bản (XML / JSON) hoặc bạn đang sử dụng tính trừu tượng của lớp dữ liệu chăm sóc bản dịch cho bạn (vì vậy bạn thậm chí không nhận thấy rằng có bản dịch).

Nhưng khi bạn đang mã hóa ở lớp dữ liệu nhị phân, bạn sẽ chú ý và nó rất quan trọng. Ví dụ: Khi tôi làm việc tại VERITAS (Symantec bây giờ), tôi đang xây dựng phần mềm đang được xây dựng trên 25 nền tảng phần cứng khác nhau (không chỉ có endian lớn / nhỏ còn có các loại khác).


Học sinh của tôi cũng đã phát triển cho điện thoại di động và sử dụng điện toán đám mây, vì vậy họ biết thế giới không phải là PC và Mac.
Ellen Spertus

@Loki - có thể tuần tự hóa và khử nối tiếp mà không cần biết phần cuối của máy. Bạn chỉ thực sự cần biết thứ tự byte của dữ liệu trong tệp / luồng / bất cứ thứ gì. Ví dụ, (char) (x & 0xFF)trong C cung cấp cho bạn byte ít quan trọng nhất bất kể các vấn đề về cuối, chỉ giả sử rằng một byte là 8 bit. Tôi đã thiết kế các định dạng tệp nhị phân mà không biết các máy mà phần mềm sẽ chạy trên đó - về cơ bản tôi đã chọn một thứ tự endian cho định dạng tệp mà không quan tâm đến phần cứng.
Steve314

@espertus: Chắc chắn là có thể.
Martin York

1
@ Steve314: Có tất nhiên bạn có thể. Khi bạn đang làm việc trên "Lớp dữ liệu nhị phân", bạn có thể nghĩ ra bất kỳ lược đồ nào bạn muốn để tuần tự hóa dữ liệu của mình và không khó để đưa ra các sơ đồ có thể di chuyển được. Mặc dù cá nhân tôi sẽ không bận tâm đến việc phát minh lại một bánh xe đã được chế tạo và thử nghiệm tốt từ những năm 60. Tra cứu ` h2nl và gia đình. nhóm chức năng này cung cấp một cách di động (tiêu chuẩn) để thực hiện những điều tối ưu cho nền tảng của bạn.
Martin York

4

Không, không ai đã thắng. Chúng tôi là một loài mà chúng tôi đã thất bại trong việc chuẩn hóa thứ tự mà chúng tôi lưu trữ các byte của mình, cùng với hướng chúng tôi viết và bên đường chúng tôi lái xe.

Do đó, bất kỳ ai muốn truyền dữ liệu giữa hai hệ thống khác nhau qua mạng hoặc trong một tệp, chỉ có khoảng 50% khả năng phiên bản ban đầu hợp lý của mã kết xuất dữ liệu của họ là chính xác trong môi trường của họ và ngay cả khi nó hoạt động , có 50% cơ hội làm việc trong khách hàng của họ.

Để giải quyết vấn đề này, bạn cần tìm kiếm các chức năng cụ thể của nền tảng với các tên như "htonl" trong các tiêu đề có tên rõ ràng có từ những năm 70 như "arpa / inet.h", vì tình hình đã không được cải thiện kể từ đó và có lẽ sẽ không bao giờ .


10
Hóa ra chúng tôi đã đứng ra - thay vì gửi 4 byte để biểu thị một số nguyên, chúng tôi gửi một khối văn bản được định dạng bằng văn bản tiêu đề đặc biệt, dấu ngoặc góc, từ khóa và biểu diễn ASCII của 4 byte đó. Kết thúc nhận sau đó phân tích định dạng để lấy văn bản số nguyên và chuyển đổi lại thành 4 byte. Điều này được gọi là tiến bộ, tôi đã nói :-)
gbjbaanb

$ tìm kiếm năng khiếu xml | wc -l 677
Andrew Wagner

1

Vẫn chưa có sự đồng thuận:

  • Phần lớn các hệ thống máy tính lớn hơn (máy chủ / máy tính để bàn / máy tính xách tay) hiện đang sử dụng các kiến ​​trúc nhỏ về cuối
  • Phần lớn các máy tính nhỏ hơn (máy tính bảng / điện thoại) sử dụng kiến ​​trúc bộ xử lý độc lập endianness, nhưng chạy các hệ điều hành sử dụng thứ tự endian nhỏ

Vì vậy, ở cấp độ phần cứng, LE là phổ biến hơn nhiều. Nhưng:

  • Hầu hết các giao tiếp giữa các máy tính được thực hiện bằng các giao thức xác định thứ tự lớn
  • Một tỷ lệ rất lớn phần mềm của thế giới chạy trên nền tảng ảo mặc định theo thứ tự lớn cuối cùng bất cứ khi nào dữ liệu được ghi vào bộ nhớ ngoài.

Cả hai đơn đặt hàng sẽ được với chúng tôi trong tương lai gần.


Phần lớn các hệ thống lớn nhất (ví dụ: "sắt lớn") thường là endian lớn. Đó là, cái gọi là hệ thống mini hoặc máy tính lớn (chiếm một lượng lớn xử lý phụ trợ mà hầu hết chúng ta không quan tâm.)

@jdv Nhưng hầu hết các hệ thống máy tính lớn nhất là các máy x86-64 endian nhỏ, và ở đó, vấn đề hiệu năng.
dùng877329

Tôi không nghĩ bất cứ ai cũng có thể đưa ra bất kỳ khẳng định mạnh mẽ nào rằng sự tồn tại là bất cứ điều gì ngoài sự thuận tiện từ phía các nhà thiết kế kiến ​​trúc (cho bất cứ điều gì họ muốn đạt được). Vào thời điểm tôi đưa ra nhận xét cổ xưa đó, sắt lớn là BE. Nhưng điều này không phải vì nó là BE, mà bởi vì kiến ​​trúc xảy ra theo cách đó.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.