Этим он ничем не отличился по сравнению, например, с ARM/32. Вообще весь embedded такой. Завтра вам вместо микросхемы управления двигателем, условно, ABC123 поставят PQR456, а у неё другие регистры, коэффициенты и вообще неонка внутре другого цвета. Всё, переписывай что-то, причём "на вчера", потому что контейнеровоз уже заканчивают загружать. Вместо STM32QQQ27PQR250 дают STM32QQQ26PQR240B, а у него некоторые команды Neon медленнее на два такта, и у вас начались мелькания на экране. И тэ дэ и тэ пэ. А вот "инструкция", о которой вы говорите, представлена в виде опций поддержки в самом бинарнике, средствами расширений ELF (ну, по крайней мере, они стараются загнать всё туда).
Этот эксперимент, может, не с такими различиями в версиях, проводят тысячи людей ежедневно, запуская старые системы в докере. До 10-летней давности бывает систематически, больше - иногда. У меня фидошный софт сборки 2004 года, от FreeBSD4 на современной 14-й (но тут надо пакет библиотек совместимости ставить, а одну так тянуть за собой через апгрейды); да, это не линукс, но картина схожая.
Это неправда. Писать числа в десятичной позиционной системе начали индийцы, а у них запись слева направо. Арабы только позаимствовали подход, не меняя порядка цифр в физической записи. Европейцы, приняв у арабов, сохранили физический порядок, фактически восстановив (ещё этого не зная) исходный индийский порядок. Пожалуйста, не повторяйте эти глупые мифы про "арабский" порядок.
Кстати, и цифры некорректно называть арабскими. Их точная форма на момент заимствования была другой, и сейчас есть "южноарабский" отдельный вариант. Вот в Юникоде исходные цифры: ٠١٢٣٤٥٦٧٨٩ - ну как, похоже? Правильнее всего называть наши современные цифры итальянскими (или имени Фибоначчи, это он "притащил" их в христианскую Европу, форма сохраняется в его варианте).
А LE как раз логичен - младшие разряды в байте с младшим адресом
И что с того? В этом нет никакого явного преимущества, если смотреть и на дизайн "железа", и на поведение софта. В одном случае лучше одно, в другом - другое.
Вот пример: числа переменной длины в памяти (частые во многих форматах), старший бит определяет, последний байт или нет. Когда записывается такое число в память, чуть меньше возни при LE формате: выделил семь бит, сдвинул вправо, проверил, ноль или нет, пошёл дальше. (Со знаковыми чуть сложнее, но тоже подходит.) А собирать его обратно надо фактически с конца. Зато при BE сложнее записывать (фактически, надо записать в стиле LE и потом развернуть), зато читать легче - на каждый байт сдвиг и побитовое "или". Поэтому форматы [u]leb128 в DWARF - глупость, там отладчик читает сотни раз на одну запись в генераторе в компиляторе, надо было BE. А вот "длинную арифметику" чуть-чуть проще в LE, там на одну переменную индекса получается меньше при операциях типа сложения-вычитания. Не будет тут универсальности, не надейтесь.
Ваш оппонент почти полностью прав прав, LE для 8080 был "изобретён" независимо от PDP-11, 6502 и прочих предшественников, как локальная микрооптимизация. Про это есть воспоминания его разработчика с высказыванием сожаления об этом решении. С ходу ссылку не нашёл, но она широко известна. Ну а дальше именно популярность x86 (через IBM PC) способствовала продвижению LE, вплоть до того, что в RISC-V назначили его базовым вариантом (и про это есть утверждения авторов), командный поток там всегда в LE.
Сейчас даже X86 менее запутанна, чем RISC-V. Авторы последней придумали 100500 расширений, из которых часть уже несовместимы друг с другом, и без механизма их надёжной идентификации. Самый главный набор детектируется по битам в сервисном регистре, а вот для прочих устойчивого гарантированного метода просто нет, не завезли. По сравнению с этим кошмарик cpuid в x86 выглядит прилично.
Именно что pytest анализирует код тестов (результат их парсинга питоновским парсером в виде AST), находит assertʼы и дорабатывает их. Это в отличие от unittest, который так отрабатывает только свои методы.
смотрим чем наиболее он существенно синтаксически отличается
Ну вот и следующий вопрос - а почему вы взяли именно эти синтаксические отличия, а не, например, динамическую типизацию, "batteries included" и предельное облегчение интерактивной работы? А отступы много где есть как синтаксический элемент...
Как-то забыл эту тему, случайно вспомнил... мы рядом чуть глубже обсуждали, но таки лучше вынести в отдельное сообщение:
Пофикшено в RFC 8260 чанками I-DATA.
Нет. Нету раздельного приёмного окна для каждого потока, значит, ты говоришь о чём-то другом, но не том, что я имею в виду. Возможность передавать огромные сообщения по кусочкам это, конечно, прикольно, но такой разрез с чуть большей затратой можно сделать и в юзерленде (добавить, например, один байт с теми же однобитовыми флагами B и E, или вообще впихнуть их в PPID).
Когда потоков много, общий ACK будет гораздо эффективнее
И он будет означать только то, что что-то услышано, но не что данные приняты - это если в пакете были чанки нескольких потоков, из которых из одного данные приняты, а другого - нет, потому что окна нету. Увы.
Ну, по крайней мере, стараются минимизировать сбрасывание через PCIDы. И для новых процессоров уже необязательно делать ограничения через TLB. Вот из моего лаптопного i7-12650H пропал флаг bugs: cpu_meltdown (а в старом десктопе ещё есть). Есть оба spectre, но их плясками с TLB не лечат.
Ну так на это есть таймеры. Они могут быть сделаны тоже в стиле файлов (достаточно часто) или нет, но должны обеспечивать возможность проснуться раз в пару десятков миллисекунд и отправить несколько килобайт в буфер звуковухи. С видео сложнее, но сама карта эту сложность компенсирует в себе.
То есть cat не "просто" применяет read к мыши, а получает от неё какие-то события?
Что есть "просто" у вас, не знаю, но этот метод состоит в том, чтобы в цикле читать порцию данных (обычно фиксированного размера), если что-то происходит, то read() срабатывает и данные приходят. И это не только мышь, сейчас так стараются все входные источники обрабатывать.
Ну да, цена обработки системного вызова даже в простейшем случае это примерно как 20-50 косвенных переходов по адресу или ветвлений по непредсказанной ветке. А вот TLB не сбрасывают, это не переход на другую нитку (даже другого процесса, чтобы надо было менять сам корневой каталог трансляции).
Где "новизна"? "Каталог" как раз более старый термин. "Директория" это продукт тупых переводчиков 90-х. А "папка", как перевод "folder", имеет более широкий смысл: папка может быть и виртуальной (в Windows Explorer полно таких, Dolphin из KDE тоже такое умеет).
Вообще формально ничто не мешает запретить любому интерпретатору именно мапить файл скрипта в память. То, что пара распространённых не делает это, не показатель.
Но он всё таки действует умнее и сначала удаляет существующий файл.
Я б тут даже поправил: идеальный вариант такого менеджера пишет новый файл рядом и затем вызывает rename(), который атомарная операция.
Но пару раз я видел последствия того, как ничего из таких защитных мер не было сделано, или сделано неверно (записано поверх существующего файла): пример. Хотя я тут не уверен, что в библиотеке фонтов не было логики однажды открыть файл и закэшировать смещения.
Этим он ничем не отличился по сравнению, например, с ARM/32. Вообще весь embedded такой. Завтра вам вместо микросхемы управления двигателем, условно, ABC123 поставят PQR456, а у неё другие регистры, коэффициенты и вообще неонка внутре другого цвета. Всё, переписывай что-то, причём "на вчера", потому что контейнеровоз уже заканчивают загружать. Вместо STM32QQQ27PQR250 дают STM32QQQ26PQR240B, а у него некоторые команды Neon медленнее на два такта, и у вас начались мелькания на экране. И тэ дэ и тэ пэ.
А вот "инструкция", о которой вы говорите, представлена в виде опций поддержки в самом бинарнике, средствами расширений ELF (ну, по крайней мере, они стараются загнать всё туда).
Этот эксперимент, может, не с такими различиями в версиях, проводят тысячи людей ежедневно, запуская старые системы в докере. До 10-летней давности бывает систематически, больше - иногда. У меня фидошный софт сборки 2004 года, от FreeBSD4 на современной 14-й (но тут надо пакет библиотек совместимости ставить, а одну так тянуть за собой через апгрейды); да, это не линукс, но картина схожая.
И какая польза была бы в том, что мы "знали" бы вес разрядов?
Никаких "вешалок". Два индекса вместо одного, или смещение к одному из индексов. Чуть-чуть менее удобно, но подъёмно без проблем.
Это неправда. Писать числа в десятичной позиционной системе начали индийцы, а у них запись слева направо. Арабы только позаимствовали подход, не меняя порядка цифр в физической записи. Европейцы, приняв у арабов, сохранили физический порядок, фактически восстановив (ещё этого не зная) исходный индийский порядок. Пожалуйста, не повторяйте эти глупые мифы про "арабский" порядок.
Кстати, и цифры некорректно называть арабскими. Их точная форма на момент заимствования была другой, и сейчас есть "южноарабский" отдельный вариант. Вот в Юникоде исходные цифры: ٠١٢٣٤٥٦٧٨٩ - ну как, похоже? Правильнее всего называть наши современные цифры итальянскими (или имени Фибоначчи, это он "притащил" их в христианскую Европу, форма сохраняется в его варианте).
И что с того? В этом нет никакого явного преимущества, если смотреть и на дизайн "железа", и на поведение софта. В одном случае лучше одно, в другом - другое.
Вот пример: числа переменной длины в памяти (частые во многих форматах), старший бит определяет, последний байт или нет. Когда записывается такое число в память, чуть меньше возни при LE формате: выделил семь бит, сдвинул вправо, проверил, ноль или нет, пошёл дальше. (Со знаковыми чуть сложнее, но тоже подходит.) А собирать его обратно надо фактически с конца. Зато при BE сложнее записывать (фактически, надо записать в стиле LE и потом развернуть), зато читать легче - на каждый байт сдвиг и побитовое "или". Поэтому форматы [u]leb128 в DWARF - глупость, там отладчик читает сотни раз на одну запись в генераторе в компиляторе, надо было BE.
А вот "длинную арифметику" чуть-чуть проще в LE, там на одну переменную индекса получается меньше при операциях типа сложения-вычитания.
Не будет тут универсальности, не надейтесь.
Ваш оппонент почти полностью прав прав, LE для 8080 был "изобретён" независимо от PDP-11, 6502 и прочих предшественников, как локальная микрооптимизация. Про это есть воспоминания его разработчика с высказыванием сожаления об этом решении. С ходу ссылку не нашёл, но она широко известна. Ну а дальше именно популярность x86 (через IBM PC) способствовала продвижению LE, вплоть до того, что в RISC-V назначили его базовым вариантом (и про это есть утверждения авторов), командный поток там всегда в LE.
Сейчас даже X86 менее запутанна, чем RISC-V. Авторы последней придумали 100500 расширений, из которых часть уже несовместимы друг с другом, и без механизма их надёжной идентификации. Самый главный набор детектируется по битам в сервисном регистре, а вот для прочих устойчивого гарантированного метода просто нет, не завезли. По сравнению с этим кошмарик cpuid в x86 выглядит прилично.
Именно что pytest анализирует код тестов (результат их парсинга питоновским парсером в виде AST), находит assertʼы и дорабатывает их. Это в отличие от unittest, который так отрабатывает только свои методы.
Ну вот и следующий вопрос - а почему вы взяли именно эти синтаксические отличия, а не, например, динамическую типизацию, "batteries included" и предельное облегчение интерактивной работы?
А отступы много где есть как синтаксический элемент...
Этому есть подтверждение? (опрос/анализ UX от приличного агенства)
Как-то забыл эту тему, случайно вспомнил... мы рядом чуть глубже обсуждали, но таки лучше вынести в отдельное сообщение:
Нет. Нету раздельного приёмного окна для каждого потока, значит, ты говоришь о чём-то другом, но не том, что я имею в виду. Возможность передавать огромные сообщения по кусочкам это, конечно, прикольно, но такой разрез с чуть большей затратой можно сделать и в юзерленде (добавить, например, один байт с теми же однобитовыми флагами B и E, или вообще впихнуть их в PPID).
И он будет означать только то, что что-то услышано, но не что данные приняты - это если в пакете были чанки нескольких потоков, из которых из одного данные приняты, а другого - нет, потому что окна нету. Увы.
Ну, по крайней мере, стараются минимизировать сбрасывание через PCIDы. И для новых процессоров уже необязательно делать ограничения через TLB. Вот из моего лаптопного i7-12650H пропал флаг bugs: cpu_meltdown (а в старом десктопе ещё есть). Есть оба spectre, но их плясками с TLB не лечат.
Видимо, ваша реплика оказалась слишком неоднозначна. Если вы имели в виду что-то другое, то уточните.
Ну так на это есть таймеры. Они могут быть сделаны тоже в стиле файлов (достаточно часто) или нет, но должны обеспечивать возможность проснуться раз в пару десятков миллисекунд и отправить несколько килобайт в буфер звуковухи. С видео сложнее, но сама карта эту сложность компенсирует в себе.
Что есть "просто" у вас, не знаю, но этот метод состоит в том, чтобы в цикле читать порцию данных (обычно фиксированного размера), если что-то происходит, то read() срабатывает и данные приходят. И это не только мышь, сейчас так стараются все входные источники обрабатывать.
Ну да, цена обработки системного вызова даже в простейшем случае это примерно как 20-50 косвенных переходов по адресу или ветвлений по непредсказанной ветке. А вот TLB не сбрасывают, это не переход на другую нитку (даже другого процесса, чтобы надо было менять сам корневой каталог трансляции).
В 2009 ещё не производилась TLC, ну а флэшку могли заказать из более надёжной серии (стенки транзисторов толще, легирование точнее, и т.д.)
Где "новизна"? "Каталог" как раз более старый термин. "Директория" это продукт тупых переводчиков 90-х. А "папка", как перевод "folder", имеет более широкий смысл: папка может быть и виртуальной (в Windows Explorer полно таких, Dolphin из KDE тоже такое умеет).
Вообще формально ничто не мешает запретить любому интерпретатору именно мапить файл скрипта в память. То, что пара распространённых не делает это, не показатель.
И защиты ядром в таком случае у них не будет.
Я б тут даже поправил: идеальный вариант такого менеджера пишет новый файл рядом и затем вызывает rename(), который атомарная операция.
Но пару раз я видел последствия того, как ничего из таких защитных мер не было сделано, или сделано неверно (записано поверх существующего файла): пример. Хотя я тут не уверен, что в библиотеке фонтов не было логики однажды открыть файл и закэшировать смещения.
Это пока не начинаются проблемы типа таких. Или флэш-память с более 2 уровнями заряда (MLC, QLC и далее).
Дырявые абстракции — они такие.