Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Пт сен 22, 2017 3:50 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 455 сообщений ]  На страницу 1 2 3 4 531 След.
Автор Сообщение
 Заголовок сообщения: Новая модель ядра
СообщениеДобавлено: Пн май 01, 2006 11:46 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
Всем
Я заменил все непосредственные адреса на символьные и переместил ядро. Пока грузится по адресу 0х01010000, адреса 0х0 - 0x00FFFFFF используются для обнаружения ошибок со старыми адресами.
Предлагаю использовать адреса 0x0 - 0x7FFFFFFF для приложений, 0x80000000-0x803FFFFF для таблиц страниц 0x80400000 и выше для системы. LFB можно отображать на родные адреса видеокарты.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вт май 02, 2006 5:09 pm 
Не в сети

Зарегистрирован: Пт ноя 12, 2004 3:20 pm
Сообщения: 90
Поддерживаю.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вт май 02, 2006 5:32 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Мне понравилось.
Поддерживаю!


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вт май 02, 2006 6:36 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
За поддержку спасибо.

Предлагаю обсудить распределение памяти внутри ядра.
Сейчас карта памяти содержит много дыр. Можно часть переменных из диапазона 0x0000 - 0xFFFF объявить в коде ядра через uglobal и постепенно отказаться от размещения переменных по непосредственным адресам. Всем найденым переменным я дал имена в верхнем регистре. Эти имена предварительные, их можно обсудить и изменить. Сейчас код выглядит так
Код:
const.inc

MOUSE_X             equ 0x0100FB0A
MOUSE_Y             equ 0x0100FB0C

m_ps2.inc

add     AX,[MOUSE_X]    ;[XCoordinate]
cmp     AX,0
jge     @@M1
mov     AX,0
Теперь по распеределению памяти.
В диапазоне 0x0000-0xFFFF можно сохранить таблицу прерываний реального режима и область данных БИОС Выше поместить IDT и GDT. IDT занимает максимум 2 кб для GDT можно зарезервировать место на 1024 селекторов оставшееся место использовать для загрузки/перезагрузки ядра. Для кода ядра можно зарезервировать 256-384 кб и разместить в диапазоне 0x40000 - 0x9FFFF оставшуюся память использовать для работы со старыми ДМА.
Все остальные данные из первого мб памяти перенести выше 1 мб. LFB будет отображаться непосредственно на адреса видеопамяти поэтому все данные с адресов 0xC00000-0xFFFFFF можно сдвинуть вниз на адреса 0x800000-0xBFFFFF.
После перехода к страничной адресации эти физические адреса памяти будут отображены на диапазон линейных 0x80400000 и выше, а приложения будут использовать адреса 0x0000 - 0x7FFFFFFF. Базовые адреса всех дескрипторов будут выставлены в 0x0000 - получится "простая плоская модель памяти".


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вт май 02, 2006 9:55 pm 
Serge
Я так понимаю, что не только приложения, но и само ядро будет обращаться к памяти через менеджер памяти?
Перенесение всех переменных и областей будет титаническим трудом.

Цитата:
для GDT можно зарезервировать место на 1024 селекторов

Для оконного стека придется зарезервировать тоже 1024 входа.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Вт май 02, 2006 10:39 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
Mario79
Цитата:
Я так понимаю, что не только приложения, но и само ядро будет обращаться к памяти через менеджер памяти?
Если речь идет о выделении и возвращении памяти, то оно должно происходить через менеджер памяти это нормально для любой ОС. Резервировать память и располагать ее по фиксированным адресам тупиковый путь. На определение всех переменных я потратил 11 дней и большая часть времени ушла на отлов всяких [0xFE04] которым вообще не место по фиксированным адресам. Что касается стека окон, то данные разбросаны в разных местах и очень завязаны на максимальное количество окон и PID. Переделка оконной системы это отдельный большой вопрос.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср май 03, 2006 11:48 am 
Не в сети

Зарегистрирован: Пт ноя 12, 2004 3:20 pm
Сообщения: 90
По GUI есть некоторые наработки, но без DLL для пользовательских процессов они ничего не стоят.
Пока стоит оставить его, как есть. Главное, чтобы "перенесённое" ядро правильно работало.
Когда появится постраничное выделение/освобождение памяти для программ, можно будет полностью выкинуть старый GUI.

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

