Board.KolibriOS.org

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Serge

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

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

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

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

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