OSDev

Тааакс, понятно. Простого, удобного и надёжного способа нет. Уродская архитектура.


С геморроем как раз не могу согласиться. Без использования задач нужно отображать часть адресного пространства ОС в адресное пространство текущей задачи, заботиться о том, чтобы обработчик работал только с данными, представленными в ЭТОМ адресном пространстве, либо всё равно преключаться в другую задачу – ядро или планировщик. В целом получается один хрен.


Фигасе! Как же так? TSS больше нет? Полностью раздельных адресных пространств нет?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

TSS есть, но в единственном числе и совсем для другого. Аппаратного переключения задач больше нет, ну а что оно бесполезно, подтверждается тем, что ни одна (!) сколько-нибудь распространённая ось для ИА-32 ею не пользовалась.



Я четверть века был уверен, что хуже архитектуры 16-, 32- и 64-разрядных процессоров, чем у Intel, не существует. Лишь в конце прошлого года я узнал, что ошибался для 16-разрядных архитектур: микроконтроллеры PIC ещё хуже. Но среди 32- и 64-разрядных Интел по-прежнему впереди планеты всей. Ну а ПК... ИБМ выбрала для своего компутера худший из трёх на тот момент существовавших микропроцессоров, а сам проект сделала тяп-ляп. Поэтому не приходится удивляться, что современные ПК -- это сплошные костыли и подпорки, с которыми сама Интел нынче борется, первой выкидывая устаревшие интерфейсы и внедряя новые.



Ошибаетесь. Код ОС по-любому должен иметь "нормальный" доступ к адресному пространству задачи, причём для выполнения очень многих функций -- без этого будет жуткий геморрой. Соответственно, единственное на практике приемлемое решение -- резервировать часть виртуального адресного пространства каждой задачи под нужды системы и туда эту самую систему отображать. Винда, например, в 32-разрядном режиме использует для своих нужд 1 или 2 старших гигабайта адресного пространства каждого процесса; аналогично дело обстоит и в других операционных системах. Можно менять положение используемой ОС области, менять её размеры -- но суть остаётся та же.

Это не очень сильный аргумент против аппаратного переключения задач. Мало ли, кто чем не пользовался. Инструмент Интелом разработан, в своё время в него были вложены немалые деньги и право на жизнь он вполне имеет. Может быть, причина только в его несовершенстве.


По поводу PIC-ов полностью согласен. Постоянное переключение банков памяти, на которое уходит значительная часть кода – редкостный геморрой. Но есть и интересные моменты – условное исполнение следующей команды. Условные переходы выглядят некрасиво, зато в ряде случаев переходы вообще использовать не нужно.
Из 32-битных архитектур, с которыми доводилось работать, мне больше всего нравится VAX-11.


Как они сами оправдывают это масштабное злодеяние, они и не предполагали, что эта поделка обретёт ТАКУЮ популярность. Они расчитывали, что это преходящее и чисто экспериментальное решение. И вообще мало кто его купит.


Я и не утверждал обратного. Со стороны ядра нет проблем получить доступ к пространству задачи. Я про обратную ситуацию, – некрасиво, если огромная часть адресного пространства занята кусками ОС. Опять получается нагромождение идеологических недоделок. Кто-то подумал, что задаче с лихвой хватит двух гигов под данные, остальное размапируем, как захочется, всё равно физическое пространство не превышает 4Г. С появлением с одной стороны PAE, с другой стороны ресурсоёмких задач – CAD, обработка видеоматериалов, игры с охрененными библиотеками текстур и ландшафтов и пр., 2 гига уже совсем не кажутся достаточными, даже, прямо скажем, тесновато будет. Откусить за "так" 1 гиг от адресного пространства – жестокая шутка над прикладной задачей. Именно в этом свете, я думаю, адресное пространство задачи должно быть девственно чистым, – только то, что реально необходимо задаче и ни страницы лишней.
Кстати, наверняка именно потому, что всё мапировано в адресное пространство задачи, аппаратное переключение и не используется во многих ОС.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

VAX-11 -- наилучшая в плане системы команд архитектура из всех, что мне встречались (ну а в 16-разрядном мире на таковом месте находится её прямой предок -- PDP-11). Но в то же время пресловутое деление виндузового АП на две равные половины восходит именно к ВАХу. Именно так оно делилось в VAX/VMS, но там это объяснялось аппаратными особенностями устройства управления памятью (системная архитектура VAX-11 существенно хуже, чем система команд -- в DEC её явно не шибко хорошо продумывали). Ну а в ВинНТ перенесли многие вещи из VAX/VMS -- и это разделение, и идеологию обработки прерываний (только сделали её ещё переносимой на разные архитектуры, чем излишне усложнили и в целом ухудшили), и ещё ряд вещей. Не зря же главный архитектор ВинНТ был и создателем VAX/VMS.

Аппаратное переключение задач не используется в силу его крайне низкой эффективности. На 80386 сохранить-восстановить контекст ручками получалось ощутимо быстрей, чем это делалось аппаратно, да вдобавок было куда больше гибкости (ручное ж, а не намертво зашитое бездарными архитекторами Интел). Ну а использовать одновременно и медленную, и неудобную вещь... нафиг оно разработчикам надо, не говоря о том, что это усложнит перенос ОС на другие архитектуры? (а на переносимости зацикленными были, да во многом остаются не только юниксоиды, но и разработчики винды).

