Есть ещё одна идея.

База сегментов теперь 0 так что нет необходжимости перегружать сегментные регистры ds и es. В них можно сразу загрузить app_data, только для защищённого стека нужен pl0 сегмент. Если совместить всё это с программной многозадачностью то получится очень хорошая экономия тактов: постоянное значение ds, es и ts. Только cs и ss будут меняться при прерываниях. Единственная проблема может возникнуть с графическим сегментом если программа будет грузить селектор в ds или es. В принципе теперь этот сегмент не нужен.

Serge
Насколько я знаю, программная многозадачность работает существенно медленно, чем аппаратная. Как мне объяснили то что, например Linux поддерживает программную многозадачность, отнюдь не отменяет наличие аппаратной. Зачем терять дополнительные ресурсы? Ведь на слабых машинах (а пока мы не отказались от 32-х битной поддержки их надо принимать в расчет) будет значительное снижение скорости.
Возможно, стоит рассмотреть какой-нибудь комбинированный вариант? Например, для драйверов (если мы собрались выносить их из ядра) и быстрых приложений использовать аппаратное переключение, а каждое аппаратное переключение можно поделить на программные если нужно... Или я опять туплю и предлагаю не то? В общем, совсем переходить на программную многозадачность не стоит. Как еще вариант (если это проще) можно сделать как в том же Linux выборочную компиляцию с аппаратной или программной многозадачностью.

Mario79

> Насколько я знаю, программная многозадачность работает существенно медленно, чем аппаратная

Откуда такая информация?

Вот что происходит в Колибри. Перед вызовом do_change_task в стеке уже сохранены все регистры и eflags Потом процессор выполняет far jmp и начинается куча проверок: проверяется селектор tss, дескриптор tss потом сохраняются все регистры выходящей задачи (по второму разу, они уже в стеке) и начинается загрузка регистров входящей задачи и опять проверяются загружаемые селекторы кода и стека и наконец после того как переключение уже произошло из стека ещё раз загружаются все регистры и селекторы. Фактически каждоё сохранение и восстановление контекста производится два раза и ещё с кучей разных проверок. Следует учесть что переключение происходит в кольце 0 то есть нет необходимости перегружать cs ss ds es

При программном переключении значение esp сохраняется в данных выходящей задачи, из данных входящей загружается новый esp и новый cr3, в cr0 устанавливается бит TS. Вот и всё переключение. Значения регистров востановятся из стека. Никаких лишних сохранений и проверок.
Видимо поэтому аппаратное переключение уже нигде не используется, а в х86-64 его вообще нет. Если бы оно было быстрее програмного то навярняка бы осталось.

А приложения не смогут изменять cs, ss и пр. регистры, тем самым нарушив работу всех остальных приложений. Или диспечер задач будет не сохранять эти регистры, а каждый раз выстанавлить определенные зачения?

..bw

bw

Заменить cs и ss на неправильные нельзя, программа сразу вылетит. es и ds принудительно устанавливаются в правильное значение в обработчиках прерываний. Программа ничего не сможет испортить.

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

..bw

bw

Со временем получится микроядро

Что-то 419 плоское ядро не удалось загрузить нигде После выбора параметров комп уходит на перезагрузку. Пробовал убивать драйвера - не помогло. В vmware та же песня.

Heavyiron
Это шутка такая про 419 ревизию? На сайте всего-то 415 ревизия.
То ядро котрое выкладывал Serge у меня на A64 заработало без проблем.

На сайте выкладываются только ревизии ОФИЦИАЛЬНОГО ядра, а если ты зайдешь в просмотр свн, то увидишь, что ревизия плоского ядра как раз 419.

Нашел причину глюка: если не сжимать kerpack-ом, то работает

Heavyiron

>После выбора параметров комп уходит на перезагрузку

То есть до того как дискета считается ?

http://infinity-sound.narod.ru/flat_.7z

Это #419 со всеми драйверами. Vmware у меня нет но в Bochs, Quemu и VirtualPC работает.

В vmware вылетает после загрузки дискеты, в реале - гружусь с С:\. Но как уже говорил, это если сжать ядро kerpak-ом

Heavyiron

Тогда всё ясно. Звгрузка ядра изменилась.