в рантайм. порядка 100 байт увеличение размера

yogev_ezra, системе сборки безразлично, сколько версий собирать, и добавить новую версию для сборки может любой с правами на коммит в репозиторий - для этого достаточно создать новую папку в data/ с файлом Makefile внутри и нужными настройками.

Я считаю, что не нужно делать разные сборки для разных процессоров, сборка должна быть универсальной. В любом случае от того, что сборка объявлена i586-совместимой, программы не изменятся, и код нужно будет переделывать на i586-совместимый; обычно - за исключением участков, критичных по скорости, которых мало; но все участки кода важны по размеру - можно просто сохранять код i586-совместимым, не используя новые инструкции. Там, где они действительно увеличивают скорость и это действительно важно, так что действительно нужны два варианта кода, лучше выбор между ними делать на стадии выполнения программы, а не при компиляции.

CleverMouse wrote:Я считаю, что не нужно делать разные сборки для разных процессоров, сборка должна быть универсальной. В любом случае от того, что сборка объявлена i586-совместимой, программы не изменятся, и код нужно будет переделывать на i586-совместимый; обычно - за исключением участков, критичных по скорости, которых мало; но все участки кода важны по размеру - можно просто сохранять код i586-совместимым, не используя новые инструкции. Там, где они действительно увеличивают скорость и это действительно важно, так что действительно нужны два варианта кода, лучше выбор между ними делать на стадии выполнения программы, а не при компиляции.

Большое спасибо за совет! Тогда подскажите, пожалуйста, как в FASM делать проверку на архитектуру?
Я попробую внести это изменение в Snake - выглядит не очень сложно для меня.

Да не нужна там проверка на архитектуру, скорость некритична, так что достаточно версии для i586. Вставить макросы наподобие http://redmine.kolibrios.org/projects/k ... macros.inc (с) hidnplayr, и всё. Можно прямо в общий macros.inc.

CleverMouse wrote:Да не нужна там проверка на архитектуру, скорость некритична, так что достаточно версии для i586. Вставить макросы наподобие http://redmine.kolibrios.org/projects/k ... macros.inc (с) hidnplayr, и всё. Можно прямо в общий macros.inc.

Ну я для общего случая спросил - например, для Infinity скорость критична.
Я правильно понял, что проверка выполняется командой "if __CPU_type eq p5" ?

Это проверка стадии компиляции - в качестве config.inc берётся programs/config.inc, в котором написано __CPU_type fix p5, и при компиляции с неизменённым programs/config.inc компилятор обработает код между if __CPU_type eq p5 ... end if; при отдельно взятой компиляции - не в автосборке - можно написать в config.inc что-нибудь другое, и тогда компилятор не будет обрабатывать код между if __CPU_type eq p5 ... end if.

Там, где скорость критична, желательно даже в универсальной сборке иметь оба варианта, для этого проверка стадии компиляции не годится.

CleverMouse wrote:Это проверка стадии компиляции - в качестве config.inc берётся programs/config.inc, в котором написано __CPU_type fix p5, и при компиляции с неизменённым programs/config.inc компилятор обработает код между if __CPU_type eq p5 ... end if; при отдельно взятой компиляции - не в автосборке - можно написать в config.inc что-нибудь другое, и тогда компилятор не будет обрабатывать код между if __CPU_type eq p5 ... end if.

Там, где скорость критична, желательно даже в универсальной сборке иметь оба варианта, для этого проверка стадии компиляции не годится.

Теперь мне более-менее ясно. Тогда я хочу добавить на SVN 2 авто-сборки: i586-eng и i586-rus, и попытаться сделать так, чтобы в этих авто-сборках всё компилировалось под i586, а в двух других авто-сборках поменять, чтобы всё компилировалось под i686. Таким образом, владельцы i686 смогут получить весь прирост производительности, какой только можно от всех программ, а пользователи i586 смогут запускать все приложения на своих компьютерах. У кого-то есть возражения против этого?

yogev_ezra, я возражаю. При таком подходе скачавшие сборку i686 получат не только незаметную прибавку в скорости, но и заметное увеличение размера за счёт того, что код системного вызова с sysenter длиннее простого int 0x40, скачавшие сборку i586 не получат на новых процессорах скорости там, где это важно, на новых процессорах, хотя могли бы, а у поддерживающих всё это появится двойная головная боль от того, что придётся каждый раз уточнять, какая версия проверялась, - и вообще будет жуткая путаница, чреватая ошибками. Более того, никакие настройки сборки не сделают программы, использующие SSE2, работающими на i586.

