Comments 68
Я всё жду, когда же интернет протоколы поправят. Ну и крипто-алгоритмы заодно.
Я пока ipv17 жду. Думаю после него можно будет протоколы полностью поправить.
Хм, легаси же. Вроде форматы изображений тоже используют BE. Хотя, имхо, этот зоопарк с LE и BE вносит ненужную фрагментацию и сложности. Если уж все решили использовать LE, то давайте постепенно убивать BE.
Хуже когда встречаются деятели которые говорят "давайте поддержим все", и с разными объяснениями создают формат где поддерживается и LE и BE. В начале файла обычно байтик, позволяющий различать что прислали.
Особые извращенцы (не будем все показывать на OGC пальцем) вставляют этот байтик перед каждым полем в файле, типа можно писать то BE, то LE в пределах одной записи.
Вы за всех не говорите. IBM, например, не решила
Для тех, кто в танке, пожалуйста. Если RISC-V - запутанная, то есть ли незапутанная архитектура?
Нету. ARM, например, бывают и LE (большинство), и BE (меньшинство, но именно их ставят во всякое там сетевое оборудование); довольно многие могут "на лету" переключать порядок следования байтов...
И вообще, непонятна сия истерика ЛТ: BE встречается не так уж и редко, и использующие его процы системой поддерживаются, так какая проблема добавить ещё один такой проц?
Проблема в том, что предложенные ему коммиты были гуано эйпсов с первого же взгляда.
Ну и, возможно, ужос перед всеми случаями типа "8 байт числа memcpy-нули в unsigned long для удобства работы" (недавно такое разбирал из 1994 года), которые от таких фокусов ломаются, хотя их и не должно быть в популярном софте.
Ну так низкое качество кода -- не повод отказываться от поддержки чего-то там. Если на то пошло, само ядро Линуха, как и любой крупный проект, -- тоже та ещё свалка дерьма (а иначе они бы не ломали в каждой большой версии совместимость с драйверами из более ранних версий).
"8 байт числа memcpy-нули в unsigned long для удобства работы" (недавно такое разбирал из 1994 года)
Нельзя слегка поподробнее? Ну или ссылку, где сие описано. Просто интересно знать, что за проблема такая всплыла.
Про качество ядра Линукс - драйвера ломаются те, которые out of tree, и это фича а не баг.
Идеального проектирования на все случаи жизни не существует, а обратная совместимость - особенно внутри ядра - имеет очень разную цену для бесплатного (Линух) и платного (например, Винда) продуктов.
Ну и отдельно хочу напомнить, что юзерспейс Линух особо не ломает. Был бы интересный эксперимент, взять какой-нибудь центос 5 или 6, и для него собрать и настроить ядро 6.х. Я почти уверен, что остальная система замену ядра с модулями не заметит.
Юзерспейс завязан на libc, а libc завязана на ядро. Так что очень даже заметит
Был бы интересный эксперимент
Этот эксперимент, может, не с такими различиями в версиях, проводят тысячи людей ежедневно, запуская старые системы в докере. До 10-летней давности бывает систематически, больше - иногда. У меня фидошный софт сборки 2004 года, от FreeBSD4 на современной 14-й (но тут надо пакет библиотек совместимости ставить, а одну так тянуть за собой через апгрейды); да, это не линукс, но картина схожая.
Цена универсальности. На RISC-V можно сделать и простенький чип для роутера, и здоровенный процессор для серверов или вычислительных кластеров. Достигается тем, что есть базовая система, а есть расширения.
То есть там не архитектура сама по себе сложная, просто обозначение RISC-V само по себе недостаточно для однозначного определения архитектуры конкретного чипа.
А так есть и незапутанные в этом смысле архитектуры - скажем, те, на которых только одна линейка процессоров в принципе сделана.
Основная проблема подхода RISC-V - невозможно писать сколько-нибудь предсказуемый по производительности и переносимый софт.
К каждому бинарню под RISC-V должна где-то идти инструкция, на каких процессорах оно может запуститься. Это просто дикий ужас.
Вот с этим я, в общем и целом, соглашусь. Но, как по мне, достаточно внедрить в Линух поддержку лишь определённого подмножества всех возможных вариантов сей архитектуры.
Очевидно, например, что никакой "настоящий" Уних, а значит, и Линух невозможен без виртуальной памяти, что требует наличия MMU -- т.е. микроконтроллеры сразу идут лесом (как это имеет место и на, скажем, ARM: Линух работает на архитектурах ARMv7-A, 8-A, 9-A, но никак не на -R или -M -- на них бывают лишь нестандартные "огрызки" типа ucLinux). Соответственно, это прописывается как безусловное требование к поддержке.
То же самое можно сказать и относительно набора команд: вполне разумно требовать наличия тех расширений, без которых невозможна эффективная реализация ядра ОС (скажем, связанных с семафорами, барьерами и прочим для многопроцессорных систем), но глупо объявлять обязательными расширения для всяких там нейросетей и прочие специализированные прикладные фишки.
К каждому бинарню
runtime dispatching позволяет бинарю использовать хоть AVX512, при этом поддерживая fallback для старых процессоров.
С одной стороны мы сейчас имеем неформальные "наборы" инструкций x86-64v2 / v3 и т.п. С другой, был Clean Linux, который сразу скомпилирован под свежие процессоры, а не "самый старый x86-64", чтобы везде-везде запускалось. Поэтому устаканится где-то посередине, а вендор на то и вендор, чтобы вендорить :) (и вообще, с открытый исходный код скомпилировал для целевой машины и все (: )
Всё бы хорошо, но сколько таких наборов инструкций у intel? Они появлялись в версиях архитектур сразу пачками, и дай боже наберётся 4 "поколения". Плюс, RISC-V позволяет иметь (и они существуют) проприоретарные расширения + некоторые наборы инструкций были реализованы до стандартизации и выглядят "почти также, но не так".
И там десятки расширений. Не, в целом-то понятно, что условный cpuid в помощь, пишите софт, диспетчеризуйте вызовы и вот это все, но это усложняет разработку - раз. Ибо комбинаторный взрыв имеет место быть и отладка всех сценариев будет дико дорогой.
Делает невозможным предсказать запустится ли такой софт у потребителя, а если запустится, то с какой производительностью.
В общем и целом, пока RISC-V не перестанут играть в лего, эта архитектура так и останется нишевой, ориентированной на разработку под заказ. CPU общего назначения на ней не изобрести
Согласен, но считаю общий знаменатель найдется. А массовость в ближайшие 20 лет обеспечивать нечем: у ARM были телефоны.
Плюс, RISC-V позволяет иметь (и они существуют) проприоретарные расширения + некоторые наборы инструкций были реализованы до стандартизации и выглядят "почти также, но не так".
Всю эту проприетарщину не загоняют в код ядра. Могут в отдельные драйверы, не более.
Делает невозможным предсказать запустится ли такой софт у потребителя, а если запустится, то с какой производительностью.
У кастомного процессора под конкретную железку - потребитель один и чётко определён.
Если же кому-то продадут лаптоп с убунтой, там будут совершенно конкретные наборы особенностей - грубо говоря, RV64GV.
Читать мануал по ISA действительно страшновато, но надо уметь понимать, читая его, что будет в конкретном случае. И есть отдельно спеки на "профили", вот эти профили и надо смотреть, а не каждое какое-нибудь ZabcdTRex20Reptile+.
CPU общего назначения на ней не изобрести
Давно сделали. Но потребность рынка не сформировалась, поэтому надо явно искать, где купить.
Этим он ничем не отличился по сравнению, например, с ARM/32. Вообще весь embedded такой. Завтра вам вместо микросхемы управления двигателем, условно, ABC123 поставят PQR456, а у неё другие регистры, коэффициенты и вообще неонка внутре другого цвета. Всё, переписывай что-то, причём "на вчера", потому что контейнеровоз уже заканчивают загружать. Вместо STM32QQQ27PQR250 дают STM32QQQ26PQR240B, а у него некоторые команды Neon медленнее на два такта, и у вас начались мелькания на экране. И тэ дэ и тэ пэ.
А вот "инструкция", о которой вы говорите, представлена в виде опций поддержки в самом бинарнике, средствами расширений ELF (ну, по крайней мере, они стараются загнать всё туда).
Сейчас даже X86 менее запутанна, чем RISC-V. Авторы последней придумали 100500 расширений, из которых часть уже несовместимы друг с другом, и без механизма их надёжной идентификации. Самый главный набор детектируется по битам в сервисном регистре, а вот для прочих устойчивого гарантированного метода просто нет, не завезли. По сравнению с этим кошмарик cpuid в x86 выглядит прилично.
у 4004 достаточно простая система команд
RISC‑V и так уже достаточно запутанная архитектура
RISC-V не архитектура, а ISA. Архитектуру можно создать с любой степенью запутанности.
не архитектура, а ISA
Подскажите, а что означает буковка А в аббревиатуре ISA?
Тут имеется в виду даже не сама архитектура RISC-V, а запутанность кода и конфигов для ее поддержки в ядре из-за кучи вариантов конфигурации ISA, ядер и периферии.
Периферия к архитектуре процессора относится вообще чуть более чем никак: один и тот же периферийный контроллер можно прикрутить (либо вообще без переделок, либо с минимальными переделками) и к ARM, и к MIPS, и к RISC-V, и даже к IA-32/AMD64, особняком стоят только IBMовские мэйнфреймы (z/Architecture) из-за принципиально иной организации ввода-вывода.
Насчёт кучи вариантов поддержки тех или иных расширений... По большому счёту, ядру нужно лишь знать про то, какие регистры процессора надо сохранять/восстанавливать при переключении процессов/потоков/задач, как устроено MMU и ряд подобных вещей; ему вовсе не требуется знать про наличие/отсутствие расширений системы команд, прямо не влияющих на набор регистров (это разработчикам компиляторов это нужно знать и учитывать, чтобы генерировать код, наиболее оптимальный для конкретного процессора). Все такие вещи являются зависящими от архитектуры и реализуются специфичными для неё модулями, которые не должны сколько-нибудь "стратегически" влиять на код ОС в целом.
Периферия к архитектуре процессора относится вообще чуть более чем никак: один и тот же периферийный контроллер можно прикрутить (либо вообще без переделок, либо с минимальными переделками) и к ARM, и к MIPS, и к RISC-V, и даже к IA-32/AMD64, особняком стоят только IBMовские мэйнфреймы (z/Architecture) из-за принципиально иной организации ввода-вывода.
Да, но Linux поддерживает конкретные процессоры с конкретной периферией и Линус тут имеет в виду, что для RISC-V из-за открытости приходится поддерживать кучу таргетов с разной нестандартной периферией, хаками для багов обхода хардварной имплементации и тд.
По большому счёту, ядру нужно лишь знать про то какие регистры процессора надо сохранять/восстанавливать при переключении процессов/потоков/задач, как устроено MMU и ряд подобных вещей;
Ну вот у вас есть 100500 RISC-V процессоров с разным набором регистров, разными MMU, контроллерами прерываний и периферией, а тут еще LE/BE надо учитывать.
Периферия -- это драйверы, а соответственно, забота не команды, занимающейся собственно Линухом (ядром), а производителей процессоров, содержащих эту периферию.
Регистры же... Не думаю, что там будет 100500 вариантов -- скорей, всё сведётся к всего нескольким дефайнам для условной трансляции модулей, отвечающих за поддержку архитектуры и абсолютно никак не будет влиять на ядро в целом. Но это надо погружаться в тему, чтоб сказать наверняка.
Периферия -- это драйверы, а соответственно, забота не команды, занимающейся собственно Линухом (ядром), а производителей процессоров, содержащих эту периферию.
Любой код в mainline это в том числе забота команды ядра. Кроме обычного мержа патчей от вендоров, так же бывают глобальные изменения(например введение device tree), которые требуют поменять кучу вендорского кода и это ложится на этих самых людей. Поэтому Линус и так критичен к изменениям, а многие вендоры железа имеют свои форки со старой версией ядра - чтобы избежать требовательного мержа в mainline и портирования на его новые версии.
Довольно смешная позиция. Если бы ядро не занималось поддержкой зоопарка периферии, а всерьёз полностью переложило бы это на производителей, линукс за пределы университетов бы не вышел никогда.
Вообще, MS не разрабатывает дрова видюх и другой сложной периферии, которая плохо стандартизирована (или вообще никак не стандартизирована) -- и ничё, живут как-то. Кроме того, сейчас у разработчика некоего процессора стоит вопрос: либо он обеспечивает совместимость с Линухом, а значит, предоставляет необходимые драйверы, либо уже он, а не Линух, идёт куда подальше.
Хорошо, что вы смягчили позицию. Не просто периферия, а не стандартизированная периферия. Сравнение с MS тоже уместно - показывает, что важна доля рынка.
Ну так у Линуха сейчас доля рынка во всяких промышленных компьютерах и прочих Малинках близка к 100% -- примерно как у Винды на обычных ПК. А соответственно, его разработчикам давно уже не требуется заботиться о поддержке каждого чиха того или иного процессора. Хочет сообщество RISC-V полноценной поддержки в Линухе -- пускай само пишет все необходимые драйверы и т.д. и т.п., опираясь на исходники обычного "стандартного" ядра. Ну а не сделает этого -- у них не будет шансов на успешную конкуренцию с, скажем, ARM, за исключением микроконтроллерного сегмента, где Линуху просто не место -- там либо голое железо, либо недосистемы вроде FreeRTOS.
В Windows все совсем не так - там есть стабильный интерфейс между ядром и драйверами, который не меняется десятилетиями. В Linux же часто для поддержки нового оборудования нужно пересобирать ядро, а бинарная совместимость с драйверами регулярно ломается, требуя пересборки и драйверов тоже.
В Windows все совсем не так - там есть стабильный интерфейс между ядром и драйверами, который не меняется десятилетиями.
Он менялся несколько раз в ключевых подсистемах.
В Linux же часто для поддержки нового оборудования нужно пересобирать ядро, а бинарная совместимость с драйверами регулярно ломается, требуя пересборки и драйверов тоже.
Задача сохранения совместимости тут возложена на авторов дистрибутивов, которые держат один интерфейс на несколько версий в течение заметного периода (5-10 лет).
Напомню из за чего все это началось, вся эта проблема байтов. Давным давно, в процессоре интел, придумали оптимизацию, загружать байты задом наперед, чтобы их можно было удобнее и быстрее складывать. И вот с тех пор мы имеем такой гемор во всей индустрии.
Порядок "младший-старший" был реализован, как минимум, ещё в PDP-11 -- а это 1969-й год, т.е. существенно раньше, чем появился 8086. Что касается порядка "старший-младший", то он возник одновременно с делением машинного слова на байты -- в IBM System/360, 1964 год. Так что всё это возникло совершенно без участия Интел и без всякой оглядки на подобные оптимизации.
Ваш оппонент почти полностью прав прав, LE для 8080 был "изобретён" независимо от PDP-11, 6502 и прочих предшественников, как локальная микрооптимизация. Про это есть воспоминания его разработчика с высказыванием сожаления об этом решении. С ходу ссылку не нашёл, но она широко известна. Ну а дальше именно популярность x86 (через IBM PC) способствовала продвижению LE, вплоть до того, что в RISC-V назначили его базовым вариантом (и про это есть утверждения авторов), командный поток там всегда в LE.
Не для 8080 (который 8-разрядный), а для 8086/8088, тогда уже. И не изобретён: сам порядок байтов LE к тому времени уже достаточно длительное время использовался. Оптимизацию под него придумали -- это вполне возможно и разумно, но не более того.
С популярностью тоже есть вопросы. В частности, до массового распространения IBM PC и его клонов, самой популярной архитектурой, получившей широчайшее распространение, тоже была LE -- в виде PDP-11. Тот же ARM возник не шибко позже появления IBM PC -- в 1984-м, если память не изменяет, и основным вариантом был LE. Ну и т.д. и т.п. Так что не думаю, что именно ПК от IBM в одиночку сыграли роль в доминировании именно LE -- но определённо сыграли такую роль для многих современных ИТшников, считающих этот порядок "единственно верным".
Не для 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". Это хорошо видно по, например, организации виртуальной памяти.
в 8080 LE не даёт никакого преимущества (но и недостатков тоже). Вот в 6502 даёт преимущество а в 6800 BE даёт недостаток.
задом-наперед - это Big Endian
А LE как раз логичен - младшие разряды в байте с младшим адресом
У BE только одно оправдание: похож на то, как мы пишем цифры - сначала старшие разряды, потом младшие. Проблема правда в том, что цифры мы пишем по арабски (справа налево) при привычном письме, ещё с греков, слева направо.
Злые языки утверждают, что с греков-то это задом-наперед и началось: они финикиские письмена (которые писались справа-налево) на просвет читали.
BE столь же логичен. И вообще, нет никакой реальной разницы, дело лишь в привычке. Я в своё время с лёгкостью переходил от СМ ЭВМ (PDP-11) с LE и восьмеричной системой на ЕС ЭВМ (System/370) с BE и шестнадцатеричной системой и обратно -- вообще никаких проблем не испытывал.
Но ведь когда мы числа на бумаге пишем, мы сначала старшие разряды пишем, разве нет? А это BЕ. Почему вдруг LE логичнее стало? Из-за этого BE намного удобнее, когда raw-дампы памяти в hex-виде смотришь. Тогда все числа видны, как они есть, независимо от размера типов данных. Любую структуру смотришь, и всё очевидно. А если машина в LE, то все значения в уме переворачивать нужно, и размеры всех типов знать обязательно, чтобы правильно перевернуть. Как человек, постоянно работающий и с BE, и с LE машинами, считаю BE прям сильно более удобным в этом плане.
Но ведь когда мы числа на бумаге пишем, мы сначала старшие разряды пишем, разве нет?
Потому что мы их пишем справа-налево, как арабы
Именно. Для тех, кто пишет разряды в числах справа налево, а сами числа слева направо, использование BE выглядит логичным, потому что это оно и есть. И не нужно лишний раз ломать мозг при визуальном парсинге данных, для него другой работы найдётся.
справа-налево, как арабы
Это неправда. Писать числа в десятичной позиционной системе начали индийцы, а у них запись слева направо. Арабы только позаимствовали подход, не меняя порядка цифр в физической записи. Европейцы, приняв у арабов, сохранили физический порядок, фактически восстановив (ещё этого не зная) исходный индийский порядок. Пожалуйста, не повторяйте эти глупые мифы про "арабский" порядок.
Кстати, и цифры некорректно называть арабскими. Их точная форма на момент заимствования была другой, и сейчас есть "южноарабский" отдельный вариант. Вот в Юникоде исходные цифры: ٠١٢٣٤٥٦٧٨٩ - ну как, похоже? Правильнее всего называть наши современные цифры итальянскими (или имени Фибоначчи, это он "притащил" их в христианскую Европу, форма сохраняется в его варианте).
Впервые встречаю человека, пишущего числа справа налево. Чего только не бывает.
Как раз наоборот - в BE, пока мы не знаем длину слова, мы вообще не знаем веса разрядов, когда начинаем их читать с меньших адресов.
В LE всё очевидно. Сначала байт с весом 1 , потом с весом 256 ...
А если длинная арифметика с числами переменной длины, то в BE - вообще вешалки...
А если длинная арифметика с числами переменной длины, то в BE - вообще вешалки...
Абсолютно никаких проблем, поскольку такая арифметика реализуется не чисто аппаратными средствами, а чисто программными, и абсолютно ничто не мешает именно для таких чисел хранить байты в порядке "младший-старший" -- всё равно их интерпретацию (как чисел переменной длины) осуществляет программа, а не процессор (для которого таких чисел попросту нет -- если не рассматривать весьма специфические случаи вроде десятичных чисел на мэйнфреймах IBM).
в BE, пока мы не знаем длину слова, мы вообще не знаем веса разрядов, когда начинаем их читать с меньших адресов.
И какая польза была бы в том, что мы "знали" бы вес разрядов?
А если длинная арифметика с числами переменной длины, то в BE - вообще вешалки...
Никаких "вешалок". Два индекса вместо одного, или смещение к одному из индексов. Чуть-чуть менее удобно, но подъёмно без проблем.
А LE как раз логичен - младшие разряды в байте с младшим адресом
И что с того? В этом нет никакого явного преимущества, если смотреть и на дизайн "железа", и на поведение софта. В одном случае лучше одно, в другом - другое.
Вот пример: числа переменной длины в памяти (частые во многих форматах), старший бит определяет, последний байт или нет. Когда записывается такое число в память, чуть меньше возни при LE формате: выделил семь бит, сдвинул вправо, проверил, ноль или нет, пошёл дальше. (Со знаковыми чуть сложнее, но тоже подходит.) А собирать его обратно надо фактически с конца. Зато при BE сложнее записывать (фактически, надо записать в стиле LE и потом развернуть), зато читать легче - на каждый байт сдвиг и побитовое "или". Поэтому форматы [u]leb128 в DWARF - глупость, там отладчик читает сотни раз на одну запись в генераторе в компиляторе, надо было BE.
А вот "длинную арифметику" чуть-чуть проще в LE, там на одну переменную индекса получается меньше при операциях типа сложения-вычитания.
Не будет тут универсальности, не надейтесь.
1. Простота и скорость сравнения чисел (на аппаратном уровне)
Представьте, что вам нужно сравнить два 32-битных числа, поступающих по сети (в BE). В BE они передаются байт за байтом, от старшего к младшему.
· На BE-процессоре (например, в сетевом маршрутизаторе):
· Сравнивается первый (старший) байт числа A и число B.
· Если они разные — всё, результат ясен сразу. Можно даже не дожидаться приема остальных байтов и начинать маршрутизацию пакета.
· Это похоже на сравнение строк: "5000" и "4000" — первая же цифра дает ответ.
· На LE-процессоре:
· Чтобы сравнить числа так же эффективно, ему пришлось бы либо:
1. Ждать, пока все байты не будут приняты и реконвертированы в LE, и только потом сравнивать. Это добавляет задержку (латентность).
2. Сравнивать байты в обратном порядке, начиная с последнего принятого байта, что усложняет логику.
Вывод: Для задач, где критична скорость последовательной обработки потоков данных (сетевые пакеты, потоки данных), BE эффективнее на аппаратном уровне.
Психологический и исторический аспект
BE часто называют "сетевым порядком" (Network Byte Order) не просто так. На заре интернета инженеры, проектировавшие протоколы, мыслили именно в терминах последовательных потоков данных, где старшие, самые значимые части идут первыми. Это интуитивно согласуется с BE.
Итог: Аналогия
Представьте два завода:
· Завод BE: Детали на конвейере едут в том порядке, в котором они будут собраны в готовое изделие (колесо -> ось -> рама). Сборщик в начале линии сразу видит, что собирается автомобиль, а не велосипед.
· Завод LE: Детали едут в обратном порядке (рама -> ось -> колесо). Чтобы понять, что собирается, сборщику нужно либо дождаться всей партии деталей, либо мысленно перевернуть весь процесс.
Ждать, пока все байты не будут приняты
Так это в любом случае надо, чтобы проверить чексумму, не?
Это ХабрГПТ еще и не знает, что процессоры обрабатывают байты не по одному, а машинными словами.
Для раутеров всё совсем не так, чем толще, тем больше специфика.
Ещё в 1990-х, Cisco Catalyst 19xx серий как раз умел начинать раутинг ещё по не до конца полученному адресу. То же умели 3comʼы примерно тех же времён, модели не помню, но мне на курсах это рассказывали.
И никто процессоры общего пользования в линейные процессоры карт не ставит (пардон, и там и тут "процессоры", но идея должна быть понятна), там специализированные ASICʼи с табличной логикой для быстрого разбрасывания, и чем толще раутер, тем эти процессоры "толще" и специальнее. Им как раз вписать принятие решения по неполному адресу просто и полезно. Например, такой процессор в раутере Core-уровня не будет из IPv6 адреса разбирать что-то дальше первых 4 байт (октетов), на основе принципа, что PA и PI получают блоки /32; если нужно хотя бы по 6 байтам, то это уже не Core, а Distribution тип железки. А чтобы по последним 8 - так это только на конкретном собственном интерфейсе уже финального хопа.
Так что в случае процессоров общего пользования вы, конечно, были бы правы, но именно для сетевой маршрутизации - нет, советую "изучить матчасть" (™).
Не.
1. В достаточно "толстом" раутере, да, может быть кадр принят целиком для проверки чексуммы, но этим занимается тупой ASIC на плате. А дальше включается логика раутинга, и вот в ней даже внутренние передачи между процессорами карт и/или центральными раутерными (это разные!) могут подчиняться логике опознания по началу адреса. Поэтому и IPv4, и IPv6 адреса представлены как BE, и это не хотели менять при создании v6.
2. Вполне может быть "оптимистичная" логика, когда кадр передаётся на выход ещё не принятый до конца, но если обнаруживается, что битый, то передача прерывается. Тут уже от вендора зависит. Я помню с ISPшных времён, что Cisco где-то при переходе от 19xx к 25xx, 35xx и т.п. это отменяла, оставив только store-and-forward, а CatOSʼные каталисты вообще этого не умели изначально, но что у других вендоров - ХЗ, могли и применить.
В целом, да, в большинстве случаев, скорее всего, сейчас тотальный store-and-forward, при котором уже неважно, но на 100% я не буду ручаться.
Печалька. 35% посетителей хабра не знают что такое LE/BE. Всё более не айти ресурс(
LE/BE, да какая разница. А вот память, она идёт слева направо? Или сверху вниз? Или может наоборот, снизу вверх? Вот действительно важные вопросы.
Линус Торвальдс жёстко отверг поддержку big-endian RISC-V