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

M>Вопрос давний, но до сих пор интересно все-таки, зачем Microsoft нарочно не стала его поддерживать в своих компиляторах C/C++, требуя отдельных *.asm файлов с функцией? Притом и в gcc и в clang есть встроенный в C/C++ 64-битный ассемблер, то есть, это похоже какое-то принципиальное решение, вряд ли для MS было сложно его реализовать.

Но это надо было его реализовать правильно. Это включает в себя описание входных параметров (чтобы не надо было их доставать из памяти или заботиться о том, чтобы оказалось только в совместимом регистре), выходных параметров и побочных эффектов. Если такого нет, компилятору приходится начинать гадать, что же ему надо сохранять и почему. В GCC всё это есть, в Watcom есть (или было, пока жил), в некоторых других — тоже. MSVC сканирует ассемблерный код на предмет конкретных регистров, но, согласно доке, все 6 основных (не включая SP и BP) на входе и на выходе такого блока не важны, то есть ему приходится всё сохранять в память перед ассемблерным блоком и восстанавливать после него. Мало того, там нужно сохранять Flags! (наверно, имеется в виду только DF и тому подобное, но это уже показательно). А в случае 64-битки сохранять и восстанавливать уже 14 регистров, включая аргументы функции... дорого.

Дальше вопрос внутренностей компилятора — насколько он сочетается с внедрением в него цельных блоков кода с описанием их входов/выходов. Что GCC именно так и работает — общеизвестно. Аналогично Clang. ICC — не знаю, но хотя бы совместим. Про MSVC тут мало что известно, даже после перехода на SSA.

Думаю, вывод прост — прикинули стоимость внедрения, что надо или разрабатывать с 0 своё, или позорно копировать идеи у ненавистного GCC, и вердиктом стало "нуегонах".

Лично мне тут обидно за мелкие, но очень полезные иногда фишки по ускорению критичных участков. Например, типа "косого" умножения и деления. В микрософтовском же SafeInt3 проверка, что умножение 32*32 не переполняется, делается через расширение обоих аргументов до 64 бит — удорожание операции в разы (а на 32-битке вообще это уходит в библиотеку). Замена на трёхстрочную ассемблерную вставку ускоряет на порядки. Да, это частный узкий случай, но были отзывы, что нарывались. Или атомарные операции — отлично встраиваются (хотя тут intrinsicʼи обычно даны).

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

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

M>>Вопрос давний, но до сих пор интересно все-таки, зачем Microsoft нарочно не стала его поддерживать в своих компиляторах C/C++, требуя отдельных *.asm файлов с функцией? Притом и в gcc и в clang есть встроенный в C/C++ 64-битный ассемблер, то есть, это похоже какое-то принципиальное решение, вряд ли для MS было сложно его реализовать.

N>Но это надо было его реализовать правильно. Это включает в себя описание входных параметров (чтобы не надо было их доставать из памяти или заботиться о том, чтобы оказалось только в совместимом регистре), выходных параметров и побочных эффектов. Если такого нет, компилятору приходится начинать гадать, что же ему надо сохранять и почему. В GCC всё это есть, в Watcom есть (или было, пока жил), в некоторых других — тоже. MSVC сканирует ассемблерный код на предмет конкретных регистров, но, согласно доке, все 6 основных (не включая SP и BP) на входе и на выходе такого блока не важны, то есть ему приходится всё сохранять в память перед ассемблерным блоком и восстанавливать после него. Мало того, там нужно сохранять Flags! (наверно, имеется в виду только DF и тому подобное, но это уже показательно). А в случае 64-битки сохранять и восстанавливать уже 14 регистров, включая аргументы функции... дорого.

Действительно "век живи — век учись", я даже не знал, что MSVC сохраняет регистры перед входом в ассемблерный блок. Я то думал, что это исключительно проблемы программиста, который осознанно использует настолько низкоуровневые механизмы. Тогда действительно проще уж делать вместо вставок описывать отдельные функции на ассемблере в отдельном файле.

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

M>Вопрос давний, но до сих пор интересно все-таки, зачем Microsoft нарочно не стала его поддерживать в своих компиляторах C/C++, требуя отдельных *.asm файлов с функцией? Притом и в gcc и в clang есть встроенный в C/C++ 64-битный ассемблер, то есть, это похоже какое-то принципиальное решение, вряд ли для MS было сложно его реализовать. Конечно, вставлять ассемблерные вставки прямо внутрь кода на C++ не очень-то хорошая практика программирования, но все-таки иногда это удобно и в других компиляторах вроде бы никто не выкидывал эту возможность.

Внятного ответа от микрософт так и не нашлось, есть всякие инсинуации, но похоже просто кому-то было лень (в Intel С++ ведь есть).

Т.к. недавно пришлось с этим ограничением столкнуться, то решил не заморачиваться и использовать MASM64. Ничего сложного не оказалось, устанавливается расширение AsmDude и вперед. Стандартный отладчик VS для asm работает хорошо.

Вопрос давний, но до сих пор интересно все-таки, зачем Microsoft нарочно не стала его поддерживать в своих компиляторах C/C++, требуя отдельных *.asm файлов с функцией? Притом и в gcc и в clang есть встроенный в C/C++ 64-битный ассемблер, то есть, это похоже какое-то принципиальное решение, вряд ли для MS было сложно его реализовать. Конечно, вставлять ассемблерные вставки прямо внутрь кода на C++ не очень-то хорошая практика программирования, но все-таки иногда это удобно и в других компиляторах вроде бы никто не выкидывал эту возможность.

N>Но это надо было его реализовать правильно. Это включает в себя описание входных параметров (чтобы не надо было их доставать из памяти или заботиться о том, чтобы оказалось только в совместимом регистре), выходных параметров и побочных эффектов.
Могли бы оставить хотябы для __declspec(naked) ассемблерных функций, оставив все это на откуп программисту. Но это уже конечно совсем не inline, — просто удобняшка.