Прошу прощения что я написал тему так расплывчита, но если писать подробно, то строка т форме для темы сообщения не поместися. Я так понял что в сегодняшней жизни лучше писать на языке С или С++, а использовать ассемблер как вставки в код. Я понимаю что если делаешь программу на языке С для микроконтроллера и в итоге программа не влезает в микроконтроллер, так как памяти у микроконтроллера мало, это понятно надо писать на ассемблере тогда, а мне бы хотелось узнать в каких случаях использовать ассемблеровские вставки на стадии написания кода, а не когда его весь наберёшь. В каких случаях надо использовать ассемблеровские вставки? И ещё я сейчас изучаю DirectX 9 SDK на С++. Имеет ли смысл потом изучать DirectX 9 SDK на ассемблере, если да, то в чём преимущества?
Насчёт микроконтроллеров (и не только). На асме есть смысл писать в первую очередь тогда, когда нужна очень хорошая оптимизация (но, есно, для этого надо хорошо владеть языком, понимать, как процессор исполняет команды и т.д. и т.п., поэтому средний программист вряд ли напишет на асме расчётную задачу эффективнее, чем на ЯВУ при использовании качественного оптимизирующего компилятора). Кроме того, если программа состоит почти исключительно из манипуляций битами-байтами (а таковых программ на микроконтроллерах много), ассемблер также может оказаться привлекательным выбором, даже если особой оптимальности не требуется, поскольку подобные операции для него совершенно естественны (в отличие от, например, сложных расчётных задач). Насчёт ДиректХ. Никакого смысла в асме (кроме оптимизации) там нет, поэтому и прибегать к нему есть смысл только в случае слишком низкой эффективности кода на ЯВУ.
zuze Почитай пожалуйста эту тему: http://wasm.ru/forum/viewtopic.php?id=26074&p=1 В особенности посты криса =) http://wasm.ru/forum/viewtopic.php?pid=236082#p236082
zuze Смотря что кодить. Если ты текстовый редактор писать собрался, то ассемблер не нужен. Если ты собрался писать чтото связанное с вирусами, руткитами, под процессор и тп., то тут только асм.
zuze Очень просто. Когда не хватает возможностей ЯВУ - используй асм. Или когда на ассемблере проще написать - редкий случай, как в посте у SII. На асме очень интересно писать, но, к сожалению, процесс длительный.
zuze Научиться писать хотя-бы маленькие, но полноценные приложения на asm увлекательно и полюбому полезно, т.к. позволяет понять суть работы программы "изнутри" (в том числе и DX с его COM), такое понимание ооочень труднодостижимо при использовании исключительно ЯВУ, но стопудово полезно после него совсем по другому смотришь на различные трюки и приёмы оптимизации в Hi level. Для МК юзаю исключительно асм и очень им доволен - получается красиво, компактно, эффективно. Для win и т.п. полноценная прога на асме слишком громоздка (в смысле исходник) и тяжела в сопровождении, поэтому там он целесообразен для "поиска просветления" и разработки отдельных функций или их библиотек критичных к скорости выполнения.
Нигде. Сейчас компиляторы могут оптимизировать код похлеще твоих асмовских вставок. Ну только если ФАСМ, то да.
Большего бреда трудно себе представить. А если MASM то уже всё, не подходит? Какая разница какой ассемблер использовать. Это не HLL, компилятор не оптимизирует. И разные ассемблеры код сгенерируют одинаковый. Задолбала тупая пропаганда >:[
Ага. Лапши ещё много осталось? Пример в студию. Пример кода который после компиляции FASM будет оптимальнее, чем после компиляции MASM.
jaja Забавно! Похоже надо учиться писать в машинных кодах, а не на АСМе. =D =D Потом окажится, что ФАСМовский компилятор и машинный код оптимизирует.
Гы-гы вот пример того, как применение простейших правил оптимизации - "разбивай сложные составные команды типа xchg, loop, movsd и т.п. на простые 'RISK' комбинации" и "по возможности разбивай цепочки зависимых команд" даёт в 1,4 раза ускорение перед извращениями компилятора ). Причём для того чтобы применять эти правила вовсе не обязательно досконально помнить навороченные тонкости с временем исполнения команд, это просто задачка на сообразительность - а-ля увлекательная головоломка ), которая даёт эффект в большинстве случаев, хотя если ещё и тонкости камешков знаешь и помнишь, результат может быть лучше, хотя может оказаться зависимым от модели процессора (но полюбому получится шустрее компиляторного). А про FPU вообще отдельная песня ) например преобразование float/double в int MSVC 9 делает так: Code (Text): Address Hex dump Command Comments 00408840 /$ 833D 100F4100 CMP DWORD PTR DS:[410F10],0 00408847 |. 74 2D JE SHORT 00408876 ; --------- Это основной вариант работы -------------- 00408849 |> 55 PUSH EBP 0040884A |. 8BEC MOV EBP,ESP 0040884C |. 83EC 08 SUB ESP,8 0040884F |. 83E4 F8 AND ESP,FFFFFFF8 ; QWORD(8.-byte) stack alignment 00408852 |. DD1C24 FSTP QWORD PTR SS:[LOCAL.2] 00408855 |. F20F2C0424 CVTTSD2SI EAX,QWORD PTR SS:[LOCAL.2] ; FLOAT 0.5859569403873213 0040885A |. C9 LEAVE 0040885B |. C3 RETN ; --------- Это непонятно когда используется -------------- 0040885C |. 833D 100F4100 CMP DWORD PTR DS:[410F10],0 00408863 |. 74 11 JE SHORT 00408876 00408865 |. 83EC 04 SUB ESP,4 00408868 |. D93C24 FSTCW WORD PTR SS:[LOCAL.0] 0040886B |. 58 POP EAX 0040886C |. 66:83E0 7F AND AX,007F 00408870 |. 66:83F8 7F CMP AX,7F 00408874 |.^ 74 D3 JE SHORT 00408849 ; <- переход на основной вариант ; --------- сюда переход после проверки флага CMP DWORD PTR DS:[410F10],0 в самом начале -------------- ; надо полагать этот флаг устанавливается при инициализации CRT и означает наличие/отсутствие sse2 00408876 |> 55 PUSH EBP 00408877 |. 8BEC MOV EBP,ESP 00408879 |. 83EC 20 SUB ESP,20 0040887C |. 83E4 F0 AND ESP,FFFFFFF0 0040887F |. D9C0 FLD ST 00408881 |. D95424 18 FST DWORD PTR SS:[ESP+18] 00408885 |. DF7C24 10 FISTP QWORD PTR SS:[ESP+10] 00408889 |. DF6C24 10 FILD QWORD PTR SS:[ESP+10] 0040888D |. 8B5424 18 MOV EDX,DWORD PTR SS:[ESP+18] 00408891 |. 8B4424 10 MOV EAX,DWORD PTR SS:[ESP+10] 00408895 |. 85C0 TEST EAX,EAX 00408897 |. 74 3C JE SHORT 004088D5 00408899 |> DEE9 FSUBP ST(1),ST 0040889B |. 85D2 TEST EDX,EDX 0040889D |. 79 1E JNS SHORT 004088BD 0040889F |. D91C24 FSTP DWORD PTR SS:[ESP] 004088A2 |. 8B0C24 MOV ECX,DWORD PTR SS:[ESP] 004088A5 |. 81F1 00000080 XOR ECX,80000000 004088AB |. 81C1 FFFFFF7F ADD ECX,7FFFFFFF 004088B1 |. 83D0 00 ADC EAX,0 004088B4 |. 8B5424 14 MOV EDX,DWORD PTR SS:[ESP+14] 004088B8 |. 83D2 00 ADC EDX,0 004088BB |. EB 2C JMP SHORT 004088E9 004088BD |> D91C24 FSTP DWORD PTR SS:[ESP] 004088C0 |. 8B0C24 MOV ECX,DWORD PTR SS:[ESP] 004088C3 |. 81C1 FFFFFF7F ADD ECX,7FFFFFFF 004088C9 |. 83D8 00 SBB EAX,0 004088CC |. 8B5424 14 MOV EDX,DWORD PTR SS:[ESP+14] 004088D0 |. 83DA 00 SBB EDX,0 004088D3 |. EB 14 JMP SHORT 004088E9 004088D5 |> 8B5424 14 MOV EDX,DWORD PTR SS:[ESP+14] 004088D9 |. F7C2 FFFFFF7F TEST EDX,7FFFFFFF 004088DF |.^ 75 B8 JNE SHORT 00408899 004088E1 |. D95C24 18 FSTP DWORD PTR SS:[ESP+18] 004088E5 |. D95C24 18 FSTP DWORD PTR SS:[ESP+18] 004088E9 |> C9 LEAVE 004088EA \. C3 RETN причём этот монстр сидит в CRT и соответсвенно требует её подключения И всё это вместо простого и банального FIST / FISTP, которая конечно не свехшустрая команда, но явно не стоит замены на такое чудище ) Это маленькие иллюстрации к "пониманию работы прог изнутри" и поиску просветления через асм )
Это смотря какого компилятора, и смотря на сколько шустрее По сравнению с MS VS (про Intel C++ я вообще молчу) намного быстрее не получится. Незначительно ускорить можно (до 15-20% если повезёт), но времени на это уйдёт куда больше. Это не эквивалентная замена. Приведение float к int ВСЕГДА округляет к нулю, а FIST - в зависимости от режима округления FPU. А вот менять этот самый режим округления FPU - это очень напряжно для процессора. Хочешь просто FIST/FISTP - укажи ключ /QIfist.
вопрос о нужности программирования на асме я бы сравнил с вопросом о нужности программирования как процесса которым озабочен лично. сотни миллионов людей имеют дело с компами/мк разных видов очень часто и даже кажен день и совершенно не нуждаются в программировании. если им начать убеждать начать программировать - они вам сообщат миллион причин по каким это делать не стоит. и будут совершенно правы. причин по которым проганье == пустая потеря времени существенно больше и они основательнее доводов в пользу программинга. впрочем это относится к абсолютно всему. скажите, зачем нам речь, если мы не слушаем собеседника или сразу же забываем разговор, а если и запоминаем, то никогда не пытаемся понять, что именно человек имел ввиду? а если, что и слушаем с удовольствием, то это совершенно бесполезные или даже вредные вещи?
cppasm я же привёл пример где по сравнению с MSVC получилось в 1,4 раза, причём основное время ушло на разборку недоразумения с rnd, а не на саму оптимизацию, которая там очевидна ) А за /QIfist спасибо - с ним в моей проге сразу исчезли артефакты в отрисовке мелких линий, которые из-за режима округления частенько не сходились на 1-2 пикселя, а то я уж думал дело в фичах GDI+
cppasm Вообще-то 15-20% -- это отнюдь не незначительно. И если на 15% ускорить какой-нить цикл, который выполняется миллионы раз, итоговый выигрыш будет очень большим. Ну а сколько времени уйдёт на ручную оптимизацию, это совсем другой вопрос, а именно стоит ли овчинка выделки. Для программы одноразового использования уж точно не стоит, ну а вот, например, для планировщика ОС...
