Linux or Windows?

ВЕрсию не знаю... скажите, как посмотреть... Я ведь всего неделю где-то назад с линухом "познакомился", хотя догадуюсь как... когда буду под Линухом, напишу, какая...
Linux у меня 64-битный UBUNTU 7.10

 

rei3er

Угу, именно в разном понимании дело. Для меня код ядра работает в контексте процесса, если функции этого кода ядра логически связаны с действиями, выполняемыми процессом.

Однако в любом случае куча стеков режима ядра не нужна -- с этого, собственно, разговор и начался

Тогда я действительно вижу только одну причину столь неэкономного расходования памяти: сложность реализации более эффективного механизма на ЯВУ без довольно широкого использования ассемблера. Хотя, возможно, этот механизм возник "исторически", и позже его просто не стали менять (по принципу: работает -- не трогай).

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

Я не линухоид Так что просьба уточнить, что здесь к чему. Правильно ли я понял, что задача пользователя обратилась к функции API для ожидания некоего сигнала, и эта функция должна остановить задачу до поступления означенного сигнала, а после поступления вновь ввести её в список готовых к работе задач? И в чём разница между pause и sys_pause?

Если позволите, сначала покончим с предыдущим пунктом, не то, боюсь, полная каша возникнет

Спасибо. Похоже, по количеству запущенных потоков Линух поэкономнее Винды. Правда, у меня и Мускул крутится, и Апач, и MS SQL, и ещё что-то-сам-уже-не-помню-что, но всё же... Тем не менее, 80 потоков -- это 640 килобайт под стек режима ядра. Многовато будет

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

Много. Очень много. Крайне громоздкая и неэффективная OS/360 меньше в памяти занимала, даже если все её модули, которые только можно было сделать резидентными, делались таковыми (мне в своё время удалось забить меньше мегабайта и я совершенно не знал, чем забить ещё два -- машина имела 3 Мб). Другое дело, что Винда ничуть не компактнее: экзешник с ядром (ntoskrnl.exe) в моём стервере-2003 занимает более 2,3 Мб. Правда, собственно кода там немногим более половины.

UbIvItS

Извините, насчёт "абсолютной" не соглашусь. Или Вы скажете, что брэйнфак трахает мозги исключительно субъективно, а при объективной оценке программы на нём столь же читаемы, сколь и на Си или Паскале?

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

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

А что до ОС, то от меня её точно не дождётесь, ибо я убеждён, что ОС должна писаться на асме. Не видел я сколько-нибудь хороших ОС, написанных на ЯВУ. И что-то мне подсказывает, что не увижу

vito

Извините, но с Вашей стороны обоснованных ответов я так и не увидел. Так что обвинения в стёбе -- не по адресу.

Вы, вероятно, сотрудник фирмы СААБ или Министерства обороны Швеции, что с такой уверенностью утверждаете?

В общем, с Вами разговор закончен. Ибо стёбом заниматься не вижу смысла.

 

pause() - функция-обертка libc, посредством int 0x80/sysenter/syscall вызывает sys_pause()
sys_pause() - внутренняя функция ядра
ее назначение вы описали правильно, только ожидание идет не некоторого сигнала, а любого

продолжайте

 

zen:

ВЕрсия ГНОМа 2.20.0
Дата сборки: 17.09.2007

 

SII
Знаешь, я не люблю Паскаль, но слова плохого о нем не сказал. Как и о тех кто на нем пишет.
Ты же хаешь С и называешь, пусть не напрямую (а иногда и напрямую) тех кто на нем пишет, извращенцами.
Вообще говоря, это оскорбление.

По рассуждениям ты владеешь вопросом. Кажется. Но несешь полную чушь.

Все ОС отстой, потому что написаны на извращенческом С. Для меня это открытие
После чего, оказывается ОС должна писаться на чистом Асме.
Знаешь, ты частично прав. Потому как.

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

//----------

