Heavyiron
Заранее прошу не воспринимать то, что я пишу как наезд или еще чего-нибудь (очень уж часто на меня обижаться стали).
А если приложение не использует макросы или использует их лишь частично? Или ты все приложения переписал?
И вообще ИМХО нужно было переписать только те, которые действительно нуждаются повышении производительности, например графические.
И еще основные приложения: LAUNCHER, CPU, @PANEL, @ICON по умолчанию должны быть обычными, иначе придется делать два дистрибутива как минимум.

1) Я переписал все программы на свн, которые написаны на Fasm-e - теперь они используют один общий macros.inc. В этом имхо много плюсов. Непереписанными остались только run, scrnsoot (они используют полностью несовместимый macros.inc) и gmon (по просьбе Ghost-a).
2) Если программы не используют макросы, то придется перед каждой компилляцией заменять системный вызов на нужную форму Чтобы упростить эту процедуру, собственно, и была проделана вся эта работа.
3) Если переделать графические программы и включить их в дистрибутив, то почему бы не сделать это и с остальными? Все равно такой дистрибутив некрасиво предлагать владельцам старых компов, если там графические проги не работают. Я в принципе, за 2 дистрибутива (не знаю, как к этому отнесется diamond ) Скрипт я старался сделать так, чтобы он максимально упрощал сборку любых дистрибутивов.
4) По поводу LAUNCHER, CPU, @PANEL, @ICON см. пункт 3

Протестил 485 ядро с самыми последними прогами с сайта Heavyiron-а.

Тут уже кто-то писал что вылазит синий экран с настройками вначале, потом начинает грузится - идёт текст (кстати детектинг девайсес чёт долго начало) и после текста всё замирает.

Я вызвал прогу cpu, запустил kfm. Из него пробовал запустить launcher - ничё не получилось. Хорошо, позапускал всё что надо, кроме иконок через Энтер - заработало. Решил протестить остальные проги - работают 50\50.

Да, прирост скорости я ощутил, а может показалось

В любом случае надо ждать более стабильного ядра.

Тестил 488
Скрость и правда чуть прибавилась.
А вот некоторые программы работают неправильно или не работают. Хуже всего, что не работает Fasm.

Народ, огромная просьба: расшифровывайте понятие "некоторые" программы не работают (и еще хотелось бы знать, как именно они не работают ). У меня просто не было времени на доскональный тест, потому и выложил на растерзание Фасм проверю

1.Fasm уже упомянул...
2.таблица Менделеева. Просто попробуй запусти, это надо видеть.
3.Потаскай по экрану Sysxtree - при этом различные элементы окна меняют размер и местоположение.

Heavyiron
Некоторые программы:
1. Подтверждаю: FASM, SYSXTREE (соответственно приложения, использующие его для выбора файла, например midamp)
2. Таблица Менделеева у меня работала нормально.
3. Дополняю: VRR (не загрузочный, обычный), SKINSEL, CHESS, PONG.
4. SCRSHOT теряет фокус на EDITBOX при щелчке мышки, надо заменить EDITBOX на более новый (спроси у <Lrz>).
Правда, надо учитывать, что это лишь видимые эффекты. Во скольких программах есть не видимые эффекты неизвестно. Также я практически не проверял сетевые программы.

Кстати, а Diamond согласился с переписыванием KFAR? Он вообще в курсе.
Еще неплохо бы так собирать из-под самой Колибри. Раньше когда все влезало на дискету (в том числе исходники) Иван Поддубный сделал для CMD компиляцию всех приложений. Правда то о чем я говорю несколько сложней реализовать, так как придется отдельное приложение писать, скорее всего.
P.S. То ли компер у меня слишком крутой, то ли что еще, но прироста у меня никакого не наблюдается практически. Единственное приложение, которое показало прирост FIRE2, на прерываниях 586, на FAST CALL 590.

Leency wrote:кстати детектинг девайсес чёт долго начало

Это все из-за нового драйвера ps/2 мыши. Он теперь не просто детектит мышь, оне еще пытается перевести мышь в другие режимы(скролл, 5 кнопок). Я тоже удивился, какая-то уж сильно большая задержка(как я считаю). Все функции по работе с ps/2 были взяты из ядра, поэтому не знаю в чем проблема - буду искать, может что ускорить получится.

Mario79 wrote:Кстати, а Diamond согласился с переписыванием KFAR? Он вообще в курсе.

