Little Endian выиграл?


34

Недавно, когда я рассказывал о битве «Большой против Литва», один из студентов спросил, решено ли это, и я понял, что не знаю. Глядя на статью в Википедии , кажется, что наиболее популярные в настоящее время пары ОС / архитектура используют Little Endian, но этот протокол Интернета определяет Big Endian для передачи числовых значений в заголовках пакетов. Это было бы хорошим резюме текущего статуса? Предоставляют ли современные сетевые карты или процессоры аппаратную поддержку для переключения порядка байтов?

Ответы:


25

Я бы сказал, что это не столько выиграл, сколько перестал иметь значение. ARM, который составляет в основном весь рынок мобильной связи, является bi-endian (о, ересь!). В том смысле, что x86 в основном «выиграл» на рынке настольных компьютеров, я думаю, вы могли бы сказать, что выиграл little endian, но я думаю, учитывая общую глубину кода (мелкую) и абстракцию (много) многих современных приложений, это гораздо меньше проблем, чем это было. Я не помню, чтобы в моем классе по компьютерной архитектуре действительно появлялся порядок байтов.

Я подозреваю, что многие разработчики даже не знают о порядке байтов или почему это важно. Потому что для подавляющего (и я имею в виду, подавляющего большинства) это совершенно не имеет отношения к их повседневной рабочей среде. 30 лет назад все было по-другому, когда все кодировали гораздо ближе к металлу, а не манипулировали текстовыми файлами на экране причудливыми и драматическими способами.

Мое общее подозрение состоит в том, что объектно-ориентированное программирование было началом конца заботы об обратном порядке, поскольку уровни доступа и абстракции в хорошей ОО-системе скрывают детали реализации от пользователя. Поскольку реализация включает в себя порядок байтов, люди привыкли, что это не явный фактор.

Приложение: zxcdw упомянул переносимость как проблему. Что же произошло с местью за последние 20 лет? Языки программирования построены на виртуальных машинах. Конечно, порядковый номер виртуальной машины может иметь значение, но он может быть сделан очень согласованным для этого одного языка до такой степени, что это в основном не проблема. Только разработчикам виртуальных машин даже придется беспокоиться о порядке байтов с точки зрения переносимости.


2
Есть еще много очень важных доменов, в которых это важно, например, при написании любой формы переносимого кода. Фактически, где это, вероятно, не имеет значения, это при написании непереносимого кода, привязанного к платформе.
zxcdw

@zxcdw, который ведет нас непосредственно к армии языков виртуальных машин ... Я не думал об этом.
Мировой инженер

Ваше дополнение не совсем верно (и я также не согласен с @zxcdw): порядковый номер имеет значение только при трансляции между многобайтовыми целыми числами и байтовыми потоками и становится проблемой, когда это делается неявно и варьируется между платформами. Большинство современных языков (будь то на основе виртуальных машин или нет) достигают переносимости, когда вы делаете это редко (с целыми числами в качестве непрозрачного типа данных), а затем имеют порядковый номер, либо указанный независимо от платформы, либо явно выбранный программистом.
Майкл Боргвардт

2
@MichaelBorgwardt ARM делает arium.com/pdf/Endianness.pdf
мировой инженер,

2
@zxcdw - даже в ассемблере вам не всегда нужно знать порядок байтов. Например, константы не нуждаются в указании байта за раз. Ситуация чем-то похожа на определенный стиль сериализации в C - x & 0xFFвсегда дает вам наименее значимый байт независимо от порядка байтов (при условии, что ваши байты равны 8 битам каждый), потому что вы задали интересующие вас биты по их значению, не их относительное положение в памяти.
Steve314

4

Endians имеет значение только при передаче двоичных систем данных.

С повышением скорости процессора (и гораздо более низкой стоимостью хранения) интерфейсы двоичных данных становятся все более редкими, поэтому вы не замечаете их на уровне приложений. Вы используете либо текстовый формат передачи (XML / JSON), либо вы используете абстракцию уровня данных, которая позаботится о переводе (так что вы даже не заметите, что есть перевод).

