Board.KolibriOS.org

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, чтобы у них не было проблем с новыми версиями ядра в ближайшем будущем.

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

И упало каменное слово
На мою еще живую грудь.
...

По моему можно было просто поправить автосборку, что бы у всех собиралось под 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 это - именно то что надо.