[FormatCft 0]

Доброго времени суток!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. Есть ли у кого своя реализация Heap_x.c? А то, что то не хочется использовать реализации которые есть (то без чистки памяти, то без объединения свободных блоков).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2. Еще вопрос по heap_3.c. Этот хип использует стандартный Си-шный хип или просто есть возможность его использовать?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[zltigo 0]

Есть ли у кого своя реализация Heap_x.c?

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

Еще вопрос по heap_3.c. Этот хип использует стандартный Си-шный хип или просто есть возможность его использовать?

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

[FormatCft 0]

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

Ого! Значительные навороты! ! !

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

Или хотябы подсказать в каком направлении двигаться.

 

К делу не относится, но еще были объединены блоки памяти под TCB и Stack.

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

 

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

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

[sergeeff 1]

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

[FormatCft 0]

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

Спасибо за ссылку! ! !

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

Изменено 7 октября, 2008 пользователем FormatCft

[zltigo 0]

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

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

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

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

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

Да, так.

 

 

Компактная и быстрая.

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

[FormatCft 0]

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

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

 

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

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

 

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

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

[sergeeff 1]

Спасибо за ссылку! ! !

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

 

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

[zltigo 0]

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

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

[Terminator 0]

Запустил в своём проекте heap_3

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

[FormatCft 0]

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

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

 

Запустил в своём проекте heap_3

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

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

[sergeeff 1]

To zltigo:

 

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

Я не агент команды, написавшей TLSF, просто интересно уяснить для себя про монументальность.

[zltigo 0]

А в чем уважаемый гуру вы усмотрели "монументальность" TLSF аллокатора? По моему ничего особо навороченного там нет...

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

[FormatCft 0]

опсотв ))

Изменено 7 октября, 2008 пользователем FormatCft

[sergeeff 1]

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

 

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