Какие доводы и аргументы? Я должен объяснить, что написать сегодня ось на чистом асме сегодня нереально? Или я должен опровергать утверждение, что причина плохого качества ПО в том что он написан на С?

Хорошо.

Значит ОС на асме. Потому как С позволяет извратится и качество кода низкое?
Я правильно уловил логическую цепочку?
А Асм не позволяет

?
Так где же логика? И что я должен опровергать?
Во всем этом ....., я вижу только одно Паскаль.
//-----------
Я замечал странную закономерность. Фанатичность, стремление что - то доказать свойственна фанатам начальных языков - таких как Бейсик или Паскаль. Именно они с непробиваемым упорством доказывают, что весь мир не прав. Что их языки на самом деле самые самые. Что на них можно все. Комплекс.
Подобного не встретишь у кодеров на Джаве например. Они могут поспорить, но знают себе цену.

 

Теперь по порядку:
>>>Или, если угодно, записать алгоритмически одинаковое решение кучей разных способов.
То есть говоря простыми словами мы имеем больший простор при решении одной задачи и всегда вправе выбрать нужный нам способ.
>>>Паскаль существенно ограничивает подобную свободу творчества.
Далее идет:
>>>С моей точки зрения, это благо.
Тут судя по контексту 2 варианта:
1. Либо Паскаль ВСЕГДА выбирает наилучший вариант.
2. Либо он не способен предоставлен нужной для решения задачи гибкости.
Судя по Вашему настроению и отношению к Си вы наверно полагаете что это 1 вариант. Так вот возьмите смело в руки MS Visual Studio, напишите самый извращенный код на Си и включите режим оптимизации компилятора (на скорость хотябы). После сравните по скорости с вашим "идеальным кодом" который вы смогли бы сделать на паскале. На Си даже извращенческий метод написания rol/ror уже давно сворачивается, также как и многие другие приемы.
По поводу того что С++ очень большое зло )). Честно говоря до этого момента ни разу не видел чтобы хорошие игровые движки писали на Паскале раз он стабильнее. Наблюдается четкая тенденция к переходу на net или C++. Сказать что это очень плохо нельзя, так как после хороших проверок выяснилось что в принципе из технологий выжимают все. Так же С++ с его наворотами применяют при написании драйверов, которые от этого свою стабильность не теряют. Конечно бывают некоторые проблемы с классами (например несрабатывание деструктора при завершении системного потока, компилятор может распознать что это завершающий код, но этого не делает), и это не по вине стандарта как такового. Мною небыло замечено ни одного руткита или нормального вируса написанного на Паскале. Конечно это хороший язык в какой-то степени. Я когда-то ненавидел Сишников которые нелюбили Паскаль, мне приходилось изучать Си чтобы нормально использовать MSDN, пытался защищать это творение, да в целом я был сильным фанатом, в итоге я уже долго на Си, пытался попробовать спустя пару лет программить на Паскале, Делфях, увы ))) Для меня выбор четкий - Си и тут без вариантов. На том же GetAFreelancer, GetACoder всегда требуется программер на Си, Си шпрех, С++. Значительно реже Delphi (самопал в основном). Судя по проектам прошедшим через мои руки за последнии годы, все это были C++ приложения. Даже многие очень известные из мира 3rd party программ для GSM-debranding'а. И вот хоть за убеждайтесь никогда не убедите что подобные приложения можно сделать на паскале. Ну нет в нем чего-то.

 

rei3er

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

Кроме того, сразу накладываю ограничение: команда int 80h может выдаваться лишь кодом задачи (потока в терминологии Винды, процесса, насколько понимаю, в терминологии Линуха), хотя эта задача может работать как в режиме пользователя (CPL=3), так и в режиме ядра (CPL=0). Обработчики же прерываний вызывать int 80h не могут.

Итак, шаг 1. Задача выдаёт int 80h, управление получает обработчик этого int, причём с запрещёнными прерываниями. Получив управление, он тотчас же вызывает подпрограмму, которая сохраняет это программное прерывание для дальнейшей обработки. Если точнее, функции этой подпрограммы следущие:

