Добрый день! В связи с переходом с низкоуровневого программирования (MASM) на высокоуровневое (Visual Studio) вознили вопросы: 1. Каким образом в VS можно добавить ассемблерный код и как грамотно взаимодействовать со структурами данных (массивами, записями) VS ? для начала хотелось бы реализовать что-нибудь на подобие asm-команды BSR r32, mem32 Код (Text): __forceinline int bsr(int * value) ... bsr eax, value return eax; ... 2. Можно ли каким-нибудь образом прикрутить obj-файл MASM'a к VS ? 3. Какой синтаксис ассемблера наиболее распространён: AT&T или MASM ? Имеет ли смысл учить AT&T, если с ним ещё не знаком? Буду рад услышать ваше мнение.
slavanap берем файлик масм кода, прикрепляем к прожекту, делаем asm.h где в си варианте описываем прототипы public фунок с асм файла. Пользуемся и наслаждаемся что нету тех ублюдошных вставок, которые не проканают в х64 моде. *ток вот с хидерами и либами масма не разобрался (мож в студии гдет есть, хз) - копировал с масма себе в прожект и не парился. чо там с gcc по этому поводу = хз.
по умолчанию gcc использует AT&T синтаксис, который первое время у человека, привыкшего к интеловскому синтаксису, вызывает жуткое недоумение... на самом деле AT&T получше вписывается в концепции вставок в си-код, но с какой-то там бородатой версии gcc можно спокойно писать код в интеловском синтаксисе, используя ключ компилятора -masm=intel (если ничего не путаю)... только вот вид асм-вставки в gcc (asm("<код>") отличается от vs (__asm { <код> }), так что кросскомпиляцию видимо не получится сделать... а чем не устраивает сторонний ассемблер, способный генерировать обж-файлы в gcc и vs форматах? например, yasm, nasm или fasm... yasm вообще очень легко интегрируется со студией посредствам одного xml-файла... и кстати в gcc/mingw при сборки под x64 архитектуру асм-вставки перевариваются прекрасно, еще один повод забить на дураций мелкомягкий компилятор...
Видимо тем что он хочет чтобы код инлайнился. slavanap - всё украдено до тебя: http://msdn.microsoft.com/en-us/library/x8zs5twb.aspx Для BSR есть интринсик _BitScanReverse: http://msdn.microsoft.com/en-us/library/fbxyd7zd.aspx
а что мешает форс-инлайнить функцию из асм-файла? я правда не пробовал так делать, но что-то мне подсказывает, что с этим не должно быть проблем...
Rel Это значит что целостность системы нарушается, проекции изменяются в обход защиты и вредонос отваливается при восстановлении кодосекций ?
Функции даже из другого сишного файла не инлайнятся без Link-Time Code Generation. С кодогенерацией времени сборки инлайнятся за счёт того, что компилятор в объектник вместе с бинарным кодом сохраняет байткод (промежуточный) для функции. Для функций из asm файлов (написаных вручную) байткода нету, и никакой forceinline их заинлайнить компилятору не поможет.
slavanap По пункту №2 - в некоторых сборках студии (не экспрес, а в монструозных есть ml.exe но не .inc-файлов ни туториалов с эксамполами не прилагается). В таких зборках в проэкт можно включать даже .asm-файлы (главное помнить что окончательнуюю зборку делает линкер), то есть обозначать в листинге на Си нужно функциюю как extern - ну и с понятиями манлинг/декорирование ознакомится (чтоб понять как линкер находит в обьекниках и статических библиотеках функиции). PS нехитрый макрос #define db _emit - если решился использовать __asm{}
что касается MASM сказать не могу, но например сгенеренные на FASMе формата MS COFF объектники без проблем прицепляются. там только небольшой нюанс в декорации, но это ерунда. довольно удобно использовать туже Build-Event систему. ну а если писать функцию то пожалуй так: __declspec(naked) unsigned int __stdcall _bsr(int *ptr) { __asm { xor eax, eax push ebx mov ebx, [esp+8] //так то +4 но изза push ebx +8 mov ebx, [ebx] bsr eax, ebx pop ebx ret 4 } }
Лучше, конечно, не мешать. Если не хотите дольше искать ошибки и получить лишние проблемы при переходе между платформами. + не указали такой способ: написать .DLL на асме и добавить её.
