Мне кажется, любовь к ассемблеру – это навсегда. К любому другому языку можно остыть, но если ты проникся к асму, то время от времени будешь возвращаться к нему, потому что просто по кайфу :)
У разных ОС (я не имею в виду разные версии Windows или разные сборки Linux, разумеется, хотя и там есть свои нюансы), во-первых, разный формат исполняемых файлов, а во-вторых, разный набор и метод вызова системных функций. Конечно, 2+2*2 и т.п. будет работать на любой ОС, а что вы будете делать с этим дальше?
Почему именно об x86? Чем не угодил ARM? В Z80 или 6502 мало инструкций? Ну, так и на brainfuck люди выделывают ого-го что. Взгляните на демосцену, которая в РФ зиждется на 70-80% на одном только спектруме.
Если ассемблер так хорош, почему же мы не видим десктопных программ на нем? Компиляторов? СУБД?
Читайте внимательно, я писал, что "писать всегда на ассемблере – занятие не очень разумное с точки зрения времени, усилий, вероятности допустить ошибку и кроссплатформенности (я сам реже пишу на ассемблере, нежели на других языках)".
Умно — написать эффективный транслятор, который будет без потерь транслировать высокоуровневый код в ассемблер
Значит, ассемблер вам всё-таки пригодится? Иначе что вы будете делать потом с этим кодом, не зная ассемблера и не имея программ трансляции/компиляции?
Вы пишете, что ассемблер дает "полный контроль над кодом". Не дает. Современные процессоры используют out-of-order выполнение команд, то есть произвольно их переставляют местами. Вы над этим не имеете контроля и скорее всего даже не знаете, как это работает.
Над исполнением кода вы не имеете 100% контроля (хотя на out-of-order тоже можно влиять, существуют барьерные и сериализирующие инструкции; к тому же, для отдельных процессоров это всё возможно изучить, да сложно). А над кодом имеете.
Опять же, это глупо — переходить на ассемблер ради сокращения программы. Умно — переделать компилятор, чтобы он умел выкидывать неиспользуемые функции. gcc это более-менее умеет.
Мы не живём в идеальном мире, никогда не будет компилятора, который оставит лишь минимум того, что необходимо. А глупо или умно – это уже зависит от целей и задач, не надо уж так резать и смотреть только со своего угла.
Ну и без библиотек тоже плохо. Что вы будете делать, когда вам понадобится множество, словарь и другие структуры данных?
Я не призываю писать всё на асме (см. выше). Что я буду делать? Если очень надо, буду реализовывать его на асме (либо найду модуль/либу, делающую то, что мне нужно), либо буду использовать другой язык – это же очевидно :)
Супероптимизация — это умно. Сидеть руками переставлять байты — глупо.
Идея прикольная, но где же эти ваши супероптимизаторы в реальности? Или это просто очередная недореализованная идея? Опять же, всё зависит от ситуации. Текущие компиляторы далеко не всегда умеют генерить самый быстрый код. А дальше всё зависит от опыта и компетенций. Кстати, справится ли этот супероптимизатор с программой, которая использует свой же код как данные (сейчас вы, наверное, скажете, что это бредовая затея)?
Эта дрянь не нужна.
Как скажете. Кстати, почему вы решили, что использование недокументированных функций – неотъемлемая часть защиты и антиотладки?
8086 вышел по моему в 70-х годах, в нем 16-битные команды исполнялись строго по очереди, и с тех пор все поменялось радикально: процессоры стали 64-битные, в них используется out-of-order параллельное исполнение команд, а Интел должен тянуть это дремучее легаси.
Легко и удобно рассуждать, сидя в кресле. А что сделали бы вы на месте архитектора? Они уже попытались всё сломать, создав Itanium, и где он теперь? Кстати говоря, в x64 часть legacy вполне успешно вырезали.
Опять же, если брать Эльбрус, то система команд там намного современнее и логичнее, жаль только, что команды очень жирные.
Хорошо, когда процессор разрабатывается тогда, когда было создано уже много всего и можно с оглядкой на конкурентов сразу придумать нормальную архитектуру, правда? Посмотрим, насколько эффективен и чист будет Эльбрус, когда мы перейдём к какому-нибудь 256-битному коду :)
Комп — это же не просто универсальный девайс для работы с информацией, а в первую очередь свобода. Важная часть которой — я могу любую программу нажать правой кнопочкой, выбрать «открыть в дебаггере» и поправить всё что мне не нравится.
Это не моя цитата... А Линукс – это уже холивар.
Но вот сомневаюсь, что быстрокод там пишут руками или руками считают тайминги, думаю, что это у них как-то тоже автоматизировано.
Тайминги не считают (по крайней мере, покомандно), но код небольших интр, поверьте мне, пишут руками на асме (за крайне редким исключением).
Никто не мешает вам, используя ассемблер, писать машинные коды через db :)
Машинные коды вряд ли можно назвать языком программирования. Если брать определение из Википедии, то "Язы́к программи́рования — формальный язык, предназначенный для записи компьютерных программ. Язык программирования определяет набор лексических, синтаксических и семантических правил, определяющих внешний вид программы и действия, которые выполнит исполнитель (обычно — ЭВМ) под её управлением."
Если так докапываться, то можно сказать, что и машинные коды не всегда являются самыми низкоуровневыми, ведь бывает ещё и микрокод :)
"Низкоуровневая программа" – не очень понятный термин. Программа на C, работающая с оборудованием – это низкоуровневая программа? Да и к чему изобретать замену уже устоявшимся терминам? Понятие "язык" в данном случае вполне уместен, хоть он и имеет разные диалекты и разные правила написания под разные процессоры. "Язык ассемблера" можно сравнить с "языком людей", который в то же время может быть "русскими", "английским", "французский" или "японским" (x86, ARM, Z80...). При этом каждый из этих языков может иметь несколько диалектов (MASM, NASM, GAS).
Тот же Python тоже бывает версии 2 и 3, которые довольно серьёзные различия. Тот же C++ тоже имеет некоторые различия в стандартах C++03 и C++20. И даже C/C++ одной и той же редакции будет иметь отличия в интринсиках и библиотеках для разных ОС/процессоров (более того, даже компиляторы привносят свои нюансы: VC++ vs GCC). Может, тогда и эти языки не стоит называть языками?
Ассемблеры состоят из нескольких модулей: транслятор в объектный модуль и сборщик (линкер; хотя есть и 2 в 1: тот же fasm), поэтому называть линкер ассемблером как-то не очень корректно (хоть он и переводится как "сборщик").
Транслятор в объектные модули, в смысле? Тут грань между трансляцией и компиляцией довольно условная, ИМХО, поскольку они же в машинный формат транслируют, а чем это не компиляция?
Да и, к примеру, NASM и fasm – вполне полноценные компиляторы (первый хоть и не во все исполняемые форматы переводит).
Дело не в этом, а в востребованности, конкуренции (кол-во разработчиков на вакансию), сложности языка, ИМХО. Я бы не сказал, что зарплаты программистов Python выше, чем на C++, хотя последний явно куда ближе к низкому уровню.
В области информационной безопасности, кстати, бывают вакансии с весьма достойными зарплатами (250 т.р. и выше), где в качестве требований указывают знание C/C++, ассемблера, опыт написания драйверов, знание внутреннего устройства ОС.
Не поленился сейчас и посмотрел на HH з/п ассемблерщиков. На первой странице нашёл ARM-разработчика с з/п до 350 т.р и инженера-программиста BIOS с з/п до 200 т.р. Есть ещё 160 и от 110. Так что, всё не так уж и плохо.
А где она возвращает true? Я не вижу ни одного такого места в блок-схемах, кроме того места, где она возвращает true после того, как получила true от вызова самой себя (а поскольку во всех остальных местах она возвращает false, то такое событие наступить не может).
У вас функция получается что-то вроде такого (если выкинуть все места с расчётами):
Почему у вас везде функция возвращает false (кроме «Что вернул метод» -> true -> «Вернуть true»)? Полагаю, в правых нижних эллипсах должно быть «Вернуть true» (в обоих схемах).
Мне кажется, любовь к ассемблеру – это навсегда. К любому другому языку можно остыть, но если ты проникся к асму, то время от времени будешь возвращаться к нему, потому что просто по кайфу :)
У каждого языка и технологии своя область применения. Писать всегда на асме не призываю (читайте внимательнее), но знать его полезно.
Пока @raamidне ответил, много всего интересного на шейдерах можете посмотреть здесь: https://www.shadertoy.com.
У разных ОС (я не имею в виду разные версии Windows или разные сборки Linux, разумеется, хотя и там есть свои нюансы), во-первых, разный формат исполняемых файлов, а во-вторых, разный набор и метод вызова системных функций. Конечно, 2+2*2 и т.п. будет работать на любой ОС, а что вы будете делать с этим дальше?
Почему именно об x86? Чем не угодил ARM? В Z80 или 6502 мало инструкций? Ну, так и на brainfuck люди выделывают ого-го что. Взгляните на демосцену, которая в РФ зиждется на 70-80% на одном только спектруме.
Читайте внимательно, я писал, что "писать всегда на ассемблере – занятие не очень разумное с точки зрения времени, усилий, вероятности допустить ошибку и кроссплатформенности (я сам реже пишу на ассемблере, нежели на других языках)".
Значит, ассемблер вам всё-таки пригодится? Иначе что вы будете делать потом с этим кодом, не зная ассемблера и не имея программ трансляции/компиляции?
Над исполнением кода вы не имеете 100% контроля (хотя на out-of-order тоже можно влиять, существуют барьерные и сериализирующие инструкции; к тому же, для отдельных процессоров это всё возможно изучить, да сложно). А над кодом имеете.
Мы не живём в идеальном мире, никогда не будет компилятора, который оставит лишь минимум того, что необходимо. А глупо или умно – это уже зависит от целей и задач, не надо уж так резать и смотреть только со своего угла.
Я не призываю писать всё на асме (см. выше). Что я буду делать? Если очень надо, буду реализовывать его на асме (либо найду модуль/либу, делающую то, что мне нужно), либо буду использовать другой язык – это же очевидно :)
Идея прикольная, но где же эти ваши супероптимизаторы в реальности? Или это просто очередная недореализованная идея? Опять же, всё зависит от ситуации. Текущие компиляторы далеко не всегда умеют генерить самый быстрый код. А дальше всё зависит от опыта и компетенций. Кстати, справится ли этот супероптимизатор с программой, которая использует свой же код как данные (сейчас вы, наверное, скажете, что это бредовая затея)?
Как скажете. Кстати, почему вы решили, что использование недокументированных функций – неотъемлемая часть защиты и антиотладки?
Легко и удобно рассуждать, сидя в кресле. А что сделали бы вы на месте архитектора? Они уже попытались всё сломать, создав Itanium, и где он теперь? Кстати говоря, в x64 часть legacy вполне успешно вырезали.
Хорошо, когда процессор разрабатывается тогда, когда было создано уже много всего и можно с оглядкой на конкурентов сразу придумать нормальную архитектуру, правда? Посмотрим, насколько эффективен и чист будет Эльбрус, когда мы перейдём к какому-нибудь 256-битному коду :)
Это не моя цитата... А Линукс – это уже холивар.
Тайминги не считают (по крайней мере, покомандно), но код небольших интр, поверьте мне, пишут руками на асме (за крайне редким исключением).
Не понял, про какие команды вы говорите в начале.
Никто не мешает вам, используя ассемблер, писать машинные коды через db :)
Машинные коды вряд ли можно назвать языком программирования. Если брать определение из Википедии, то "Язы́к программи́рования — формальный язык, предназначенный для записи компьютерных программ. Язык программирования определяет набор лексических, синтаксических и семантических правил, определяющих внешний вид программы и действия, которые выполнит исполнитель (обычно — ЭВМ) под её управлением."
Если так докапываться, то можно сказать, что и машинные коды не всегда являются самыми низкоуровневыми, ведь бывает ещё и микрокод :)
Я изучаю ARM и могу сказать, что он не менее великолепен, очень интересные штуки в нём есть :)
"Низкоуровневая программа" – не очень понятный термин. Программа на C, работающая с оборудованием – это низкоуровневая программа? Да и к чему изобретать замену уже устоявшимся терминам? Понятие "язык" в данном случае вполне уместен, хоть он и имеет разные диалекты и разные правила написания под разные процессоры. "Язык ассемблера" можно сравнить с "языком людей", который в то же время может быть "русскими", "английским", "французский" или "японским" (x86, ARM, Z80...). При этом каждый из этих языков может иметь несколько диалектов (MASM, NASM, GAS).
Тот же Python тоже бывает версии 2 и 3, которые довольно серьёзные различия. Тот же C++ тоже имеет некоторые различия в стандартах C++03 и C++20. И даже C/C++ одной и той же редакции будет иметь отличия в интринсиках и библиотеках для разных ОС/процессоров (более того, даже компиляторы привносят свои нюансы: VC++ vs GCC). Может, тогда и эти языки не стоит называть языками?
Ассемблеры состоят из нескольких модулей: транслятор в объектный модуль и сборщик (линкер; хотя есть и 2 в 1: тот же fasm), поэтому называть линкер ассемблером как-то не очень корректно (хоть он и переводится как "сборщик").
Транслятор в объектные модули, в смысле? Тут грань между трансляцией и компиляцией довольно условная, ИМХО, поскольку они же в машинный формат транслируют, а чем это не компиляция?
Да и, к примеру, NASM и fasm – вполне полноценные компиляторы (первый хоть и не во все исполняемые форматы переводит).
Интринсик – это аналог инструкции процессора. Поэтому изучая интринсики вы изучаете и ассемблер (в несколько ином синтаксисе) :)
Да, я тоже писал на паскале. Но на асме было всё же веселее :)
Дело не в этом, а в востребованности, конкуренции (кол-во разработчиков на вакансию), сложности языка, ИМХО. Я бы не сказал, что зарплаты программистов Python выше, чем на C++, хотя последний явно куда ближе к низкому уровню.
В области информационной безопасности, кстати, бывают вакансии с весьма достойными зарплатами (250 т.р. и выше), где в качестве требований указывают знание C/C++, ассемблера, опыт написания драйверов, знание внутреннего устройства ОС.
Не поленился сейчас и посмотрел на HH з/п ассемблерщиков. На первой странице нашёл ARM-разработчика с з/п до 350 т.р и инженера-программиста BIOS с з/п до 200 т.р. Есть ещё 160 и от 110. Так что, всё не так уж и плохо.
У вас функция получается что-то вроде такого (если выкинуть все места с расчётами):
Такая функция никогда не завершится и не вернёт true :)
Вторую часть было бы интересно почитать.
MR_VF