Обновить
16K+
8

Пользователь

16
Рейтинг
13
Подписчики
Хабр КарьераХабр Карьера
Отправить сообщение

Это будет уже в libcxxabi, часть я взял из libcxxrt. Идея состоит в том, что у меня будут С совместимые апи в духе vsnprintf (будет следующая статья, уже в черновиках есть), malloc и т.д. и на этой базе я реализую уже new/delete с itatium hooks но без исключений. С апи нужны что бы взять например деманглер из libcxxrt, в общем зависимости для стороеннего кода на С который я возможно захочу использовать

Спасибо, арм только буду изучать. Взял книгу по асму RISC-V

Благодарю вас что навели на мысль: https://github.com/GNUDimarik/small_allocator/commit/b77123deb5f6c6d2e7f50f5358413d0a0318de18#diff-45b5c5bc4e257b0cd52937a7cfb5217b4d4f26711cc3300c5e7aef051b4ef9e9R558
не стесняйтесь создавать issue на github если наши ошибку где-то.
Буду признателен если ошибки будут не в main.cpp он тестовый и его функция лишь в визуализации дампа для статьи и дебага, просто пишите каменты сюда о нем

ERROR: memory: Bad magic number это избыточный лог который выводится функцией mem_block_check_block которая вызывается в коде следующего вида:
static void mem_block_resolve_from_align(void ptr){ auto p = ptr; if (!mem_block_check_block(ptr)) { auto offset = *mem_block_get_magic_from_header(ptr); p = mem_block_char_ptr(ptr) - offset; } return p; }
думаю этот лог нужно убрать и оставить лог только в функции проверки целостности
сделаю и только что увидел что не помешало бы добавить проверку в mem_realloc как в mem_free

Исправил, благодарю вас за внимательность!

Просил chatgpt сгенерировать. Перед этим я с ним обсуждал алгоритм, писать очень подробный промпт тоже сработает (проверено)

Это ошибка. Спасибо за замечание. Исправил

Верно. Это тема следующей статьи. Оглавление таки приделаю :-D

Вам во вторую часть :-)

Пожалуй не помешало бы оглавление в начале )

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

Не уверен что лучше и не уверен что будет лучше :-)

Но будет работать и для удоволетворения зависимости libcxxrt должно быть достаточно.

Можно будет сравнить когда аллокатор будет закончен

Похоже что там пул аллокатор, не общего назначения

Вам не следует спешить. Аллокатор начинается с подобных алгоритмов. Перед красно черным деревом вы изучаете бинарное. Это пример просто.

Аллокатор это все что распределяет память :-)

Аллокаторы везде используются где есть распределение памяти. std::cout то же в себе что то распределяет, так что даше Hello world на С++ содержит их. Я лишь говорю что я пишу конкретно про осдев, но принцип да, можно везде применять. Безусловно. Как сортировку например. Можно в игре массив сортировать, можно и ОС. Алгоритм это алгоритм

Для реализации стандартной библиотеки соответствующий стиль кода. Вообще Главный плюс в том, что научитесь понимать алгоритмы в STL со временем. Сначала будет бить по глазам, а потом ревью пойдет как по маслу :-D

Что бы привыкнуть, лучше всего таким стилем писать имо

Это код теста что бы запустить у себя и проверить. Далее будет юнит тест. Тоже будет проходиться в системе. using namespace std уйдет в итоговой демке которая будет грузится в эмуляторе только. Но до этого еще далеко.

Зависимости cstring и cerrno будут предоставлены, если нужно я расскажу в отдельной статье как

Я разрабатывал стандартрую библиотеку для ОС и использовал соответствующий стиль. Он такой, что бы не было пересечений, вроде как это так объясняется. Примеры пересечений выдумывать не стану )

Через статью будет явный список допилен сюда свободных блоков. В OSDEV что бы был хешмеп его нужно ручками приделать с свой рантайм сначала. Нам пока рано в данный момент :-)

Каким образом? Она пытается слить последовательно идущие блоки друг с другом.

Один вызов пытается сделать что то такое:

[free block] [free block] [free block] @[allocated block]@[free block] --

--> [free block * 3] @[allocated block]@[free block]

Другое дело что список односвязный и если свободен предыдущий блок, а не следующий, то она этого не поймет так как двигается по списку вперед. Из вывода теста аллокатора видно что это порождает фрагментацию в конце:

_MemoryBlock: service block address 0x55efd7b4beb8 size 8 size with overhead 16 state allocated
_MemoryBlock: block address 0x55efd7b4bec8 size 15832 size with overhead 15840 state free
_MemoryBlock: block address 0x55efd7b4fca8 size 504 size with overhead 512 state free
_MemoryBlock: service block address 0x55efd7b4fea8 size 8 size with overhead 16 state allocated

Это происходит именно поэтому. При освобождении блока (самый большой блок был свободен изначально) она вызывается для блока переданного в mem_free, но не для предыдущего. Таким образом вся память корректно освобождается в тесте в итоге, но она фрагментирована

1

Информация

В рейтинге
564-й
Зарегистрирован
Активность

Специализация

Инженер встраиваемых систем, Системный инженер
Ведущий
C++
Java
Git
Английский язык
ООП