Простые алгоритмы шифрования

Во-первых, преимуществ у rept не так много:
1. возможность записать в одну строку.
2. возможность задания переменной с начальным значением (хотя часто и repeat'овского % достаточно).
Хотя, согласен, что rept в общем и целом удобнее
А во-вторых, не так часто приходится делать столь огромное кол-во циклов rept/repeat, тем более, внутреннее содержание этих директив может куда существеннее влиять на скорость компиляции.

Ага, а теперь посмотрите в диспетчер задач, сколько памяти жрёт при этом fasmg, несколько гигов (у меня он отваливается аккурат после 4 ГБ)!

 

Вообще-то вон во втором тесте repeat работать не будет совсем. На выходе 1 байт. По-моему он к макродвижку вообще не относится, просто повторяет конструкцию n раз, потому такие хорошие результаты в старом фасме с повторением 1 байта. Ну и его ценность только в скорости там, где он будет работать. В новом rept и repeat похоже одно и то же. Ну и как бы почти в два раза шустрей, чем на старом.

--- Сообщение объединено, 6 окт 2018 ---

repeat это еще не самый ужас

 

дело вовсе не во вкусах и цветах, а в реальных возможностях инструмента и его перспективах. сравни пул разрабов гсс и масма == картина маслом.

 

masm можно в студии юзать, добавляя асм-листинги в проект.

 

Это будет то же самое, что любым другим ассемблером объектный файл собрать и прилинковать куда надо.

 

Гсс - это GCC ? Как его вообще можно сравнивать с MASM'ом, ещё бы Python предложил
Как же сравнивать перспективы разных ассемблеров?

И вообще, мы сейчас о компиляторах или о диалектах? К примеру, UASM (диалект MASM) вплоне себе живёт и развивается.
Что же касается fasm, то там нововведения появляются раз в 3-5 лет (не считая багфиксов в 1.73). Томаш сам говорил, что добавлять новых фич особо не планирует, и так fasm 1 слишком раздут. Плюс это его стремление реализовывать всё через макросы лично мне кажется довольно сомнительным. Но там есть реально интересные фишки, которых нет в других асмах: virtual, used, load/store, match, операторы bsr/bsf и т.п., которые склоняют сделать выбор в его пользу.
Вполне неплохо себя чувствует NASM. И проектов на нём очень много. Есть NASMX.
Неперспективно писать, пожалуй, на TASM, ну и малоизвестных ассемблерах. А тройка MASM, NASM, fasm вполне себя неплохо чувствуют, ИМХО.

--- Сообщение объединено, 7 окт 2018 ---

Макросы fasm'а, кстати, тоже устарели. Они были написаны очень давно, и там нельзя, например, использовать library несколько раз, импортировать через import новые функции (если они были добавлены, скажем, при использовании win32ax.inc). Сейчас макродвижок fasm 1 позволяет это делать, но include'ы, см. дату файлов – 2009-2012 годов (лишь некоторые 2014-2015 годов).

--- Сообщение объединено, 7 окт 2018 ---

Раз уж тема про пул разработчиков пошла:
fasm разрабатывает 1 человек
NASM – 11 человек + 3 администратора
UASM – 2 человека
MASM – детище Microsoft, но он вообще сейчас обновляется? Не считая макромодулей Hutch'а и т.п.

 

кто-то же обновляет ml.exe, идущий в комплекте со студией, значит какая-то работа идет.

 

Майкрософт от МАСМ не оказывался ... он поставляется в составе студии.

 

Не выбросили, а выставили. И не на помойку, а в музей.

 

f13nd, видимо майкрософт таки хочет всех перевести всех на дотнет или еще какую-то ересь, и запретить винапи и прочий "опасный" код, или как там они это называют. Но, поддержка аес-инструкций есть, значит, какая-то работа да ведется (или велась), хотя бы по минимуму.

 

Пока будет выходить новые процы в них будут новые команды.
А значит и асм обновлять нужно.
Пока мелкософт будет выпускать ОС под них будет нужен АСМ.
Драйвера ...ядро...планировщики и пр.
Поэтому я бы не хоронил раньше срока.

 

asmlamo, всё это можно написать на текущей редакции MASM'а (и даже более ранних).
Достаточно только нужные инструкции добавлять и всё.

 

чой-то я не понял.. о каких разных ассемблерах идёт речь??? и при чём тут питон?

впрочем, список поддерживаемых платформ действительно несопоставимый

 

А, ну если под GCC подразумевается GAS, тогда ок. Пул действительно разный.
Но синтаксис GAS не всем привычен, даже в режиме Intel.

 

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

 

Для локеров обычно AES+RSA используют. Поточные шифры для локеров - самоубийство.

Но всё равно gcc ещё остаётся внушительным инструментом разработки, и те кто уже привыкли с ним работать врядли перейдут на что-то новое(как я например). А для мелких проектов вообще нет разницы чем они собраны(по крайней мере она не заметна).

 

А в чём, собственно, Clang интереснее, чем GCC ?

 

Единственные сомнительные достоинства которые у него есть - генерить не такой простой код(что позволяет его легче реверсить, по мне это минус), и то что он разрабатывался в качестве замены gcc(учитывая что gcc обновляется это бесполезно, даже аргументом нельзя назвать пока не будет реальных результатов) а также своё ide-gui делать на шланговой основе(гуй можно прикрутить куда угодно, главное чтоб не мешал. так что тоже сомнительное преимущество).
https://ru.m.wikipedia.org/wiki/Clang

И судя по тестам на скорость(первые гугловские ссылки), шланг пока отстаёт от gcc так что какая из него замена - непонятно. Вывод: пока шланг не покажет кардинально нового подхода к собиранию екзешников, или хотя бы достигнет одинаковой производительности с gcc - переходить на него не имеет смысла.

 

LLVM ?

 

Иии? Что вам как программисту это даёт? Оптимизация лучше будет едва ли от этого. По крайней мере, я на некоторых задачах тестил, GCC работал быстрее. Где-то, безусловно, Clang будет быстрее (особенно на вводе-выводе, ибо он не использует MSVCRT). Т.е. это спорный момент. А ещё что? Платформ у GCC даже поболее будет, насколько я знаю. У Clang файл меньше получается, если компилить со встройкой библиотек. Ну т.е. у каждого свои + и -.
Чем Clang однозначно лучше, и чтобы это было существенно?