1. Можно ли без автоматического формирования особого случая вызвать iret на третьем кольце для переключения задачи. 2. Зачем при каждом особом случае процессору переключать tss?
конечно можно (если сможешь бит NT установить) Code (Text): pushfd or dword [esp], 0x4000 popfd ; set NT bit iretd только есть следующие НО: 1. Поле link в текущем TSS сегменте должно содержать валидный селектор дескриптора TSS 2. В дескрипторе должны быть установлены биты P и B 3. DPL дескриптора должен быть не меньше CPL особый случай это исключение? не за чем кроме #TS
с первым вопросом понятно. Спасибо. На счет второго я так и непонял. Я имею виду такой случай: (все обработчики вызываются через шлюзы, т.е. без задач) задача третьего кольца ловит исключение или скажем прерывание, и нужно вернутся обратно в код текущей задачи, зачем iret передаст управление задаче предку в поле связи текущей задачи? Или мне нужно тогда везде ставить в обработчиках такой код?: Code (Text): sti popfd ret far
Доп. вопрос. Если IOPL позволяет текущей задаче делать ввод/вывод сможет ли она его делать если будет карта ввода/вывода в которой все запрещено?
ну дык а чем просто Code (Text): iretd ; retf для шлюза вызова не катит? со стека будут сняты последовательно EIP, CS, [EFLAGS], ESP, SS, что вернет управление прерванному коду передаст только в случае наличия в EFLAGS бита NT нужно, например, вот для такого кода Code (Text): task_code: ; что-нибудь делаем iretd ; автоматическое переключение на предыдущую задачу (head) (потому как NT установлен) head: ... call 1 SHL 3:0000h ; 1-ый дескриптор в GDT - TSS дескриптор (в сегменте TSS поле EIP содержит адрес task_code), здесь как раз идет установка NT ...
в том то и дело что текущая программа уже имеет статус вложеннной и я нехочу переключать задачу при исключении и прерывании по iretd, сбрасывать флаг нельзя.
NoName а понял, что ты хочешь тогда используй retf, но придется со стеком повозиться Code (Text): exception_handler: push ebp mov ebp, esp ... add esp, 14 popfd ; restore flags mov eax, dword [ebp + 14] ; get ESP mov dword [ebp + 10], eax mov eax, dword [ebp + 18] ; get SS mov dword [ebp + 14], eax leave retf
К слову, в x64 архитектуре (IA-32e) в 64 битном режиме не поддерживается переключение задач Вот такой облом. Хотя доступ к соотвествующим регистрам (TR.. ) возможен. Особо не разбирался, но походу там только программное пререключение задач работает.
интересно, из каких соображений так сделано... ведь если используется нечто посложнее flat модели, переключение задач програмными средствами становится затруднительным, если вообще возможным
Кто сказал, что в новых процессорах НЕ ПОДДЕРЖИВАЕТСЯ ПЕРЕКЛЮЧЕНИЕ ЗАДАЧ? IMHO этого просто НЕ МОЖЕТ БЫТЬ !!!TermoSINteZ, во первых, если не работает у тебя, не значит что этого нет вообще? Да и где это вообще проверялось, на какой системе?
OioVologda А производитель процессоров и сказал. Но это относится только к 64-му режиму. И к хардварному переключению. Да им все рано особо никто и не пользовался Если кто-то не верит см. Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A, 6.2.3 AMD64 Architecture Programmer’s Manual Volume 2, 2.7, 2.8
rei3er Производитель настойчиво подталкивает к flat Да и не в модели дело, просто руками переключится эффективнее получается (по мнению гуру, ибо сам я таким не страдал).
нет, как раз в модели дело не уверен, что вручную получится переключать эффективнее, если использвать в полном объеме сегментацию
А вот напримеря я страдаю хардварным переключением, и лично я как раз и использую в полном объеме сегментацию. Это что же мне теперь ядро переписывать и руками все менять! и CR3 и LDTR и еще туеву кучу того гавна, которое процессор сохранял и восстанавливал за меня сам... Мне пофиг на то, что винда и линюха, мать их, используют flat и программную переключалку. Да и по-моему, не факт, что ручное переключение быстрее хардварного? Да и как тогда допустим IO карту менять?
rei3er А чем сегментация-то страшна? Не вижу принципиальной разницы. Да и для 64 это уже не актуально
Сейчас не актуально. Лет 25 назад считали, что и 640 килобайт будет достаточно на всю оставшуюся жизнь.
И еще вопрос, получается, что в 64 архитектуре вообще нет понятия шлюз задачи, и переход на TSS ничего не дает? Если все таки переключение при загрузке в TR не работает, нафиг тогда вообще там TSS, для регистров стека могли бы что нибудь легче придумать...
быстрее потому как не надо сохранять/восстанавливать CS, DS, SS, ES, GS, FS, LDTR, EIP а каждая операция загрузки сегментного регистра крайне медленная операция ну ты же ее как-то создаешь для каждой задачи аналогичным образом при ручном переключении задач меняешь адрес в TSS дескрипторе (адрес TSS сегмента) и делаешь LTR
