OSDev

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

а выходим из обработчика iret эта инструкция отличается от "ret" в том, что она также выводит из стека флаги в регистр флагов.
Кстати это отличие между call и int 1

Не согласен в корне. Очень много занимался Novell NetWare. Админил, писал всякие мелочи. В ней были потоки и работала она без перезагрузки годами. Рекорд - помню показывали на Brainshare фотку с консоли экрана, где аптайм был более 5-ти лет. Она стояла в каком-то игорном заведении. Это в России, в остальном мире - возможно есть и большие достижения. Вообще ОС была своеобразная (одна корпоративная многозадачность чего стОит), но были в ней фичи, которых в других или не было вообще, или появились намного позднее (SFTIII, распределенная база данных объектов). SFTIII так кстати никто повторить не смог (только аппаратными решениями), а это реально работало! Сошла со сцены эта операционка, когда попыталась стать как все. С выходом 5-й версии в самом конце 90-х появилась джава, вместо SFTIII - кластеры и стендбай серверы, упала скорость работы и надежность (в этом кстати очень часто винили аутсорсинг разработки) и клиенты стали массово мигрировать на 2000-й.

Что касаемо основной дискуссии, то позвольте мне как ассемблерщику с достаточным стажем высказатся за языки высого уровня. По моему мнению любой крупный ассемблерный проект неминуемо хоронит сам себя. Реально - у проектов на ассемблере два достоинства - компактность кода и более высокая скорость работы. Всё это было обязательно в 80-е и раньше, желательно в 90-е, а сейчас не востребовано т.к. память и процессоры стоят дешево, Требования теперь другие - переносимость, скорость разработки и легкость сопровождения проекта (то что в наше время стоит дорого). Всего этого на ассемблере не добится. Хороший код системы - тот, который для аппаратно независимых частей одинаковый для всех процессоров (в идеале - для 32 и 64 битных). Как это сделать на ассемблере?

Есть алгоритм решения задачи, а есть компиляторы, транслятора, со своим лексиконом для их реализации. Мне проще писать на фасме, я могу написать на нём всё и собственно это и делаю для ОС, мне на нём проще, а теперь я убедился, что тем, чем пользуюсь в асме(конструкции командами) в других языках не сделать.
В ОС есть разные объекты у которых есть переменные и адреса функций её, ссылки на другие объекты(вообще продуманные объекты в ОС это её 90%, с ними можно интересные вещи делать), так вот ссылка на объект обязательно должна быть в регистре, например ebp, а пользоваться её функциями нужно читая её адрес со смещением на неё, по пути цеплять в регистры данные её как параметры, и вызывается call dword[ebp+?].
Это похоже как в дельфи пишут типа Form.Canvas.paint. объект форма имеет много типов функций переменных, канвас тоже самое и вызывают функцию паинт.
Но языки ариентированы на винду, а мы пишем свою ОС.

Это не винда, это дельфи.
Точно так же можно написать и под Нет (будет работать почти везде) и под лазарус (опять же, будет работать почти везде).
Сама винда об этих заморочках ничего не знает, она построена на динамических библиотеках, а не на ООП.
Form.Canvas.paint - это не элемент ОС (и, кстати, не элемент языка).

ЯВУ, кстати говоря, редко бывают ориентированы на какую-то одну ОС. Если язык завязан на ОС или архитектуру, то это либо не ЯВУ, либо плохой ЯВУ (я не имею в виду всякие batch/shell/AREXX/etc - на них же ОС писать не станешь ).



Все это верно для компонентов, которые действительно платформонезависимы (TCP/IP, проверка прав доступа, отрисовка окошка). Их, ИМХО, следует писать только на ЯВУ (написать тут что-нибудь внятное на ассемблере - малореально. Смотри КолОС, как негативный пример.).
Но какой смысл в портируемом коде обработчика страничного сбоя или переключателе контекста? ИМХО, это лучше и проще писать на АСМ.

ЗЫ-ИМХО: если портируемость не нужна, качество языка определяется временем, через которое программа в руках незнакомого с code formatting превращается в кашу. В этом смысле ассемблер - самый худший язык (а самый лучший - питон, но на нем ОС, к сожалению, не напишешь).

_________________
Found a CPU. LAPIC ID: 00

Объект Form про которую говорил это объект винды, который больше ни где не используется, такими конструкциями в Дельфи можно пользоваться и в других ОС с другими объектами, но как идёт работа не понятно.
КоОС мёртвая и ни кто её не пишет, но кто вам мешает написать лучше, а если напишут на фасме хорошую ОС вы что скажете, "этого не далжно быть", а теоретически это возможно на 100%.
Кто мне помешает написать проверку TCP/IP на фасме, причём если во всех ос будет одинаковая проверка, то взламываться тоже будут одинакова

ОБЪЕКТ Form - это объект библиотеки делфи. Внутри него реализован доступ к Windows API. Windows API не объектно-ориентированая (по крайней мере, снаружи). А в лазарусе оный объект реализует доступ например к QT.
---
Теоретически, существует код написанный на ФАСМ, реализующий "хорошую" ОС, тк ФАСМ - Тьюринг-полный. Но не факт, что есть на свете программист, способный этот код написать . (Я не говорю что это априори невозможно. Но ОЧЕНЬ тяжело и главное - бессмысленно.).

_________________
Found a CPU. LAPIC ID: 00

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

Это не умный кусок памяти. Это всего лишь структура и ассоциированные с ней функции. Никакого отношения к ОС они не имеют.
В Windows ВСЯ работа с окнами идет через WinAPI. Любые навороты (будь то делфовские VCL с формами, будь то QT, будь то .NET) в конечном итоге вызывают функции WinAPI для управления окнами.

ИМХО на асме можно написать "хорошую ось" (вернее её ядро) целиком, и не так уж это прям нереально и архитрудно. И смысл есть - при нормальных навыках программирования работать оно будет быстрее, чем на ЯВУ. Читаемость же зависит от стиля. Можно писать как КОС, которую действительно нереально поддерживать, а можно нормально оформлять и комментировать код, описывая всю логику работы.
Но написать драйвера всех устройств и реализацию всех протоколов на асм невозможно по количеству времени, поскольку их огромное количество, к тому же под многие устройства есть готовые драйвера на ЯВУ (под тот же линух), которые можно при желании портировать (хоть часто непросто).

Ну дык этих осей было полно, ведь до Мультикса (самый конец 1960-х) вообще все они писались только на асме, да и после, вплоть до 1980-х, именно асм был основным языком.



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



Насчёт времени Вы правы, а вот насчёт возможности портировать драйверы... Чтобы их просто взять готовыми, нужно, чтобы подсистема ввода-вывода, входящая в состав ядра системы, на 100% соответствовала системе, откуда берутся драйвера -- ну а по объёму и сложности эта подсистема превосходит любую другую, а зачастую одна имеет больший объём, чем всё остальное ядро системы со всеми этими многозадачностями, управлением памятью, таймерами и т.п. Но мало того, что нужна совместимость по вводу-выводу; остальное тоже очень важно. Например, многие драйверы в Винде используют потоки режима ядра -- пожалуй, самый большой недостаток архитектуры самой Винды, который не только усложняет систему, но ещё и делает её поведение малопредсказуемым. Соответственно, в самописной ОС, способной использовать драйверы Винды, необходимо обеспечить поддержку всех таких системных механизмов, т.е. по крайней мере в плане ядра написать свою Винду. То же самое касается и Линуха, и БЗДи, и любой другой системы. Ну а если ядро своей системы серьёзно отличается от другого, ни о каком простом портировании драйверов речи уже не будет: их придётся переделывать, и очень серьёзно.

Соответственно, как ни крути, а драйверы тоже придётся делать свои. Драйверы нижнего уровня, непосредственно взаимодействующие с "железом", есть смысл писать на ассемблере: они, как правило, небольшие по размерам и требуют таких специфических операций, как управление прерываниями, доступ к портам ввода-вывода и т.п. вещи, не слишком хорошо выразимые на языках высокого уровня (про эффективность уже вообще молчу, а ведь сокращение времени выполнения даже одного обработчика прерывания может прилично поднять характеристики системы в целом, в первую очередь её скорость реакции на эти самые прерывания). Кроме того, низкроуровневые драйверы привязаны к конкретному железу, а соответственно, и переносимость у них относительная (между разными системами её нет в силу различий в системных сервисах, предоставляемых ядром системы драйверам, ну а между разными архитектурами её нет в силу различий в программировании внешних устройств; лишь немногие устройства присутствуют в практически неизменном виде в разных архитектурах). А вот высокоуровневые драйверы типа файловых систем и сетевых протоколов, ИМХО, лучше писать на ЯВУ. Они действительно являются более-менее переносимыми и между разными архитектурами (поскольку не "завязаны" на аппаратуру), и между системами (поскольку интерфейс с ОС, зависящий от неё, обычно составляет лишь малую часть сложности таких драйверов, и проще переписать его, чем заново писать весь драйвер).