Как стать автором
Обновить

Комментарии 31

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

Кроме того мы можем создать проект используя только .asm файлы (без С++), добавив метод main:
.CODE
main PROC
invoke printf, ADDR helloWorld
ret
main ENDP
Кстати, да. Как-то даже не думал, что с этим проблемы могут быть. В качестве некоторой замены, правда есть x64 Intrinsics
Честно говоря, чем думать как уложиться в intrinsics и во что оно перейдет при компиляции — порой проще на ассемблере написать. Вот для использования SIMD-инструкций порой действительно хватает их intristic эквивалентов.
>создать проект используя только .asm файлы (без С++)
Тогда может не создавать С++ проект в VS, а использовать для этого другие инструменты?)
В студии уже есть готовый и очень неплохой отладчик. Плюс привычка. Для кого-то это может быть определяющим фактором. Как вариант возможно, что имеется несколько проектов, один из которых — библиотека на ассемблере. Такой метод позволит всё держать в одном месте.
Ну и последний тезис «за» — вставки ассемлера ограничены в возможностях — емнип, нельзя объявлять данные, что приведёт к мешанине двух языков в пределах одной функции.
Правда в Visual Studio нет подсветки синтаксиса для Asm (хотя где-то помнится пробегала инструкция по допиливанию подсветки, может даже на хабре).
А чем SoftICE плох? В своё время написаное на MASM'e да и не только отлаживалось именно им, хотя конечно, у всех свои предпочтения)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я не говорю, что плох (хотя, имхо, большинство его плюсов для исследования программы или уровня ядра, где студия вообще не даст развернуться, ну разве что 2 компа и COM порт :) или в этом плане уже что-то улучшилось?). Просто если уже есть студия с неплохим отладчиком — то почему её не использовать?
2 компа не нужно. достаточно виртуальной машины
Айс больше заточен под отладку драйверов. Дебажить им обычные программы неудобно.
В статье есть борьба с искажением имён компилятором C++. Но C++ кода нет. Может, использовать в качестве основного файла main.c, чтобы проблемы не возникало?
Насколько я понял, это просто пример. В реальном C++ приложении так обойтись не получится:)
Интересная статья!
Я у себя в Колледже и вправду учил только асм на консольке. Теперь буду пробовать переходить под Win.
Спасибо!
НЛО прилетело и опубликовало эту надпись здесь
void* readName()
{
char name[255];
scanf("%s", &name);
return &name;
}

Возвращение указателя на локальные данные процедуры это так брутально…
Вообще-то, слово «ассемблер» легко склоняется:

И. ассемблер
Р. ассемблера
Д. ассемблеру
В. ассемблер
Т. ассемблером
П. ассемблере

Или у вас старая болезнь переводчиков, связанная с боязнью склонять иностранные слова? Раньше вот «Интернет» не склоняли.

НЛО прилетело и опубликовало эту надпись здесь
Может, стоило бы упомянуть, что возврат адреса локальной переменной в других случаях чревато осложнениями?
Кстати, здесь можно найти информацию о том, как добавить поддержку асма и для 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# объективно позволяет реализовывать проекты на порядки быстрее).
При разработке программ для Windows может возникнуть необходимость написать часть кода на ассемблере.

Я просто оставлю это без комментария.
>По умолчанию Visual Studio не распознает файлы с кодом на ассемблер.

Это действительно так. По-моему, это связано с тем, что при создании файла из студии нет выбора типа .asm — можно создать текстовый файл и сменить расширение.

Но, если вы вдруг забыли, где настраивается Custom build rules, можно просто исключить файл .asm из проекта и добавить его снова — в этом случае система подхватит его правильно и предложит диалоговое окошко, в котором уже есть соответствующее правило.

Многие из нас изучали ассемблер в университете, но почти всегда это ограничивалось простыми алгоритмами под DOS.

У нас, к сожалению, было ещё хуже — даже до ввода-вывода чего-то в консоль под DOS дело не дошло.

Полезная статья!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.