Ucząc ostatnio o bitwie Big vs. Little Endian, uczeń zapytał, czy została rozstrzygnięta, i zdałem sobie sprawę, że nie wiem. Patrząc na artykuł z Wikipedii , wydaje się, że najpopularniejsze obecnie pary OS / architektura używają Little Endian, ale protokół internetowy określa Big Endian do przesyłania wartości liczbowych w nagłówkach pakietów. Czy byłoby to dobre podsumowanie obecnego statusu? Czy obecne karty sieciowe lub procesory zapewniają sprzętową obsługę przełączania kolejności bajtów?
Odpowiedzi:
Twierdziłbym, że nie tyle wygrane, co przestały mieć znaczenie. ARM, który składa się w zasadzie na cały rynek mobilny, jest bi-endian (och, herezja!). W tym sensie, że x86 po prostu „wygrał” rynek komputerów stacjonarnych. Przypuszczam, że można powiedzieć, że wygrał mały Endian, ale myślę, że biorąc pod uwagę ogólną głębokość kodu (płytkość) i abstrakcję (wiele) wielu dzisiejszych aplikacji, jest to o wiele mniejszy problem niż to kiedyś było. Nie przypominam sobie, by Endianness pojawił się naprawdę na mojej lekcji architektury komputerowej.
Podejrzewam, że wielu programistów nie zdaje sobie nawet sprawy z endianizmu ani dlaczego jest to ważne. Ponieważ dla ogromnej (i mam na myśli ogromną ) większości jest to całkowicie nieistotne dla ich codziennego środowiska pracy. Inaczej było 30 lat temu, kiedy wszyscy kodowali znacznie bliżej metalu, w przeciwieństwie do manipulowania plikami tekstowymi na ekranie w fantazyjny i dramatyczny sposób.
Moje ogólne podejrzenie jest takie, że programowanie obiektowe było początkiem końca dbania o endianizm, ponieważ warstwy dostępu i abstrakcji w dobrym systemie OO ukrywają szczegóły implementacji przed użytkownikiem. Ponieważ wdrożenie obejmuje endianizm, ludzie przyzwyczaili się, że nie jest to wyraźny czynnik.
Dodatek: zxcdw wspomniał o możliwości przenoszenia. Co jednak zemściło się w ciągu ostatnich 20 lat? Języki programowania zbudowane na maszynach wirtualnych. Oczywiście endianność maszyny wirtualnej może mieć znaczenie, ale można ją uczynić bardzo spójną dla tego jednego języka do tego stopnia, że zasadniczo nie jest to problemem. Tylko implementatorzy maszyn wirtualnych musieliby się martwić o endianowość z punktu widzenia przenośności.
x & 0xFFzawsze daje najmniej znaczący bajt bez względu na porządek endian (zakładając, że twoje bajty to 8 bitów każdy), ponieważ określiłeś bity, którymi jesteś zainteresowany, ich wartością, nie ich względna pozycja w pamięci.
Endians naprawdę ma znaczenie tylko w przypadku przesyłania systemów danych binarnych.
Wraz z postępem szybkości procesora (i znacznie niższym kosztem przechowywania) interfejsy danych binarnych stają się coraz rzadsze, więc nie można ich zauważyć w warstwie aplikacji. Używasz tekstowego formatu przesyłania (XML / JSON) lub używasz abstrakcji warstwy danych, która zajmuje się tłumaczeniem za ciebie (więc nawet nie zauważysz, że istnieje tłumaczenie).
Ale kiedy kodujesz w warstwie danych binarnych, zauważasz to i jest to bardzo ważne. Na przykład, kiedy pracowałem w VERITAS (teraz Symantec), budowałem oprogramowanie, które było budowane na 25 różnych platformach sprzętowych (nie tylko big / little endian istnieją inne typy).
(char) (x & 0xFF)w C daje najmniej znaczący bajt bez względu na problemy endianowe, przy założeniu, że bajt ma 8 bitów. Zaprojektowałem binarne formaty plików, nie znając maszyn, na których oprogramowanie będzie działało - w zasadzie wybrałem endian zamawiając format pliku bez dbania o sprzęt.
Nie, nikt nie wygrał. My, gatunek, nie udało nam się ujednolicić kolejności, w jakiej przechowujemy nasze bajty, wraz z kierunkiem, w którym piszemy, i bokiem ulicy, którą jedziemy.
W rezultacie każdy, kto chce przesyłać dane między dwoma różnymi systemami za pośrednictwem sieci lub pliku, ma tylko około 50% szans na poprawność początkowej wersji swojego kodu zrzutu danych w swoim środowisku, a nawet jeśli działa , ma 50% szans na pracę u klienta.
Aby sobie z tym poradzić, należy poszukać funkcji specyficznych dla platformy o nazwach takich jak „htonl” w nagłówkach, których nazwy oczywiście sięgają lat 70-tych, takich jak „arpa / inet.h”, ponieważ od tego czasu sytuacja się nie poprawiła i prawdopodobnie nigdy się nie poprawi .
Nadal nie ma konsensusu:
Na poziomie sprzętowym LE jest znacznie bardziej powszechny. Ale:
Oba zamówienia będą u nas w dającej się przewidzieć przyszłości.