Скажем так: я в курсе (как и практически всего происходящего в svn-репозитории), но возражаю. Причём это относится не только к kfar, но и ко всем программам вообще. По следующим причинам:
1) Команда "int 0x40" занимает 2 байта. Макрос "mcall" для sysenter в типичной ситуации - 12 байт. Для syscall - 4 байта. Напоминаю, что Колибри позиционируется не только как быстрая ОС, но и как маленькая ОС. При замене "int 0x40" -> "mcall" быстрая система медленной определённо не станет, а вот раздувание всех приложений, причём на существенную величину (10 байт на каждый системный вызов, а таких вызовов даже в банальном "Hello, World" около десятка - что уж говорить о серьёзных приложениях), не пройдёт незамеченным.
2) Не имеет смысла все системные вызовы оптимизировать по скорости. В среднем 90% времени программы уходит на 10% её кода, так? То есть в 90% кода заведомо не нужна предельная скорость, а вот размер...
3) Системный вызов заключается не только в переходе между 3-кольцом и 0-кольцом, а ещё и производит некоторую работу в 0-кольце. Если это обращение к дискете (функции 58 и 70), то нет абсолютно никакой выгоды в "fast system call".
4) Макросы - это только макросы и не учитывают текущей ситуации. Простейший пример: для syscall есть команды "push ecx/pop ecx". Допустим, мы вызываем сисфункцию, не использующую ecx (а таких довольно много - скажем, 10/11/23, 12.1/12.2, 2, 17 - основной цикл большинства программ, между прочим). Тогда нам не нужно сохранять/восстанавливать ecx, а достаточно иметь на стеке зарезервированный dword. Если идёт серия таких вызовов, то достаточно сделать "push ecx" в начале и "pop ecx" в конце. Другая ситуация: мы явно инициализируем ecx, например, константой 4. Тогда получится "mov ecx,4/push ecx" при "purge mov" или даже "push 4/pop ecx/push ecx" без "purge mov", в то время как достаточно обычного "push 4".
5) Совместимость страдает. Кстати к вопросу о совместимости: на каком минимальном процессоре работает Колибри? Вроде бы сейчас требуется наличие rdtsc, т.е. минимум Пень, и его достаточно. Это так?
6) При таком подходе требуется ко всем программам подключать macros.inc. Допустим, некто оптимизировал какую-нибудь программу по скорости до такта (или не всю программу, а некоторый цикл - это выглядит более реалистично), а потом некто другой просто подключил macros.inc. И вот результат - mov,add,sub превратились в непонятно что и скорость уменьшилась, а размер, естественно, увеличился (см. пункт 1). Кроме того, лично я, когда пишу "mov", хочу быть уверенным, что это именно "mov", если я хочу видеть "push x/pop y", я так и напишу. Конечно, можно везде писать "purge mov,add,sub", но неудобно же...

Конструктивное предложение: создать файл, скажем, fastcall.inc с единственным макросом mcall_fast. В критических участках приложений (и только в них) заменить "int 0x40"/"mcall" на "mcall_fast", а "mcall" оставить синонимом "int 0x40". По крайней мере, это решает пункты 2,3,6 и снимает остроту пункта 1.

Поэкспериментировал немного: размер всех программ на свн при "int 0x40" и при SYSENTER отличается где-то ~ на 30 kb в несжатом виде и ~ 14 кб после сжатия kpack-ом. После запихивания их всех в образ, разница составила еще меньше - 7 кб. Вроде не такое уж и страшное раздувание для сотни программ даже в пределах дискеты, от которой уже начали по-немногу уходить.

Пересказываю свой предыдущий пост вкратце:
1) Происходит раздувание программ.
2)3) Происходит ненужное раздувание программ.
4) Происходит лишнее раздувание программ.
5) Теряется совместимость.
6) Наличествуют теневые эффекты.

Залил исправления для fasm, period, sysxtree, https, chess, pong, некоторые косметические изменения исходников (благодарю diamond-а за замечания).
По поводу vrr - повторить не удалось, вроде все работает; skinsel окна не имеет и меняет скин только при наличии нескольких скинов в образе, которые к тому же должны быть прописаны в файле настроек. Со scrshoot пока ситуация подвисает... либо полностью переписывать программу на общий скин, либо менять editbox, чтобы он не использовал макросы.
diamond
В принципе, я согласен с тем, что быстрый вызов нужен не везде, но теперь менять все назад и заниматься выбором критических мест, где ускорение нужно 1) самому как-то не хочется; 2) учитывая объем работы, не думаю, что кто-то другой за это возьмется
По поводу пункта 6:
при простой замене int 0x40 на пустой mcall в принципе ничего не изменилось - если использовать ключ "р5", то на выходе получится абсолютно идентичный код, со всеми оптимизациями. А если бояться несовместимости и ненужного раздувания, то можно просто не использовать быстрые вызовы в официальном дистрибутиве, а оставить их как возможность для желающих чуть увеличить скорость за счет некоторого увеличения размеров бинарников.

Heavyiron
С VRR вопрос не в твоих изменения похоже, он и в обычном виде не запускается.

Heavyiron, даже если официальный дистрибутив не будет использовать быстрые вызовы, лично для меня ничего не изменится, потому что я каждый день обновляю систему с svn