Оптимизация ядерной графики
-
почему в голосовании нет варианта "заменить графический на текстовый режим"?)И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Gluk
потому что зачем.
потому что зачем.
Почему нет варианта вырезать всю графику из ядра полностью?
Выделить в библиотеки и драйверы в смысле
Выделить в библиотеки и драйверы в смысле
Если перефразировать CleverMouse: "У нас уже есть одна операционная система, выглядящая как DOS, - это DOS"Gluk wrote:почему в голосовании нет варианта "заменить графический на текстовый режим"?)
yogev_ezra, то есть Колибри отличается от остальных ОС только своим интерфейсом?
Если портировать гр. инт. Колибри под линукс, такой линукс станет Колибри?
Если портировать гр. инт. Колибри под линукс, такой линукс станет Колибри?
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
И понесся флуд и оффтоп и возрыдали сирые форума сего...
Mario, в моем сообщении трижды упоминается Колибри, и дважды графика (см. заголовок темы), для двух строчек это достаточно много
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Твой первый пост отклоняется от темы в провоцирующее русло "Давайте отрежем Сусанину ногу...", а тема насчет оптимизации GUI, а не замены его на что-то. Колибри исторически сложилась (в наследии от Menuet) как ОС с GUI. Вопрос об отделении GUI от ядра уже обсуждался в других темах форума.
Я думаю не имеет смысла опять все в одну кучу сваливать. В конечном счете если бы кто-то действительно хотел сделать Колибри с текстовым режимом вместо GUI, то он бы это сделал или нет?
Я думаю не имеет смысла опять все в одну кучу сваливать. В конечном счете если бы кто-то действительно хотел сделать Колибри с текстовым режимом вместо GUI, то он бы это сделал или нет?
не только примитивы, но и саму GUIшку "вынес" бы в виде отдельного апи, например, типа int 0x50art_zh wrote:А на какой номер новые примитивы
(вот в биосе int 0x10 существует целевым назначением и это хорошо ведь).
Зачем все на 40 все лепить?
Куда их экономить то, вектора эти, не вижу прока.
А вот тематическо-функциональное разделение мне кажется уместным, особенно в свете новых технологий, редакций, принципиально нового движка и т.д...
Дабы не было крика про поддержку "старого" GUI, вещи касательно 40вых дел можно ведь и не трогать, оставив на "пока", вполне возможно атрофируются сами со временем..., как проигравшая технология GUI.
VaStaNi, быстрые системные вызовы sysenter и syscall имеют только одну точку входа.
Кроме того, вы, похоже, не прочли или не осознали пост, на который отвечаете, - в посте речь шла о создании нескольких новых примитивов, а отнюдь не о переносе или замене существующих.
Кроме того, вы, похоже, не прочли или не осознали пост, на который отвечаете, - в посте речь шла о создании нескольких новых примитивов, а отнюдь не о переносе или замене существующих.
Сделаем мир лучше!
VaStaNi
Столь радикальные изменения подразумевают смену соглашения о порядке передачи параметров в ядро ?
Если нет - тогда зачем менять шило на мыло? int40 - это пусть забавный, но все-таки не самый идиотский вариант.
Если да - тогда надо глубоко продумать альтернативный механизм, иначе можно что-то еще смешнее накостылять.
Ради эллипса конечно не стоит огород городить, а вот для парсера очередей GUI-запросов - вполне.
CleverMouse
fastcall и syscall оказались малоэффективной заменой для int40, их можно безболезненно убрать из макроопределения mcall. А потом - и из ядра. Полгодаругани - и всё забудется...
Для syscall заметное (до трех раз!) ускорение входа в Ring0 достигается только если не переключать стек задачи, и не использовать ecx для передачи параметров. А еще лучше - передавать все параметры в стеке.
Но это, в сущности, и определяет некий новый API-механизм, к которому можно будет приклеить и соответствующий fastcall, и int50.
Столь радикальные изменения подразумевают смену соглашения о порядке передачи параметров в ядро ?
Если нет - тогда зачем менять шило на мыло? int40 - это пусть забавный, но все-таки не самый идиотский вариант.
Если да - тогда надо глубоко продумать альтернативный механизм, иначе можно что-то еще смешнее накостылять.
Ради эллипса конечно не стоит огород городить, а вот для парсера очередей GUI-запросов - вполне.
CleverMouse
fastcall и syscall оказались малоэффективной заменой для int40, их можно безболезненно убрать из макроопределения mcall. А потом - и из ядра. Полгода
Для syscall заметное (до трех раз!) ускорение входа в Ring0 достигается только если не переключать стек задачи, и не использовать ecx для передачи параметров. А еще лучше - передавать все параметры в стеке.
Но это, в сущности, и определяет некий новый API-механизм, к которому можно будет приклеить и соответствующий fastcall, и int50.
ну вот и чудненько. Если еще кто по графике спец и поддержит, то просуммировав пройденный опыт можно надеяться, что удастсяart_zh wrote:А еще лучше - передавать все параметры в стеке.
Но это, в сущности, и определяет некий новый API-механизм, к которому можно будет приклеить и соответствующий fastcall, и int50.
пусть и не глубоко, но перспективно и по сабжу суть - это было бы весьмаart_zh wrote:глубоко продумать альтернативный механизм, иначе можно что-то еще смешнее накостылять.
угу. Ты один из вариантов уже предложил. Только не "смену", а новое, заточенное под...art_zh wrote:Столь радикальные изменения подразумевают смену соглашения о порядке передачи параметров в ядро ?
Думаю может и еще кто то экспериментировал с целью оптимизации. НУ и примитивы вполне свои плюсы могут дать, хотя бы, как упрощения вызовов, легкость использования, объявления...
Имхо.
Поддерживаю идею. Быстрые вызовы дают слишком мизерные улучшения. Может при их появлении и был смысл, но с тех пор микроархитектуры сильно поменялись.
Хм, неожиданный поворот событий. Ну, я быстрые вызовы тоже не использую.
Сделаем мир лучше!
Ну вроде у всех было время проголосовать (сдается мне, что и у троллей тоже).
Пора принимать трудное решение - переходить исключительно на 32-битную графику, или оставить всё блин как есть.
Пока что прозвучал только один (весьма убедительный и очень авторитетный) консервативный довод.
Да, есть эмуляторы.
И еще не везде выкинули старые надежные платформы (EGA не видел, но VGA в натуре еще есть!!), на которых только ДОС и Колибри можно реально запустить.
Ну и что, так и будем ждать когда они совсем сдохнут, или все-таки оглянемся вперёд?
Пора принимать трудное решение - переходить исключительно на 32-битную графику, или оставить всё блин как есть.
Пока что прозвучал только один (весьма убедительный и очень авторитетный) консервативный довод.
Да, есть эмуляторы.
И еще не везде выкинули старые надежные платформы (EGA не видел, но VGA в натуре еще есть!!), на которых только ДОС и Колибри можно реально запустить.
Ну и что, так и будем ждать когда они совсем сдохнут, или все-таки оглянемся вперёд?
Who is online
Users browsing this forum: No registered users and 25 guests