-- регистры общего назначения задачи, вызвавшей прерывание, сохраняются в стеке, чтобы впоследствии их можно было восстановить (ещё ранее в стеке аппаратно были сохранены регистр флагов, CS и EIP);

-- индикатор глубины вложенности обработчиков прерываний изменяется на единицу. Я бы для удобства анализа сделал бы так: значение этого индикатора, равное +1, соответствует выполнению кода задачи (при этом, естественно, активен стек задачи), а значения <=0 соответствуют выполнению кода обработчиков прерываний (активен стек системы); чем меньше значение -- тем больше вложенность обработчиков, т.е. этот индикатор декрементируется при начале обработки прерывания и инкрементируется при завершени. Поскольку команда int выдаётся только кодом задачи, при входе в обработчик индикатор будет равен +1, а после его декремента на этом шаге станет равен нулю. Для надёжности здесь можно проверить последний факт: если это не так, int был выдан не задачей, а обработчиком прерывания, и тогда происходит крах системы (выдаётся BSOD);

-- если выполнялась задача режима ядра (смотрим на CS, сохранённый в стеке), аппаратное переключение стеков не происходит, поэтому выполняем его программно: текущий ESP запоминаем в нашем единственной TSS, после чего загружаем в него адрес вершины стека системы (тоже из TSS); кроме того, устанавливаем признак программного переключения стека. Если же задача работала в режиме пользователя, эти действия были выполнены автоматически, и нам остаётся лишь сбросить признак программного переключения стека. Разница будет в том, что в первом случае регистры задачи были сохранены в её собственном стеке, а во втором -- в стеке системы; это надо будет учитывать при возобновлении выполнения задачи или при переключении задач);

-- прерывания разрешаются;

-- управление возвращается обработчику int 80h.

Шаг 2. Обработчик выполняет необходимые проверки (допустимы ли параметры вызванной функции и т.п.) и передаёт управление обработчику конкретной функции. Поскольку все эти действия по сути элементарны, на них останавливаться не буду.

Шаг 3. Обработчик конкретной функции -- sys_pause -- переводит задачу в состояние ожидания поступления сигнала. Как это оформляется в Линухе, я пока толком не знаю (хотя знаю про состояние TASK_INTERRUPTIBLE; возможно, оно для этих целей подходит), но мы речь ведём, собственно, не о Линухе как таковом, а как подобную функцию можно реализовать вообще, обходясь при этом без стека режима ядра для задачи пользовательского режима. В общем, действия обработчика функции sys_pause заключаются в установке (или сбросе) специального бита в блоке управления задачей, который свидетельствует о переходе задачи в состояние ожидания до прихода сигнала.

Шаг 4. Задача выполняться не может, необходимо выбрать следующую задачу, готовую к выполнению. Однако обработчик этого не делает, он лишь устанавливает признак необходимости выполнения такого действия.

Шаг 5. Обработчик вызывает подпрограмму завершения прерывания, при этом стек системы соответствует состоянию, имевшему место сразу после первого шага -- т.е. он пуст, за исключением значений регистров задачи, сохранённых при прерывании. Эта подпрограмма выполняет следующие действия:

-- Запрещает прерывания, чтобы ей в её чёрном деле никто не помешал

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

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

-- Если же запроса на перепланирование нет, подпрограмма восстанавливает контекст прерыванной задачи и возвращает ей управление.

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

Собственно, на этом всё. Задача переведена в ожидание, стек для этого не потребовался. Что, собственно, и требовалось.

Вопросы по этому алгоритму?

 

vito

Да, Си я хаю и буду хаять. Человека же я назвал извращенцем в шутку и только после того, как он сам об этом сказал. Вроде как он не обиделся, а если обидется -- ЕМУ приношу свои извинения. Вас же это не касается.

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

Пожалуйста, приведите конкретную цитату, где я такое сказал. Не можете -- извольте извинятся за клевету.

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

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

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

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

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

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

