Board.KolibriOS.org

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

Ну, так какие проблемы? В дефолтной сборке применяем максимально совместимый код. Если кому-либо нужен прирост он перекомпилирует под себя исходники Infinity, с нужными ему параметрами и положит в образ. Либо скачает готовый бинарник файла и также положит в образ на место дефолтного. Благо инструменты для этого имеются как в самой Колибри, так и в сторонних системах.

Однако есть у меня подозрение что переписывать Infinity в данный момент просто некому. Serge и без того занятой человек.

Mario wrote:Ну, так какие проблемы? В дефолтной сборке применяем максимально совместимый код. Если кому-либо нужен прирост он перекомпилирует под себя исходники Infinity, с нужными ему параметрами и положит в образ. Либо скачает готовый бинарник файла и также положит в образ на место дефолтного. Благо инструменты для этого имеются как в самой Колибри, так и в сторонних системах.

Но почему вы все против 4 сборок одновременно? Тем более, что CleverMouse писала:

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

То есть, с одной стороны, для сервера - что 2 авто-сборки, что 4 - значения не имеет, для пользователя - удобство (скачал и поставил, без необходимости изменения образа), а с другой стороны - люди против. Я ни в коем случае не собираюсь делать назло и добавлять авто-сборки под i586, если люди против, но я просто не вижу аргументов в ваших возражениях.

yogev_ezra, удобство для пользователя - это не ломать голову над тем, какой образ из нескольких предложенных ему нужен - попробуй "на пальцах" объяснить разницу между i586- и i686-образами простому пользователю, не знакомому со словосочетанием "центральный процессор" и не имеющем представления о деталях железа его компа, - а прсто записать систему на дискету или флешку и чтобы она везде работала, причём критичные по скорости участки - по возможности быстрее; удобство для программиста, борющегося с багами, - это получить снимок доски отладки и по этой информации иметь возможность выяснить, что где упало; удобство для тестера - по возможности меньше разных комбинаций, каждую из которых нужно тестировать. Удвоение числа сборок никакому удобству не способствует.

yogev_ezra wrote: Но почему вы все против 4 сборок одновременно?

Потому что озвученной проблемы они не решают. Infinity и другой код не работающий на отличных от требуемой для них конфигурации все-равно не заработают. Для того чтобы код объективно был 586-м или 686-м с возможностью условной компиляции - требуется переписать очень много кода. Пока это не сделано, делать отдельные сборки исключительно ради 2-3% прироста скорости (я учитываю общий средний прирост скорости) и при этом терять совместимость крайне неэффективный путь. У нас нет такого человеческого ресурса в проекте, чтобы разбираться с удвоенным или учетверенным числом проблем, которые возникнут у пользователей. Другое дело если бы реально присутствовала условная компиляция под определенную архитектуру - но этого повторюсь нет в наличии.

CleverMouse
Спасибо, за проделанную работу.

Также есть предложение в предстоящем дистрибутиве указать в качестве официальных сборщиков diamond'а и CleverMouse.

yogev_ezra
Переделать Infinity не так уж сложно, нужно только заменить несколько раз встечающиеся в одной процедуре инструкции pminsw и pmaxw. Дело в том, что просто элегантная замена мне на ум не приходит, т.к. там идёт работа с 64-битными данными, а инструкций чистого MMX вообще ни на что не хватает, сделали бы аналог rol/ror уже можно было бы сделать простую замену.

Asper, вроде бы в чистом i586 нет даже SSE, а не только SSE2, так что этим дело не ограничится.

CleverMouse
Да, есть только чистый MMX. SSE2 в Infinity используется опционально и по умолчанию не используется, так что этим дело пока и ограничивается.

No, the first pentiums did not have MMX, only the pentium Pro/pentium MMX wich is essentially P5 and P6 respectively AFAIK
I have all mentioned processors, if uncertain, I can do some tests.

I think the more important question we should ask ourself: do systems like eBox have mmx/sse ? (and drop the original P5 for sound alltogether)

hidnplayr wrote:No, the first pentiums did not have MMX, only the pentium Pro/pentium MMX wich is essentially P5 and P6 respectively AFAIK

Yes, that's correct. MMX was added in Pentium MMX / Pentium Pro. The original Pentiums did not have it.

hidnplayr wrote:I think the more important question we should ask ourself: do systems like eBox have mmx/sse ? (and drop the original P5 for sound alltogether)

Vortex86MX (the CPU used in eBox-3300MX I sent to Asper and Ataualpa, and in Gecko Edubook) has MMX. For backward compatibility, it's turned off by default. You have to enable it in BIOS to use it. I have already done that for Asper / Ataualpa of course.

Vortex86DX (the previous CPU generation, used in eBox-3300-L2 I sent to you) does not have MMX, but it does not have HD audio either (it uses AC97 USB audio chip). Since it uses a non-standard 5V power adapter, I have stopped selling it in Israel due to customs problems it caused me. The new eBox-3300MX uses standard 12V power input.

So if someone wants my opinion, 99% computers used today have CPU with MMX commands, and the ones without MMX (like Vortex86DX) are not relevant anymore, so we can safely assume that MMX is a requirement to fully enjoy KolibriOS.

hidnplayr
Yes, I speak about Vortex86MX.

Я добавила вывод списка всех файлов в svn*-info.txt - как в скрипт для сборки новых образов, так и в существовавшие файлы. Если есть возражения - я могу убрать.

А Doom тоже собирается автоматически? Или пока что еще нет? Если да, то очень интересно посмотреть на его скрипт автосборки...

Sorcerer wrote:А Doom тоже собирается автоматически? Или пока что еще нет? Если да, то очень интересно посмотреть на его скрипт автосборки...

Пока ещё нет

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

Теперь всё работает - спасибо большое!

Я конечно не сишник, но могу оценить некоторые вещи. Зачем собирать в автосборке проект который является достаточно тяжелым, не входит в состав ночной сборки и не меняется очень давно? Смысл нагружать сервер?