Но когда вы кодируете на уровне двоичных данных, вы это замечаете, и это очень важно. Например, когда я работал в VERITAS (сейчас Symantec), я создавал программное обеспечение, которое создавалось на 25 различных аппаратных платформах (не только big / little endian, но и другие типы).


Мои ученики также разрабатывали мобильные телефоны и использовали облачные вычисления, поэтому они знают, что мир - это не ПК и Mac.
Эллен Спертус

@Loki - можно сериализовать и десериализовать, не зная порядковый номер машины. Вам действительно нужно знать порядок байтов данных в файлах / потоках / что угодно. Например, (char) (x & 0xFF)в C дает вам младший байт независимо от порядка байтов, предполагая только, что байт равен 8 битам. Я разработал двоичные форматы файлов, не зная машин, на которых будет работать программное обеспечение - я в основном выбрал порядок байтов для формата файлов, не заботясь об аппаратном обеспечении.
Steve314

@espertus: Конечно, возможно.
Мартин Йорк,

1
@ Steve314: Да, конечно, вы можете. Когда вы работаете над «уровнем двоичных данных», вы можете разработать любую схему, которую хотите сериализовать, и нетрудно разработать схемы, которые являются переносимыми. Хотя лично я бы не стал изобретать колесо, которое было построено и хорошо испытано с 60-х годов. Посмотрите на ` h2nl и семью. это семейство функций обеспечивает переносимый (стандартный) способ работы, оптимальный для вашей платформы.
Мартин Йорк,

4

Нет, никто не победил. Мы, как вид, не сумели стандартизировать порядок, в котором мы храним наши байты, а также направление, которое мы пишем, и сторону улицы, по которой мы едем.

Как следствие, любой, кто хочет передавать данные между двумя разными системами по сети или в файле, имеет всего лишь около 50% вероятности того, что разумная начальная версия их кода дампа данных будет правильной в их среде, и даже если она работает , имеет 50% шанс работать в своих клиентов.

Чтобы справиться с этим, вам нужно поискать специфичные для платформы функции с именами, такими как «htonl», в заголовках с именами, явно восходящими к 70-м годам, например, «arpa / inet.h», потому что с тех пор ситуация не улучшилась и, вероятно, никогда не улучшится. ,


10
Оказывается, мы стандартизировали - вместо того, чтобы отправлять 4 байта для представления целого числа, мы отправляем блок текста, отформатированный со специальным текстом заголовка, угловыми скобками, ключевыми словами и представлением ASCII этих 4 байтов. Затем принимающая сторона анализирует форматирование, чтобы получить целочисленный текст, и преобразует его обратно в 4 байта. Это называется прогресс, мне сказали :-)
gbjbaanb

$ aptitude search xml | wc -l 677
Эндрю Вагнер

1

Все еще нет единого мнения:

  • Большинство крупных компьютерных систем (сервер / настольный компьютер / ноутбук) в настоящее время используют архитектуры с прямым порядком байтов
  • Большинство компьютеров меньшего размера (планшеты / телефоны) используют архитектуру процессора, не зависящую от порядка байтов, но используют операционные системы, которые используют порядок байтов в порядке байтов

На аппаратном уровне LE встречается гораздо чаще. Но:

  • Большая часть взаимодействия между компьютерами осуществляется с использованием протоколов, которые указывают порядок с прямым порядком байтов
  • Очень большая часть мирового программного обеспечения работает на виртуальной платформе, которая по умолчанию принимает порядок с прямым порядком байтов при записи данных во внешнее хранилище.

Оба заказа будут с нами в обозримом будущем.


Большинство крупнейших систем (т. Е. «Большое железо») обычно с прямым порядком байтов. То есть так называемые мини-или мэйнфрейм-системы (которые составляют огромную часть серверной обработки, о которой большинство из нас не заботятся)

@jdv Но большинство крупнейших вычислительных систем - это машины с прямым порядком x86-64, и там производительность имеет значение.
user877329

Я не думаю, что кто-либо может утверждать, что порядковый номер - это нечто большее, чем удобство со стороны дизайнеров архитектуры (для всего, чего они хотят достичь). В то время, когда я сделал этот древний комментарий, большое железо было БЫТЬ. Но это не потому, что это BE, а потому, что архитектура такова.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.