Как избежать работы на старых процессорах? А то падает на SSE2…

Компилятор (MSVC новых версий) ставит во вполне обычном коде SSE2-инструкции. И в процессе работы на Pentium-III программа неожиданно падает.

Надо сделать так чтобы не просто падать непонятно почему, а выводить пользователю конкретное окно что необходим процессор с поддержкой SSE2 или там AVX…

Вопрос можно разделить на части:

1. Как проверить поддерживаемые процессором режимы - понятно (CPUID и т.п.). Но, где гарантия что компилятор не использует SSE2 для какой-нибудь инициализации ещё до того как я вставлю проверку?

2. Если компилятору разрешено SSE2 - это ещё не значит что он обязательно использует SSE2. Как бы узнавать что вот в конкретной этой программе были использованы инструкции SSE2, AVX, и т.п. расширения?
И, если SSE2/AVX было - то тогда уже вставлять на старте проверку поддержки процессора и предупреждение.
Если принудительно на старте требовать от пользователя SSE2 - а вдруг окажется что в этой программе то SSE2 и не использовалось нигде… Неоправданно теряем пользователя.

А ключика -arch:IA32 уже нет, что ли?

Цитата f2065 @ 18.05.17, 17:19

Но, где гарантия что компилятор не использует SSE2 для какой-нибудь инициализации ещё до того как я вставлю проверку?

Ну если вы сразу в начале main'а запишете такую проверку, то наверное некий неявный ГОСТ на main сгарантирует, что ничего до вашей проверки особого не будет.

Цитата f2065 @ 18.05.17, 17:19

Как бы узнавать что вот в конкретной этой программе были использованы инструкции SSE2, AVX, и т.п. расширения?

Формально - почти никак. Ибо можно запилить что-то на ASM'е вида:

 db ту-ту
Label1:
 db ля-ля

и тогда компилятор увидит, что вроде как SSE2 нету (код, начинающийся с ту-ту, создаёт одну хорошую инструкцию), но при прыжке на Label1 окажется, что код с ля-ля уже создаст SSE2-инструкцию.

Цитата Qraizer @ 18.05.17, 17:51

А ключика -arch:IA32 уже нет, что ли?

Есть. Но решение типа "отключить создание SSE2" - это слишком просто и не подходит…
Мне надо знать - создан SSE2-код или нет.
Чтобы затем уже пользователю сообщить при реальной необходимости.

Добавлено 18.05.17, 18:10

Цитата Славян @ 18.05.17, 18:05

Формально - почти никак. Ибо можно запилить что-то на ASM'е вида:

Я рассматриваю ситуацию когда асма нету (либо асм написан мной и тогда я 100% знаю использовал я там SSE2 или нет).
Мне надо знать сам компилятор вставлял SSE2 где-то или нет…

Ну, можно кастомизировать __tmainCRTStartup(), добавив туда свой код. Сырцы, вроде, к любой версии студии прилагаются.

Цитата f2065 @ 18.05.17, 18:07

Мне надо знать сам компилятор вставлял SSE2 где-то или нет…

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

Цитата Qraizer @ 18.05.17, 18:12

Ну, можно кастомизировать __tmainCRTStartup(), добавив туда свой код. Сырцы, вроде, к любой версии студии прилагаются.

А если так?

bool ChkSSE() {  
   // return boolean
}  
  
bool SSE = ChkSSE();  
  
int main() {  
  if (SSE) return -1;  
}

Цитата f2065 @ 18.05.17, 17:19

Как избежать работы на старых процессорах? А то падает на SSE2…

1) Компилировать 64-битную версию. Все процессоры в 64-бит режиме обязаны поддерживать SSE2.
2) При компиляции настроить создание ассемблерного листинга кода, там поиском искать строку "xmm" например, результат использовать как надо.

А может (если есть инсталлятор) писать разные ветки - с SSE и без?

Цитата Pacific @ 19.05.17, 06:25

1) Компилировать 64-битную версию. Все процессоры в 64-бит режиме обязаны поддерживать SSE2.

Сильное ограничение "платформ". Если прога не работает с гигабайтами ОЗУ, то зачем ей 64 бита?

Цитата Pacific @ 19.05.17, 06:25

2) При компиляции настроить создание ассемблерного листинга кода, там поиском искать строку "xmm" например, результат использовать как надо.

Не все SSE2-инструкции пишутся с xmm*; как следствие - ненадёжная проверка.

Цитата Pacific @ 19.05.17, 06:25

Компилировать 64-битную версию.

Есть много компов где процы тянут SSE3 но из-за нехватки ОЗУ стоит 32-битная винда. Ну и с таким подходом проще не 64-битноую версию компилировать а проверять процессор и на старте сообщать что он не поддерживается.
Однако вопрос как избежать подобной неоправданной дискриминации. Т.е. запрещать работу программы только если программе реально необходим SSE

Цитата Славян @ 19.05.17, 18:54

Не все SSE2-инструкции пишутся с xmm*

Ну в принципе инструкций SSE/SSE2/SSE3/SSE4/AVX не так уже много, можно написать утилиту для поиска всех.

Но пока что кажется проще запретить создание SSE-кода если софт не критичен по скорости работы…

Цитата f2065 @ 19.05.17, 19:16

Ну в принципе инструкций SSE/SSE2/SSE3/SSE4/AVX не так уже много, можно написать утилиту для поиска всех.

Но есть (как минимум) такие подводные камни:
1.Если в коде есть комментарии, содержащие строчки вида "xmm", "clflush" и пр., то простая проверка по наличию таких строк будет давать ложные срабатывания. Итог: убирать комментарии.
2.Если в коде есть переменные с названиями a'la "myclflush" или "int superxmm4;", то тоже в созданом ASM-файле может начинаться ложное срабатывание. Итог: убирать строки исх. кода.

Славян
В Visual Studio можно выбирать, как генерировать листинг. Там есть вариант "Assembly-Only Listing (/FA)".

Да, знаю. Но вот же получилось с таким выбором:

int clflush( int a) { return a*a; }
...
cout << clflush( int(FreqQP.LowPart) );

PUBLIC  ?clflush@@YAHH@Z                ; clflush

Добавлено 20.05.17, 03:50
Ну и в коде:

    mov eax, DWORD PTR _FreqQP$[ebp]
    push    eax
    call    ?clflush@@YAHH@Z            ; clflush

Славян
Парсить ASM-листинг не так уж и сложно, все эти исключения можно прописать в парсере. Думаю, даже regexp какой-нибудь для вытаскивания инструкций можно сделать.

Сообщение отредактировано: Pacific - 20.05.17, 08:50