На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
Обратите внимание:
1. Прежде чем начать новую тему или отправить сообщение, убедитесь, что вы не нарушаете правил форума!
2. Обязательно воспользуйтесь поиском. Возможно, Ваш вопрос уже обсуждали. Полезные ссылки приведены ниже.
3. Темы с просьбой выполнить какую-либо работу за автора в этом разделе не обсуждаются.
4. Используйте теги [ code=cpp ] ...текст программы... [ /code ] для выделения текста программы подсветкой.
5. Помните, здесь телепатов нет. Старайтесь формулировать свой вопрос максимально грамотно и чётко: Как правильно задавать вопросы
6. Запрещено отвечать в темы месячной и более давности без веских на то причин.

Полезные ссылки:
user posted image FAQ Сайта (C++) user posted image FAQ Форума user posted image Наши Исходники user posted image Поиск по Разделу user posted image MSDN Library Online (Windows Driver Kit) user posted image Google

Ваше мнение о модераторах: user posted image B.V.
Модераторы: B.V.
Страницы: (2) [1] 2  все  ( Перейти к последнему сообщению )  
> Как избежать работы на старых процессорах? А то падает на SSE2…
Компилятор (MSVC новых версий) ставит во вполне обычном коде SSE2-инструкции. И в процессе работы на Pentium-III программа неожиданно падает.

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

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

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

2. Если компилятору разрешено SSE2 - это ещё не значит что он обязательно использует SSE2. Как бы узнавать что вот в конкретной этой программе были использованы инструкции SSE2, AVX, и т.п. расширения?
И, если SSE2/AVX было - то тогда уже вставлять на старте проверку поддержки процессора и предупреждение.
Если принудительно на старте требовать от пользователя SSE2 - а вдруг окажется что в этой программе то SSE2 и не использовалось нигде… Неоправданно теряем пользователя.
А ключика -arch:IA32 уже нет, что ли?
Одни с годами умнеют, другие становятся старше.
Цитата f2065 @
Но, где гарантия что компилятор не использует SSE2 для какой-нибудь инициализации ещё до того как я вставлю проверку?
Ну если вы сразу в начале main'а запишете такую проверку, то наверное некий неявный ГОСТ на main сгарантирует, что ничего до вашей проверки особого не будет. :unsure:

Цитата f2065 @
Как бы узнавать что вот в конкретной этой программе были использованы инструкции SSE2, AVX, и т.п. расширения?
Формально - почти никак. Ибо можно запилить что-то на ASM'е вида:
ExpandedWrap disabled
     db ту-ту
    Label1:
     db ля-ля
и тогда компилятор увидит, что вроде как SSE2 нету (код, начинающийся с ту-ту, создаёт одну хорошую инструкцию), но при прыжке на Label1 окажется, что код с ля-ля уже создаст SSE2-инструкцию. :yes-sad:
Цитата Qraizer @
А ключика -arch:IA32 уже нет, что ли?

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

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

Я рассматриваю ситуацию когда асма нету (либо асм написан мной и тогда я 100% знаю использовал я там SSE2 или нет).
Мне надо знать сам компилятор вставлял SSE2 где-то или нет…
Ну, можно кастомизировать __tmainCRTStartup(), добавив туда свой код. Сырцы, вроде, к любой версии студии прилагаются.
Одни с годами умнеют, другие становятся старше.
Цитата f2065 @
Мне надо знать сам компилятор вставлял SSE2 где-то или нет…
Ну тогда - да, есть такой шанс узнать (в теории). Но, думается, что компиляторы не говорят, какие они инструкции насоздавали и, т.о., есть ли среди них такие-то иль такие-то. :yes-sad: Ибо весьма тонкая и крайне редко кому нужная особенность.
Цитата Qraizer @
Ну, можно кастомизировать __tmainCRTStartup(), добавив туда свой код. Сырцы, вроде, к любой версии студии прилагаются.

А если так?
ExpandedWrap disabled
    bool ChkSSE() {  
       // return boolean
    }  
      
    bool SSE = ChkSSE();  
      
    int main() {  
      if (SSE) return -1;  
    }
Мои программные ништякиhttp://majestio.info
Цитата f2065 @
Как избежать работы на старых процессорах? А то падает на SSE2…

1) Компилировать 64-битную версию. Все процессоры в 64-бит режиме обязаны поддерживать SSE2.
2) При компиляции настроить создание ассемблерного листинга кода, там поиском искать строку "xmm" например, результат использовать как надо.
А может (если есть инсталлятор) писать разные ветки - с SSE и без?
Цитата Pacific @
1) Компилировать 64-битную версию. Все процессоры в 64-бит режиме обязаны поддерживать SSE2.
Сильное ограничение "платформ". Если прога не работает с гигабайтами ОЗУ, то зачем ей 64 бита? <_<

Цитата Pacific @
2) При компиляции настроить создание ассемблерного листинга кода, там поиском искать строку "xmm" например, результат использовать как надо.
Не все SSE2-инструкции пишутся с xmm*; как следствие - ненадёжная проверка. :no-sad:
Цитата Pacific @
Компилировать 64-битную версию.
Есть много компов где процы тянут SSE3 но из-за нехватки ОЗУ стоит 32-битная винда. Ну и с таким подходом проще не 64-битноую версию компилировать а проверять процессор и на старте сообщать что он не поддерживается.
Однако вопрос как избежать подобной неоправданной дискриминации. Т.е. запрещать работу программы только если программе реально необходим SSE

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

Но пока что кажется проще запретить создание SSE-кода если софт не критичен по скорости работы…
Цитата f2065 @
Ну в принципе инструкций SSE/SSE2/SSE3/SSE4/AVX не так уже много, можно написать утилиту для поиска всех.
Но есть (как минимум) такие подводные камни:
1.Если в коде есть комментарии, содержащие строчки вида "xmm", "clflush" и пр., то простая проверка по наличию таких строк будет давать ложные срабатывания. Итог: убирать комментарии. :'(
2.Если в коде есть переменные с названиями a'la "myclflush" или "int superxmm4;", то тоже в созданом ASM-файле может начинаться ложное срабатывание. Итог: убирать строки исх. кода. :'(
Славян
В Visual Studio можно выбирать, как генерировать листинг. Там есть вариант "Assembly-Only Listing (/FA)".
Да, знаю. Но вот же получилось с таким выбором:
ExpandedWrap disabled
    int clflush( int a) { return a*a; }
    ...
    cout << clflush( int(FreqQP.LowPart) );

ExpandedWrap disabled
    PUBLIC  ?clflush@@YAHH@Z                ; clflush
:whistle:

Добавлено
Ну и в коде:
ExpandedWrap disabled
        mov eax, DWORD PTR _FreqQP$[ebp]
        push    eax
        call    ?clflush@@YAHH@Z            ; clflush
:oops:
Славян
Парсить ASM-листинг не так уж и сложно, все эти исключения можно прописать в парсере. Думаю, даже regexp какой-нибудь для вытаскивания инструкций можно сделать.
Сообщение отредактировано: Pacific -
1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
0 пользователей:


[ Script Execution time: 0,1511 ]   [ 20 queries used ]   [ Generated: 24.05.17, 09:40 GMT ]