Fast System Call

Internal structure and you change requests/suggestions
  • Я может плохо соображаю, но зачем трогать 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, чтобы у них не было проблем с новыми версиями ядра в ближайшем будущем.
  • Насчет сотен юзеров ты конечно оптимистично погорячился, но если уж считаешь что второй раз мартышкин труд будет полезен, то я тогда не возражаю. :mrgreen:
  • И упало каменное слово
    На мою еще живую грудь.
    ...

    По моему можно было просто поправить автосборку, что бы у всех собиралось под int40.
    > генерится совсем другой код.
    какие проблемы с этим возникали?
    Я понял что идеи две:
    1. Сэкономить место
    2. Использовать SYSCALL/SYSENTER с другими параметрами нежели int40. - но тут получим только раздувание кода.

    Таки в чем идея? В принципе код писался с целью эксперимента и мне его не жалко, только я:
    1. Не вижу мотивированных причин для его удаления
    2. Этот код мог послужить кому то хорошим примером, для дальнейшего развития системы, его удаление заставит переписывать подобный код в будущем с нуля.
  • Ghost
    Идея одна - ускорить отработку некоторых новых системных вызовов не на 30%, а в 3 раза, как положено.

    Очень много времени занимает переключение стека и эмуляция int40.

    Ну и фиг с этой эмуляцией. Давай вызывать старые сисфункции только через int40,
    и добавим новую группу (быстрых) вызовов через syscall (с эмуляцией через int41 для тех, у кого этого нет).

    Вот и вся идея.

    PS
    И упало каменное слово
    На мою еще живую грудь.
    Это стихи надломленной женщины бальзаковского возраста. Тебе они совсем не подходят.
  • Стихи цитировал к безоговорочному решению выбросить код.
    Я отсутствовал продолжительное время, но сдается мне что вешать на быстрые вызовы нечего ) Расчищать место для будущей постройки хорошо, но по моему её ещё даже в планах нет?
  • Ghost wrote:Я отсутствовал продолжительное время, но сдается мне что вешать на быстрые вызовы нечего ) Расчищать место для будущей постройки хорошо, но по моему её ещё даже в планах нет?

    ... Этот код мог послужить кому то хорошим примером, для дальнейшего развития системы, его удаление заставит переписывать подобный код в будущем с нуля.
    Посмотри svn//kernel/branches/Kolibri-A/trunk/core/syscall.inc
    твой код работает просто замечательно! и в таком виде он раскрывается на 100%, а не эмулирует дремучее программное прерывание.

    "Длинный" системный сервис на syscall переносить нет смысла, зато для операций типа rdmsr или putpixel это - именно то что надо.
  • Who is online

    Users browsing this forum: Yandex [Bot] and 11 guests