Попытался скомпилировать один из старых проектов в x64 и получил: '__asm' keyword not supported on this architecture. Это как понять? Совсем отменили ассемблерные вставки? Или все-таки что-то можно сделать?

Здравствуйте, SWW, Вы писали:

SWW>Попытался скомпилировать один из старых проектов в x64 и получил: '__asm' keyword not supported on this architecture. Это как понять? Совсем отменили ассемблерные вставки? Или все-таки что-то можно сделать?

В студии совсем отменили. Но мы для этого пользуем Intel Compiler — там все это работает при чем кросплатформенно (то есть синтаксис асм вставок одинаковый для всех платформ).

Если нет возможности перети на интел — надо задуматся а так ли нужны вам асм вставки? Оптимизаторы нынче очень хорощи, а для векторных операций есть intrinsic functions (правда под msvc только до SSE2 — может информация уже устарела так как я все еще на 2008 студии)

Здравствуйте, Аноним, Вы писали:


А>Если нет возможности перети на интел — надо задуматся а так ли нужны вам асм вставки? Оптимизаторы нынче очень хорощи,

так бывает так что алгоритм уже на асме — таким уж из декомпилера вышел

Здравствуйте, dudkin, Вы писали:

А>>Если нет возможности перети на интел — надо задуматся а так ли нужны вам асм вставки? Оптимизаторы нынче очень хорощи,

D>так бывает так что алгоритм уже на асме — таким уж из декомпилера вышел

Не поверите — но таки да, бывает что алгоритм сразу на асме. В первую очередь те, в которых активно используется перенос — вычисление различных CRC, скремблеры. У меня на асме написана функция преобразования числа с плавающей точкой из старых форматов (IBM, VAX) в IEEE — они отличаются лишь положением мантиссы и значением порядка, поэтому проще передвинуть ее на новое место, чем извлекать отдельно мантиссу и порядок, а потом вычислять из них double. Наконец, поменять байты проще на асме, прямо на месте, командами xchg или bswap чем вызывать hton* из отдельной библиотеки — если файл записан в big-endian, а файлы бывают в несколько гигов, то выигрыш по времени оказывается весьма существенным.

Здравствуйте, SWW, Вы писали:

SWW>Не поверите — но таки да, бывает что алгоритм сразу на асме. В первую очередь те, в которых активно используется перенос — вычисление различных CRC, скремблеры. У меня на асме написана функция преобразования числа с плавающей точкой из старых форматов (IBM, VAX) в IEEE — они отличаются лишь положением мантиссы и значением порядка, поэтому проще передвинуть ее на новое место, чем извлекать отдельно мантиссу и порядок, а потом вычислять из них double. Наконец, поменять байты проще на асме, прямо на месте, командами xchg или bswap чем вызывать hton* из отдельной библиотеки — если файл записан в big-endian, а файлы бывают в несколько гигов, то выигрыш по времени оказывается весьма существенным.

чего же не поверить! сам балуюсь иногда с detours и thunking или имею дело чужими имплементациями у которых сырц-кода нету

Здравствуйте, dudkin, Вы писали:

А>>Если нет возможности перети на интел — надо задуматся а так ли нужны вам асм вставки? Оптимизаторы нынче очень хорощи,
D>так бывает так что алгоритм уже на асме — таким уж из декомпилера вышел
Мнэээ. И вы из декомпилера его назад в компилер и в продакшен? И не стрёмно?

Здравствуйте, Banned by IT, Вы писали:

BBI>Мнэээ. И вы из декомпилера его назад в компилер и в продакшен? И не стрёмно?

было дело всю ночь потом не спал боялся.

Здравствуйте, SWW, Вы писали:

SWW>Не поверите — но таки да, бывает что алгоритм сразу на асме. В первую очередь те, в которых активно используется перенос — вычисление различных CRC, скремблеры.
У меня когда то были асм вставки в коде для длинной математики. Как раз сложение, вычитание, сдвиг. На момент написания был солидный выигрыш по скорости. Не так давно выкинул, оказалось что сегодняшний компилер сгенерил код, по скорости отличающийся от асма на величину, крайне близкую к погрешности измерений.

