Не для 8080 (который 8-разрядный), а для 8086/8088, тогда уже. И не изобретён: сам порядок байтов LE к тому времени уже достаточно длительное время использовался. Оптимизацию под него придумали -- это вполне возможно и разумно, но не более того.
С популярностью тоже есть вопросы. В частности, до массового распространения IBM PC и его клонов, самой популярной архитектурой, получившей широчайшее распространение, тоже была LE -- в виде PDP-11. Тот же ARM возник не шибко позже появления IBM PC -- в 1984-м, если память не изменяет, и основным вариантом был LE. Ну и т.д. и т.п. Так что не думаю, что именно ПК от IBM в одиночку сыграли роль в доминировании именно LE -- но определённо сыграли такую роль для многих современных ИТшников, считающих этот порядок "единственно верным".
А если длинная арифметика с числами переменной длины, то в BE - вообще вешалки...
Абсолютно никаких проблем, поскольку такая арифметика реализуется не чисто аппаратными средствами, а чисто программными, и абсолютно ничто не мешает именно для таких чисел хранить байты в порядке "младший-старший" -- всё равно их интерпретацию (как чисел переменной длины) осуществляет программа, а не процессор (для которого таких чисел попросту нет -- если не рассматривать весьма специфические случаи вроде десятичных чисел на мэйнфреймах IBM).
BE столь же логичен. И вообще, нет никакой реальной разницы, дело лишь в привычке. Я в своё время с лёгкостью переходил от СМ ЭВМ (PDP-11) с LE и восьмеричной системой на ЕС ЭВМ (System/370) с BE и шестнадцатеричной системой и обратно -- вообще никаких проблем не испытывал.
Ну так у Линуха сейчас доля рынка во всяких промышленных компьютерах и прочих Малинках близка к 100% -- примерно как у Винды на обычных ПК. А соответственно, его разработчикам давно уже не требуется заботиться о поддержке каждого чиха того или иного процессора. Хочет сообщество RISC-V полноценной поддержки в Линухе -- пускай само пишет все необходимые драйверы и т.д. и т.п., опираясь на исходники обычного "стандартного" ядра. Ну а не сделает этого -- у них не будет шансов на успешную конкуренцию с, скажем, ARM, за исключением микроконтроллерного сегмента, где Линуху просто не место -- там либо голое железо, либо недосистемы вроде FreeRTOS.
Вообще, MS не разрабатывает дрова видюх и другой сложной периферии, которая плохо стандартизирована (или вообще никак не стандартизирована) -- и ничё, живут как-то. Кроме того, сейчас у разработчика некоего процессора стоит вопрос: либо он обеспечивает совместимость с Линухом, а значит, предоставляет необходимые драйверы, либо уже он, а не Линух, идёт куда подальше.
Вот с этим я, в общем и целом, соглашусь. Но, как по мне, достаточно внедрить в Линух поддержку лишь определённого подмножества всех возможных вариантов сей архитектуры.
Очевидно, например, что никакой "настоящий" Уних, а значит, и Линух невозможен без виртуальной памяти, что требует наличия MMU -- т.е. микроконтроллеры сразу идут лесом (как это имеет место и на, скажем, ARM: Линух работает на архитектурах ARMv7-A, 8-A, 9-A, но никак не на -R или -M -- на них бывают лишь нестандартные "огрызки" типа ucLinux). Соответственно, это прописывается как безусловное требование к поддержке.
То же самое можно сказать и относительно набора команд: вполне разумно требовать наличия тех расширений, без которых невозможна эффективная реализация ядра ОС (скажем, связанных с семафорами, барьерами и прочим для многопроцессорных систем), но глупо объявлять обязательными расширения для всяких там нейросетей и прочие специализированные прикладные фишки.
Периферия -- это драйверы, а соответственно, забота не команды, занимающейся собственно Линухом (ядром), а производителей процессоров, содержащих эту периферию.
Регистры же... Не думаю, что там будет 100500 вариантов -- скорей, всё сведётся к всего нескольким дефайнам для условной трансляции модулей, отвечающих за поддержку архитектуры и абсолютно никак не будет влиять на ядро в целом. Но это надо погружаться в тему, чтоб сказать наверняка.
Порядок "младший-старший" был реализован, как минимум, ещё в PDP-11 -- а это 1969-й год, т.е. существенно раньше, чем появился 8086. Что касается порядка "старший-младший", то он возник одновременно с делением машинного слова на байты -- в IBM System/360, 1964 год. Так что всё это возникло совершенно без участия Интел и без всякой оглядки на подобные оптимизации.
Периферия к архитектуре процессора относится вообще чуть более чем никак: один и тот же периферийный контроллер можно прикрутить (либо вообще без переделок, либо с минимальными переделками) и к ARM, и к MIPS, и к RISC-V, и даже к IA-32/AMD64, особняком стоят только IBMовские мэйнфреймы (z/Architecture) из-за принципиально иной организации ввода-вывода.
Насчёт кучи вариантов поддержки тех или иных расширений... По большому счёту, ядру нужно лишь знать про то, какие регистры процессора надо сохранять/восстанавливать при переключении процессов/потоков/задач, как устроено MMU и ряд подобных вещей; ему вовсе не требуется знать про наличие/отсутствие расширений системы команд, прямо не влияющих на набор регистров (это разработчикам компиляторов это нужно знать и учитывать, чтобы генерировать код, наиболее оптимальный для конкретного процессора). Все такие вещи являются зависящими от архитектуры и реализуются специфичными для неё модулями, которые не должны сколько-нибудь "стратегически" влиять на код ОС в целом.
Ну так низкое качество кода -- не повод отказываться от поддержки чего-то там. Если на то пошло, само ядро Линуха, как и любой крупный проект, -- тоже та ещё свалка дерьма (а иначе они бы не ломали в каждой большой версии совместимость с драйверами из более ранних версий).
"8 байт числа memcpy-нули в unsigned long для удобства работы" (недавно такое разбирал из 1994 года)
Нельзя слегка поподробнее? Ну или ссылку, где сие описано. Просто интересно знать, что за проблема такая всплыла.
Нету. ARM, например, бывают и LE (большинство), и BE (меньшинство, но именно их ставят во всякое там сетевое оборудование); довольно многие могут "на лету" переключать порядок следования байтов...
И вообще, непонятна сия истерика ЛТ: BE встречается не так уж и редко, и использующие его процы системой поддерживаются, так какая проблема добавить ещё один такой проц?
Потому что скорость расчёта в "десятичном текстовом" виде будет многократно меньше, чем при естественном для машины двоичном числовом, а схемы для всего этого будут существенно сложней.
Скорей всего, причина в том, что автор использует инструменты, которые сами заточены на реальный режим. Винда с помощью режима V86 может эмулировать ДОС, но поддержка V86 выпилена из 64-разрядного режима процессора; соответственно, если работа идёт под 64-разрядной Виндой, гонять ДОСовские программы прямо из-под Винды невозможно (только ставить ДОС на виртуальную машину или там какой ДОСБох использовать).
Особого смысла в их хранении отдельно нет. Проще хранить всю сумму не в рублях, а в копейках (или там в десятых/сотых копейки -- зависит от конкретных требований).
Ещё от архитектуры процессора зависит. Мэйнфреймы IBM от самого своего рождения (Система 360, 1964 год) имеют поддержку двоично-десятичных чисел (до 31 десятичной цифры плюс знак), и на них "экономическая" информация естественным образом считается в десятичной системе. Вот на ПК (IA-32, AMD64 -- неважно) или, скажем, на ARM любой разновидности такие вещи приходится считать, используя целочисленную арифметику; плавающая запятая -- лишь для задач, где ошибки округления приемлемы (скажем, научные расчёты: там не обязательно, чтоб последняя циферка сходилась, достаточно лишь обеспечить необходимую точность).
Собрать все вантузы в Фоллауте -- это святое! :)
скорей, как понос сознания...
Не для 8080 (который 8-разрядный), а для 8086/8088, тогда уже. И не изобретён: сам порядок байтов LE к тому времени уже достаточно длительное время использовался. Оптимизацию под него придумали -- это вполне возможно и разумно, но не более того.
С популярностью тоже есть вопросы. В частности, до массового распространения IBM PC и его клонов, самой популярной архитектурой, получившей широчайшее распространение, тоже была LE -- в виде PDP-11. Тот же ARM возник не шибко позже появления IBM PC -- в 1984-м, если память не изменяет, и основным вариантом был LE. Ну и т.д. и т.п. Так что не думаю, что именно ПК от IBM в одиночку сыграли роль в доминировании именно LE -- но определённо сыграли такую роль для многих современных ИТшников, считающих этот порядок "единственно верным".
Абсолютно никаких проблем, поскольку такая арифметика реализуется не чисто аппаратными средствами, а чисто программными, и абсолютно ничто не мешает именно для таких чисел хранить байты в порядке "младший-старший" -- всё равно их интерпретацию (как чисел переменной длины) осуществляет программа, а не процессор (для которого таких чисел попросту нет -- если не рассматривать весьма специфические случаи вроде десятичных чисел на мэйнфреймах IBM).
BE столь же логичен. И вообще, нет никакой реальной разницы, дело лишь в привычке. Я в своё время с лёгкостью переходил от СМ ЭВМ (PDP-11) с LE и восьмеричной системой на ЕС ЭВМ (System/370) с BE и шестнадцатеричной системой и обратно -- вообще никаких проблем не испытывал.
Ну так у Линуха сейчас доля рынка во всяких промышленных компьютерах и прочих Малинках близка к 100% -- примерно как у Винды на обычных ПК. А соответственно, его разработчикам давно уже не требуется заботиться о поддержке каждого чиха того или иного процессора. Хочет сообщество RISC-V полноценной поддержки в Линухе -- пускай само пишет все необходимые драйверы и т.д. и т.п., опираясь на исходники обычного "стандартного" ядра. Ну а не сделает этого -- у них не будет шансов на успешную конкуренцию с, скажем, ARM, за исключением микроконтроллерного сегмента, где Линуху просто не место -- там либо голое железо, либо недосистемы вроде FreeRTOS.
Вообще, MS не разрабатывает дрова видюх и другой сложной периферии, которая плохо стандартизирована (или вообще никак не стандартизирована) -- и ничё, живут как-то. Кроме того, сейчас у разработчика некоего процессора стоит вопрос: либо он обеспечивает совместимость с Линухом, а значит, предоставляет необходимые драйверы, либо уже он, а не Линух, идёт куда подальше.
Вот с этим я, в общем и целом, соглашусь. Но, как по мне, достаточно внедрить в Линух поддержку лишь определённого подмножества всех возможных вариантов сей архитектуры.
Очевидно, например, что никакой "настоящий" Уних, а значит, и Линух невозможен без виртуальной памяти, что требует наличия MMU -- т.е. микроконтроллеры сразу идут лесом (как это имеет место и на, скажем, ARM: Линух работает на архитектурах ARMv7-A, 8-A, 9-A, но никак не на -R или -M -- на них бывают лишь нестандартные "огрызки" типа ucLinux). Соответственно, это прописывается как безусловное требование к поддержке.
То же самое можно сказать и относительно набора команд: вполне разумно требовать наличия тех расширений, без которых невозможна эффективная реализация ядра ОС (скажем, связанных с семафорами, барьерами и прочим для многопроцессорных систем), но глупо объявлять обязательными расширения для всяких там нейросетей и прочие специализированные прикладные фишки.
Периферия -- это драйверы, а соответственно, забота не команды, занимающейся собственно Линухом (ядром), а производителей процессоров, содержащих эту периферию.
Регистры же... Не думаю, что там будет 100500 вариантов -- скорей, всё сведётся к всего нескольким дефайнам для условной трансляции модулей, отвечающих за поддержку архитектуры и абсолютно никак не будет влиять на ядро в целом. Но это надо погружаться в тему, чтоб сказать наверняка.
Порядок "младший-старший" был реализован, как минимум, ещё в PDP-11 -- а это 1969-й год, т.е. существенно раньше, чем появился 8086. Что касается порядка "старший-младший", то он возник одновременно с делением машинного слова на байты -- в IBM System/360, 1964 год. Так что всё это возникло совершенно без участия Интел и без всякой оглядки на подобные оптимизации.
Периферия к архитектуре процессора относится вообще чуть более чем никак: один и тот же периферийный контроллер можно прикрутить (либо вообще без переделок, либо с минимальными переделками) и к ARM, и к MIPS, и к RISC-V, и даже к IA-32/AMD64, особняком стоят только IBMовские мэйнфреймы (z/Architecture) из-за принципиально иной организации ввода-вывода.
Насчёт кучи вариантов поддержки тех или иных расширений... По большому счёту, ядру нужно лишь знать про то, какие регистры процессора надо сохранять/восстанавливать при переключении процессов/потоков/задач, как устроено MMU и ряд подобных вещей; ему вовсе не требуется знать про наличие/отсутствие расширений системы команд, прямо не влияющих на набор регистров (это разработчикам компиляторов это нужно знать и учитывать, чтобы генерировать код, наиболее оптимальный для конкретного процессора). Все такие вещи являются зависящими от архитектуры и реализуются специфичными для неё модулями, которые не должны сколько-нибудь "стратегически" влиять на код ОС в целом.
Ну так низкое качество кода -- не повод отказываться от поддержки чего-то там. Если на то пошло, само ядро Линуха, как и любой крупный проект, -- тоже та ещё свалка дерьма (а иначе они бы не ломали в каждой большой версии совместимость с драйверами из более ранних версий).
Нельзя слегка поподробнее? Ну или ссылку, где сие описано. Просто интересно знать, что за проблема такая всплыла.
Нету. ARM, например, бывают и LE (большинство), и BE (меньшинство, но именно их ставят во всякое там сетевое оборудование); довольно многие могут "на лету" переключать порядок следования байтов...
И вообще, непонятна сия истерика ЛТ: BE встречается не так уж и редко, и использующие его процы системой поддерживаются, так какая проблема добавить ещё один такой проц?
Тогда даже шутка была: какой бы поисковый запрос ни ввели, ему будет удовлетворять, по меньшей мере, один порносайт.
Наивный чукотский юноша... (с)
Потому что скорость расчёта в "десятичном текстовом" виде будет многократно меньше, чем при естественном для машины двоичном числовом, а схемы для всего этого будут существенно сложней.
Всего-то 18,5 десятичных цифр... Маловато будет! :) (на мэйнфреймах -- до 31)
Скорей всего, причина в том, что автор использует инструменты, которые сами заточены на реальный режим. Винда с помощью режима V86 может эмулировать ДОС, но поддержка V86 выпилена из 64-разрядного режима процессора; соответственно, если работа идёт под 64-разрядной Виндой, гонять ДОСовские программы прямо из-под Винды невозможно (только ставить ДОС на виртуальную машину или там какой ДОСБох использовать).
Особого смысла в их хранении отдельно нет. Проще хранить всю сумму не в рублях, а в копейках (или там в десятых/сотых копейки -- зависит от конкретных требований).
Ещё от архитектуры процессора зависит. Мэйнфреймы IBM от самого своего рождения (Система 360, 1964 год) имеют поддержку двоично-десятичных чисел (до 31 десятичной цифры плюс знак), и на них "экономическая" информация естественным образом считается в десятичной системе. Вот на ПК (IA-32, AMD64 -- неважно) или, скажем, на ARM любой разновидности такие вещи приходится считать, используя целочисленную арифметику; плавающая запятая -- лишь для задач, где ошибки округления приемлемы (скажем, научные расчёты: там не обязательно, чтоб последняя циферка сходилась, достаточно лишь обеспечить необходимую точность).