Asmxygen
Websvn
Builds
Bugs
FTP
Wiki
Telegram
Discord
RedditПрактически будет три менеджера памяти.
Менеджер страничной памяти.
Его работа должна быть совершенно прозрачной для программ и большинства функций системы.
Менеджер кучи для ядра. Это может быть любая вариация malloc выделяющая память блоками, кратными странице, и выравненными на размер страницы.
Менеджер кучи для приложений.
Эта функция будет выделять память страничными блоками но по адресам, доступным приложению. Просто malloc портирую на основе кода написанного Doug Lea (используется GNU libc, описание на http://gee.cs.oswego.edu/dl/html/malloc.html).
Что касается 64 функции то она не сильно мешает. Можно резервировать для старых программ 4 мегабайта адресов от начала приложения и пусть ф.64 с ними работает. БОльшие блоки памяти будут получаться через вызов user_alloc и освобождаться user_free. Их описание будет сильно похоже на MS Win VirtualAlloc. Что касается выделения памяти для DMA, то здесь нет никаких проблем, можно определить те области физической памяти, которые используются устройствами и при необходимости отображать в адресное пространство задачи как это происходит с LFB. Селектор gs никому не мешает и трогать его я не собираюсь. Просто можно вызовом user_alloc зарезервировать в адресном пространстве программы буфер, отобразить туда LFB и работать с ним обычным образом. А ещё большинство видеокарт имеют больше 4 мБ памяти и эти мегабайты совсем не используются. Речь шла об этом.
Менеджер DLL в MeOS
Грузить библиотеки в адресное пространство ядра?! Чтобы код DLL-ки исполнялся в 0-кольце?! И маленький глюк библиотеки рушил систему нафиг?! (Я уж молчу про огромную дыру в безопасности в этом случае). И для разных процессов одна и та же DLL-ка, как правило, использует разные данные.
Ты предлагаешь при запуске выделять программе столько памяти, сколько ей надо, а не сколько указано в заголовке. Эту фразу я могу истолковать только одним способом - будет изначально выделяться память под размер файла и в дальнейшем, по мере обращения к существующим, но не выделенным страницам, обработчик #PF будет выделять новую физическую память. А это - сильные тормоза.
Проблема с malloc/free следующая. В принципе функции 64 самой по себе достаточно для организации менеджера памяти 3-кольца в самой программе. Дело в том, что создавать malloc/free как системные вызовы неэффективно - при выделении малых объёмов памяти каждый раз выходить в 0-кольцо и возвращаться - очень медленно. В Windows и Linux это реализовано в DLL (Windows, функции HeapAlloc/HeapReAlloc/HeapFree) / shared libraries (Linux, malloc/realloc/free). Ну а под DOS/Windows каждый компилятор ЯВУ считает своим долгом вставить собственную реализацию malloc/free прямо в exe-шник (причём не базирующуюся на Heap*, а выполняющую кучу теоретически эффективных действий).
И кстати, можно особо не ссылаться на то, что FASM поддерживает COFF - я хорошо разбираюсь в исходниках FASM'а (а также в исходниках ядра - практически всех, кроме работы с сетью и железом, но включая вышеупомянутый менеджер памяти) и без проблем могу добавить поддержку нового формата - был бы формат...
Ты предлагаешь при запуске выделять программе столько памяти, сколько ей надо, а не сколько указано в заголовке. Эту фразу я могу истолковать только одним способом - будет изначально выделяться память под размер файла и в дальнейшем, по мере обращения к существующим, но не выделенным страницам, обработчик #PF будет выделять новую физическую память. А это - сильные тормоза.
Проблема с malloc/free следующая. В принципе функции 64 самой по себе достаточно для организации менеджера памяти 3-кольца в самой программе. Дело в том, что создавать malloc/free как системные вызовы неэффективно - при выделении малых объёмов памяти каждый раз выходить в 0-кольцо и возвращаться - очень медленно. В Windows и Linux это реализовано в DLL (Windows, функции HeapAlloc/HeapReAlloc/HeapFree) / shared libraries (Linux, malloc/realloc/free). Ну а под DOS/Windows каждый компилятор ЯВУ считает своим долгом вставить собственную реализацию malloc/free прямо в exe-шник (причём не базирующуюся на Heap*, а выполняющую кучу теоретически эффективных действий).
И кстати, можно особо не ссылаться на то, что FASM поддерживает COFF - я хорошо разбираюсь в исходниках FASM'а (а также в исходниках ядра - практически всех, кроме работы с сетью и железом, но включая вышеупомянутый менеджер памяти) и без проблем могу добавить поддержку нового формата - был бы формат...
Ушёл к умным, знающим и культурным людям.
1. Пока речь идет только о загрузке драйверов и то только на стадии прожектов. Сейчас ситуация с драйверами вообще никакая. Я пытаюсь это изменить.
2. Ты совершенно точно уловил принцип: выделять память в обработчике #PF. И это не сильные тормоза, мы же не грузим страницы с диска. Зато это решает все проблемы с прожорливыми приложениями. Исключение обрабатывается без преключения задач а выделение страницы происходит быстро. На худой случай, если программа так торопится получить всю память сразу можно использовать в самом начале mov eax, [4096], mov eax, [8192] и т.д. хотя я считаю это плохой идеей.
3. Я не собираюсь создавать malloc/free как системные функции. это будет простой inc файл с необходимым кодом.
в начале программы надо вызвать init_malloc, которая создаст кучу и сделает всю черновую работу. Например jpeglib из jpegview использует свою версию malloc. Я хочу сделать версию malloc доступную для всех. Думаю многие нуждаются в этом. Если у кого то уже есть готовые решения - очень хорошо.
4. По поводу COFF.
Это один из вариантов. Формат хорошо описан и он подходит для этих целей. Если есть другие подходящие стандартные форматы - можно использовать их, это лучше, чем изобретать свой уникальный формат.
Наконец можно сделать разные версии загрузчиков.
Последнее.
Твой отладчик здорово помог мне разобраться с загрузкой сжатых программ. Увы функции, которые он использовал пока не доделаны. Если не сложно, пожалуйста напиши мне на infinity_sound<собака>mail.ru какие системные функции использует отладчик и какие функции от менеджера памяти ему могут понадобиться. Кстати, отладчик кандидат номер 1 на загрузку в ядро - это обещает большие возможности.
Для всех
Каким должен быть размер адресного пространства приложений? Сколько резервироватьь на нужды ядра?
2. Ты совершенно точно уловил принцип: выделять память в обработчике #PF. И это не сильные тормоза, мы же не грузим страницы с диска. Зато это решает все проблемы с прожорливыми приложениями. Исключение обрабатывается без преключения задач а выделение страницы происходит быстро. На худой случай, если программа так торопится получить всю память сразу можно использовать в самом начале mov eax, [4096], mov eax, [8192] и т.д. хотя я считаю это плохой идеей.
3. Я не собираюсь создавать malloc/free как системные функции. это будет простой inc файл с необходимым кодом.
в начале программы надо вызвать init_malloc, которая создаст кучу и сделает всю черновую работу. Например jpeglib из jpegview использует свою версию malloc. Я хочу сделать версию malloc доступную для всех. Думаю многие нуждаются в этом. Если у кого то уже есть готовые решения - очень хорошо.
4. По поводу COFF.
Это один из вариантов. Формат хорошо описан и он подходит для этих целей. Если есть другие подходящие стандартные форматы - можно использовать их, это лучше, чем изобретать свой уникальный формат.
Наконец можно сделать разные версии загрузчиков.
Последнее.
Твой отладчик здорово помог мне разобраться с загрузкой сжатых программ. Увы функции, которые он использовал пока не доделаны. Если не сложно, пожалуйста напиши мне на infinity_sound<собака>mail.ru какие системные функции использует отладчик и какие функции от менеджера памяти ему могут понадобиться. Кстати, отладчик кандидат номер 1 на загрузку в ядро - это обещает большие возможности.
Для всех
Каким должен быть размер адресного пространства приложений? Сколько резервироватьь на нужды ядра?
Serge
Чем тебя не устраивает текущая карта памяти? В ней для приложений отведено 2Гb-256Mb. Для ядра - 1Гb-16Mb ( общий размер оперативки должен быть так же меньше данного числа).
memtest.7z - как раз реализация malloc/free/realloc для приложений в виде .inc файла (основанная только на 64 функции).
Чем тебя не устраивает текущая карта памяти? В ней для приложений отведено 2Гb-256Mb. Для ядра - 1Гb-16Mb ( общий размер оперативки должен быть так же меньше данного числа).
memtest.7z - как раз реализация malloc/free/realloc для приложений в виде .inc файла (основанная только на 64 функции).
Serge
Отправил. Впрочем, описание 69-й функции скоро войдёт в документацию, которую я делаю.
Сам отладчик mtdbg работает только через 69-ю функцию (даже 64-ю пока не использует), а вот в ядре код обработки системных функций использует read/write_process_memory и сообщения отладки, реализация которых аналогична IPC (функция debugger_notify из debug.inc).
Отправил. Впрочем, описание 69-й функции скоро войдёт в документацию, которую я делаю.
Сам отладчик mtdbg работает только через 69-ю функцию (даже 64-ю пока не использует), а вот в ядре код обработки системных функций использует read/write_process_memory и сообщения отладки, реализация которых аналогична IPC (функция debugger_notify из debug.inc).
Ушёл к умным, знающим и культурным людям.
diamond
Можно в обработчике #PF выделять память не по одной странице а блоками по 4, 8 и т.д.
Например если в системе осталось мало памяти можно использовать "скупой" вариант и выделять по одной странице, если много выделять несколько страниц. При загрузке программы выделять память только под загрузку файла, а дальше уже в зависимости от доступной физической памяти
Можно в обработчике #PF выделять память не по одной странице а блоками по 4, 8 и т.д.
Например если в системе осталось мало памяти можно использовать "скупой" вариант и выделять по одной странице, если много выделять несколько страниц. При загрузке программы выделять память только под загрузку файла, а дальше уже в зависимости от доступной физической памяти
halyavin
Я думаю что память ядра лучше держать одним блоком. например 0-256 мБ ядро 256мБ и выше приложения.
Можно сразу зарезервировать под ядро 1 гБ и отдать все остальное место приложениям. Считаю, что не стоит разбивать адресное пространство ядра на верхнюю и нижнюю часть а в середине держать приложение. Это усложняет работу с таблицами страниц.
Я думаю что память ядра лучше держать одним блоком. например 0-256 мБ ядро 256мБ и выше приложения.
Можно сразу зарезервировать под ядро 1 гБ и отдать все остальное место приложениям. Считаю, что не стоит разбивать адресное пространство ядра на верхнюю и нижнюю часть а в середине держать приложение. Это усложняет работу с таблицами страниц.
halyavin
Как я понимаю 64 функция использовалась когда страничной памяти не было и нужно было изменять пределы сегменто кода и данных. Со страничной памятью в этом нет необходимости пределы сразу устанавливаются на максимальное значение и 64 ф. просто прибавляет и отрезает память от конца программы.
Теперь вопрос. Графический редактор создает 4мб буфер, потом еще два буфера по 2 мБ и решает что первый буфер ему не нужен.
Что сделает 64 функция?
Как я понимаю 64 функция использовалась когда страничной памяти не было и нужно было изменять пределы сегменто кода и данных. Со страничной памятью в этом нет необходимости пределы сразу устанавливаются на максимальное значение и 64 ф. просто прибавляет и отрезает память от конца программы.
Теперь вопрос. Графический редактор создает 4мб буфер, потом еще два буфера по 2 мБ и решает что первый буфер ему не нужен.
Что сделает 64 функция?
64 ничего сама не делает. В твоём примере она поможет, только если программа переместит оставшиеся 2 блока вниз.
Вот и я о том же.
А почему не удалось переместить ядро по адресам 0хС0000000+? Идея неплохая, Может стоит довести ее до завершения?
А почему не удалось переместить ядро по адресам 0хС0000000+? Идея неплохая, Может стоит довести ее до завершения?
-
- Posts 896
- Joined: Thu May 19, 2005 4:43 pm
Serge,в моем графическом редакторе память выделяется так.
При запуске программы резервируется 100 килобайт памяти(под саму программу).Потом выделяется 4 мегабайта под экранный буфер при помощи ф.64.
При открытии графического файла программа смотрит,не помещается ли файл в 4-х мегабайтовую область.Если не помещается,то выделяется дополнительная память равная (размер_графического_файла - 4Мб).
Потом программа смотрит какого размера картинка.Резервируется 64 ф. дополнительная память
(Picture_SizeX*Picture_SizeY*3)*2.
В первом буфере храниться сама картинка,а во втором её копия,для того,чтобы реализовать возможность
'ОТМЕНА ПОСЛЕДНЕГО ДЕЙСТВИЯ'
Надеюсь изменение менеджера памяти не сильно скажется на работе 64 функции.А то не хочется переписывать код графического редактора(я и так его с нуля переписывал в феврале ).
При запуске программы резервируется 100 килобайт памяти(под саму программу).Потом выделяется 4 мегабайта под экранный буфер при помощи ф.64.
При открытии графического файла программа смотрит,не помещается ли файл в 4-х мегабайтовую область.Если не помещается,то выделяется дополнительная память равная (размер_графического_файла - 4Мб).
Потом программа смотрит какого размера картинка.Резервируется 64 ф. дополнительная память
(Picture_SizeX*Picture_SizeY*3)*2.
В первом буфере храниться сама картинка,а во втором её копия,для того,чтобы реализовать возможность
'ОТМЕНА ПОСЛЕДНЕГО ДЕЙСТВИЯ'
Надеюсь изменение менеджера памяти не сильно скажется на работе 64 функции.А то не хочется переписывать код графического редактора(я и так его с нуля переписывал в феврале ).
Никаких изменений в работе 64ф. не будет. Будет два варианта или ф 64 или user_alloc, выделяющая блок и возвращающая указатель. Использовать их вместе не получится.
Я хочу максимально сохранить возможности существующих функций, добавив несколько новых.
Я хочу максимально сохранить возможности существующих функций, добавив несколько новых.
Serge
Переместить все ядро по адресам 0xC0000000+ не удалось потому, что нужно модифицировать кучу кода по всему ядру. Некоторое упрощение произойдет если поставить org 0xC0000000. Но нужно решить в какое именно место его поставить (например нельзя этого делать до инициализации таблиц страниц в менеджере памяти). Здесь главная проблема - объем работы. Можно создать на нашем subversion-сервере отдельную ветку и постепенно проводить эти изменения. Возьмешься за реализацию этого проекта?
Если удастся сделать нормальный менеджер адресного пространства ядра, то можно будет и не отображать динамическую память на адреса 0xC01000000+ (оно нужно в основном для того, чтобы выделять одну страницу без необходимости модификаций таблиц страниц).
Переместить все ядро по адресам 0xC0000000+ не удалось потому, что нужно модифицировать кучу кода по всему ядру. Некоторое упрощение произойдет если поставить org 0xC0000000. Но нужно решить в какое именно место его поставить (например нельзя этого делать до инициализации таблиц страниц в менеджере памяти). Здесь главная проблема - объем работы. Можно создать на нашем subversion-сервере отдельную ветку и постепенно проводить эти изменения. Возьмешься за реализацию этого проекта?
Если удастся сделать нормальный менеджер адресного пространства ядра, то можно будет и не отображать динамическую память на адреса 0xC01000000+ (оно нужно в основном для того, чтобы выделять одну страницу без необходимости модификаций таблиц страниц).
Я готов взяться за эту работу и кое что уже начал делать. Но мне нужен доступ к вашему серверу версий и объясните как с ним работать, у меня есть небольшой опыт работы с CVS.
И ещё надо отказаться от использования абсолютных адресов в численном виде. Например mov eax, [0x3000+ebx+0x10]
заменять на
чего_то_там equ 0x3000
mov eax, [чего_то_там+ebx+0x10]
Создать файл для всех таких глобальных переменныых и дать им имена.
Это сильно упростит все возможные модификации в дальнейшем и снизит риск ошибок.
И надо окончательно определиться с распределением адресного пр-ва.
Можно зарезервировать нижние 2 гБ адресов для приложений и верхние два для ядра системы. И зарезервировать часть физической памяти в диапазоне 0 - 0х00FF FFFF для старых устройств ДМА.
И ещё надо отказаться от использования абсолютных адресов в численном виде. Например mov eax, [0x3000+ebx+0x10]
заменять на
чего_то_там equ 0x3000
mov eax, [чего_то_там+ebx+0x10]
Создать файл для всех таких глобальных переменныых и дать им имена.
Это сильно упростит все возможные модификации в дальнейшем и снизит риск ошибок.
И надо окончательно определиться с распределением адресного пр-ва.
Можно зарезервировать нижние 2 гБ адресов для приложений и верхние два для ядра системы. И зарезервировать часть физической памяти в диапазоне 0 - 0х00FF FFFF для старых устройств ДМА.
Посидев как-то на канале #meos и пообщавщись с mike.dld решил попробовать реализовать какое-то подобие длл. Уже есть небольшие наброски. Конечно на менеджер длл то что я сделал совсем не тянет,но это единственная тема про длл на форуме (...а может я полохо искал).
То что я сделал буду называть пока недодлл (с лёгкой руки Поддубного...). Эта недодлл уже может грузить библиотеки простого формата (небольшой заголовок,пару таблиц и код),использовать функции библиотек. Библиотеки тоже в совю очередь могут грузить библиотеки и использовать их фунции. Пока не разобрался с релоками и не знаю как проводить инициализацию библиотек (нужен менеджер памяти,пока нашёл мп от halyavin и от mike.dld... ). Если кто заинтересовался могу выслать код.... и жду конструктивной критики
То что я сделал буду называть пока недодлл (с лёгкой руки Поддубного...). Эта недодлл уже может грузить библиотеки простого формата (небольшой заголовок,пару таблиц и код),использовать функции библиотек. Библиотеки тоже в совю очередь могут грузить библиотеки и использовать их фунции. Пока не разобрался с релоками и не знаю как проводить инициализацию библиотек (нужен менеджер памяти,пока нашёл мп от halyavin и от mike.dld... ). Если кто заинтересовался могу выслать код.... и жду конструктивной критики
Who is online
Users browsing this forum: No registered users and 29 guests