OSDev

Dragon



В общем верно, но не всегда. Например, если заранее понятно, что некий алгоритм требует большого времени для выполнения или пожирает очень много памяти, то следует сначала хорошенько подумать: возможно, удастся найти иной способ решения стоящей задачи. А вот низкоуровневую оптимизацию проводить действительно следует лишь после того, как модуль (или вся программа в целом) уже работает. Исключением является разве что передача параметров в процедуры, если разработка ведётся на ассемблере: там надо заранее озаботиться о передаче либо через регистры, либо через стек, чтобы потом не менять в тысяче мест. Правда, помочь в этой ситуации могут макрокоманды (не вызывать подпрограммы непосредственно с помощью CALL, а оформлять вызов с помощью макросов) -- но в любом случае надо чётко описывать, какие регистры сохраняются, какие изменяются... Понятно, что на ЯВУ этой проблемы нет.

SadKo



Что ничего плохого, не соглашусь: ООП может привести к уменьшению производительности, а это плохо. Другое дело, что обычно достоинства превосходят недостатки.



Тоже вставлю свои три копейки. Во-первых, инкапсуляция вовсе не обязательно требует ООП: дели программы на модули, которые "видят" друг друга только через явно прописанные интерфейсы -- и всё. Во-вторых, полиморфизм -- штука мощная и полезная, но иногда можно его имитировать без явного применения ООП. Например, ядро ОС вызывается прикладными программами через единую точку входа (либо шлюз для CALL, либо через какой-то INT). Ядро выполняет первоначальную обработку запроса, общего для всех функций, а затем передаёт управление конкретному обработчику, опираясь на код функции. Это можно реализовать через ООП (каждый обработчик представляет собой класс, наследующий свои свойства от базового класса "обработчик"), но эффективнее (да, пожалуй, в данном конкретном случае и проще) реализовать то же самое через обычную таблицу вызовов без ООП. Ну и в-третьих, с объектом нельзя сделать больше, чем позволяет интерфейс, только в том случае, если использовать исключительно высокоуровневые "фичи". Понятно, что если, например, осуществлять копирование участков памяти на низком уровне, то можно и напортачить, хотя такое копирование будет выполняться быстрее, чем с использованием специализированных методов.

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



Жутко удобная и почти столь же жутко неэффективная :) Дизассемблировал как-то игрушку такую -- Герои меча и магии 3 (написана на VS 6, судя по библиотекам). Там используются шаблоны для хранения различных объектов (деревья применяются, строки, ещё что-то). Работать всё работает, но лишнего кода... "о мама мия!" В общем, при ручном написании того же самого даже на том же Си (не говоря уже об асме) объём кода сократился бы, наверное, вдвое, а скорость работы соответствующих подпрограмм в несколько раз выросла б. Понятное дело, что на пне-4 это несущественно, но когда игрушка только появилась, она откровенно тормозила на первых "пнях" с невысокой частотой (типа 133 МГц).

Кстати, мораль сей басни такова: тестируйте свои гениальные программы на медленных машинах :)



Частично разобрался в процессе упомянутого дизассемблирования и полностью присоединяюсь к рекомендациям :) В ядре -- только ЯВНЫЕ проверки всего, что может быть неправильным, и ЯВНАЯ же обработка всех этих неправильностей. Использовать SEH в низкоуровневых программах себе дороже выйдет. В высокоуровневых -- когда как. Я обычно стараюсь не допустить возникновения исключений в принципе, но иногда использую и SEH, когда программа красивше от этого становится или ради универсальности (например, упоминаемые мною деревья вырабатывают исключения при обнаружении какой-то кривизны).



Вспоминается известная шутка: "Наша работа настолько секретная, что мы сами не знаем, что мы делаем". Так что, действительно, если не знаешь -- сначала разберись, а потом программируй, а не наоборот.

