Семпл. --- Сообщение объединено, 8 мар 2026 --- Вот что найдено, w10: На сколько это верно нужно проверять.
CaptainObvious, смотреть нужно с разных сторон. Пока еще не известно какая из идей "выстрелит" в итоге. Но я бы просто для этого создал топик рядом...
Mikl___, те кто предлагает нейронки пусть сделают небольшой poc демонстрирующий их гениальную идею. Благо веса нейросети можно сохранять в файл и подгружать по мере надобности, чтобы не захламлять тему.
Пришел к некоторым выводам по поводу пакета масм64. Изначально была неопределенность нужно ли добавлять masm32. Сейчас точно знаю ответ на этот вопрос и могу обьяснить почему. Чуть позже напишу дорожную карту к чему на данный момент пришли и какие имхо есть перспективы. f13nd, сказал интересную фразу: Именно это и надо делать. --- Сообщение объединено, 9 мар 2026 --- От простого к сложному.
По-моему, однозначно - нужно, если, конечно, с этим у вас не добавятся лишние проблемы, по поводу адаптации всей вашей задумки. Можно даже и компилятор CL(32\64) добавить с рантаймом. Чтобы на скорую руку можно было что-то простенькое скомпилировать. Ну а там, смотрите сами - советовать, ведь, всегда проще. Мне кажется, что MASM64\32 - однозначно не стоит сбрасывать со счетов тому, кто интересуется ассемблерами. Все-таки, как не крути, а MASM - это глыба, потому что Microsoft - глыба. Далеко ходить не нужно. Достаточно взять WinDbg. Есть ему альтернатива? Ответ очевиден. Да, я понимаю, есть x64Dbg и т.п, но все-таки, по сравнению с WinDbg, это чуть упрощённые вещи, да и по-моему, не совсем профессиональные.
Research, Вот что у меня ещё есть на диске (masm-файлы от VS 2015). Когда-то скачивал с GitHub, сейчас этого ресурса нет. Может пригодится. https://www.sendspace.com/file/16dv4t
Код (Text): import os,ctypes data=""" .code mainCRTStartup proc ret mainCRTStartup endp end """ data = data.encode('utf-8') CreateNamedPipeW = ctypes.windll.kernel32.CreateNamedPipeW ConnectNamedPipe = ctypes.windll.kernel32.ConnectNamedPipe CloseHandle = ctypes.windll.kernel32.CloseHandle WriteFile = ctypes.windll.kernel32.WriteFile PIPE_ACCESS_INBOUND = 0x00000001 PIPE_ACCESS_OUTBOUND = 0x00000002 PIPE_TYPE_BYTE = 0x00000000 PIPE_TYPE_MESSAGE = 0x00000004 PIPE_READMODE_MESSAGE = 0x00000002 pipe = CreateNamedPipeW( '\\\\.\\pipe\\masmnamedpipe'.encode('utf-16le'), PIPE_ACCESS_OUTBOUND, PIPE_TYPE_BYTE, 1, len(data), 0, 0, 0 ) INVALID_HANDLE_VALUE = 0xFFFFFFFFFFFFFFFF if (pipe==0 or pipe==INVALID_HANDLE_VALUE): print('ERROR: Can not create named pipe') quit() os.system('masm64\\bin\\ml64.exe /c /Fo "1.obj" \\\\.\pipe\masmnamedpipe') res = ConnectNamedPipe(pipe, 0 ) if (res==0): CloseHandle(pipe) print('ERROR: Can not connect named pipe') quit() byteswritten = b'\x00\x00\x00\x00\x00\x00\x00\x00' res = WriteFile( pipe, data, len(data), byteswritten, 0 ) if (res==0): CloseHandle(pipe) print('ERROR: Can not send data') quit() CloseHandle(pipe) Масму можно даже передать файл через пайп, без приземления на жесткий диск. Таким образом можно не просто под комментарии что-то припрятать, а реализовать полноценный внешний препроцессор с блекджеком и всей атрибутикой. Директивы для сборки, макроязык какой-ниубдь расширенный, что угодно. Мне не понятно только зачем это надо, масм не дает ни единого преимущества.
В учебных/творческих целях. Был масм32 от майкрософт, в котором было: Набор директив, упрощающих написание структурированного кода: Высокоуровневые конструкции: Директивы .if, .else, .while, .repeat и .until позволяют писать условия и циклы без ручного создания меток и переходов -2-6-10. Это делает код более читаемым и похожим на языки высокого уровня. Упрощённый вызов процедур: Директива invoke берет на себя рутину по размещению аргументов в регистрах или стеке в соответствии с соглашением о вызовах. В паре с директивами PROTO (объявление прототипа) и PROC (определение процедуры) это обеспечивает проверку количества и типов аргументов -1-2-6. Макросы для прологов/эпилогов: Microsoft предоставляет набор макросов (например, push_reg, alloc_stack), которые помогают генерировать корректные прологи и эпилоги функций с unwind-информацией, что критически важно для 64-битной платформы -7. Однако, самое главное изменение произошло при переходе на 64-битную архитектуру: Они просто удалили эти возможности для 64-битной версии. (Если я правильно понял). Потом какой-то чел написал temphls для masm64 со всеми этими макросами. Сделать в виде примеров решающие задачи от простого к сложному, например: Математические и арифметические вычисления Это основа для старта. Задачи включают вычисление выражений, работу с разными типами данных и целочисленную арифметику. Пример 1 (Базовые операции): Вычислить Y = (x1 - x2) + (x3 - x4) для процессора Intel 8080. Значения переменных хранятся в памяти -2. Пример 2 (Разные типы данных): Вычислить D = (B * C) + A, где A — двойное слово, B — слово, а C — байт. Это учит правильно работать с операндами разного размера -4. Пример 3 (Алгоритмы): Вычисление суммы ряда 1 + 3^2 + 5^2 + ... или нахождение наибольшего общего делителя (НОД) двух чисел по алгоритму Евклида -3-10. Работа с данными и структурами Здесь основное внимание уделяется обработке массивов, битовым операциям и логике. Пример 1 (Обработка массивов): Найти сумму элементов одномерного массива из 10 чисел. Это классическая задача на организацию циклов и адресацию памяти -2-10. Пример 2 (Логические операции): Вычислить значение логической функции: Y = ((¬x1) & x2) ∨ (x3 & (¬x4)). Такие задачи полезны для понимания работы на битовом уровне -2. Пример 3 (Условные вычисления): Вычислить Y[k] = (A[k]^2 + k) * (A[2k+1] + A[2N+2-2k]) для массива A, проверяя деление на ноль -9. И т.д. Список можно продолжать бесконечно. Перевести такие примеры с фасма. Сейчас с помощью нейронок будет легче разобраться чем раньше. Добавить CL(32\64). Сделать такие же примеры для С. Работа с строками. Интернет. Все что угодно. Когда нужно решить какую-либо задачу под рукой будет готовый код. Вообще подобный подход в другой сфере (не с ассемблером) мне оч. даже помогал. Если перенести на ассемблер, мне кажется будет то же самое. Можно назвать это экспериментом. Практика - критерий истины.
Смысл этого утверждения в том, что если тезис подтверждается практикой, то он является истиной. Например если масм позволяет эффективней других трансляторов решать практические задачи, то он самый эффективный. А у тебя телега впереди лошади: если масм зачем-то понадобится, то вот он.
Пусть будет масм. Без других трансляторов. Я как Когнитрон Фукусимы: ищу закономерности бесполезные для решения практических задач.
Что касается masm'а, то у меня мнение по нему, пока а уровне интуиции. Рождён в солидной конторе, живет не один десяток лет, а значит логически - должен быть надежен, по сравнению с более молодыми конкурентами. Примеров с кодом - море. Ида, кстати, генерирует ассемблерный код, который ближе к masm'у. Его (код) потом приходится меньше исправлять, для компиляции в masm. А так, да, согласен с Фаиндом, что Фасм по части гибкости и всяких крутых и хитрых фишек, пока, по-моему, непревзойдён никем из его конкурентов. Единственно, что меня удивляет в FASM, так это то, как там реализована система генерации отладочных символов.
А вы последнюю версию сборки UASM скачайте, там, вроде, и количество и качество. https://www.terraspace.co.uk/uasm257_x64.zip --- Сообщение объединено, 11 мар 2026 --- Я, конечно, понимаю, что с моим мнением на WASM особо никто не считается, как собствено и со мной, но всё же внесу свои "пять копеек". Моё мнение, если уж заморачиватся с MASM32\64, то нужно брать ML64, ML, link и все остальное, что связано с MASM из VS 2026. Все-таки как не крути, а компилятор в VS плотно связан с ассемблером. А так как формат закрытый, то доказать, что там ничего не улучшалось со времён VS 2008, невозможно. А вдруг улучшалось, а поддержка новых инструкций... Повторюсь, мое мнение - MASM64\32 брать из VS 2026 pro, ну или хотя бы из VS 2022 pro. Компилятор - не критично, можно и из VS 2008 взять. Хотя, опять же, все они разные. Но это если по большому счёту заморачиваться. Было бы, конечно, здорово заполучить компактный набор всех компиляторов VS. Но я понимаю - мечты, мечты...