CleverMouse wrote:yogev_ezra, я возражаю. При таком подходе скачавшие сборку i686 получат не только незаметную прибавку в скорости, но и заметное увеличение размера за счёт того, что код системного вызова с sysenter длиннее простого int 0x40, скачавшие сборку i586 не получат на новых процессорах скорости там, где это важно, на новых процессорах, хотя могли бы, а у поддерживающих всё это появится двойная головная боль от того, что придётся каждый раз уточнять, какая версия проверялась, - и вообще будет жуткая путаница, чреватая ошибками. Более того, никакие настройки сборки не сделают программы, использующие SSE2, работающими на i586.

Ну Вы уж прямо из крайности в крайность. Тогда подскажите, пожалуйста, как в отдельно взятой программе (например, Snake) сделать проверку на архитектуру в run-time? Macros by hidnplayr не делают этой проверки, они просто привязаны к config.inc . А я бы хотел увидеть именно код проверки архитектуры процессора.

В начале работы программы нужно сделать Теперь процедуру, в которой полезны инструкции cmovcc, нужно написать в двух вариантах - с этими инструкциями и без них - и вызывать косвенно Это пример для CMOVcc, наличием SSE заведует бит 25, наличием SSE2 - бит 26 в edx, наличием SSE3 - бит 0 в ecx; проверка наличия, например, SSE2 имеет вид

yogev_ezra,
эти две cmovnz были добавлены из соображений компактности кода, о быстродействии _там_ я не думал, поэтому громоздкая проверка в рантайме, думаю, была бы неуместна. Я залил на svn изменённый под i586 вариант: Исправлены только две строчки. Если ещё где-нибудь вылезет - сообщай.

CleverMouse,
предложение по файлу информации о сборке. Почему бы не использовать вывод команд вроде 'tree -s' или 'du -B 1'? На мой взгляд, они могут предоставить более детальную информацию в дополнение к текущему варианту.

dunkaist, добавить детальную информацию о всех файлах легко, вопрос в том, нужно ли это.

yogev_ezra
Я соглашусь с CleverMouse о нецелесообразности сборки отличающейся от p5. Кроме увеличения размера приложения, можно получить несовместимость с процессорами, которые относятся 686-м, но не имеют поддержки sysenter или syscall.

В приложении разумеется можно действовать как угодно, но совместимость нужно сохранять. К тому же я не думаю, что Snake является показательным примером где требуется какой-либо особый прирост в скорости.

И еще мне кажется по прежнему имеется непонимание того что p5, p6 или к6, не являются синонимами подобными сборке 586 и 686 для *NIX систем. Поскольку в Колибри большинство программ на ассемблере, то меняется лишь метод обращения к API ядра - автоматического применения новых инструкций процессора от этого не происходит, как это сделано для компиляторов языков высокого уровня.

Таким образом от тупой замены int 0x40 на sysenter или syscall, мы не получим большого прироста, но получим головную боль от несовместимости.

З.Ы. Если уж мне лично нет особой веры, то читаем тему отсюда и далее. Там приводится мнение "эталона непогрешимости".

Mario wrote:И еще мне кажется по прежнему имеется непонимание того что p5, p6 или к6, не являются синонимами подобными сборке 586 и 686 для *NIX систем. Поскольку в Колибри большинство программ на ассемблере, то меняется лишь метод обращения к API ядра - автоматического применения новых инструкций процессора от этого не происходит, как это сделано для компиляторов языков высокого уровня.

Таким образом от тупой замены int 0x40 на sysenter или syscall, мы не получим большого прироста, но получим головную боль от несовместимости.

Да, Вы правы, действительно - я думал, что это синонимы. С int 0x40 у меня, мягко говоря, нет никаких проблем, а твёрдо говоря, я вообще не понимаю, что это Поэтому 100% оставим, как есть

Проблема у меня только с командами и регистрами, появившимися начиная с процессора i686 (как то, cmov, xmm0). Для таких программ, как Infinity, быстродействие важно, поэтому при запуске на i686 эти команды логично оставить. Однако хотелось бы, чтобы они работали и на i586. Поэтому я и предложил делать 4 сборки вместо двух: по две на i586 и по две на i686. Мне это представляется более целесообразным, чем определение архитектуры в run-time, потому что скомпилированный код так будет короче.