Линус Торвальдс категорически высказался против предлагаемой поддержки режима big‑endian для архитектуры RISC‑V в ядре Linux. Всё началось с вопроса в рассылке о том, смогут ли патчи для RISC‑V BE попасть в текущий цикл разработки ядра:
О господи. Кто‑то всерьёз занимается поддержкой BE в 2025 году?
ЗАЧЕМ?
Серьёзно, это звучит просто ТУПО. Есть какая‑то реальная причина для этого, или это снова история в стиле «RISC‑V используется в академических курсах по проектированию, и люди хотят заниматься порядком байтов из академического интереса»?
Потому что я был бы более чем счастлив просто провести черту и сказать: 'Новые проблемы с порядком байтов — это чья‑то ЧУЖАЯ проблема', и сказать людям перестать валять дурака.
Давайте не будем усложнять вещи без веской причины. И у нас НЕТ причин добавлять новый порядок байтов.
RISC‑V и так уже достаточно запутанная архитектура с миллионами глупых проблем в конфигурации. Не делайте всё ещё хуже.
Лучше посоветуйте этим людям сходить к психотерапевту. Это будет ГОРАЗДО продуктивнее.
Аргументы Линуса выглядят вполне обоснованными.
Затем Линус погуглил информацию и ещё больше разошёлся:
Окей, я только что погуглил это, и я принял решение:
МЫ НЕ БУДЕМ ПРЕВЕНТИВНО ПОДДЕРЖИВАТЬ BIG‑ENDIAN НА RISC‑V.
Задокументированное 'обоснование' этого безумия слишком глупо для слов, но поскольку riscv.org всё же выразил это словами, я просто процитирую эти слова здесь:
«Всё ещё существуют приложения, где важен способ хранения данных, например протоколы, передающие данные через Интернет с полями big‑endian. Поэтому когда little‑endian системе нужно прочитать или изменить сетевой пакет, ей приходится менять big‑endian значения на little‑endian и обратно — процесс, который может занять до 10–20 инструкций на платформе RISC‑V без расширения Zbb»
Другими словами, это предполагает, что RISC‑V добавит режим big‑endian из‑за
(a) интернет‑протоколов — где перестановка байтов не является проблемой
(b) использования «некоторых реализаций RISC‑V, которые не поддерживают существующее расширение Zbb» в качестве оправдания.
Это просто безумие. Во‑первых, даже если бы перестановка байтов была реально затратной для сетей — а это не так, ведь реальные затраты обычно связаны с подсистемами памяти — просто реализуйте чёртово расширение Zbb.
Не говорите «мы слишком некомпетентны, чтобы реализовать Zbb, поэтому мы просим чтобы ВСЕ ОСТАЛЬНЫЕ почувствовали боль от гораздо худшего решения и ещё больше фрагментируем RISC‑V».
Я надеюсь, что это какая‑то первоапрельская шутка, но эта страница датирована «10 марта 2025 года». Близко, но недостаточно близко.
Это тот тип глупых вещей, который просто выставляют RISC‑V в плохом свете.
Бен[автор коммита] — я боюсь, что на этой странице есть «доп материалы», указывающие на codethink.
Я вижу, что частично CONFIG_CPU_BIG_ENDIAN уже попал внутрь, но это должно прекратиться.
Главное ядро для основной разработки. Не для случайных экспериментов, которые делают мир хуже.
И да, мы open source, и это означает, что более чем приветствуется попытаться доказать, что я неправ.
Если окажется, что BE RISC‑V станет реальной вещью, которая релевантна и действительно найдёт место в экосистеме RISC‑V, тогда конечно мы должны поддерживать это в этот момент в главном ядре.
Но я действительно думаю, что это на самом деле делает RISC‑V только хуже, и что мы не должны активно помогать фрагментации.
Так что не ждите, что RISC‑V BE появится в главном ядре Linux.
Комментарии (66)
kuraga333
02.10.2025 10:20Для тех, кто в танке, пожалуйста. Если RISC-V - запутанная, то есть ли незапутанная архитектура?
SIISII
02.10.2025 10:20Нету. ARM, например, бывают и LE (большинство), и BE (меньшинство, но именно их ставят во всякое там сетевое оборудование); довольно многие могут "на лету" переключать порядок следования байтов...
И вообще, непонятна сия истерика ЛТ: BE встречается не так уж и редко, и использующие его процы системой поддерживаются, так какая проблема добавить ещё один такой проц?
lealxe
02.10.2025 10:20Проблема в том, что предложенные ему коммиты были гуано эйпсов с первого же взгляда.
Ну и, возможно, ужос перед всеми случаями типа "8 байт числа memcpy-нули в unsigned long для удобства работы" (недавно такое разбирал из 1994 года), которые от таких фокусов ломаются, хотя их и не должно быть в популярном софте.SIISII
02.10.2025 10:20Ну так низкое качество кода -- не повод отказываться от поддержки чего-то там. Если на то пошло, само ядро Линуха, как и любой крупный проект, -- тоже та ещё свалка дерьма (а иначе они бы не ломали в каждой большой версии совместимость с драйверами из более ранних версий).
"8 байт числа memcpy-нули в unsigned long для удобства работы" (недавно такое разбирал из 1994 года)
Нельзя слегка поподробнее? Ну или ссылку, где сие описано. Просто интересно знать, что за проблема такая всплыла.
win32asm
02.10.2025 10:20Про качество ядра Линукс - драйвера ломаются те, которые out of tree, и это фича а не баг.
Идеального проектирования на все случаи жизни не существует, а обратная совместимость - особенно внутри ядра - имеет очень разную цену для бесплатного (Линух) и платного (например, Винда) продуктов.
Ну и отдельно хочу напомнить, что юзерспейс Линух особо не ломает. Был бы интересный эксперимент, взять какой-нибудь центос 5 или 6, и для него собрать и настроить ядро 6.х. Я почти уверен, что остальная система замену ядра с модулями не заметит.
netch80
02.10.2025 10:20Был бы интересный эксперимент
Этот эксперимент, может, не с такими различиями в версиях, проводят тысячи людей ежедневно, запуская старые системы в докере. До 10-летней давности бывает систематически, больше - иногда. У меня фидошный софт сборки 2004 года, от FreeBSD4 на современной 14-й (но тут надо пакет библиотек совместимости ставить, а одну так тянуть за собой через апгрейды); да, это не линукс, но картина схожая.
K0styan
02.10.2025 10:20Цена универсальности. На RISC-V можно сделать и простенький чип для роутера, и здоровенный процессор для серверов или вычислительных кластеров. Достигается тем, что есть базовая система, а есть расширения.
То есть там не архитектура сама по себе сложная, просто обозначение RISC-V само по себе недостаточно для однозначного определения архитектуры конкретного чипа.
А так есть и незапутанные в этом смысле архитектуры - скажем, те, на которых только одна линейка процессоров в принципе сделана.
ReadOnlySadUser
02.10.2025 10:20Основная проблема подхода RISC-V - невозможно писать сколько-нибудь предсказуемый по производительности и переносимый софт.
К каждому бинарню под RISC-V должна где-то идти инструкция, на каких процессорах оно может запуститься. Это просто дикий ужас.
SIISII
02.10.2025 10:20Вот с этим я, в общем и целом, соглашусь. Но, как по мне, достаточно внедрить в Линух поддержку лишь определённого подмножества всех возможных вариантов сей архитектуры.
Очевидно, например, что никакой "настоящий" Уних, а значит, и Линух невозможен без виртуальной памяти, что требует наличия MMU -- т.е. микроконтроллеры сразу идут лесом (как это имеет место и на, скажем, ARM: Линух работает на архитектурах ARMv7-A, 8-A, 9-A, но никак не на -R или -M -- на них бывают лишь нестандартные "огрызки" типа ucLinux). Соответственно, это прописывается как безусловное требование к поддержке.
То же самое можно сказать и относительно набора команд: вполне разумно требовать наличия тех расширений, без которых невозможна эффективная реализация ядра ОС (скажем, связанных с семафорами, барьерами и прочим для многопроцессорных систем), но глупо объявлять обязательными расширения для всяких там нейросетей и прочие специализированные прикладные фишки.
VADemon
02.10.2025 10:20К каждому бинарню
runtime dispatching позволяет бинарю использовать хоть AVX512, при этом поддерживая fallback для старых процессоров.
С одной стороны мы сейчас имеем неформальные "наборы" инструкций x86-64v2 / v3 и т.п. С другой, был Clean Linux, который сразу скомпилирован под свежие процессоры, а не "самый старый x86-64", чтобы везде-везде запускалось. Поэтому устаканится где-то посередине, а вендор на то и вендор, чтобы вендорить :) (и вообще, с открытый исходный код скомпилировал для целевой машины и все (: )
ReadOnlySadUser
02.10.2025 10:20Всё бы хорошо, но сколько таких наборов инструкций у intel? Они появлялись в версиях архитектур сразу пачками, и дай боже наберётся 4 "поколения". Плюс, RISC-V позволяет иметь (и они существуют) проприоретарные расширения + некоторые наборы инструкций были реализованы до стандартизации и выглядят "почти также, но не так".
И там десятки расширений. Не, в целом-то понятно, что условный cpuid в помощь, пишите софт, диспетчеризуйте вызовы и вот это все, но это усложняет разработку - раз. Ибо комбинаторный взрыв имеет место быть и отладка всех сценариев будет дико дорогой.
Делает невозможным предсказать запустится ли такой софт у потребителя, а если запустится, то с какой производительностью.
В общем и целом, пока RISC-V не перестанут играть в лего, эта архитектура так и останется нишевой, ориентированной на разработку под заказ. CPU общего назначения на ней не изобрести
VADemon
02.10.2025 10:20Согласен, но считаю общий знаменатель найдется. А массовость в ближайшие 20 лет обеспечивать нечем: у ARM были телефоны.
netch80
02.10.2025 10:20Плюс, RISC-V позволяет иметь (и они существуют) проприоретарные расширения + некоторые наборы инструкций были реализованы до стандартизации и выглядят "почти также, но не так".
Всю эту проприетарщину не загоняют в код ядра. Могут в отдельные драйверы, не более.
Делает невозможным предсказать запустится ли такой софт у потребителя, а если запустится, то с какой производительностью.
У кастомного процессора под конкретную железку - потребитель один и чётко определён.
Если же кому-то продадут лаптоп с убунтой, там будут совершенно конкретные наборы особенностей - грубо говоря, RV64GV.
Читать мануал по ISA действительно страшновато, но надо уметь понимать, читая его, что будет в конкретном случае. И есть отдельно спеки на "профили", вот эти профили и надо смотреть, а не каждое какое-нибудь ZabcdTRex20Reptile+.
CPU общего назначения на ней не изобрести
Давно сделали. Но потребность рынка не сформировалась, поэтому надо явно искать, где купить.
netch80
02.10.2025 10:20Этим он ничем не отличился по сравнению, например, с ARM/32. Вообще весь embedded такой. Завтра вам вместо микросхемы управления двигателем, условно, ABC123 поставят PQR456, а у неё другие регистры, коэффициенты и вообще неонка внутре другого цвета. Всё, переписывай что-то, причём "на вчера", потому что контейнеровоз уже заканчивают загружать. Вместо STM32QQQ27PQR250 дают STM32QQQ26PQR240B, а у него некоторые команды Neon медленнее на два такта, и у вас начались мелькания на экране. И тэ дэ и тэ пэ.
А вот "инструкция", о которой вы говорите, представлена в виде опций поддержки в самом бинарнике, средствами расширений ELF (ну, по крайней мере, они стараются загнать всё туда).
netch80
02.10.2025 10:20Сейчас даже X86 менее запутанна, чем RISC-V. Авторы последней придумали 100500 расширений, из которых часть уже несовместимы друг с другом, и без механизма их надёжной идентификации. Самый главный набор детектируется по битам в сервисном регистре, а вот для прочих устойчивого гарантированного метода просто нет, не завезли. По сравнению с этим кошмарик cpuid в x86 выглядит прилично.
AuroraBorealis
02.10.2025 10:20RISC‑V и так уже достаточно запутанная архитектура
RISC-V не архитектура, а ISA. Архитектуру можно создать с любой степенью запутанности.
ildarz
02.10.2025 10:20не архитектура, а ISA
Подскажите, а что означает буковка А в аббревиатуре ISA?
gxcreator Автор
02.10.2025 10:20Тут имеется в виду даже не сама архитектура RISC-V, а запутанность кода и конфигов для ее поддержки в ядре из-за кучи вариантов конфигурации ISA, ядер и периферии.
SIISII
02.10.2025 10:20Периферия к архитектуре процессора относится вообще чуть более чем никак: один и тот же периферийный контроллер можно прикрутить (либо вообще без переделок, либо с минимальными переделками) и к ARM, и к MIPS, и к RISC-V, и даже к IA-32/AMD64, особняком стоят только IBMовские мэйнфреймы (z/Architecture) из-за принципиально иной организации ввода-вывода.
Насчёт кучи вариантов поддержки тех или иных расширений... По большому счёту, ядру нужно лишь знать про то, какие регистры процессора надо сохранять/восстанавливать при переключении процессов/потоков/задач, как устроено MMU и ряд подобных вещей; ему вовсе не требуется знать про наличие/отсутствие расширений системы команд, прямо не влияющих на набор регистров (это разработчикам компиляторов это нужно знать и учитывать, чтобы генерировать код, наиболее оптимальный для конкретного процессора). Все такие вещи являются зависящими от архитектуры и реализуются специфичными для неё модулями, которые не должны сколько-нибудь "стратегически" влиять на код ОС в целом.
gxcreator Автор
02.10.2025 10:20Периферия к архитектуре процессора относится вообще чуть более чем никак: один и тот же периферийный контроллер можно прикрутить (либо вообще без переделок, либо с минимальными переделками) и к ARM, и к MIPS, и к RISC-V, и даже к IA-32/AMD64, особняком стоят только IBMовские мэйнфреймы (z/Architecture) из-за принципиально иной организации ввода-вывода.
Да, но Linux поддерживает конкретные процессоры с конкретной периферией и Линус тут имеет в виду, что для RISC-V из-за открытости приходится поддерживать кучу таргетов с разной нестандартной периферией, хаками для багов обхода хардварной имплементации и тд.
По большому счёту, ядру нужно лишь знать про то какие регистры процессора надо сохранять/восстанавливать при переключении процессов/потоков/задач, как устроено MMU и ряд подобных вещей;
Ну вот у вас есть 100500 RISC-V процессоров с разным набором регистров, разными MMU, контроллерами прерываний и периферией, а тут еще LE/BE надо учитывать.
SIISII
02.10.2025 10:20Периферия -- это драйверы, а соответственно, забота не команды, занимающейся собственно Линухом (ядром), а производителей процессоров, содержащих эту периферию.
Регистры же... Не думаю, что там будет 100500 вариантов -- скорей, всё сведётся к всего нескольким дефайнам для условной трансляции модулей, отвечающих за поддержку архитектуры и абсолютно никак не будет влиять на ядро в целом. Но это надо погружаться в тему, чтоб сказать наверняка.
gxcreator Автор
02.10.2025 10:20Периферия -- это драйверы, а соответственно, забота не команды, занимающейся собственно Линухом (ядром), а производителей процессоров, содержащих эту периферию.
Любой код в mainline это в том числе забота команды ядра. Кроме обычного мержа патчей от вендоров, так же бывают глобальные изменения(например введение device tree), которые требуют поменять кучу вендорского кода и это ложится на этих самых людей. Поэтому Линус и так критичен к изменениям, а многие вендоры железа имеют свои форки со старой версией ядра - чтобы избежать требовательного мержа в mainline и портирования на его новые версии.
Hardcoin
02.10.2025 10:20Довольно смешная позиция. Если бы ядро не занималось поддержкой зоопарка периферии, а всерьёз полностью переложило бы это на производителей, линукс за пределы университетов бы не вышел никогда.
SIISII
02.10.2025 10:20Вообще, MS не разрабатывает дрова видюх и другой сложной периферии, которая плохо стандартизирована (или вообще никак не стандартизирована) -- и ничё, живут как-то. Кроме того, сейчас у разработчика некоего процессора стоит вопрос: либо он обеспечивает совместимость с Линухом, а значит, предоставляет необходимые драйверы, либо уже он, а не Линух, идёт куда подальше.
Hardcoin
02.10.2025 10:20Хорошо, что вы смягчили позицию. Не просто периферия, а не стандартизированная периферия. Сравнение с MS тоже уместно - показывает, что важна доля рынка.
SIISII
02.10.2025 10:20Ну так у Линуха сейчас доля рынка во всяких промышленных компьютерах и прочих Малинках близка к 100% -- примерно как у Винды на обычных ПК. А соответственно, его разработчикам давно уже не требуется заботиться о поддержке каждого чиха того или иного процессора. Хочет сообщество RISC-V полноценной поддержки в Линухе -- пускай само пишет все необходимые драйверы и т.д. и т.п., опираясь на исходники обычного "стандартного" ядра. Ну а не сделает этого -- у них не будет шансов на успешную конкуренцию с, скажем, ARM, за исключением микроконтроллерного сегмента, где Линуху просто не место -- там либо голое железо, либо недосистемы вроде FreeRTOS.
Hardcoin
02.10.2025 10:20Так оно и пишет. Статья ведь не о том, что сообщество risc-v просит авторов ядра написать код. Статья о том, что сообщество код написало, но код плохой (по мнению Линуса)
CrashLogger
02.10.2025 10:20В Windows все совсем не так - там есть стабильный интерфейс между ядром и драйверами, который не меняется десятилетиями. В Linux же часто для поддержки нового оборудования нужно пересобирать ядро, а бинарная совместимость с драйверами регулярно ломается, требуя пересборки и драйверов тоже.
netch80
02.10.2025 10:20В Windows все совсем не так - там есть стабильный интерфейс между ядром и драйверами, который не меняется десятилетиями.
Он менялся несколько раз в ключевых подсистемах.
В Linux же часто для поддержки нового оборудования нужно пересобирать ядро, а бинарная совместимость с драйверами регулярно ломается, требуя пересборки и драйверов тоже.
Задача сохранения совместимости тут возложена на авторов дистрибутивов, которые держат один интерфейс на несколько версий в течение заметного периода (5-10 лет).
mynameco
02.10.2025 10:20Напомню из за чего все это началось, вся эта проблема байтов. Давным давно, в процессоре интел, придумали оптимизацию, загружать байты задом наперед, чтобы их можно было удобнее и быстрее складывать. И вот с тех пор мы имеем такой гемор во всей индустрии.
SIISII
02.10.2025 10:20Порядок "младший-старший" был реализован, как минимум, ещё в PDP-11 -- а это 1969-й год, т.е. существенно раньше, чем появился 8086. Что касается порядка "старший-младший", то он возник одновременно с делением машинного слова на байты -- в IBM System/360, 1964 год. Так что всё это возникло совершенно без участия Интел и без всякой оглядки на подобные оптимизации.
netch80
02.10.2025 10:20Ваш оппонент почти полностью прав прав, LE для 8080 был "изобретён" независимо от PDP-11, 6502 и прочих предшественников, как локальная микрооптимизация. Про это есть воспоминания его разработчика с высказыванием сожаления об этом решении. С ходу ссылку не нашёл, но она широко известна. Ну а дальше именно популярность x86 (через IBM PC) способствовала продвижению LE, вплоть до того, что в RISC-V назначили его базовым вариантом (и про это есть утверждения авторов), командный поток там всегда в LE.
SIISII
02.10.2025 10:20Не для 8080 (который 8-разрядный), а для 8086/8088, тогда уже. И не изобретён: сам порядок байтов LE к тому времени уже достаточно длительное время использовался. Оптимизацию под него придумали -- это вполне возможно и разумно, но не более того.
С популярностью тоже есть вопросы. В частности, до массового распространения IBM PC и его клонов, самой популярной архитектурой, получившей широчайшее распространение, тоже была LE -- в виде PDP-11. Тот же ARM возник не шибко позже появления IBM PC -- в 1984-м, если память не изменяет, и основным вариантом был LE. Ну и т.д. и т.п. Так что не думаю, что именно ПК от IBM в одиночку сыграли роль в доминировании именно LE -- но определённо сыграли такую роль для многих современных ИТшников, считающих этот порядок "единственно верным".
netch80
02.10.2025 10:20Не для 8080 (который 8-разрядный), а для 8086/8088, тогда уже.
Нет, как раз раньше, причём даже 8008. https://stackoverflow.com/a/36263273/
В частности, до массового распространения IBM PC и его клонов, самой популярной архитектурой, получившей широчайшее распространение, тоже была LE -- в виде PDP-11.
Ага, мы-то знаем, что такое PDP endian :))
У PDP-11 сам LE заметно маскировался восьмеричными форматами для человека, и плотным упором на 16-битные значения. Что там слегка "под капотом" LE, тогда, конечно, знали, но прямого внимания не было, в отличие от x86, где уже на уровне машкодов побайтное представление давало, что LE просто бросалось в глаза, как сердитая кошка.но определённо сыграли такую роль
Обсуждаемый RISC-V как раз действует по принципу "всё, о чём у нас нет своего твёрдого мнения, делаем, как в x86". Это хорошо видно по, например, организации виртуальной памяти.
mpa4b
02.10.2025 10:20в 8080 LE не даёт никакого преимущества (но и недостатков тоже). Вот в 6502 даёт преимущество а в 6800 BE даёт недостаток.
mordusnaglus
02.10.2025 10:20задом-наперед - это Big Endian
А LE как раз логичен - младшие разряды в байте с младшим адресом
У BE только одно оправдание: похож на то, как мы пишем цифры - сначала старшие разряды, потом младшие. Проблема правда в том, что цифры мы пишем по арабски (справа налево) при привычном письме, ещё с греков, слева направо.
Злые языки утверждают, что с греков-то это задом-наперед и началось: они финикиские письмена (которые писались справа-налево) на просвет читали.SIISII
02.10.2025 10:20BE столь же логичен. И вообще, нет никакой реальной разницы, дело лишь в привычке. Я в своё время с лёгкостью переходил от СМ ЭВМ (PDP-11) с LE и восьмеричной системой на ЕС ЭВМ (System/370) с BE и шестнадцатеричной системой и обратно -- вообще никаких проблем не испытывал.
Rio
02.10.2025 10:20Но ведь когда мы числа на бумаге пишем, мы сначала старшие разряды пишем, разве нет? А это BЕ. Почему вдруг LE логичнее стало? Из-за этого BE намного удобнее, когда raw-дампы памяти в hex-виде смотришь. Тогда все числа видны, как они есть, независимо от размера типов данных. Любую структуру смотришь, и всё очевидно. А если машина в LE, то все значения в уме переворачивать нужно, и размеры всех типов знать обязательно, чтобы правильно перевернуть. Как человек, постоянно работающий и с BE, и с LE машинами, считаю BE прям сильно более удобным в этом плане.
mordusnaglus
02.10.2025 10:20Но ведь когда мы числа на бумаге пишем, мы сначала старшие разряды пишем, разве нет?
Потому что мы их пишем справа-налево, как арабы
Rio
02.10.2025 10:20Именно. Для тех, кто пишет разряды в числах справа налево, а сами числа слева направо, использование BE выглядит логичным, потому что это оно и есть. И не нужно лишний раз ломать мозг при визуальном парсинге данных, для него другой работы найдётся.
netch80
02.10.2025 10:20справа-налево, как арабы
Это неправда. Писать числа в десятичной позиционной системе начали индийцы, а у них запись слева направо. Арабы только позаимствовали подход, не меняя порядка цифр в физической записи. Европейцы, приняв у арабов, сохранили физический порядок, фактически восстановив (ещё этого не зная) исходный индийский порядок. Пожалуйста, не повторяйте эти глупые мифы про "арабский" порядок.
Кстати, и цифры некорректно называть арабскими. Их точная форма на момент заимствования была другой, и сейчас есть "южноарабский" отдельный вариант. Вот в Юникоде исходные цифры: ٠١٢٣٤٥٦٧٨٩ - ну как, похоже? Правильнее всего называть наши современные цифры итальянскими (или имени Фибоначчи, это он "притащил" их в христианскую Европу, форма сохраняется в его варианте).
SergeiPod
02.10.2025 10:20Как раз наоборот - в BE, пока мы не знаем длину слова, мы вообще не знаем веса разрядов, когда начинаем их читать с меньших адресов.
В LE всё очевидно. Сначала байт с весом 1 , потом с весом 256 ...
А если длинная арифметика с числами переменной длины, то в BE - вообще вешалки...
SIISII
02.10.2025 10:20А если длинная арифметика с числами переменной длины, то в BE - вообще вешалки...
Абсолютно никаких проблем, поскольку такая арифметика реализуется не чисто аппаратными средствами, а чисто программными, и абсолютно ничто не мешает именно для таких чисел хранить байты в порядке "младший-старший" -- всё равно их интерпретацию (как чисел переменной длины) осуществляет программа, а не процессор (для которого таких чисел попросту нет -- если не рассматривать весьма специфические случаи вроде десятичных чисел на мэйнфреймах IBM).
netch80
02.10.2025 10:20в BE, пока мы не знаем длину слова, мы вообще не знаем веса разрядов, когда начинаем их читать с меньших адресов.
И какая польза была бы в том, что мы "знали" бы вес разрядов?
А если длинная арифметика с числами переменной длины, то в BE - вообще вешалки...
Никаких "вешалок". Два индекса вместо одного, или смещение к одному из индексов. Чуть-чуть менее удобно, но подъёмно без проблем.
netch80
02.10.2025 10:20А LE как раз логичен - младшие разряды в байте с младшим адресом
И что с того? В этом нет никакого явного преимущества, если смотреть и на дизайн "железа", и на поведение софта. В одном случае лучше одно, в другом - другое.
Вот пример: числа переменной длины в памяти (частые во многих форматах), старший бит определяет, последний байт или нет. Когда записывается такое число в память, чуть меньше возни при LE формате: выделил семь бит, сдвинул вправо, проверил, ноль или нет, пошёл дальше. (Со знаковыми чуть сложнее, но тоже подходит.) А собирать его обратно надо фактически с конца. Зато при BE сложнее записывать (фактически, надо записать в стиле LE и потом развернуть), зато читать легче - на каждый байт сдвиг и побитовое "или". Поэтому форматы [u]leb128 в DWARF - глупость, там отладчик читает сотни раз на одну запись в генераторе в компиляторе, надо было BE.
А вот "длинную арифметику" чуть-чуть проще в LE, там на одну переменную индекса получается меньше при операциях типа сложения-вычитания.
Не будет тут универсальности, не надейтесь.
NoName97
02.10.2025 10:201. Простота и скорость сравнения чисел (на аппаратном уровне)
Представьте, что вам нужно сравнить два 32-битных числа, поступающих по сети (в BE). В BE они передаются байт за байтом, от старшего к младшему.
· На BE-процессоре (например, в сетевом маршрутизаторе):
· Сравнивается первый (старший) байт числа A и число B.
· Если они разные — всё, результат ясен сразу. Можно даже не дожидаться приема остальных байтов и начинать маршрутизацию пакета.
· Это похоже на сравнение строк: "5000" и "4000" — первая же цифра дает ответ.
· На LE-процессоре:
· Чтобы сравнить числа так же эффективно, ему пришлось бы либо:
1. Ждать, пока все байты не будут приняты и реконвертированы в LE, и только потом сравнивать. Это добавляет задержку (латентность).
2. Сравнивать байты в обратном порядке, начиная с последнего принятого байта, что усложняет логику.
Вывод: Для задач, где критична скорость последовательной обработки потоков данных (сетевые пакеты, потоки данных), BE эффективнее на аппаратном уровне.
Психологический и исторический аспект
BE часто называют "сетевым порядком" (Network Byte Order) не просто так. На заре интернета инженеры, проектировавшие протоколы, мыслили именно в терминах последовательных потоков данных, где старшие, самые значимые части идут первыми. Это интуитивно согласуется с BE.
Итог: Аналогия
Представьте два завода:
· Завод BE: Детали на конвейере едут в том порядке, в котором они будут собраны в готовое изделие (колесо -> ось -> рама). Сборщик в начале линии сразу видит, что собирается автомобиль, а не велосипед.
· Завод LE: Детали едут в обратном порядке (рама -> ось -> колесо). Чтобы понять, что собирается, сборщику нужно либо дождаться всей партии деталей, либо мысленно перевернуть весь процесс.
gxcreator Автор
02.10.2025 10:20Ждать, пока все байты не будут приняты
Так это в любом случае надо, чтобы проверить чексумму, не?
nin-jin
02.10.2025 10:20Это ХабрГПТ еще и не знает, что процессоры обрабатывают байты не по одному, а машинными словами.
netch80
02.10.2025 10:20Для раутеров всё совсем не так, чем толще, тем больше специфика.
Ещё в 1990-х, Cisco Catalyst 19xx серий как раз умел начинать раутинг ещё по не до конца полученному адресу. То же умели 3comʼы примерно тех же времён, модели не помню, но мне на курсах это рассказывали.И никто процессоры общего пользования в линейные процессоры карт не ставит (пардон, и там и тут "процессоры", но идея должна быть понятна), там специализированные ASICʼи с табличной логикой для быстрого разбрасывания, и чем толще раутер, тем эти процессоры "толще" и специальнее. Им как раз вписать принятие решения по неполному адресу просто и полезно. Например, такой процессор в раутере Core-уровня не будет из IPv6 адреса разбирать что-то дальше первых 4 байт (октетов), на основе принципа, что PA и PI получают блоки /32; если нужно хотя бы по 6 байтам, то это уже не Core, а Distribution тип железки. А чтобы по последним 8 - так это только на конкретном собственном интерфейсе уже финального хопа.
Так что в случае процессоров общего пользования вы, конечно, были бы правы, но именно для сетевой маршрутизации - нет, советую "изучить матчасть" (™).
netch80
02.10.2025 10:20Не.
1. В достаточно "толстом" раутере, да, может быть кадр принят целиком для проверки чексуммы, но этим занимается тупой ASIC на плате. А дальше включается логика раутинга, и вот в ней даже внутренние передачи между процессорами карт и/или центральными раутерными (это разные!) могут подчиняться логике опознания по началу адреса. Поэтому и IPv4, и IPv6 адреса представлены как BE, и это не хотели менять при создании v6.
2. Вполне может быть "оптимистичная" логика, когда кадр передаётся на выход ещё не принятый до конца, но если обнаруживается, что битый, то передача прерывается. Тут уже от вендора зависит. Я помню с ISPшных времён, что Cisco где-то при переходе от 19xx к 25xx, 35xx и т.п. это отменяла, оставив только store-and-forward, а CatOSʼные каталисты вообще этого не умели изначально, но что у других вендоров - ХЗ, могли и применить.
В целом, да, в большинстве случаев, скорее всего, сейчас тотальный store-and-forward, при котором уже неважно, но на 100% я не буду ручаться.
ITDiver77
02.10.2025 10:20Печалька. 35% посетителей хабра не знают что такое LE/BE. Всё более не айти ресурс(
MechanicZelenyy
02.10.2025 10:20Не то что мы олды, точно знаем что LE это когда в json идут сначала короткие ключи, а BE это когда длинные.
DrGluck07
02.10.2025 10:20LE/BE, да какая разница. А вот память, она идёт слева направо? Или сверху вниз? Или может наоборот, снизу вверх? Вот действительно важные вопросы.
nin-jin
Я всё жду, когда же интернет протоколы поправят. Ну и крипто-алгоритмы заодно.
akostrikov
Я пока ipv17 жду. Думаю после него можно будет протоколы полностью поправить.
Godless
а ipv6 уже и на аукционах закончился?))
akostrikov
Не знаю, но боюсь ipv17 разберут - на сайте так и не понял что это такое. Но я и не старался :)
Groh
"есть 18 независимых стандартов"
David_Osipov
Хм, легаси же. Вроде форматы изображений тоже используют BE. Хотя, имхо, этот зоопарк с LE и BE вносит ненужную фрагментацию и сложности. Если уж все решили использовать LE, то давайте постепенно убивать BE.
mentin
Хуже когда встречаются деятели которые говорят "давайте поддержим все", и с разными объяснениями создают формат где поддерживается и LE и BE. В начале файла обычно байтик, позволяющий различать что прислали.
Особые извращенцы (не будем все показывать на OGC пальцем) вставляют этот байтик перед каждым полем в файле, типа можно писать то BE, то LE в пределах одной записи.