Board.KolibriOS.org
http://board.kolibrios.org/

Новая модель ядра
http://board.kolibrios.org/viewtopic.php?f=35&t=509
Страница 1 из 31

Автор:  Serge [ Пн май 01, 2006 11:46 pm ]
Заголовок сообщения:  Новая модель ядра

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

Автор:  Иван Поддубный [ Вт май 02, 2006 5:09 pm ]
Заголовок сообщения: 

Поддерживаю.

Автор:  andrew_programmer [ Вт май 02, 2006 5:32 pm ]
Заголовок сообщения: 

Мне понравилось.
Поддерживаю!

Автор:  Serge [ Вт май 02, 2006 6:36 pm ]
Заголовок сообщения: 

За поддержку спасибо.

Предлагаю обсудить распределение памяти внутри ядра.
Сейчас карта памяти содержит много дыр. Можно часть переменных из диапазона 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 - получится "простая плоская модель памяти".

Автор:  Mario79 [ Вт май 02, 2006 9:55 pm ]
Заголовок сообщения: 

Serge
Я так понимаю, что не только приложения, но и само ядро будет обращаться к памяти через менеджер памяти?
Перенесение всех переменных и областей будет титаническим трудом.

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

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

Автор:  Serge [ Вт май 02, 2006 10:39 pm ]
Заголовок сообщения: 

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

Автор:  Иван Поддубный [ Ср май 03, 2006 11:48 am ]
Заголовок сообщения: 

По GUI есть некоторые наработки, но без DLL для пользовательских процессов они ничего не стоят.
Пока стоит оставить его, как есть. Главное, чтобы "перенесённое" ядро правильно работало.
Когда появится постраничное выделение/освобождение памяти для программ, можно будет полностью выкинуть старый GUI.

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

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

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

Автор:  Serge [ Ср май 03, 2006 12:57 pm ]
Заголовок сообщения: 

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

Автор:  Иван Поддубный [ Ср май 03, 2006 2:06 pm ]
Заголовок сообщения: 

А для буферов AC97 разве не требуется память DMA? Проблема не в том, чтобы выделить N страниц, а в том, чтобы выделить N последовательных страниц.

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

Автор:  Serge [ Ср май 03, 2006 3:25 pm ]
Заголовок сообщения: 

Большие страницы появились в Пентиум и АМД К5, глобальные в Пентиум Про. Проблем с совместимостью не будет. Можно написать разные версии кода в зависимости от возможностей процессора. Что касается выделения последовательных страниц для буферов ДМА то это тоже не проблема. Можно написать код для выделения страниц блоками разной длины и с разным выравниванием.

Автор:  Mario79 [ Ср май 03, 2006 5:39 pm ]
Заголовок сообщения: 

Serge
Цитата:
Можно написать код для выделения страниц блоками разной длины и с разным выравниванием.

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

Автор:  Serge [ Ср май 03, 2006 5:44 pm ]
Заголовок сообщения: 

Надо еще подумать об использовании видеопамяти на картах где больше 4 Мб. Сейчас она пропадает зря.

Автор:  andrew_programmer [ Ср май 03, 2006 8:26 pm ]
Заголовок сообщения: 

Только надо помнить,что чтение из видеопамяти происходит на порядок медленнее,чем запись.Но это все-же быстреее,чем
эмулировать оперативку при помощи жесткого диска.

Автор:  Иван Поддубный [ Ср май 03, 2006 8:40 pm ]
Заголовок сообщения: 

А это идея - выбрасывать редкоиспользуемые страницы в видеопамять, когда свободная оперативка заканчивается.
Она уже где-нибудь реализована?

Автор:  rabid rabbit [ Ср май 03, 2006 10:53 pm ]
Заголовок сообщения:  Re: Новая модель ядра

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


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

Страница 1 из 31 Часовой пояс: UTC+03:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/