Чи виграв Маленький Ендіан?

34

Нещодавно викладаючи про битву Великий проти Малого Ендіана, студент запитав, чи це було врегульовано, і я зрозумів, що не знаю. Переглядаючи статтю Wikipedia , здається, що найпопулярніші поточні пари ОС / архітектури використовують Little Endian, але Інтернет-протокол визначає Big Endian для передачі числових значень у заголовках пакетів. Це буде гарним підсумком поточного стану? Чи надають поточні мережеві картки чи процесори апаратну підтримку для переключення порядку байтів?

— Еллен Спертус
джерело

25

Я б стверджував, що це не стільки виграно, скільки перестало мати значення. АРМ, який складає в основному весь мобільний ринок, є двобічним (о, єресь!). У тому сенсі, що x86 в основному "виграв" ринок робочого столу, я думаю, ви можете сказати, що маленький ендіан виграв, але я думаю, що враховуючи загальну глибину коду (неглибоку) та абстракцію (багато) багатьох сучасних додатків, це набагато менше питання, ніж це було раніше. Я не пригадую, щоб в моєму класі «Комп’ютерна архітектура» дійсно з'явилася небезпека.

Я підозрюю, що багато розробників навіть не знають про небезпеку чи про те, чому це важливо. Бо для величезних (і я маю на увазі величезних ) більшості це абсолютно не має значення для їх щоденного робочого середовища. Це було інакше 30 років тому, коли всі кодували набагато ближче до металу, на відміну від маніпулювання текстовими файлами на екрані у вигадливих та драматичних способах.

Моє загальне підозру в тому, що об'єктно-орієнтоване програмування було початком кінця турботи про витривалість, оскільки шари доступу та абстракції в хорошій системі OO приховують деталі реалізації від користувача. Оскільки реалізація включає нестабільність, люди звикли, що вона не є явним фактором.

Додаток: zxcdw згадував портативність. Однак що виникло з помстою за останні 20 років? Мови програмування, побудовані на віртуальних машинах. Зрозуміло, що виграшність віртуальної машини може мати значення, але це може бути дуже послідовно для цієї мови до того моменту, коли це в основному не проблема. Тільки розробникам VM навіть доведеться турбуватися про небезпеку з точки зору портативності.

— Світовий інженер
джерело

2

Є ще багато дуже релевантних доменів, в яких це має значення, наприклад, при написанні будь-якої форми портативного коду. Інфакт, де це, мабуть, не має значення, - це при написанні не портативного коду, прив'язаного до платформи.

— zxcdw

@zxcdw, який веде нас безпосередньо до армії мов віртуальної машини там ... Я про це не думав.

— Світовий інженер

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

— Майкл Боргвардт

2

@MichaelBorgwardt ARM робить arium.com/pdf/Endianness.pdf

— World Engineer

2

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

— Steve314

4

Ендіани мають значення лише тоді, коли ви передаєте бінарні системи даних.

З підвищенням швидкості процесора (і набагато меншими витратами на зберігання) бінарні інтерфейси даних стають все рідшими, тому ви не помічаєте їх на рівні додатків. Ви або використовуєте текстовий формат передачі (XML / JSON) або використовуєте абстракцію рівня даних, яка піклується про переклад для вас (тому ви навіть не помічаєте, що є переклад).

Але коли ви кодуєте на рівні бінарних даних, ви це помічаєте, і це дуже важливо. Наприклад, коли я працював у VERITAS (Symantec зараз), я будував програмне забезпечення, яке будується на 25 різних апаратних платформах (не тільки великі / маленькі ендіани, є й інші типи).

— Мартін Йорк
джерело

Мої студенти також розробляли мобільні телефони та використовували хмарні обчислення, тому вони знають, що світ - це не ПК та Маки.

— Еллен Спертус

@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

$ здатність пошуку xml | wc -l 677

— Ендрю Вагнер

1

Консенсусу досі немає:

Більшість великих комп'ютерних систем (сервер / настільний ПК / ноутбук) в даний час використовують архітектури малої ендіанської економіки
Більшість менших комп’ютерів (планшетів / телефонів) використовують архітектуру процесорів, незалежних від виснаженості, але запускають операційні системи, що використовують замовлення малої ендіанності

Так на апаратному рівні ЛЕ набагато частіше зустрічається. Але:

Більшість міжкомп'ютерних комунікацій здійснюються за допомогою протоколів, які задають порядок великого ендіанства
Дуже велика частка світового програмного забезпечення працює на віртуальній платформі, яка за замовчуванням виконує замовлення великого рівня, коли дані записуються у зовнішній накопичувач.

Обидва замовлення будуть з нами в осяжному майбутньому.

— Жюль
джерело

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

@jdv Але більшість найбільших обчислювальних систем - це маленькі ендіанські машини x86-64, і там продуктивність має значення.

— user877329

Я не думаю, що хтось може стверджувати, що цілеспрямованість - це не що інше, як зручність з боку дизайнерів архітектури (для того, що вони хочуть досягти). У той час, коли я робив цей древній коментар, велике залізо було БЕ. Але це не тому, що це BE, а тому, що архітектура буває такою.