Теперь Вам понятно, что я считаю нужным использовать в ядре ОС ассемблер, а не Си не из-за того, что на Си можно извращаться, а на ассемблере -- нет, а из-за того, что ассемблер позволяет создать более эффективную программу?

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

 

im1111

Вы, как, увы, и весьма многие другие, смешиваете две вещи: язык программирования и компилятор этого языка. Я являюсь сторонником языков типа Паскаля и противником языков типа Си. Это никоим образом не связано с моим отношением к компиляторам этих языков. Я прекрасно знаю, что компилятор Дельфи генерирует отвратительный по качеству код, уступающий коду, генерируемому компилятором Си++ из Visual Studio и тем более интеловскому компилятору того же языка. Однако хорошее качество оптимизации, выполняемой компилятором, не делает хорошим язык программирования. Разницу понимаете?

И второе. Берётесь ли Вы утверждать, что нельзя создать компилятор Паскаля, не уступающий по качеству генерируемого кода компилятору Си? Я, например, утверждаю, что качество оптимизации напрямую вообще не связано с входным языком. Та же Интел, например, выпускает очень эффективный компилятор Фортрана, а не только Си++.

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

Однако я совершенно с Вами согласен насчёт того, что основная масса ПО создаётся на Си и си-подобных языках. Однако я считаю, что причины этого -- не технические, а, скажем так, "социальные". Вот, например, Вы пишете:

Получается, что Вы были вынуждены использовать Си по нетехническим причинам: не из-за того, что сам язык Си круче языка Паскаль, а из-за того, что информация в MSDN приведена для Си, а не для Паскаля. Получается, если бы MSDN был бы рассчитан на Паскаль, а не на Си, Вы бы продолжали программировать на Паскале?

То же самое касается обучения. Во многих, если не во всех, случаях Паскаль даётся на самом начальном этапе, после чего очень быстро переходят на Си/Си++ и в дальнейшем к Паскалю не возвращаются. В результате реальные навыки программирования студент приобретает именно на Си/Си++, а не на Паскале. Ну и на чём, по-Вашему, после окончания вуза ему проще будет работать? На языке, который он учил 3-4 года, или на том, с которым он слегка ознакомился "на заре туманной юности"? По-моему, очевидно, что основная масса студентов предпочтёт уже знакомое. Ну а если добавить к этому общий "информационный фон", что-де Си -- это круто, а Паскаль годится только для обучения (а такое мы видим довольно часто -- и эта тема не стала исключением)? Наконец, есть "корпоративные стандарты". Ты пришёл работать в компанию, где вся разработка ведётся на Си++. На чём ты вынужден будешь работать? Естественно, именно на этом языке. А если в конторе работают на Жабе, тебе придётся работать на этом языке, даже если ты изначально его не знаешь.

Таким образом, я берусь утверждать, что распространённость Си/Си++ никак не связана с техническими достоинствами этих языков, и причину надо искать в другом. В чём именно -- можно подискутировать, если у кого-то есть желание. Я первым начинать не буду

 

SII
Ваша точка зрения мне понятна.
Вы рассуждаете так:
"Автомобили класса БМВ мне не нравятся из-за их цвета, мне больше нравятся ГАЗели. Технически их можно оснастить хорошим двигателем, улучшить безопасность, комфорт. То что в БМВ есть система курсовой стабилизации, АБС, функция адаптивного освещения это не играет никакой роли, т.к. я говорю лишь о марке, а это техническая реализация. Даже наши ВАЗы делают спортивные версии авто, можно сделать и с ГАЗелью. То что у ГАЗа нету технической поддержки и приходится ехать из России в США чтобы поменять масло, это причина не техническая, на ней конечно можно ездить точно так-же как и на БМВ. Конечно БМВ хуже ГАЗели, потому как у ГАЗели цвет лучше, опять же замечу я говорю лишь о марке. БМВ конечно извращенческий автомобиль, он позволяет отключать не используемую мощь, выбирать режимы езды - комфорт, спорт. Там есть удобная навигация GPS. А в ГАЗелях выбор меньше и по моему мнению это лучше!"
Теперь сразу скажу почему не сделать движки на Паскале - нет поддержки групповой разработки приложений, всех этих namespaces и прочего. Разумеется это техническая сторона и Паскаль лучше, т.к. это все можно встроить лет так через 100.

 

