Inline Assembler отлично подходит, описанный в статье метод может пригодиться например если есть уже готовый код на ассемблер, мы можем просто добавить .asm файл и вызывать его напрямую.
Кроме того мы можем создать проект используя только .asm файлы (без С++), добавив метод main:
.CODE
main PROC
invoke printf, ADDR helloWorld
ret
main ENDP
Честно говоря, чем думать как уложиться в intrinsics и во что оно перейдет при компиляции — порой проще на ассемблере написать. Вот для использования SIMD-инструкций порой действительно хватает их intristic эквивалентов.
В студии уже есть готовый и очень неплохой отладчик. Плюс привычка. Для кого-то это может быть определяющим фактором. Как вариант возможно, что имеется несколько проектов, один из которых — библиотека на ассемблере. Такой метод позволит всё держать в одном месте.
Ну и последний тезис «за» — вставки ассемлера ограничены в возможностях — емнип, нельзя объявлять данные, что приведёт к мешанине двух языков в пределах одной функции.
Правда в Visual Studio нет подсветки синтаксиса для Asm (хотя где-то помнится пробегала инструкция по допиливанию подсветки, может даже на хабре).
Я не говорю, что плох (хотя, имхо, большинство его плюсов для исследования программы или уровня ядра, где студия вообще не даст развернуться, ну разве что 2 компа и COM порт :) или в этом плане уже что-то улучшилось?). Просто если уже есть студия с неплохим отладчиком — то почему её не использовать?
В статье есть борьба с искажением имён компилятором C++. Но C++ кода нет. Может, использовать в качестве основного файла main.c, чтобы проблемы не возникало?
Кстати, здесь можно найти информацию о том, как добавить поддержку асма и для 2010 вижлы, и как прикрутить к ней же подсветку синтаксиса асма, а так же там море другой интересной информации.
При разработке программ для Windows может возникнуть необходимость написать часть кода на ассемблер.
Программ? Нда…
Необходимость написать часть кода на ассемблере может возникнуть (а может и не возникать) при разработке драйверов специфичных устройств, но никак не программ.
Помнится, как-то оптимизируя программу заменил кусочек кода на вставку ASM размером всего десяток строк. Получил прирост скорости итераций в сотни раз.
Вместо нескольких минут результат выдавался через доли секунд.
Ахахах. Это не означает, что того же самого нельзя было добиться без использования ассемблера.
Если Вас не затруднит, приведите, пожалуйста, пример high-level кода и, соответственно, low-level кода которым Вы его заменили, получив прирост в сотни раз — будет очень любопытно посмотреть этот парадоксальный пример — возможно, научусь чему-нибудь.
High-level уже нету. за 10 лет потерялся (только заново писать). а asm попробую завтра найти. Это на PC.
Я сейчас с сигнальными процессорами связан. Так вот любая быстрая цифровая обработка сигналов немыслима без asma.
А вот драйверы отлично пишутся на C/C++, т.к. там примитивные команды управления и никакие специфические инструкции процессора не требуются.
Вы занимаетесь коммерческой разработкой на С++? Я признаюсь на С++/ASM писал только для себя, поэтому не могу ничего утверждать. Но ведь есть множество вещей вроде MMX/SSE, декодирования видео и т.п. и даже если есть обертки на С++ для их использования, эти обертки ведь тоже кто-то писал?
В целом не берусь утверждать, но думаю тут работает «никогда не говори никогда». У меня например была необходимость написать часть кода на ассемблер, пусть и в учебных целях, но необходимость.
Специально сейчас скачал исходники mplayer, минимум 15 файлов полностью на ассемблере, чем это не программа?
Эти 15 файлов, я думаю, отвечают за декодирование видео используя очень низкоуровневые методики (перечисленные Вами SIMD, а также, CUDA и т.д.).
У меня, наверное, какой-то неправильный подход, но я никогда (да, да, никогда) не возьмусь за реализацию декодирования видео, кроме случая, если вся моя задача будет состоять в написании декодера видео. Точно также, как Вы не будете писать драйвер мыши при разработке GUI.
Опять же, наверняка, я какие-то неправильные программы пишу, если у меня никогда не встречается интенсивных вычислительных задач. Я имею ввиду настолько интенсивных, чтобы их можно было бы ощутимо улучшить при помощи низкоуровневых хаков (давайте не будем забывать, что это именно хаки). Из практики могу вспомнить всего два проекта с интенсивными вычислениями. В одном использовался С++ только потому, что аналогов такой удобной геометрической библиотеки, как CGAL для .NET я не нашёл (там ещё потянулись большие числа GMP, MPFR, так что о .NET можно было сразу позабыть, если не хотелось изобретать аналоги драйверам мыши, только в мире математических алгоритмов). Во втором проекте на ура был использован C#. Я не хочу здесь втягиваться в холивар C# vs C++ (сам фанат C++, но помимо фанатизма есть ещё реальная жизнь — C# объективно позволяет реализовывать проекты на порядки быстрее).
>По умолчанию Visual Studio не распознает файлы с кодом на ассемблер.
Это действительно так. По-моему, это связано с тем, что при создании файла из студии нет выбора типа .asm — можно создать текстовый файл и сменить расширение.
Но, если вы вдруг забыли, где настраивается Custom build rules, можно просто исключить файл .asm из проекта и добавить его снова — в этом случае система подхватит его правильно и предложит диалоговое окошко, в котором уже есть соответствующее правило.
Ассемблер для Windows используя Visual Studio