Преимущества Asm над С

ну да, макросами можно и вложенность вызова функций сделать, кто ж спорит ? И ездить можно на одноколесном велосипеде(кстати таки есть люди, которые сие делают и заметьте, делают это в цирке(какая замечательная случайность получилась, не правда ли ?)). Макросами можно делать, но кто потом это будет анализировать, что там ваши макросы делают ? Все это лишние трудозатраты. Фасм да, хорош, но под него нет хидеров. И хидеры это не только

; zlib1 API calls

Код (Text):

1. import zlib1,\
2.     adler32,'adler32',\
3.     adler32_combine,'adler32_combine',\
4.     compress,'compress',\
5.     compress2,'compress2',\
6.     compressBound,'compressBound',\
7.     crc32,'crc32',\
8.     crc32_combine,'crc32_combine',\
9.     deflate,'deflate',\
10.     deflateBound,'deflateBound',\
11.     deflateCopy,'deflateCopy',\
12.     deflateEnd,'deflateEnd',\
13.     deflateInit2_,'deflateInit2_',\
14.     deflateInit_,'deflateInit_',\
15.     deflateParams,'deflateParams',\
16.     deflatePrime,'deflatePrime',\
17.     deflateReset,'deflateReset',\
18.     deflateSetDictionary,'deflateSetDictionary',\
19.     deflateSetHeader,'deflateSetHeader',\
20.     deflateTune,'deflateTune',\
21.     get_crc_table,'get_crc_table',\
22.     gzbuffer,'gzbuffer',\
23.     gzclearerr,'gzclearerr',\
24.     gzclose,'gzclose',\
25.     gzclose_r,'gzclose_r',\
26.     gzclose_w,'gzclose_w',\
27.     gzdirect,'gzdirect',\
28.     gzdopen,'gzdopen',\
29.     gzeof,'gzeof',\
30.     gzerror,'gzerror',\
31.     gzflush,'gzflush',\
32.     gzgetc,'gzgetc',\
33.     gzgets,'gzgets',\
34.     gzoffset,'gzoffset',\
35.     gzopen,'gzopen',\
36.     gzprintf,'gzprintf',\
37.     gzputc,'gzputc',\
38.     gzputs,'gzputs',\
39.     gzread,'gzread',\
40.     gzrewind,'gzrewind',\
41.     gzseek,'gzseek',\
42.     gzsetparams,'gzsetparams',\
43.     gztell,'gztell',\
44.     gzungetc,'gzungetc',\
45.     gzwrite,'gzwrite',\
46.     inflate,'inflate',\
47.     inflateBack,'inflateBack',\
48.     inflateBackEnd,'inflateBackEnd',\
49.     inflateBackInit_,'inflateBackInit_',\
50.     inflateCopy,'inflateCopy',\
51.     inflateEnd,'inflateEnd',\
52.     inflateGetHeader,'inflateGetHeader',\
53.     inflateInit2_,'inflateInit2_',\
54.     inflateInit_,'inflateInit_',\
55.     inflateMark,'inflateMark',\
56.     inflatePrime,'inflatePrime',\
57.     inflateReset,'inflateReset',\
58.     inflateReset2,'inflateReset2',\
59.     inflateSetDictionary,'inflateSetDictionary',\
60.     inflateSync,'inflateSync',\
61.     inflateSyncPoint,'inflateSyncPoint',\
62.     inflateUndermine,'inflateUndermine',\
63.     uncompress,'uncompress',\
64.     zError,'zError',\
65.     zlibCompileFlags,'zlibCompileFlags',\
66.     zlibVersion,'zlibVersion'

А еще и структуры и константы и много еще чего. Начинаешь это всё ковырять и в какой-то момент понимаешь, что нужно либо отказываться от хидеров(что и сделал автор компилятора) и начать проставлять это все вручную в кодесе. А потом исчи их в разных проектах, что ты там где попрописывал, чтобы это скопипастить и перенести в другой проект. Все это несколько попахивает маразмом. С другой стороны, если взять тему оптимизации под x86, то тут авторы, которые вопиюще кричат об оптимизации несколько лукавят. Покажите мне программу, которая делает полезные действия без вызовов апи. Нету. А ведь те же апи написаны на си. А си не тру т.к там не максимальная скорость и не максимальная компактность. По поводу компактности кодеса - тут тоже лукавят. Возьмем некоторый абстрактный проект, который что-то там делает. Сколько там будет по строкам, как думаете ? Ага, не меньше 10-20к строк. Если меньше, то это не проект, а какая-то мелкая утилита(кстати мелкая утилита получается не менее 0,8-1,5к строк). На си 20 тыс строк - это серьезнейший проект типа зевса. И ковыряться в асм проекте на 10к строк я вам скажу не сахар. Да и суппортить тоже проблематично.

 

