Доброго времени суток!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Есть ли у кого своя реализация Heap_x.c? А то, что то не хочется использовать реализации которые есть (то без чистки памяти, то без объединения свободных блоков).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2. Еще вопрос по heap_3.c. Этот хип использует стандартный Си-шный хип или просто есть возможность его использовать?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Делал свою реализацию именно по причине реализации объединения свободных блоков, алгоритма поиска наиболее подходящего, получения списка как занятых, так и свободных, добавления маркера владельца блока, организации поддержки вложеных менеджеров и сегментированного Heap. К делу не относится, но еще были объединены блоки памяти под TCB и Stack.

Если посмотрите, то это просто обертка. Проблема в том, "стандартного Сишного" в природе не существует - только некие "коты в мешке" с непонятной функциональностью. Нет смысла использовать.

Ого! Значительные навороты! ! !
Можно у Вас попросить поделиться результатами Ваших трудов? Был бы очень благодарен!
Или хотябы подсказать в каком направлении двигаться.


Мне кажется, что относится Т.е. это что-то типа не запутывать себя и не следить за каждой из областей, а сразу за двумя?


Понял. Т.е. есть смысл найти открытый нормально написанный или попыхтеть "немножко" и написать своё

В этом плане можно воспользоваться TLSF: Memory Allocator for Real-Time - http://rtportal.upv.es/rtmalloc/node/8. Испанская разработка. Компактная и быстрая.

Спасибо за ссылку! ! !
Т.е. вы её как я понял используйте? Если используйте, то нет ли каких-нибудь багов или малопреятных мелочей? Version 2.4.3 тестили?

Сообщение отредактировал FormatCft - Oct 7 2008, 08:09

Я подумаю. Основная проблема не в "секретности" а некоторой заточенности под несколько отличающееся от стандартного окружение и желательную чистку и комментирование перед раздачей

Нет, прежде всего прямое сокращение TCB на указатель и косвенное на один MCB.

Да, так.



Ну несколько монументальна . Но в качестве объекта для изучения безусловно годится.

Спасибо! Буду с нетерпением ждать


Ясно. Небольшая экономия места.


Т.е. я так понял, что для МК-го применения не подходит из-за того, что слишком много времени кушает?

Тестировал 2.4.2. Включил в свой проект и погонял свое устройство день. Все работало, как и с прежним аллокатором BGET (тоже известная вещь), т.е. никаких проблем замечено не было.

Подходит. Время дело второе. Просто излишества есть, типа сервисных наворотов, realloc(),....

Запустил в своём проекте heap_3
arm-elf-gcc + newlib небольшие правки syscalls.c, вообщем получилось как костыль. Пока работает.

Понял. Сейчас только жду вашей версии!


Спасибо! Костыли мне еще рано )) Я думаю, что буду использовать что-то из 2х предложенных вариантов (скорее всего вариант ЗлтИго)

To zltigo:

А в чем уважаемый гуру вы усмотрели "монументальность" TLSF аллокатора? По моему ничего особо навороченного там нет, а блоки выделяются достаточно шустро, и довольно изящно частично решена задача дефрагментации освобождаемой памяти. Да и с самого начала разрабатывалась для embedded применений.
Я не агент команды, написавшей TLSF, просто интересно уяснить для себя про монументальность.

Ничего особо, естественно, нет, но некоторые излишества универсальности присутствуют.

опсотв ))

Сообщение отредактировал FormatCft - Oct 7 2008, 16:20

Сразу пришла на ум легендарная фразы Вицина из "Кавказской пленницы" : "И излишества всякие, нехорошие ..."