Для простоты можно весь диапазон [0; 2] Мб отобразить однозначно на 0x80000000, а таблицы страниц - на 0x80200000. Или наоборот.

Кстати, в новых FASM 1.65.20+ какие-то изменения, связанные с адресами. Я пока не разобрался, но стоит посмотреть.
http://board.flatassembler.net/topic.php?t=5162


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср май 03, 2006 12:57 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
Сейчас используется 512 байт для FDC DMA и 64 кб для SoundBlaster. Можно оставить под ISA DMA 256 кб и разместить их в первом мегабайте, не думаю что понадобится больше. PCI DMA могут работать с памятью по любому адресу и для них память можно выделять динамически. Память под ядро и LFB можно выделять большими страницами по 4 Мб это повышает быстродействие но такие страницы должны быть выравнены на 4 Мб. Так что получается два варианта или буферы DMA и ядро делят вместе первые 4 Мб и отображаются одной большой страницей, или ядро грузится начиная с 4 Мб а часть первых 4 Мб резервируется под DMA а остальная память будет выделяться 4 Кб страницами, но при таком варианте страничная память будет фрагментирована ужи при загрузке.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср май 03, 2006 2:06 pm 
Не в сети

Зарегистрирован: Пт ноя 12, 2004 3:20 pm
Сообщения: 90
А для буферов AC97 разве не требуется память DMA? Проблема не в том, чтобы выделить N страниц, а в том, чтобы выделить N последовательных страниц.

Страницы 4 Мб вроде бы стали доступны только начиная с какого-то Пентиума? Как быть с обратной совместимостью?


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср май 03, 2006 3:25 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
Большие страницы появились в Пентиум и АМД К5, глобальные в Пентиум Про. Проблем с совместимостью не будет. Можно написать разные версии кода в зависимости от возможностей процессора. Что касается выделения последовательных страниц для буферов ДМА то это тоже не проблема. Можно написать код для выделения страниц блоками разной длины и с разным выравниванием.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср май 03, 2006 5:39 pm 
Serge
Цитата:
Можно написать код для выделения страниц блоками разной длины и с разным выравниванием.

Вот это было бы весьма кстати и не только для DMA.
Например, буфер под валпапер должен располагаться в непрерывной области и занимать ровно столько, сколько нужно для картинки. Так мы сможем не использовать его совсем на машинах с малым количеством ОЗУ и рациональней использовать выделенную под это дело память вообще. Например, для закраски фона однотонным цветом буфер не нужен вообще.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Ср май 03, 2006 5:44 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
Надо еще подумать об использовании видеопамяти на картах где больше 4 Мб. Сейчас она пропадает зря.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср май 03, 2006 8:26 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Только надо помнить,что чтение из видеопамяти происходит на порядок медленнее,чем запись.Но это все-же быстреее,чем
эмулировать оперативку при помощи жесткого диска.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср май 03, 2006 8:40 pm 
Не в сети

Зарегистрирован: Пт ноя 12, 2004 3:20 pm
Сообщения: 90
А это идея - выбрасывать редкоиспользуемые страницы в видеопамять, когда свободная оперативка заканчивается.
Она уже где-нибудь реализована?


Вернуться к началу
 Заголовок сообщения: Re: Новая модель ядра
СообщениеДобавлено: Ср май 03, 2006 10:53 pm 
Не в сети

Зарегистрирован: Вт апр 18, 2006 11:48 pm
Сообщения: 53
Serge писал(а):
Всем
Я заменил все непосредственные адреса на символьные и переместил ядро. Пока грузится по адресу 0х01010000, адреса 0х0 - 0x00FFFFFF используются для обнаружения ошибок со старыми адресами.
Предлагаю использовать адреса 0x0 - 0x7FFFFFFF для приложений, 0x80000000-0x803FFFFF для таблиц страниц 0x80400000 и выше для системы. LFB можно отображать на родные адреса видеокарты.


Почему бы прямо не написать - давайте использовать модель памяти Windows NT? ;)


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 455 сообщений ]  На страницу 1 2 3 4 531 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB