Я всё ещё медленно читаю эту статью, но решил оставить комментарий уже сейчас. И он будет не о статье, а скорее о моём мета-наблюдении. Как автор оригинального кода, который здесь и в предыдущей статье разбирают по косточкам, хочу отметить моё давнее наблюдение о судьбе программных проектов. Если какой-то проект имеет ненулевое количество пользователей, то раньше или позже его начнут использовать таким образом, какой его авторы вообще не могли себе когда-либо вообразить. В принципе, наверное это применимо к практически любому тексту.
При условии, что продолжаемая дискуссия ведётся в цивильной манере и имеет цель докопаться до истины и всех её оттенков, я остаюсь доволен :-).
Пример, хотя конкретно здесь я не смог --coverage сломаться. Но в реальном проекте с более хитрыми ограничениями на хостовые регистры эта проблема всплывает.
atakua@localhost:~$ cat no-stack-frame.c
register long long a asm("%rbp");
int main() {
return (int)a;
};
atakua@localhost:~$ gcc no-stack-frame.c
no-stack-frame.c: In function ‘main’:
no-stack-frame.c:4:5: error: frame pointer required, but reserved
4 | int main() {
| ^~~~
no-stack-frame.c:1:20: note: for ‘a’
1 | register long long a asm("%rbp");
| ^
atakua@localhost:~$ gcc -fomit-frame-pointer no-stack-frame.c
# OK
Очень интересное исследование получилось! Мой оригинальный проект был нацелен на то, чтобы быть иллюстрацией методов интерпретации для студентов, а также как упражнение для них по изменению некоторых аспектов работы интерпретаторов. Мне тогда не пришло в голову давать кому-то задачу по дальнейшей профилировке и ускорению.
У меня есть один комментарий по поводу следующего утверждения из статьи:
Рекомендация компилятору привязать одну глобальную переменную к регистру - это только рекомендация, и компилятор может ее проигнорировать.
В случае с GCC и расширения asm("reg-name") это не так. Компилятор действительно перестаёт использовать указанный регистр для своих целей. Фактически, за модификации в ABI после этого отвечает сам программист. Можно даже поставить компилятор в тупик и заставить его отказаться от компиляции кода, в котором важные для ABI регистры были у него "забраны". Например, если прибить RBP на x86-64, то компиляция с --coverage становится невозможной. GCC хочет использовать RBP для stack frame, который необходим для инструментации покрытия кода.
Ну, по правде сказать, если в биткоин-переводе вы ошиблись бы в одном символе адреса получателя (и искажённый адрес при этом имел бы корректную чексумму), то ждать так долго бы не пришлось. Потому что вы бы сразу знали, что эти деньги пропали навсегда и для получателя, и для отправителя.
Моя любимая история геймдева про Блицкриг 2, уж не знаю, правда или нет. Читал когда-то давно в каком-то бумажном журнале, недавно нашёл в сети.
Ну, сделали и мы в Блицкриге эту самую ракету. Как и немцы, сделали ее уже ближе к концу проекта и соорудили на базе объекта "самолет". Но программисты несколько схалтурили и не пооткручивали у бывшего самолета подозрительную для баллистической ракеты функциональность. Оказалость, что если во время полета к цели начинал идти дождь или снег, то во-первых ракета говорила человеческим голосом "Fliege zuruck"(нем. лечу назад), а во-вторых разворачивалась и летела обратно на базу. Фигли там, погода то нелетная.
А еще был у нас замечательный юнит — отряд спецназовцев. Войска у нас могут получать в ходе миссии опыт, а за опыт дают всякие интересные способности. Так вот, донельзя прокачанные спецназовцы получали возможность маскироваться под вражескую пехоту. Достаточно было просто кликнуть в отряд неприятельских солдатиков, и наши бойцы переодевались в их форму. Можно было безнаказанно разгуливать по вражеской базе. Ну, до первого выстрела, конечно.
Но, беда в том, что в Блицкриге кроме собственно пехоты еще были всякие антуражные юниты, типа коров, свиней и собак. Выяснилось, что спецназ вовсе не чурается переодевания в бобиков и хавроний. Если учесть, что механизм этого самого переодевания несколько глючил и часть отряда можно было нарядить в одну форму, часть в другую, то можно было создавать совершенно безумные подразделения. Например, отряд из собак, свиней и панцергренадеров. Учитывая, что отряду можно отдавать всякие приказы типа "маршировать", "ползти" и т.д., то игроку предоставлялась уникальная возможность полюбоваться марширующими свиньями. Получалось это у них, впрочем, паршиво, потому что скелет свиньи не соответствует скелету пехотинца и выглядит это как отряд ездящих не попе хрюшек. А еще этот цирк-шапито можо было запихать в окоп. Сидят, значит, свиньи с собаками в окопе и периодически из него выглядывают.
И вот моё самое любимое:
Со свиньями был связан, кстати, еще один баг, из-за которого игра падала. В какой-то момент программисты что-то такое там подкрутили и свиньи перестали быть нейтральными, а обрели возможность принадлежать какому-то игроку. Управлять ими было нельзя, но формально они могли быть "наши" или "ненаши". Так вот свиньи роняли игру. Потому что видя неприятеля, патриотичная хавронья хотела дать врагу отпор и лезла за оружием, которого у нее естественно не было. Если мне не изменяет память, программисты исправили баг, просто выдав свинье пистолет Люгер без патронов. Визуально это никак не видно, но формально, теперь, видя врага, она лезет за оружием, видит что патронов нет и на этом успокаивается.
Я четыре года назад как-то попытался разъяснить путаницу с именами архитектур. Если кратко:
x86 — Intel архитектура для 32-битных ПК, который сама Intel называет IA-32.
x64, x86_64, x86-64 — расширение AMD64 для x86, сейчас идущее в большинстве процессоров для ПК.
Всё остальное надо называть своими правильными именами (POWER(3,4,5,…), IA-64, ARMv(7,8)), иначе очень сильно сбивает. Я вот, например, эту статью до конца прочитать не смог, потому что постоянно сбивался, куда и на что мигрируют, так и плюнул.
А в чём собственно разница между вирусом и не-вирусом
А это произрастает из принципиальной нерешаемости проблемы останова (the halting problem). Поэтому я совершенно не верю в эвристические механизмы детектирования и с подозрением (но и надеждой) отношусь к методам, основанным на симуляции в песочнице. Последние в конце концов упираются в то, что они настолько хороши, насколько хороши списки контроля доступа того, что каждому приложению можно и нельзя делать (SElinux, manifest etc.)
Очень хорошая картинка, спасибо. Стоит к ней приглядеться. Конечно же, после некоторой тренировки понятно, что знаки значат, особенно если прочувствовать, что скорости даны в милях/ч, а расстояния в милях и футах.
Конечно, STOP ни с чем не спутаешь. Но вот лишь некоторые различия, которые бросаются в глаза:
знаки один и два вполне можно воспринять как указатели скорости. У нас указатели номеров дорог совсем другие и по цвету, и по форме, и буква в них включена, например M3, A101, E95.
знак №15 — мне лично был непонятен на местности, пока не объяснили
знаки 31 и 44 — аббревиатуры, непонятные без расшифровки
знак 30 — у нас это "красный кирпич на палочке"
знаки номер три и пять — вообще непонятно, что. У нас больница — это красный крест. И да, у нас есть потрясающий по понятности восклицательный знак "прочие опасности". Что-то опасное происходит, так что вы тут поосторожнее.
Не указаны знаки.
Высота проезда (clearance): у нас знак, у них надпись
К чему я это всё: с любой адекватной сигнальной системой можно жить, но для дорожных знаков критически важно быть универсальными, т.к. неправильная их интерпретация может привести к неправильным решениям в условиях высоких скоростей.
Моё мнение: и американец, и европеец/русский, оказавшись впервые в чуждой ему системе дорожных знаков, будет не в состоянии их быстро и правильно интерпретировать без предварительной тренировки. Это как приехать в Англию и начать ездить по правой стороне дороги — далеко не уедешь. Но про это хотя бы многие знают.
До сих пор помню, как меня в раннем детстве, когда я только научился читать, поражало, почему все вывески на улице, на магазинах и вокруг сделаны разными шрифтами. Моему детскому уму была непонятна причина, зачем понадобилось так портить отличную идею универсальной сигнальной системы.
В России? 1) зачем, если уже есть работающая система, совместимая с многими соседними странами; 2) почему бы сразу не на китайском — было бы достаточно одного-двух иероглифов на знак?
В Америке много чего странного, например, футы, дюймы, унции (несколько видов), галлоны. Но ничего, живём как-то на планете все вместе.
Подтверждаю. В США дорожные знаки совсем другие, их очень много и значительная часть выражена текстом.
В России последнее бы не прокатило — слова длиннее и требуют согласования (падежи, предлоги и т.п.). Тогда как на американских текстовых знаках формально правила грамматики нарушаются, но всё понятно и так — язык позволяет многое опускать.
Ну конечно же. Статья провокационная, поэтому и комментарии к ней такие же.
Да и первый пример, фактически, CGI-скрипт.
Это мог бы быть CGI-скрипт на Perl, на Bash, ну или программа на Си.
Да и для "обычных" двоичных программ точно так же обязан иметься загрузчик, который разберёт их структуру, поместит секции в память и передаст управление на точку входа. Но это не делает машинный код "языком разметки".
Может быть и непривычные, но это языки программирования. Как и, например, Postscript, TeX. Ну или эзотерические языки вроде BF, лямбда-исчисление Чёрча или ДМТ.
И описывают на HDL не только синтезируемые описания, но также потактовые модели и верифицирующие модели.
Производительность он пока что показывает хуже, чем оригинальный translated. При этом профиль VTune у них очень сильно отличается. У нового транслятора вылезли интересные эффекты вроде 4kB-aliasing и machine clears. Более подробный анализ я провесит пока что не успел, но, похоже, придётся оптимизировать операцию push, т.к. она вылезла вверх в профиле. Но надо разбираться.
Стандарт ACPI определяет интерфейсы управления энергопотреблением платформы (ЦПУ, материнская плата и периферийные устройства) для ОС.
Стандарт определяет состояния энергопотребления и производительности: для системы в целом (S0-S5), процессора (C- и P-состояния; эта статья лишь слегка коснулась C-состояний), периферийных устройств (D-состояния).
Стандарт не диктует обязательность реализации всех объявленных в нём режимов. Детали реализации режимов различаются для разной аппаратуры. Кроме того, операционные системы вольны реализовывать только некоторые из режимов сна.
За засыпание отдельных устройств отвечают их драйвера. Но что-то подсказывает мне, что обеспечение корректной поддержки D-состояний не стоит в первом приоритете у драйверописателей. Поэтому то, насколько глубоко заснёт конкретный девайс, может отличаться на разных ОС или ревизиях одной ОС.
Надо больше заборов богу заборов! Даёшь повсюду двойные заборы, а не то на внутренних заборах краску обдирают, а так хоть внешние заборы этому помешают.
Иногда мне хочется пойти в политику, но только для того, чтобы выпустить указ о повсеместном корчевании этих чёртовых заборов.
Я всё ещё медленно читаю эту статью, но решил оставить комментарий уже сейчас. И он будет не о статье, а скорее о моём мета-наблюдении.
Как автор оригинального кода, который здесь и в предыдущей статье разбирают по косточкам, хочу отметить моё давнее наблюдение о судьбе программных проектов. Если какой-то проект имеет ненулевое количество пользователей, то раньше или позже его начнут использовать таким образом, какой его авторы вообще не могли себе когда-либо вообразить. В принципе, наверное это применимо к практически любому тексту.
При условии, что продолжаемая дискуссия ведётся в цивильной манере и имеет цель докопаться до истины и всех её оттенков, я остаюсь доволен :-).
Пример, хотя конкретно здесь я не смог
--coverageсломаться. Но в реальном проекте с более хитрыми ограничениями на хостовые регистры эта проблема всплывает.Очень интересное исследование получилось! Мой оригинальный проект был нацелен на то, чтобы быть иллюстрацией методов интерпретации для студентов, а также как упражнение для них по изменению некоторых аспектов работы интерпретаторов. Мне тогда не пришло в голову давать кому-то задачу по дальнейшей профилировке и ускорению.
У меня есть один комментарий по поводу следующего утверждения из статьи:
В случае с GCC и расширения
asm("reg-name")это не так. Компилятор действительно перестаёт использовать указанный регистр для своих целей. Фактически, за модификации в ABI после этого отвечает сам программист.Можно даже поставить компилятор в тупик и заставить его отказаться от компиляции кода, в котором важные для ABI регистры были у него "забраны". Например, если прибить RBP на x86-64, то компиляция с
--coverageстановится невозможной. GCC хочет использовать RBP для stack frame, который необходим для инструментации покрытия кода.Публикация бумажных книг — это отдельный квест, со всеми этими взаимодействиями с редакторами, корректорами и прочими. Удачи в нём!
И почему никто не вспомнил про тот инцидент в Блэк Меса с тележкой?
Ну, по правде сказать, если в биткоин-переводе вы ошиблись бы в одном символе адреса получателя (и искажённый адрес при этом имел бы корректную чексумму), то ждать так долго бы не пришлось. Потому что вы бы сразу знали, что эти деньги пропали навсегда и для получателя, и для отправителя.
Моя любимая история геймдева про Блицкриг 2, уж не знаю, правда или нет. Читал когда-то давно в каком-то бумажном журнале, недавно нашёл в сети.
И вот моё самое любимое:
Я четыре года назад как-то попытался разъяснить путаницу с именами архитектур. Если кратко:
Всё остальное надо называть своими правильными именами (POWER(3,4,5,…), IA-64, ARMv(7,8)), иначе очень сильно сбивает. Я вот, например, эту статью до конца прочитать не смог, потому что постоянно сбивался, куда и на что мигрируют, так и плюнул.
А это произрастает из принципиальной нерешаемости проблемы останова (the halting problem). Поэтому я совершенно не верю в эвристические механизмы детектирования и с подозрением (но и надеждой) отношусь к методам, основанным на симуляции в песочнице. Последние в конце концов упираются в то, что они настолько хороши, насколько хороши списки контроля доступа того, что каждому приложению можно и нельзя делать (SElinux, manifest etc.)
Очень хорошая картинка, спасибо. Стоит к ней приглядеться. Конечно же, после некоторой тренировки понятно, что знаки значат, особенно если прочувствовать, что скорости даны в милях/ч, а расстояния в милях и футах.
Конечно, STOP ни с чем не спутаешь. Но вот лишь некоторые различия, которые бросаются в глаза:
Не указаны знаки.
К чему я это всё: с любой адекватной сигнальной системой можно жить, но для дорожных знаков критически важно быть универсальными, т.к. неправильная их интерпретация может привести к неправильным решениям в условиях высоких скоростей.
Моё мнение: и американец, и европеец/русский, оказавшись впервые в чуждой ему системе дорожных знаков, будет не в состоянии их быстро и правильно интерпретировать без предварительной тренировки. Это как приехать в Англию и начать ездить по правой стороне дороги — далеко не уедешь. Но про это хотя бы многие знают.
В России? 1) зачем, если уже есть работающая система, совместимая с многими соседними странами; 2) почему бы сразу не на китайском — было бы достаточно одного-двух иероглифов на знак?
В Америке много чего странного, например, футы, дюймы, унции (несколько видов), галлоны. Но ничего, живём как-то на планете все вместе.
В России последнее бы не прокатило — слова длиннее и требуют согласования (падежи, предлоги и т.п.). Тогда как на американских текстовых знаках формально правила грамматики нарушаются, но всё понятно и так — язык позволяет многое опускать.
Ну конечно же. Статья провокационная, поэтому и комментарии к ней такие же.
Это мог бы быть CGI-скрипт на Perl, на Bash, ну или программа на Си.
Да и для "обычных" двоичных программ точно так же обязан иметься загрузчик, который разберёт их структуру, поместит секции в память и передаст управление на точку входа. Но это не делает машинный код "языком разметки".
Смотря какая версия HTML.
Про то, что, казалось бы, простые языки разметки не так уж и просты, см. мой комментарий ниже.
Два контрпримера:
pshttpd — веб-сервер, написанный на Postscript 1) http://www.pugo.org/project/pshttpd/ 2) https://people.debian.org/~godisch/pshttpd/
basix — интерпретатор языка Basic, написанный на TeX: https://www.tug.org/TUGboat/tb11-3/tb29greene.pdf
Может быть и непривычные, но это языки программирования. Как и, например, Postscript, TeX. Ну или эзотерические языки вроде BF, лямбда-исчисление Чёрча или ДМТ.
И описывают на HDL не только синтезируемые описания, но также потактовые модели и верифицирующие модели.
Код inline-транслятора для ВМ готов: https://github.com/grigory-rechistov/interpreters-comparison/blob/master/translated-inline.c .
Производительность он пока что показывает хуже, чем оригинальный translated. При этом профиль VTune у них очень сильно отличается. У нового транслятора вылезли интересные эффекты вроде 4kB-aliasing и machine clears. Более подробный анализ я провесит пока что не успел, но, похоже, придётся оптимизировать операцию push, т.к. она вылезла вверх в профиле. Но надо разбираться.
Если очень кратко, то:
богу заборов! Даёшь повсюду двойные заборы, а не то на внутренних заборах краску обдирают, а так хоть внешние заборы этому помешают.Иногда мне хочется пойти в политику, но только для того, чтобы выпустить указ о повсеместном корчевании этих чёртовых заборов.