Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.146.34.191] |
|
Страницы: (2) [1] 2 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Компилятор (MSVC новых версий) ставит во вполне обычном коде SSE2-инструкции. И в процессе работы на Pentium-III программа неожиданно падает.
Надо сделать так чтобы не просто падать непонятно почему, а выводить пользователю конкретное окно что необходим процессор с поддержкой SSE2 или там AVX… Вопрос можно разделить на части: 1. Как проверить поддерживаемые процессором режимы - понятно (CPUID и т.п.). Но, где гарантия что компилятор не использует SSE2 для какой-нибудь инициализации ещё до того как я вставлю проверку? 2. Если компилятору разрешено SSE2 - это ещё не значит что он обязательно использует SSE2. Как бы узнавать что вот в конкретной этой программе были использованы инструкции SSE2, AVX, и т.п. расширения? И, если SSE2/AVX было - то тогда уже вставлять на старте проверку поддержки процессора и предупреждение. Если принудительно на старте требовать от пользователя SSE2 - а вдруг окажется что в этой программе то SSE2 и не использовалось нигде… Неоправданно теряем пользователя. |
Сообщ.
#2
,
|
|
|
А ключика -arch:IA32 уже нет, что ли?
|
Сообщ.
#3
,
|
|
|
Цитата f2065 @ Ну если вы сразу в начале main'а запишете такую проверку, то наверное некий неявный ГОСТ на main сгарантирует, что ничего до вашей проверки особого не будет. Но, где гарантия что компилятор не использует SSE2 для какой-нибудь инициализации ещё до того как я вставлю проверку? Цитата f2065 @ Формально - почти никак. Ибо можно запилить что-то на ASM'е вида:Как бы узнавать что вот в конкретной этой программе были использованы инструкции SSE2, AVX, и т.п. расширения? db ту-ту Label1: db ля-ля |
Сообщ.
#4
,
|
|
|
Цитата Qraizer @ А ключика -arch:IA32 уже нет, что ли? Есть. Но решение типа "отключить создание SSE2" - это слишком просто и не подходит… Мне надо знать - создан SSE2-код или нет. Чтобы затем уже пользователю сообщить при реальной необходимости. Добавлено Цитата Славян @ Формально - почти никак. Ибо можно запилить что-то на ASM'е вида: Я рассматриваю ситуацию когда асма нету (либо асм написан мной и тогда я 100% знаю использовал я там SSE2 или нет). Мне надо знать сам компилятор вставлял SSE2 где-то или нет… |
Сообщ.
#5
,
|
|
|
Ну, можно кастомизировать __tmainCRTStartup(), добавив туда свой код. Сырцы, вроде, к любой версии студии прилагаются.
|
Сообщ.
#6
,
|
|
|
Цитата f2065 @ Ну тогда - да, есть такой шанс узнать (в теории). Но, думается, что компиляторы не говорят, какие они инструкции насоздавали и, т.о., есть ли среди них такие-то иль такие-то. Ибо весьма тонкая и крайне редко кому нужная особенность. Мне надо знать сам компилятор вставлял SSE2 где-то или нет… |
Сообщ.
#7
,
|
|
|
Цитата Qraizer @ Ну, можно кастомизировать __tmainCRTStartup(), добавив туда свой код. Сырцы, вроде, к любой версии студии прилагаются. А если так? bool ChkSSE() { // return boolean } bool SSE = ChkSSE(); int main() { if (SSE) return -1; } |
Сообщ.
#8
,
|
|
|
Цитата f2065 @ Как избежать работы на старых процессорах? А то падает на SSE2… 1) Компилировать 64-битную версию. Все процессоры в 64-бит режиме обязаны поддерживать SSE2. 2) При компиляции настроить создание ассемблерного листинга кода, там поиском искать строку "xmm" например, результат использовать как надо. |
Сообщ.
#9
,
|
|
|
А может (если есть инсталлятор) писать разные ветки - с SSE и без?
|
Сообщ.
#10
,
|
|
|
Цитата Pacific @ Сильное ограничение "платформ". Если прога не работает с гигабайтами ОЗУ, то зачем ей 64 бита? 1) Компилировать 64-битную версию. Все процессоры в 64-бит режиме обязаны поддерживать SSE2. Цитата Pacific @ Не все SSE2-инструкции пишутся с xmm*; как следствие - ненадёжная проверка. 2) При компиляции настроить создание ассемблерного листинга кода, там поиском искать строку "xmm" например, результат использовать как надо. |
Сообщ.
#11
,
|
|
|
Цитата Pacific @ Есть много компов где процы тянут SSE3 но из-за нехватки ОЗУ стоит 32-битная винда. Ну и с таким подходом проще не 64-битноую версию компилировать а проверять процессор и на старте сообщать что он не поддерживается.Компилировать 64-битную версию. Однако вопрос как избежать подобной неоправданной дискриминации. Т.е. запрещать работу программы только если программе реально необходим SSE Цитата Славян @ Ну в принципе инструкций SSE/SSE2/SSE3/SSE4/AVX не так уже много, можно написать утилиту для поиска всех. Не все SSE2-инструкции пишутся с xmm* Но пока что кажется проще запретить создание SSE-кода если софт не критичен по скорости работы… |
Сообщ.
#12
,
|
|
|
Цитата f2065 @ Но есть (как минимум) такие подводные камни:Ну в принципе инструкций SSE/SSE2/SSE3/SSE4/AVX не так уже много, можно написать утилиту для поиска всех. 1.Если в коде есть комментарии, содержащие строчки вида "xmm", "clflush" и пр., то простая проверка по наличию таких строк будет давать ложные срабатывания. Итог: убирать комментарии. 2.Если в коде есть переменные с названиями a'la "myclflush" или "int superxmm4;", то тоже в созданом ASM-файле может начинаться ложное срабатывание. Итог: убирать строки исх. кода. |
Сообщ.
#13
,
|
|
|
Славян
В Visual Studio можно выбирать, как генерировать листинг. Там есть вариант "Assembly-Only Listing (/FA)". |
Сообщ.
#14
,
|
|
|
Да, знаю. Но вот же получилось с таким выбором:
int clflush( int a) { return a*a; } ... cout << clflush( int(FreqQP.LowPart) ); PUBLIC ?clflush@@YAHH@Z ; clflush Добавлено Ну и в коде: mov eax, DWORD PTR _FreqQP$[ebp] push eax call ?clflush@@YAHH@Z ; clflush |
Сообщ.
#15
,
|
|
|
Славян
Парсить ASM-листинг не так уж и сложно, все эти исключения можно прописать в парсере. Думаю, даже regexp какой-нибудь для вытаскивания инструкций можно сделать. |