common_up

есть мнение, что под 10 к на асме имеется сплошной дамп одной функцией, без единой метки, а под С - хорошо структурированный код, грамотно побитый на понятно названные функции, все с комментариями? так?
на С можно писать и многие пишут вполне замороченно. и С, и С++ дают очень большую свободу в написании. в то же время, и на асме можно бить на функции, оформлять, не забывать вставлять понятные метки. это не проблема языка, это проблема конкретных людей.

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

 

Си с асм-вставками не руляд?

 

Rockphorr

Личные предпочтения. Причём относится к коду на любом языке. Код становится малочитабельным. Ищешь полчаса по трём строчкам, где же некоторый счётчик инкрементируется, и находишь вложенным вызовом в вызове API, не имеющей отношения к самому счётчику.
common_up

Речь шла только о макросах из официального пакета. Так что аргумент не засчитан.

Этой сказкой пусть сторонники masm новичков пугают. А мы-то знаем, что всё можно найти, если поискать. Плюс существуют конвертеры.

Есть разница между системными и прикладными задачами. Прикладные задачи решаются без вызова апи, и именно они чаще всего нуждаются в оптимизации. Но готовая программа, решающая ту же прикладную задачу, существует в среде (ОС), с которой должна сосуществовать по её правилам, поэтому вполне очевидно, что практически любая программа работает с API системы (создать окно, записать в файл, передать сообщение по сети и т.п.). Т.е. тот факт, что полезных программ без вызовов системного API нет, совсем не говорит о том, что нет полезных действий, не требующих системное API.
Но это я так... указать на несостоятельность аргументации. Хотя сам я не сторонник ручной оптимизации в asm-коде, т.к. современные компиляторы оптимизируют без трудозатрат и зачастую ещё и гораздо качественнее.

Для некоторых узкоспециализрованных задач существуют гораздо более практичные причины, исключающие возможность использования чего-либо кроме asm. Вытекают они из двух частично перекрывающихся основных: необходимость использования архитектурных особенностей (как уже сказал deLight) и необходимость в предельно возможном контроле результирующего кода (хотя уже вижу, что повторяю мысль qqwe).

 

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

 

у кого сохранился рассказъ про фабрику фабрик фабрик и ... приаттачте пожалста

.....

спасибо iZzz32

 

...

 

в принципе - все вышеизложенное автором имеет силу при должной сноровке и умении

 

qqwe
> с другой стороны, он имеет 2 преимущества - доступ ко всем возможностям процессора
> и контроль над получаемым кодом. если вам эти 2е не настолько нужны, то и не надо
ни фига он не имеет доступа. куча команд, поддерживаемых ЦП, транслятору асма ни за что не скормишь. ну разве только через db, но в сях есть emit, однако, писать в машинных кодах желающих мало. или назовите мне транслятор, поддерживающий хотя бы 90% документированных команд из мануала интела.

контроль над кодом тоже относительный. одной и той же мнемонике может соответстовать очень много разных команд ЦП и асм выбирает их самостоятельно.

> например, вы никогда свою х86 асм прогу не перекомпилируете на любимый арм-планшет (разве что с борщем)
спорное суждение. асм x86 -> си -> асм арм.

 

kaspersky

Назовите хотя бы пять мнемоник, не поддерживаемых fasm'ом (помним, да, что их всего около полутора тысяч?), но присутствующих в intel'овской документации.

Тоже ерунда. У мнемоник имеются модификаторы, позволяющие однозначно указать, какая именно инструкция требуется. Хотя да... тут я прогнал слегка. Не для всех инструкций можно выбрать конкретный опкод, но тогда и смысла в мнемониках по сравнению с опкодом через db нету. Но указать желаемую инструкцию — далеко не предел возможностей контроля кода.

 

Там кажется еще AVX2 нет.

Да всё это конечно очень сложно. На моем сайте описан один из новых вариантов решения этой проблемы - Эпиморфный ассемблер.

 

s_d_f
Да ну. Их ещё вообще нет. Даже в основной трёхтомник не добавили. И до процессоров с их поддержкой ещё два года.

