Привет. Расскажу немного свою историю: я уже наверное года 2-3 активно программирую на ассемблере, а точнее с использованием диалекта FASM, из-за его системы макросов и прочего он является довольно таки удобным. Перешел я на программирование только на ассемблере только после того, как попробовал разные языки высокого уровня типа С/С++/Python и прочее. Относительно недавно я решил вновь вернуться в С++ и если честно, не сказать, что мне это прям нравится, имхо ЯВУ - это не мое. Я любитель низкоуровневого программирования, можете называть мазохистом. Перешел я на С++ с целью облегчить себе жизнь при разработке драйверов под Windows, либо при разработке каких-то утилит, и, действительно, я заметил, что скорость разработки ускорилась в разы. И вот я вспомнил, что в FASM-е есть стандартные макросы типа: invoke/stdcall и прочее, но их может быть недостаточно для быстрой разработки. Тк условная проверка на выполнение условия осуществляется через все тот же CMP, создание switch/case тоже реализуется через специальные отдельные метки, что, конечно же затрудняет разработку. И я вот задумался, касаемо того, чтобы создать свою кастомную систему макросов, причем не просто систему, а красивую и кастомную системную макросов на FASM, с помощью которых скорость разработки будет укорачиваться в разы, на уровне ЯВУ. То есть реализовать ООП с полиморфизм и с нормальным сокрытием, реализовать комфортные управляющие конструкции (вроде if/else, switch/case и циклов while/for), автоматизировать управление памятью, а также упростить рутинные операции, сохранив при этом полный контроль над генерируемым машинным кодом. Также можно будет добавить что-то вроде макросов для автоматического освобождения ресурсов при выходе из функции (например, автоматический вызов ExFreePool для выделенной памяти или ZwClose для дескрипторов при достижении макроса ret). Как вам идея, форумчане, стоит ли тратить время?
это всё уже есть в коробке fasm'a он предлагает вам примитивы, из которых вы можете собирать что угодно (комбинировать их). на всякий - вот хелп ..
С макросами .if/.elseif/.else/.endif немножечко фиаско вышло. По достижении ret легко реализуемо через списки, которые можно точкой пристягнуть к имени процедуры. Загвоздка только в том, чтобы освобождать ресурсы только в том случае, если они были инициализированы. А то выделишь под .if'ом, а освобождать будешь в конце процедуры.
Если твое сообщение скопировать в тот же дипсик он выдаст много вариантов макросов на фасме в виде ссылок на код/страницы форума. Были даже попытки прикрутить ооп с помощью макросов. --- Самые свежие фасм как с: https://board.flatassembler.net/topic.php?p=231362
я думаю,если твоя программа состоит из одной WinAPI - функции,то такое можно сделать на ассемблере,а вот если десяток WinAPI-функций,то нужно думать в сторону высокоуровневых ЯП,может это наивно так думать ?
Если ты пишешь на голых апи, для тебя практически нету разницы плюсы ты выбрал или макроассемблер. Внезапно. Почти строка в строку то же самое будет. Другое дело, что сам такой подход считается архаикой.
Там нет разницы типа тот же FASM поставляет макрос типа invoke который тоже позволяет в одну строчку вызвать API-функцию. (Максимум когда может возникнуть проблема, это в случае если функции подгружаются в рантайме). Тут в целом проблема не в API, а конкретно в скорости разработки на ассемблере без своей сильной базы макросов
Чтобы не быть завязанным на ограничения макросов в каком-то из ассемблеров, сделай свой простенький компилятор из высокоуровнего ассемблера, парсить ассемблерные инструкции очень просто в сравнении с другими языками. Типа свой препроцессор для асм-сорсов. В общем-то, даже полноценный парсинг может не быть необходим, просто текстовой подстановкой можно попытаться решить (через регулярки, например). По сабжу: когда ты пытаешься натянуть высокоуровневые конструкции на ассемблер, есть не нулевая вероятность закончить с полноценным, но забагованном компилятором ЯВУ. Я не говорю этого не делать, каждый человек имеет право на странное хобби, я лишь говорю, что в этом мало смысла.
Всё зависит от Вашего жизненного целеполагания. Если Вы решили сделать себя единоличным наследником Томаша Грыштара, то однозначно - да. Во всех остальных случаях - нет. Пример контраргумента: пока Вы в одиночку создаёте красивую и кастомную системную макросов на FASM, выйдет новое поколение процессоров. Например (пример, конечно, так себе, но актуальный), Intel APX со своими заведомо кондовыми 32-мя РОН. Кстати, я не видел на fasm инструментов программирования интегрированного GPU. Вот это было бы достойное распоряжение своим жизненным циклом (это я адресую даже не Вам, а себе). Я бы желал стать человеком, который создал библиотеку для программирования тензорных ядер на ассемблере. За такое изобретение любой криптовалютчик поцеловал бы Вас в PCI-слот
Макросы обычно касаются наборов инструкий, которые с 80х годов не менялись. В apx обещают обратную совместимость. Кроме того, ради пользователей, не купивших новый проц, еще лет 10 точно нафиг не надо будет этот новый набор инструкций нигде применять. А может и совсем не надо будет, как с х64 получилось. С помощью fasmg можно любой набор инструкций описать. --- Сообщение объединено, 16 июн 2026 в 20:06 --- Чтобы не быть завязанным на преимущества фасма, вроде автоматической генерации или кодирования/декодирования налету данных или кода, просто алгоритмом или по шаблону почти любого формата в момент компиляции, просто сделай шнягу для кодирования инструкций вручную. Ведь это то, как фасм видят однопроходные цэшники: штука для кодирования инструкций вручную.
Обычно после пары сотен строк таких регулярных выражений человек всё равно приходит к нормальному парсеру, только потеряв время. Как по мне ограничений особо нет, в том же макро-фасме, можно реализовать почти любой макрос, а если упираешься в ограничения конкретной реализации, то проблема чаще в архитектуре макроса, а не в самом инструментарии Также имхо если человек пишет свой набор макросов, синтаксис нужно продумывать заранее, чтобы он был последовательным и интуитивным, иначе со временем придётся писать отдельную документацию по его использованию и объяснять исключения всякие
А может быть, человек вознамерился написать библиотеку макросов для матричных вычислений с помощью AVX и FMA? Можно. Но не описан же. Так что тема вполне себе диссертабельная.
Ну тогда на случай если ТС заблудится в лесу, мох растет с северной стороны ствола, а пить воду из стоячих водоемов нельзя.
