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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Василий А. Сидоров
To : LightElf
Subj : Следующий шаг. Немного конкретики.

> > > Гм. А тады что такое для тебя large? ;)
> > Более одного DS :)
> А мужики-то и не знают...
Это устаревшее определение, но что в нём не корректного?
> > LLDT делается только при переключении на задачу. А переключая таблицы нужно ещё и анулировать соответствующие коде. Ещё неизвестно, что хуже.
> Их необязательно переключать - можно и переписать :) Что быстрее.
Э-э-э ... Входы в таблицах страниц?
Возможно и быстрее, но, как я понимаю, аннулировать адрес, который мог быть в TLB процессора всё равно нужно. А это ведёт к накладным расходам, которые стали дороже, чем десять-пятнадцать лет назад :)
> > > В общем плиз, сухой остаток выгод в студию ;)
> > Задача _полностью_ изолирована в своих сегментах. Т.е. её образ можно перебросить на другой компьютер и начать исполнять "там", не опасаясь "вредного влияния улицы".
> А чем плохо задачу полностью изолировать в своих страницах?
Тем, что задача изолирована-то она изолирована, но в гораздо бОльшем адресном пространстве, и, априори, нельзя знать какие куски этого (большого) адресного пространства ей могут понадобиться.
> > Разделяемая память полностью подконтрольна системы, поскольку не способа передать указатель между задачами без системного вызова.
> Брр. А во flat модели что не так? Ну передал указатель (опять таки только через системный вызов) - а в другой задаче эти страницы не отмаплены или отмаплены на другое место самой этой другой задачи. В чем принципиальное отличие?
В том, что не надо "ворошить" таблицу страниц только потому, что мы переключились с одной задачи на другую.
> > Если какая-то задача начнёт использовать такой указатель, не поставив в известность систему - ну что ж, ей же хуже. Ей, а не всем вокруг.
> Дык оно и сейчас так.
"Меня терзают смутные сомнения", но обоснованно аргументировать пока нечем.
> Совершенно распространенная ситуация - передаем в API указатель на локальную переменную функции. Меня это уже совершенно затрахало в случае SS != DS.
Это решаемо и без дальних указателей.
Изящества в этом решении нет, но если бОльшую часть работы возьмёт на себя компилятор - то и бог с ней, с эстетикой.
> > > да и тормозят они изрядно
> > Изрядно это сколько?
> Один такт на префикс. Что зачастую равно времени выполнения самой команды.
А то, что "на ровном" месте (просто в результате кэш-промаха) можно огрести десяток-другой тактов задержки - "просто неизбежное зло"?
> Это не считая загрузки в сегментный регистр нового значения, что вообще катастрофически долго.
Если нити между переключениями исполняются долее пары микросекунд - "катастрофически" становится лишь художественным образом.
> Кроме того, операндов часто бывает два, префикс сегментный может быть только один.
Я не особо силён в MMX+, но если исключить строковые операции - в памяти может быть только один операнд.
> > > 2) значительно снижаются возможности оптимизации с точки зрения register allocation.
> > Почему, собственно.
> Патамучта у x86 РОНы привязаны к конкретным сегментным регистрам. Неортогональная система команд, панимаешь... Инструкция (абстрактный пример) mov eax, [ebp-8] может оказаться в два раза короче, чем
> mov eax, ss:[ebx-8] и выполняться в три раза быстрее. Такая вот загогулина.
Это проблема оптимизатора. Его дело выбрать, что лучше - использовать BP исключительно для адресации стека или ставить префиксы.
> > > 3) компилятор один фиг надо переделывать.
> > Его один фиг надо переделывать.
> > Как минимум, потому, что объектная модель должна быть свойством системы, а не компилятора.
> > Ну их хотелось бы, чтобы реализация класса _действительно_ скрывалась, а не как сейчас.
> Займись? ;)
Умеренно оптимистичная оценка моей готовности заняться - начало 2008-го.
Что я смогу сделать _реально_ - совершенно отдельный вопрос.
> > С чего это вдруг, если единственный сегмент данных и (для каждой нити) единственный сегмент стека.
> С того, что если ты передаешь в другую функу указатель на переменную/буфер, этой другой функе нехило бы знать, в какой сегмент этот указатель указывает.
Решаемо. Дубово, но решаемо.
> > > > CS вообще должен быть execute-only :)
> > > Он таки execute-read на x86.
> > Э-э-э ... Флаг расписаный во всяких доках не работает или его просто никто не выставляет?
> Никто не выставляет, удобно константы (например jump table для switch) в коде хранить.
А чем RO-страницы в сегменте данных хуже?
> > Большей частью программа будет оперировать NEAR32 и, возможно, NEAR16.
> > FAR32/FAR16 потребуются разве что для вызова функций, требующих более высоких привилегий, чем RING3.
> Дык, ответь мне пожалуйста, вот к примеру функция printf какие указатели будет получать в виде параметров?
Ближние.
> > > > Селекторы задача получает на момент создания. Впоследствии могут только добавляться SS-селекторы.
> > > > Ничего особо нетривиального я тут не вижу.
> > Есть сплошной кусок пространства, который нарезается ломтиками поменьше.
> Это замечательно, трудность в том, что количество селекторов ограничено. Причем, подлость такая, они вечно кончаются не вовремя. То есть обычно их хватает за глаза, но закладываться на это нельзя.
В моей схеме число селекторов равно числу нитей задачи плюс ещё чуть-чуть.
Ограничение в восемь тысяч нитей на _задачу_ не кажется мне сковывающим.
> > > Насчет нетривиальности - это я под впечатлением менеджера селекторов OS/2.
> > Надо полагать, что большая часть финтов и фокусов связана с 16-битным защищённым режимом?
> Большая часть связана с существованием (и попыткой избежать этого существования) алиасов - то бишь перекрывающихся сегментов.
Э-э-э ... Ну если трудности создаются - надо быть готовым к их преодолению.
Или я опять не понимаю чего-то существенного?
> > Тормоза на обработке аппаратных прерываний и/или смене кольца тебя не смущают?
> Нет. Для смены кольца есть соответственные инструкции, которые делают сие весьма быстро.
И, как я понимаю, требуют некоторого кода для сохранения/восстановления точки возрата.
Кроме того, точка входа в RING0 - одна единственная, а значит надо как-то указать с какой целью мы пришли и более-менее "знатно поветвиться" в этой самой точке входа. Будь это даже "jump table для switch" :)

Fri 15 Jun 2007 19:06 Mozilla/5.0 (OS/2; U; Warp 4.5; ru-RU; rv:1.8.1.2) Gecko/200




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.