Что же до такого уровня контроля кода, как возможность выбора между 33 C0 и 31 С0... Поясните, пожалуйста, в чём конкретно здесь проблема? Если я точно знаю, что в данной точке кода мне необходимо именно 31 С0, а никак не 33 C0, то с какой стати мне вообще использовать мнемонику? Я могу представить случаи, где такое может понадобиться (например, компиляция произвольного кода в опкоды в пределах альфанумерики), но решается это уже тогда на уровне макросов и постобработки скомпилированного кода (благо, fasm это позволяет сделать в пределах одной трансляции на основе только лишь исходника), а никак не выбором более подходящей мнемоники. Ну за исключением случаев, где различное кодирование приводит к по сути различным инструкциям (jmp short/jmp near или int3/int 3).

 

l_inc
> Что же до такого уровня контроля кода, как возможность выбора между 33 C0 и 31 С0...
> Поясните, пожалуйста, в чём конкретно здесь проблема? Если я точно знаю, что в данной
чем отличается "xor eax, eax" от "foo = 0" ? и асм, и яву скрывают бинарное представление целевого кода. и асм, и яву действуют только в рамках возможностях языка, но никак не ЦП. применительно к xor eax, eax -- мне пофиг 33/31, но не пофиг префикс 66. при написании смеси 16-битного и 32-битного кода это актуально, а непосредственного контроля над ним нет.

 

kaspersky

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

опять же, при выборе опенсорсного компилера можно рулить этим процессом на тонком уровне, вплоть до интерактивности.
(пробовал только в фасме)

ссылкой на готовый конвертер не кинете? есть как раз такая необходимость

 

доработать существующий компилер? написать для своих спеццелей свою спецтулзу?

 

kaspersky

Это называется "косить под дурачка".
Тем, что foo = 0 может означать:
1) xor eax,eax
2) mov eax,0
3) sub eax,eax
4) and eax,0
а также (часто же можно в начале ф-ии увидеть xor ebx,ebx и далее использование этого нуля)
5) mov eax,ebx
6) and eax,ebx
...) куча вариантов с любым другим РОН'ом или вообще памятью.
Т.е. нельзя даже указать, чтобы это гарантированно память или конкретный регистр был. Какое вообще может быть сравнение?

А ещё и бинарное представление, и яву скрывают транзисторы. Отсюда тоже несомненно следует идентичность уровней абстракции бинарного кода и питона, верно?

В fasm есть.

P.S. Пропустил одну глупость.

Рамки ассемблера — это и есть рамки возможностей ЦП. Причём независимо от того, существует ли соответствующий транслятор ассемблера, достигающий этих рамок.

 

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

 

s_d_f
Ага. Т.е. проблема возникает тогда, когда нужно бинарно идентичное переассемблирование. Вариант, конечно. Но послушать kaspersky, так нет разницы, использовать asm или c для решения указанной проблемы.

 

l_inc
> Это называется "косить под дурачка".
> Тем, что foo = 0 может означать:
> 1) xor eax,eax
> 2) mov eax,0
...
> 4) and eax,0
Это называется "косить под дурачка" (c) ваш. покажите мне компилятор, который транслирует в and eax, 0. скорее всего будет xor eax, eax. ну может быть sub eax, eax. и только самый кривой оптимизатор вставит mov eax, 0, что, впрочем, ничего не меняет. ну и чем оно отличается от xor eax, eax? ну разве тем, что команда длиннее, но это непринципиально.

горзадо принципиальнее, что eax это 32 бита, а foo -- хз сколько. но это тоже фигня. потому что если нам нужно N бит, то так нужно и писать. сегодня нам нужно 32, а завтра 24.

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

>> и асм, и яву скрывают бинарное представление целевого кода.
> А ещё и бинарное представление, и яву скрывают транзисторы. Отсюда
> тоже несомненно следует идентичность уровней абстракции бинарного
> кода и питона, верно?
уровни абстракции -- это одно. возможность контроля -- это другое. понятно, что на питоне инжект кода в другой процесс не напишешь. и даже на си потребуются спец-компиляторы. однако, шелл-коды на асме пишутся с трудом. по крайней мере некоторые фрагменты приходится писать вручную в машинных кодах.

 

kaspersky

в свое время было принципиально, тк запись числа в регистр делала переназначение (пере.. хм, как оно зовется?) регистра, а операция над ним - нет.

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

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