qqwe ...тк асмы предназначены для обеспечения возможностей управления процессором, а не для легкого понимания людьми. (хотя, не все там так ужасно, как писали тут. особенно, насчет своего кода. если свой код стал нечитаем - самое время задуматься об его оформлении) Именно. При отвратном (а такое очень часто) проектировании вам не поможет ни C, ни пайфон, ничего. Все это от тупого менеджмента - напейсать побыстрее и побыстрее продать тонны гуанокода. Недокодеры со спичками в глазах лабают код который действительно даже на HLL читать нельзя. Под это начали разрабатывать всякие "среды программирования", IDE и прочую хренотень. Ручная коробка передач и автоматика. Легкого понимания людьми? Ну мне нужно совсем немного времени чтобы сказать что делает код если я вижу его в IDA. Уже скомпиллированный. Вы не умеете "читать" код на _любом_ языке (с минимальной документацией - может быть)? Может быть вам надо слегка подучиццо прежде чем начинать лабать реально используемые программы? Нигде в современных высоких технологиях некомпетентность не цветет так обильно как в программировании.
забивать надо молотком, а мерить линейкой полностью согласен. Возьмите все уже линейку и померяйтесь вместо того чтобы создавать подобные топеки.
Я твердо заявляю, что мой уровень знаний значительно ниже, а то и вовсе несопостовим с уровнем знаний некоторых присутствующих товарищей. Лично своими глазками проглядел не одну простыню кодеса на разных трансляторах, даже на некрофильском тасм. Нежелание писать грамотный код есть и у ассемблерщиков. Тут даже комменты не помагают. Про именованые метки никто к сожеленью из них не слыхивал. Приходится собирать код и его трейсить параллельно чтиву и проставлять реальные комменты. А только потом уже конструировать какие-то мысли относительно того, как оно всетаки работает. На это все тратится очень много времени. Асм так же учит глобальному проектированию. 10к раз подумаешь прежде чем писать процедуру ибо если неверно ее спроектировал - переписывать ее прийдется чуть ли не с нуля. Следующий момент - это отсутствие компактности. Вложенность функций - вот один из главных козырей того же си. Можно одной строкой написать то, что на асме разольется на две печатных страницы. Важность асма неоспорима, но с практической точки зрения писать на нем кодесы прикладного уровня просто глупо. По моему мнению. Доказательством оного является отсутствие серьезных проектов темной тематики. Одны тупые семплы, не более. По крайней мере в паблике не проскакивало ничего толкового. Одни недопроекты и семплы. Значит люди очехляются и понимают, что коммерческие продукты на асме в нашей тематике - это пустая трата времени и нервов.
Раз уж тема приняла такой беспощадный оборот, то я тоже выскажусь Бесспорно, что если ваша задача перековырять некий кусок данных (зашифровать, расшифровать и любые другие извращения на ваш вкус) и вы совершенно не обременены никакими ограничениями на код,то си вам тут поможет лучше всего Асм, конечно это дрочево, однако скорее всего именно он поможет вам прочитать чужую программу, если ее автор не поделился с вами исходниками, имхо полезно некоторые задачи порешать в обоих языках, реверс чужих прог, особенно с рипом чужих процедур, а также реверс своих прог научит вас лучше использовать ваш компилятор, и какбэ намекнет как нужно писать на асме - не стоит перебарщивать с оптимизацией, вы поймете ценность некоторых расходов с точки зрения повторного использования реализуя на асме высокоуровневые конструкции хоть с помощью макросов например, лучше понимаешь их ценность и обретаешь опыт целесообразного их применения
common_up А. Ясно. Спасибо. Вложенные вызовы имеются в виду: Код (Text): invoke MessageBox,<invoke GetTopWindow,[hwnd]>,\ "Message","Caption",MB_OK ;© fasm manual
мне кажется, что этот стиль приносит больше вреда чем пользы в тексте все должно быть скомпановано так чтобы потом в отладчике скомпоновать таже разделитеми
Rockphorr В принципе согласен (хотя не из-за вида в отладчике), но в данном случае это вопрос возможности, а не целесообразности.
В какой-то версии С (С99?) есть вложенные ф-ии, они даже используются в загрузчике ELF'ов (насколько я помню, в ф-ии поиска символа). Зачем они нужны я так и не понял.
Mika0x65 Мне известны вложенные функции в функциональных языках, где они так же естесственны, как в C объявить переменную: Код (Text): primes :: [Integer] primes = sieve [2..] where sieve (head:tail) = head : sieve (filter (head `notDivider`) tail) notDivider b a = a `mod` b /= 0 main = print (take 20 primes) Или в объектно-ориентированных, где функция может находиться внутри класса, описанного внутри функции или даже внутри вызова функции: Код (Text): private void addButton(Container bContainer) { final JButton myButton = new JButton("My Button"); myButton.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { JOptionPane.showMessageDialog(null, "Button clicked", "Message", JOptionPane.INFORMATION_MESSAGE); } }); bContainer.add(myButton); } Но в C впервые слышу. Можно глянуть на пример, как это выглядит?
Нашел пример. Ну в примере с Java это понятно -- там чтобы создать метод в ActionListener, надо создать файл ActionListenerXxx.java, в нем унаследоваться и т.д. Такое сворачивание позволяет бороться с издержками языка. А насчет С -- ну будет вложенная ф-ия видна только из внешней. Похоже на попытку С быть чуть-чуть С++.
Ассемблер можно условно поделить на 2 языка. Это чистый ассемблер когда мнемоники записываются строго в столбик и макро ассемблер когда макросы типа .if .elseif используют по полной. Недостатки первого 1. Не компактность кода. 2. Как правило ассемблерщики не в состоянии дать нормальные имена меткам, из-за их количества. 3. Большой код трудно поддерживать, хотя все равно существуют крупные проекты такие как fdbg. Недостатки второго 1. Это уже не совсем ассемблер. Код может быть сопоставим и похож на Cишный. 2. Не переносимость кода. 3. Очень высокий порог вхождения для новичков. Использовать ассемблер можно только для узкого круга задач. Написание ядра системы, создание хорошего компилятора, реверсинг вредоносного ПО.
s_d_f чистый ассемблер и макро ассемблер когда макросы типа .if .elseif используют по полной не существуют ибо это вещи в сферическом вакууме основное отличие асма от машкода автоматическое счисление меток и текстовые взаимооднозначные подстановки идея их добавления очень древняя, совершенствовались лишь механизмы их реализации
Из старинной справки masm32 Говорится, что многие не желают использовать invoke потому-что это уже не низкий уровень. Такой вот вакуум. И fdbg я упомянул не случайно, хотя он и на фасме.
s_d_f писание на асме как правило является следствием того, что должна быть взаимооднозначность между написанным и скомпилированным все обертки в масме и наверно в фасме ей обладают то бишь позволяют самому программисту раскрутить код который генериться ваша выдержка из справки - идиома нубов-маргиналов-идеалистов, обычно после того как человек перепишет код определенной функциональности на все лады которые ему хочется он успокаивается и если страсть к кодингу не ограничивалась простым приобретением знаний о принципиальной работе он пакует эти решения в процедуры макросы которые использует в дальнейшем мое личное мнение об инвоке и if - слишком маленкий кусочек кода они сворачивают, проверка типов которую они с собой приносят не окупает затрат на гемор с ними, в частности инвоке заставляет получить все параметры перед первым пушем, тогда как непосредственный вызов позволяет "пушить" в перемешку с расчетами параметров, .if - беззнаковый, чтоб был знак надо дописывать сдворд птр что вообщем нивелирует экономию букв
Не знаю, быть может и так. С макросами при желании можно решить любую проблему с синтаксисом. А я в windows.inc добавлю строчку кода Код (Text): sxd equ <sdword ptr> И всё будет как надо.
Это ладно. Я в одном проекте асмовый код через C++-овый препроцессор прогонял - и нормально. Компилилось как wasm, так и gnuc, несмотря на то, что они такие разные.