Кстати если уж выбирать среди языков в которых не играют значения удобность IDE, поддержка групповой работы, и прочая реализация, то тогда я выберу FASM. Это куда удобнее для разработки приложений чем паскаль, даже графику программировать на OpenGL с ним лучше, я точно знаю что я получу на выходе.
P.S. С точки зрения маркетинга Паскаль расчитан именно на студентов. Так как Си находится во многих сегментах рынка - сложные групповые проекты, драйверы устройств, обычные приложения, сетевые приложения, Delphi для графически красивых окошек и быстрой разработки. FASM/MASM - низкоуровневые приложения, для особых случаев. То для Паскаля просто не остается места, конкуренция вытеснела беднягу с рынка, если продукт не востребован на рынке то о чем вообще спор? На нем нет смысла программировать, тут только для себя. А это уже Хобби

 

im1111
+1
Почитал весь этот километровый бред, который несет многоуважаемый SII и в мыслях одни матюки...

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

А Паскаль и С - это разные концепции, разные подходы. О чем вообще тут можно спорить??

Если каким-либо средством пользуются тысячи разработчиков - то это средство, по определению, не может быть плохим.

ИМХО, SII - вы некомпетентны и c еще несформировавшейся психикой.
Как было сказано выше - Ваши посты "ниачемплятьлишьбыпоспорить" читать неприятно.

ПиСя: Вы мне напомнили "недавно сдохнувшего картонщика-рипера" МэСэ-Рэма. Он тоже фанатично Паскаль защищал

 

im1111
режимы езды - комфорт на C++? ))))
поддержки для Pascal'я действительно не хватает, а про Pascal под Linux так вообще ничего нет (.

 

t00x
Угу, можно заюзать хоть диалоги, хоть MFC в зависимости от требований. А вообще IDE VS дает действительно удобство.

 

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

 

Assault
Спор о том: "Что лучше английский, китайский или венгерский язык?" Пусть половина земного шара говорит на китайском, а еще четверть на пиндосском, всё равно Вы не заставите венгров отказаться от родного языка...

 

Mikl__
вот именно
+1
Не зависимо от структуры, морфологии, фонетики - язык - дело субъективное, и навязывать всем, что какой-то язык лучше - ИМХО, это не правильно.

 

Мне кажется что бред несёт не SII, а все остальные (не считая rei3er).
С чего вы взяли что SII фанатик? Он предоставляет аргументированные доводы, а остальные как раз и несут бред.
Неушто люди не способны вести нормальную беседу? Берите пример с rei3er.
В холивар эта тема превратилась не по вине SII !

 

T800

а смысл? Станут ли после его доводов оси писать на паскале?
Или может майкрософт с нуля перепишет ядро на асме?
в чем смысл всех этих доводов?

 

SII

постойте
если во втором случае регистры были сохранены в стеке системы, то получается, что до int 80h
TSS содержал ESP системы
также вы написали, что

но в то же время

из этого можно сделать вывод, что либо вы противоречите сами себе, либо только обработчики аппаратных прерываний не могут генерировать int 80h
если второе, то как тогда в первом случае регистры будут сохранены в собственном стеке, если после переключения на стек системы нет переключения на собственный стек
и как-то непонятно
если процессом используется собственный стек, то о какой экономии вообще идет речь?
если нет, тогда что такое собственный стек?

перед сохранением контекста в ESP находится адрес стекового фрейма с регистрами в стеке системы?
при переключении контекста стековый фрейм сохраняется, а ESP инкрементируется до значения адреса стека системы?
после переключения контекста формируется стековый фрейм из сохраненных значений для новой задачи?