Board.KolibriOS.org

имхо, в заточенных под AMD системах имеет смысл вызывать стандартные сисфункции через int40,

а специализированный сервис и расширенный ioctl драйверов (который на пнях всё равно не пойдет) - через SYSCALL/SYSRET;

с передачей параметров в пользовательском стеке (или в регистрах,- кроме ECX).

На Sempron-140 вызов функции-пустышки через SYSCALL занимает 94 такта (в 2.4 раза быстрее, чем через int40):

Кстати,

Serge, Ghost,

А обязательно ли при вызове сисфункции переключаться в стек нулевого уровня, да еще и с выцарапыванием параметра из третьего кольца: Браво, такие выверты даже в Колибри - редкость!
Только зачем?
Переключения задачи ведь все равно не происходит, а возврат в ring3 воможен только через sysret.
Так может, лучше юзерским стеком воспользоваться: быстро, просто, и методически-корректно?

art_zh
Выносим ядро ?

Serge wrote:art_zh
Выносим ядро ?

Code: Select all

xor esp, esp
sysenetr

1001-й (не самый разрушительный) способ преднамеренного членовредительства...
Согласен, для десктопа не годится.

P.S. Хотя, в принципе, эта дырка затыкается в 2 хода.

Всё равно ring 3 не прокатит. В режиме ядра может происходить переключение контекста со всеми вытекающими.

Ясно.
Нет никакого смысла резать живое ядро ради 30-40 тактов, тем более что на пнях всё равно не будет никакого выигрыша.
Спасибо Serge.

Но для AMDшного API я всё-таки его (syscall+SP3) попробую.

Внимание!
1) Начиная с #1937 отменена официальная поддержка инструкций syscall и sysenter для вызова API-функций ядра.
2) В ближайшее время эти инструкции будут удалены из всех программ репозитория (кроме /programs/develop/fast_call_test ) и заменены на int40h.
3) Старые обработчики syscall- и sysenter-вызовов оставлены в ядре до 1 июля 2011г.
4) После 01/07/11 нормальная работа старого кода с новыми версиями ядра не гарантируется.
5) Просьба к разработчикам: проверьте свой код и внесите соответствующие изменения в свои FTP-ресурсы.

Attention!
1) Since #1937 the kernel access via syscall and sysenter instructions is discontinued.
2) All the repository sources will be carefully inspected to replace these instructions with the standard int40h.
3) The current entry points of syscall and sysenter are kept in the kernel till the 1st of July, 2011
4) After 01/07/2011 the old code might not be guaranteed to work with the newer kernels.
5) Dear developers, please check your code and upload your FTPs with the fresher sources.

Может не стоит так торопиться ? Продлить переходный период и выпустить в конце официальный дистрибутив как новую точку отсчёта.
И мнение остальных неплохо узнать.

Serge
Пока народ перед фактом не поставишь - никто и не почешется.
По-моему, 6 недель - вполне приличный срок. Тем более что я не собираюсь сразу же после этого ядро кромсать назло всем.
Всего лишь гарантирую, что до июля все будет как и раньше.
И внимательно слушаю чужие мнения.

Если система станет ещё более быстрой и компактной, то я только за, удаление не нужного.

popovpa
быстрее не станет.
Можно сэкономить ~1% кода, но это только на новых машинах, где вся система со двумя десятками процессов занимает ~1% памяти.

Главный смысл -
признание эксперимента по сабжу неудачным;
возврат mcall-API на единообразный int40h;
и освобождение "быстрых" переходов для узкоспециализированных API-сервисов, оптимизированных под эти переходы.

Новые API-функции и их формат надо обсуждать отдельно.
Сейчас очевидно, что они могут появиться только когда mcall вернется на int40h, или никогда.

Я может плохо соображаю, но зачем трогать Trunk?
Какая экономия в размерах получится?
Люди старались делали и внезапно "Давайте отрежем Сусанину ногу...".

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

(вопрос_из_ЛС) wrote:Объясните в чём тогда выгода в переделке всего когда на int 0x40? Я просто в системном программировании полный ноль. Может подскажите что почитать, что бы не объяснять. Или в двух словах на колбасе.

Пользовательские программы крутятся в 3-м кольце, им доступ к критическим системным ресурсам запрещен. Когда надо - приложение посылает ядру API-запрос и диспетчер системных вызовов (core/syscall.inc) его обслуживает. Важно, что сам диспетчер работает в привилегированном 0-кольце, и поэтому приложения должны как-то к нему достучаться.

Классический метод - это вызов программного прерывания. Твоя программа может содержать инструкцию int NN, где NN- это номер нужного прерывания. Операционная система хранит таблицу для 256 прерываний, и некоторые из них могут быть использованы для вызова системных сервисов.

int40h - это стандартная менуэтовская точка входа в ядро. Она передает управление на метку i40: из core/syscall.inc
Очень простой и гибкий метод, только медленный (около 400 тактов тратится на вход-выход) и использует очень специфичный mcall-метод передачи параметров (в регистрах)

В этом сабже народ попробовал использовать более быстрые инструкции для вызова сисфункций - sysenter и syscall. Красиво и с дружно поработали, но вышел пшик: ускорение оказалось очень незначительным, а программы начали заметно раздуваться в размере. А все потому что преимущества "быстрых" вызовов были сведены к нулю из-за
1) эмуляции менуэтовского метода передачи параметров, и
2) громоздкого переключения контекста при входе в Ring0 - как при выполнении инструкции int.

Вроде бы решение лежит на поверхности: фиг с ними с mcall-вызовами, их уже никакие оптимизации не улучшат.
Давайте их оставим как были, на int40h, а "быстрые" вызовы будет проводить по-быстрому, без лишних плясок с бубном.
Чтобы узнать время или прочитать цвет точки на экране - вовсе не обязательно переключаться в стек ядра!

Но для этого надо сначала восстановить статус-кво и отменить эмуляцию int40h через syscall/sysener. Иначе новый сервис будет конфликтовать со старым кодом. Я изменил макросы mcall везде, где они встречались в транке. Теперь он генерит только int40h. Я предупредил, что уберу syscall_entry и sysenter_entry из ядра. Если мало 6 недель - подождем 6 месяцев или 6 лет, но решение надо принимать сейчас.

Mario wrote:С другой стороны я не пользовался быстрыми вызовами ни разу, но...

CleverMouse wrote:Ну, я быстрые вызовы тоже не использую.

Serge wrote:Быстрые вызовы дают слишком мизерные улучшения.

Diamond wrote:1) Происходит раздувание программ.
2)3) Происходит ненужное раздувание программ.
4) Происходит лишнее раздувание программ.
5) Теряется совместимость.
6) Наличествуют теневые эффекты.

Heavyiron wrote:В принципе, я согласен с тем, что быстрый вызов нужен не везде, но теперь менять все назад... 1) самому как-то не хочется; 2) учитывая объем работы, не думаю, что кто-то другой за это возьмется

art_zh
Мой вопрос собственно относился к тому зачем ломать, если при условной компиляции подставляется int 0x40 и никакого раздутия на уровне приложения. По крайней мере в официальном дистрибутиве собрано так.

У тебя компилится int40, а у сотен юзеров, которые скачивают транк раз в месяц и подставляют в автосборке "p6" или "k6" - генерится совсем другой код.
И надо этот код сейчас вернуть на int40, чтобы у них не было проблем с новыми версиями ядра в ближайшем будущем.