SWW> У меня на асме написана функция преобразования числа с плавающей точкой из старых форматов (IBM, VAX) в IEEE — они отличаются лишь положением мантиссы и значением порядка, поэтому проще передвинуть ее на новое место, чем извлекать отдельно мантиссу и порядок, а потом вычислять из них double.
Дык асм для этого не нужен. Битовые операции и сдвиги есть и в С. Ну а потом кастануть память в double.

SWW>Наконец, поменять байты проще на асме, прямо на месте, командами xchg или bswap чем вызывать hton* из отдельной библиотеки — если файл записан в big-endian, а файлы бывают в несколько гигов, то выигрыш по времени оказывается весьма существенным.
Давно уже есть интринсики. В том же ICC есть _bswap

Выносите асм код в отдельные асм файлы в виде функций, добавляете их в проект и компилируете с ml64 (входит в студию). На мой взгляд так даже лучше чем мешанина на двух ЯП в одном файле

Здравствуйте, SWW, Вы писали:

SWW>Здравствуйте, dudkin, Вы писали:

А>>>Если нет возможности перети на интел — надо задуматся а так ли нужны вам асм вставки? Оптимизаторы нынче очень хорощи,

D>>так бывает так что алгоритм уже на асме — таким уж из декомпилера вышел

SWW>Не поверите — но таки да, бывает что алгоритм сразу на асме. В первую очередь те, в которых активно используется перенос — вычисление различных CRC, скремблеры. У меня на асме написана функция преобразования числа с плавающей точкой из старых форматов (IBM, VAX) в IEEE — они отличаются лишь положением мантиссы и значением порядка, поэтому проще передвинуть ее на новое место, чем извлекать отдельно мантиссу и порядок, а потом вычислять из них double. Наконец, поменять байты проще на асме, прямо на месте, командами xchg или bswap чем вызывать hton* из отдельной библиотеки — если файл записан в big-endian, а файлы бывают в несколько гигов, то выигрыш по времени оказывается весьма существенным.

Х64 асм другой, так что даже еслиб __asm была бы -пришлось бы все переписывать

Здравствуйте, <Аноним>, Вы писали:

А>Х64 асм другой, так что даже еслиб __asm была бы -пришлось бы все переписывать
Какой ещё другой?
Команды те же, 32битные регистры всё ещё доступны. Мой 32битный код собрался и даже заработал без проблем.

Здравствуйте, SWW, Вы писали:

SWW>Попытался скомпилировать один из старых проектов в x64 и получил: '__asm' keyword not supported on this architecture. Это как понять? Совсем отменили ассемблерные вставки? Или все-таки что-то можно сделать?

Вот эту тему почитать — http://www.rsdn.ru/forum/cpp/4410023.flat.aspx#4410023

Автор:
Дата: 06.09.11

Здравствуйте, SWW, Вы писали:

SWW>Попытался скомпилировать один из старых проектов в x64 и получил: '__asm' keyword not supported on this architecture. Это как понять? Совсем отменили ассемблерные вставки? Или все-таки что-то можно сделать?

Теперь в MSVC нужно писать asm функции целиком, а не вставками.

Здравствуйте, fdn721, Вы писали:

F>Здравствуйте, SWW, Вы писали:

SWW>>Попытался скомпилировать один из старых проектов в x64 и получил: '__asm' keyword not supported on this architecture. Это как понять? Совсем отменили ассемблерные вставки? Или все-таки что-то можно сделать?

F>Теперь в MSVC нужно писать asm функции целиком, а не вставками.

Их и раньше можно было писать целиком х) Раньше было удобно вставить в релиз breakpoint по int 3 и ловить отладчиком х) Хотя в студии вроде есть для этих целей механизмы.

Здравствуйте, Аноним, Вы писали:

А>Если нет возможности перети на интел — надо задуматся а так ли нужны вам асм вставки? Оптимизаторы нынче очень хорощи, а для векторных операций есть intrinsic functions (правда под msvc только до SSE2 — может информация уже устарела так как я все еще на 2008 студии)

Ну, например, если у вас в программе есть элементы JIT-кодогенерации, то вставки часто всё-таки нужны, так как хочется как-то понятно записать те кусочки, из которых JIT-кодогенератор будет собирать код...