Есть такой небезызвестный товарищ, Агнер Фог, который пишет маны по оптимизации (и не только). Очень полезно к изучению: https://www.agner.org/optimize/#manuals
Мне кажется, любовь к ассемблеру – это навсегда. К любому другому языку можно остыть, но если ты проникся к асму, то время от времени будешь возвращаться к нему, потому что просто по кайфу :)
У разных ОС (я не имею в виду разные версии 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 :)
Машинные коды вряд ли можно назвать языком программирования. Если брать определение из Википедии, то "Язы́к программи́рования — формальный язык, предназначенный для записи компьютерных программ. Язык программирования определяет набор лексических, синтаксических и семантических правил, определяющих внешний вид программы и действия, которые выполнит исполнитель (обычно — ЭВМ) под её управлением."
Если так докапываться, то можно сказать, что и машинные коды не всегда являются самыми низкоуровневыми, ведь бывает ещё и микрокод :)
Спасибо, добавил ;)
Добавлю, пожалуй, спасибо ;)
Хотя по ссылке в конце статьи эта IDE (как и множество других) есть.
Ну это ж чел сделал просто по приколу. Так же как KolibriOS сделали по приколу.
В fasmg, к примеру, вы можете создать такой синтаксис, который позволит кодировать инструкцию нужным образом (31 C0 или 33 C0).
В x86 тоже не мало всяких gf2p8affineinvqb, ldmxcsr, mpsadbw, pclmulhqlqdq, v4fnmaddps, vfmsubadd132pd, vp4dpwssds, xgetbv... :)
upd: Ах, вон о чём речь. Вообще, некоторые процы ARM и Java-байткод понимают.
Проблема только в 64-битных Windows. И эту проверку можно отключить.
Есть такой небезызвестный товарищ, Агнер Фог, который пишет маны по оптимизации (и не только). Очень полезно к изучению: https://www.agner.org/optimize/#manuals
Делал в прошлом году измерялку скорости кода (в тактах).
Если интересно: https://gist.github.com/jin-x/88358e9bb1d58d01b7a318d0873208e3
Если есть понимание как улучшить, буду рад ;)
AI уже пишет AI... Может, стоило начать с чего-то попроще?
Скоро AI будет писать AI для написания AI. И далее уходим в бесконечную рекурсию.
Какого он(а/о/ы) пола, вероисповедания, сексуальной ориентации?
Почему зло? Если по приколу, почему нет?
Вряд ли разумный человек, работающий в геймдеве на корпорацию будет писать AAA игру на асме.
Спасибо, добавлю про C/C++.
Неа: https://habr.com/ru/post/318916/ :)
Мне кажется, любовь к ассемблеру – это навсегда. К любому другому языку можно остыть, но если ты проникся к асму, то время от времени будешь возвращаться к нему, потому что просто по кайфу :)
У каждого языка и технологии своя область применения. Писать всегда на асме не призываю (читайте внимательнее), но знать его полезно.
Пока @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 :)
Машинные коды вряд ли можно назвать языком программирования. Если брать определение из Википедии, то "Язы́к программи́рования — формальный язык, предназначенный для записи компьютерных программ. Язык программирования определяет набор лексических, синтаксических и семантических правил, определяющих внешний вид программы и действия, которые выполнит исполнитель (обычно — ЭВМ) под её управлением."
Если так докапываться, то можно сказать, что и машинные коды не всегда являются самыми низкоуровневыми, ведь бывает ещё и микрокод :)