Что же касается откусывания огромных кусков адресного пространства, то, как уже сказал, на ВАХе это объяснялось аппаратными особенностями. На ПК никакой нужды в этом не было, но когда делали, о недостаточности объёма в 2 Гбайта и не помышляли (тогда память даже на мэйнфреймах измерялась десятками мегабайт). Впоследствии же ядро всё раздувалось и раздувалось -- и из-за порочности самого подхода запихивать всё подряд в ядро (фактически это стало меняться в Висле, где драйверы начали откочёвывать в пространство пользователя, хотя драйверы режима пользователя были ещё в RSX-11, откуда в своё время выросла VAX/VMS), и из-за не менее порочного подхода обеспечивать переносимость _ядра_ ОС, и из-за в немалой степени обусловленного этим написания ядра на ЯВУ (программирование системных вещей на ассемблере не намного более трудоёмко, чем на Си, и ничуть не сложней в отладке).

Собственно, о чем я и говорил.

Не совсем так. Даже в микроядре небольшой модуль встраивается в адресное пространство каждого процесса. Возможно, если и не всему планировщику, то переключателю задач здесь самое место.

Во, во "несовершенстве" - удачно подобранное слово. Думаю, в Intel сильно не расстроились, когда в AMD решили не втягивать за уши в новое расширение данное архитектурное недоразумение. Они своих недоразумений понапридумывали с лихвой )))

Не вижу связи. Я начинал с аппаратного переключения, при этом у меня всегда ядро отображалось во все адресные пространства. С переходом на программное переключение все стало значительно лаконичнее и эстетичнее. Есть некоторые шероховатости. Но это связано с тем, что инженеры Intel не предусмотрели возможность использования программного переключения в своих изделиях, т.е. не обеспечили его должной поддержкой.

Да, архитектура явно была недоработана. В то время не было никаких мотивов её продумывать более тщательно. Конец 70-х годов, VAX-11/780, самый яркий представитель этого семейства, поддерживал до 8 мегабайт ОЗУ и стандартно поставлялся всего с 2Мб. Даже суперкомпьютеры Cray того времени имели не более 128Мб.


Честно говоря, не вижу принципиальной разницы во времени переключения. Вряд ли PUSHAD/POPAD с последующим выполнением кода переключения задачи по скорости сильно отличается от аппаратного сохранения/восстановления регистров в TSS.
Если говорить про гибкость, - что же такого принципиально другого может потребоваться, с чем аппаратный task switch окажется не совместим?


Это всё исторический экскурс, который мне вполне знаком. Я говорю про разработку ОС в современных реалиях, не обременённую совместимостью. Сейчас адресное пространство (если не считать 64-битную архитектуру, хотя... что будет лет через n-цать?) - вполне ценный ресурс, которым я бы не стал разбрасываться просто так.


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


Связь в том, что как только мы мапировали ОС в адресное пространство задачи, необходимость в аппаратном переключении исчезает. А вот при реализации полной изоляции адресных пространств без (хотя бы минимальной) аппаратной поддержки, увы, никак не обойтись.

PS
Кажется, у меня наклёвывается идея, как сделать единый, надёжный и удобный обработчик любых прерываний с аппаратным переключением задач...
Надо поставить серию натурных экспериментов.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Разница есть. К тому же непосредственно в подпрограмме переключения я даже pusha/popa не использую - нет необходимости. Более того, т.к. таймерный обработчик у меня является сугубо ядерным (не разделяемым) с вполне обозримым набором действий и используемых подпрограмм, я и в нем не использую pusha/popa, но это все мелочи, потому что сохранение/восстановление регистров общего назначения по времени выполнения не сравнимо с операцией аппаратного переключения. Там выполняется множество значительно более затратных и абсолютно бесполезных операций.

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

Например, перезагрузка сегментных регистров -- это кошмарно долгая операция, которая при неудачном раскладе (вполне возможном, между прочим) может растягиваться у современных процов на многие тысячи тактов. Очевидно неудачный расклад -- это отсутствие в кэше дескрипторов, которые должны быть загружены в теневые части регистров, из-за чего за ними приходится обращаться к ОЗУ, что сильно тормозит процессор (и, самое страшное, плохо сглаживается кэшем, поскольку обращения к дескрипторам сравнительно редки -- при переключении задач, -- а посему почти наверняка полученные из ОЗУ данные будут в кэше быстро затёрты другими). Но и при наличии дескрипторов в кэше операция сия выполняется долго, ведь надо не просто прочитать несколько байтов, но ещё и проверить их корректность, разложить по полочкам... Учитывая, что сегментация на практике фактически не используется, насколько это позволяет аппаратура (и отменена в 64-разрядном режиме), наивно ожидать, что сия операция оптимизирована на аппаратном уровне.

Дескрипторы сегментов лучше вообще не трогать. Один раз настроить при старте ОС и забыть про них. При переключении задач (в этих условиях) проблем с валидностью никаких быть не должно.
Чё-то вы меня заинтриговали. Надо будет при удобном случае протаймировать переключение задач в разных раскладах.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

А исследовать время выполнения разных операций было бы неплохо. Тут главная проблема -- суметь это сделать корректно. Всё ж Коре и7 -- это не 80386, сейчас куда труднее учесть все побочные факторы...