RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Следующий шаг. Немного конкретики.


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Sanych
To : Василий А. Сидоров
Subj : Следующий шаг. Немного конкретики.
> > Вообще, мне не совсем понятна приверженность некоторых (не будем показывать пальцем) сегментной модели. Заморочек много, а радости?
> Заморочки в основном связаны с перегрузкой сегментных регистров. Если исключить строковые операции, где приёмник адресуется через ES и никак иначе, что плоская, что малая модель не требуют перегружать ни CS ни DS.
> Зачем "много стэков". Просто потому, что:
> LSS [новый стек]
> JMP [точка возврата]
> гарантировано защитит стеки чужих нитей и данные от любой попытки упихнуть в стек больше, чем в него помещается.
> Если стеки невелики (несколько страниц), но их много, то отсутствие защитной страницы позволит сэкономить и адресное пространство и таблицу страниц :)
> > Конкретно хотелось бы услышать о плюсах применения small модели для случая 32-битного кода.
> Поскольку мы :) уже отказались от (в случае x86) от "один большой" сегмент на все задачи, то отдельный сегмент сегмент позволит выделить каждой задаче столько адресного пространства, сколько необходимо, а не "не те четыре гига на всякий случай".
> Все остальные "художества" вполне обеспечат страницы.
> Это, конечно, можно и плоской модели делать, но, как мне кажется, у малой есть дополнительные преимущества :)
До кучи:
Локальные данные (функции) живут в стеке. И если это есть буфер (массив данных) то при некотором стечении обстоятельств можно затереть адрес возврата из функции так чтобы его новое значение указывало на код в этом буфере.
Так можно загубить надёжность системы. А одно из пожеланий к новому ядру надёжность.


Thu 14 Jun 2007 14:54 Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.4) Gec



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.