Разработка концептуально новой ОС

Цитата

Ведь прерываний теоретически может быть до 2^12=4096 (или меньше?). Если так, то придется сразу выделить на обработчики около 100кб.

В x86  - 256 (на других платформах не знаю). Итого памяти займет около 4096 (+TSS_size*(used_ints+1_for_all_unused) ).
Но если учесть, что в системе будут обязательны обработчики исключуний (32), IRQ (16), и syscall (1-3  (больше 1 - на всякий)), не так уж и много памяти занято, тем более т.к. они обязательны, они в любом случае будут выделены.
А зачем приложениям предоставлять возможность создавать свои прерывания? Не вижу в этом необходимости.

Цитата

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

Кто считает, что это нехорошо ? Это всегда очень красиво! Я не против нее.
Но здесь с модификацией кода могут быть проблемы: придется временно включать разрешение на записть в страницы ядра,+ искать место, куда поместить эти обработчики. (А если предполагается, что выделение из Хипа, то на такой код придется выделять сразу страницу. Т.к. надо потом запретить туда записть).

Цитата

Потом, когда все обработчики без параметров - это единообразие.

Это хорошо.

Цитата

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

Но это плохо:) В дет.саду учат, что использование глобальных переменных плохо (как впрочем и goto)

Цитата

Это мне кажется более безопасным, чем когда С-функция будет брать параметр из стека - нужно будет следить за согласованностью форматов.

В ядре будет только одна согласованность. Если пишем на С, то получится cdecl, стеком занимается вызывающий. А несогласованность идет только в исключениях, которыми заниматься будет ядро.

Цитата

Видимо нужно предусмотреть в ядре не только режим обработки прерываний, но и режим "обслуживания", который имеет отдельный стек и может прерываться. При этом можно обойтись и без задачного переключения (все можно свести к усложнению постобработки).

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


И еще надо учесть, что получается сложная схема взаимосвязей, вложенности вызовов задач(а на занятую задачу переключиться нельзя), разрешение которых мне пока не кажется простой задачей.

Цитата rcz, 22.10.03, 23:46:28

В x86  - 256

А вдруг они в последующих моделях решат увеличить число прерываний - ведь возможных селекторов 4096...

Цитата

А зачем приложениям предоставлять возможность создавать свои прерывания? Не вижу в этом необходимости.

Необходимости я тоже не вижу. ..Но и "не жалко".
А вдруг в новый процессор добавят еще прерываний (аппаратных или исключений)?

На самом деле, вопрос не принципиальный - пусть будет как угодно (напр., статические обработчики), я не настаиваю.

Цитата

Но это плохо:) В дет.саду учат, что использование глобальных переменных плохо (как впрочем и goto)

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

Вообще, на каждое правило есть исключения.
По поводу goto, правда, таких исключений не знаю (разве что есть случаи, когда goto не режет глаз - но все равно не предпочтительнее).

А насчет глобальных переменных - чем по-вашему являются поля класса с точки зрения его методов? Для методов класса его переменные-члены выглядят глобальными.

Поэтому в ООП глобальные переменные действительно почти никогда не нужны.
А в plain-C глобальные переменные чаще всего оправданы (в разумных пределах).

Кстати, если без виртуальных методов (а также конструкторов с деструкторами), то классы в ядре использовать, наверное, можно?

Цитата

В этом все и дело. Постобработка работает с запрещенными прерываниями. И усложнение ее очень все затормозит.

Сначала нужно сделать упрощенную (демо) версию, где с этой проблемой не связываться. Пусть пока тормозит.
Сразу все не осилить.

Цитата

И еще надо учесть, что получается сложная схема взаимосвязей, вложенности вызовов задач(а на занятую задачу переключиться нельзя), разрешение которых мне пока не кажется простой задачей.

Поэтому сначала стоит сделать простейший вариант.
А сложных взаимодействий и вложенных вызовов задач, уверен, вообще удастся избежать и в полном варианте.

Цитата

А вдруг они в последующих моделях решат увеличить число прерываний - ведь возможных селекторов 4096...

Пока возможных селекторов в IDT только 256.
Но дело не в увеличении самим Интеллом, а перенос на другие платформы.

Цитата

Кстати, если без виртуальных методов (а также конструкторов с деструкторами), то классы в ядре использовать, наверное, можно?

Можно. Только компилятор надо подобрать.
Хотя даже в чистом С. Ведь можно сразу определить стиль вызовов - первый параметр - указатель на объект (this).
А виртуальность - вручную поддерживать vtbl.

(Где-то видел линк, как ядро можно писать на C++. Найду, кину сюда). Хотя в микроядре навероно это не необходимо.

Цитата

Вообще, на каждое правило есть исключения.
По поводу goto, правда, таких исключений не знаю (разве что есть случаи, когда goto не режет глаз - но все равно не предпочтительнее).

Выход из кучи вложенных циклов. (Как нехочется вдаваться в обсуждения стиля программирования, тем более для ядра это не самое главное).

Цитата

А в plain-C глобальные переменные чаще всего оправданы (в разумных пределах).

Да. Но у нас получается, что время потребности в переменной ограничивается одной функцией(обработчиком исключения), поэтому не стоит засорять данные ядра. Можно передавать как параметр(это архитектурно ничего не нарушит).

Цитата rcz, 23.10.03, 23:17:55

Можно. Только компилятор надо подобрать.

А что, бывают компиляторы, которые не поддерживают ++?..
Но вообще, это не проблема. Может, в ядре классы совсем не понадобятся. Хуже не отсутствие класов, а отсутствие блоков и необходимость описывать переменные сразу.

Цитата

А виртуальность - вручную поддерживать vtbl.

Уж виртуальность в ядре точно не нужна.

Цитата

(Как нехочется вдаваться в обсуждения стиля программирования, ..).

Особенно, если учесть, кто начал..

Цитата

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

Без глобальной переменной, хранящей описатель текущей задачи (потока), никак не обойтись. Иначе нельзя (или трудно) определить, какой поток прерван.

Сообщение отредактировано: nvm - 24.10.03, 13:06

и откуда ты такой взялся, разработчик концептуально новой ОС? :

...приношу извинения за некорректный тон...

В данном случае выразите Вашу мысль правильно. Иначе это скорее воспринимается как наезд.

Хотя здесь более приветствуются дельные советы.

Сообщение отредактировано: rcz - 24.10.03, 20:32

Цитата

Без глобальной переменной, хранящей описатель текущей задачи (потока), никак не обойтись. Иначе нельзя (или трудно) определить, какой поток прерван.

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