Кстати, если при применении менее эффективных с технической точки зрения методов производительность выросла, значит, программист что-то не так написал. Повод задуматься над качеством своего кода ;)

Если не ошибаюсь, то в проекте 3ОС была важна теория как таковая. Т.е. никто наверняка и не собирался писать ОС на основе разработанной теории. Для участников данного форума по-моему должна быть важна в первую очередь практическая составляющая, т.е. возможные варианты использования создаваемой ОС. Даже если человек ставит перед собой цели попробовать, научиться, оценить свои возможности и т.п. и не планирует развивать свое творение до уровня полноценной ОС, он должен перед своим проектом ставить вполне практические цели, т.е. чтобы созданная в конечном счете программа (или комплекс программ) позволяла сделать это, это и это. Делая по-другому, можно легко запутаться, опуститься на путь полного подражания и в итоге махнуть на все это дело рукой. Поэтому... общая архитектура системы, вытекающая из возможных вариантов ее практического использования, первична! А все остальное вторично.

Phantom-84

Как это:?

С какой стати общая архитектура будет вытекать из вариантов использования? Что офисную ОС, что супер-пупер ОСРВ можно сделать и микроядерной, и с монолитным ядром -- и будет успешно работать. Так причём здесь "варианты практического использования" и "архитектура системы"? Или я чего-то не понимаю?..

SII

В ООП с наследованием у тебя так и получится - таблицей ;) только называться она будет VMT.

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

Разве SEH много скушает, если например, поставить одну точку try...except на процесс? Зато можно будет отловить абсолютно все ошибки, что увеличит надёжность :)

Phantom-84

Именно архитектура/проект/идеология/теоретическая основа, а не сама практическая реализация/код, м... да? :) Точнее даже сказаь, для нормальной реализации кода, нужна хорошо продуманая архитектура ;)

Dragon



Это понятно, просто в приведённом мной примере всё это наследование-полиморфизм избыточно, поскольку решается узкоспециализированная задача. Можно для интереса прикинуть, какой объём кода займут оба подхода.



Не слишком много, но скушает, но проблема даже не в этом. Толку от того, что ты отловил фатальную ошибку? Надо ж предпринимать действия, чтобы таких ошибок не возникало ;) ИМХО, самый правильный подход заключается в том, что любое исключение в ядре вызывает крах системы (а-ля BSOD им. Б.Гейтса): исключений при нормальной работе быть попросту не может.

SII

Таких узкоспециализированных задач у тебя по ОСьке будет достаточно много, и для каждой нужно будет писать заново таблицу, что в конце концов вызовет избыточность и рассинхронизацию. С моей точки зрения проще использовать единый подход ООП. И это вроде проще. /* Прикидывать надо, когда будет реализация. */ По поводу ядра соглашусь, оно должно работать идеально, но есть же драйвера, или какиенито подключаемые модули ядра, которые было бы полезно таким образом инкапсулировать, чтобы хотябы иметь возможность их рестарта.

Dragon



Зависит от раздутости ядра. Если "истинное" микроядро -- то очень мало, если раздутое монолитное, пущай и модульное (винда, Линух) -- то действительно довольно много.



Что такое в данном контексте "рассинхронизация", вообще не понял. И не понял, в чём проблема-то? Да, каждый раз создавать таблицу переходов -- не слишком приятная работа, но особой сложностью она не отличается, просто геморрой...



Есть предложение: Вы делаете с использованием ООП фрагмент ядра, который осуществляет обработку вызовов функций API (естественно, "на бумаге" -- превратить его в полностью рабочий код за разумное время не удастся по понятным причинам), а я беру его и переделываю на свой манер, без ООП. После этого попробуем сравнить и сложность исходных текстов, и объём машинного кода. Если в общем с такой идеей согласны, можем обсудить детали по аське или через личку или почту, чтобы не захламлять форум.



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

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

Phantom-84

О терминах не спорят, о них договариваются :) Что понимать под архитектурой системой?

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