MASM64 SDK

уже давно интересны перспективы ассемблера в современном мире... компиляторы ЯВУ уже давно генерируют хороший оптимизированный код, который иногда оказывается быстрее/компактнее написанного вручную на ассемблере... с каждым днем смысл юзать ассемблер все больше и больше теряется... даже среди ассемблеров зачем юзать масм, когда есть фасм и насм?

 

в чем преимущество масма в сравнении с фасмом и насмом?

 

ну я то никакой ассемблер не юзал уже давно, кроме ассемблерных вставок в сишечке, но помню, что как минимум система макросов в том же фасме достаточно мощная... там люди умудрялись даж морферы и обфускаторы делать на одних макросах...

 

Курсы по ассемблеру точно никто не купит, так что пожалуй он и незачем

 

стоп-стоп, Товарищ.. асм есмь машинный язык и для нетипичных кодов/платформ он был/есть/будет единственным инструментом. другой Вопрос, когда на асме лабается типичка (особенно х86), вот тута действительно фиХЪня.

окошки на асме действительн@ == лажа, а вот нормальный курс по созданию сверхбыстрых кодов под различные платформы был бы на вес золота.. сейчас в проганье жутко много гламура, практически и суперкомпы перешли в область гламура

 

Имхо не бывает никаких сверхбыстрых кодов на ассемблере, бывают программисты-недоучки и их высокоуровневые убожества. В 99.5% программ несколько сэкономленных машинных тактов на итерацию никакой погоды не сделают.

 

сможешь ли ты делать полиморфные коды без асма ? а использовать векторные регистры для кэширования переменных в скалярных кодах? 3oe (out-of-order execution) тожЪ сомнительно без асма. вообще, реально толково выжимать из машины её возможности без асма практически не получится.. другой Вопрос, что можно замутить смарт генератор асм портянок, кой будет в авто-режиме тестировать различные вариации асм кода для заданной функции. Но трЭба, шобЪ он пахал с приемлемой скоростью, а тожЪ в комбинаторную яму зараза свалится

 

Если не путать понятия машинный код и ассемблер, то ассемблер полиморфному движку ни на входе ни на выходе не нужен. Генератор асм портянок - странная идея решать задачу, где все неизвестные заранее известны.

 

под "асмом" я всё-таки подразумеваю машинный код

почему странная 777 одно дело ты имеешь некую абстрактную функцию в виде псевдокода, а другое Дело == получить её Практическую реализацию под заданную платформу и с приемлемыми показателями скорости/размера/устойчивости работы/энергопотребления/..

 

Устойчивость работы и энергопотребление? То есть выбрать от 1 до 10 степень устойчивости работы? Скомпилить энергосберегающую функцию? С защитой от порчи и сглаза.

 

какая проблема морфить исходники ЯВУ на этапе компиляции? в сишечке и плюсах можно вставить любую асм-вставку в кол... если нужно что-то более близкое к машине, то можно морфить скажем LLVM IR Сlang'a или GIMPLE у GCC... в GCC можно вклиниться даж на этапе распределения регистров и что-то поморфить через модификацию RTL (register transfer language)...

 

Так он уже заявил, что кодирование инструкции называет ассемблером. То есть вставил опкод нопа - уже считай ассемблер подрубил.

 

Векторизация по-прежнему хреновая и сложно поддаётся оптимизациям со стороны компилятора.

 

также хреново дело обстоит с out-of-order execution, а про использование векторных регистров в качестве кэша в скалярных кодах совсем речи нет.

1. речь идёт о том, чтобы морфить на-лету == в циклах зачастую остаются "мёртвые" ветвления, кои в пустую загружают проц, и динамические коды позволяют патчить эти места.
1.2. асм является наиболее шустрым способом патчить код в озу на ран-тайме.
2. если про высокоуровневый морф, то наилучшим вариантом являются указатели на функции в с/с++ и довольно неплохо себя может показывать скриптянка.
===
но в любом случае №1 зер убер-гут

 

насчет GCC не знаю, но в LLVM есть некая векторизация: https://llvm.org/docs/Vectorizers.html

метаморф имеется ввиду? типа программа модифицирует сама себя и записывает в себя же?

 

угу.

 

ну кстати метаморф можно запилить и на ЯВУ, которые могут работать с кодом как с данными... например, .NET или Java компилятся в байт-код стековой виртуальной машины, можно из PE или JAR прочитать собственный байт-код, динамически его заморфить, записать байт-код обратно... ну или тот же Python, можно зачитать исполняемый скрипт, распарсить его модулем ast, отморфить его визиторами абстрактного синтаксического дерева и переписать собственный файл... но это все так для лулзов... вряд ли это окажется как то полезно на практике...