calloc malloc realloc и дефрагментация SRAMa

[zebrox]

классическая проблама, можно ли ее решить в мк?
место в сраме как бы есть, по моим подсчетам, а выделить участок для массива не получается, т.к. нет достачного непрерывного участка памяти.
как можно "сжать" все используемые переменные в начало срама?

[Jack_A]

классическая проблама, можно ли ее решить в мк?
место в сраме как бы есть, по моим подсчетам, а выделить участок для массива не получается, т.к. нет достачного непрерывного участка памяти.
как можно "сжать" все используемые переменные в начало срама?

Поскольку адреса переменных забиты уже в программной флеши, то - никак.
А вообще-то это хорошая иллюстрация к спору об "ЯВУ - ассемблер". Человек, пишущий на ЯВУ, пытается применить приемы, используемые в компах фон-Неймановской архитектуры, для МК Гарвардской архитектуры.
Мое ретроградское мнение : использоание ЯВУ в МК рационально только для больших проектов на больших камнях ( типа Мега128 ), в противном случае это просто блажь.
А откуда могут появиться в МК неиспользуемые переменные ? Что, динамически подгружаемые оверлеи - отработал, и теперь эти ресурсы не нужны ? Верится с трудом. На этапе компиляции их нужно убивать на корню.

Если уж такие гигантские объемы информации крутятся, придется прикрутить внешнюю SRAM.

[Satyr]

Причем тут ява ?
атмега128 - большой камень ? -)))))))))))))
Решение известно давно - виртуальная страничная память. Только в МК ее поддержки не бывает.
Гигабайтные объемы памяти во внешней SRAM - это ты почку продашь, чтоб столько SRAMа купить. SDRAM - правильное решение.

Что тут можно посоветовать - только самому анализировать каждую задачу и изобретать такую схему, при которой фрагментация минимизируется.

[Satyr]

Да, есличо - сдрам копейки стоит.
Контроллеры ее поддерживающие тоже совсем не экзотика и стоят доступно.

[urry]

Что-то мне подсказывает, что вопрос задан о пике - непрерывный участок памяти...
Если говорить о 18 пике, то можно переписать файл линкера.

[Kavka]

Jack_A: Какие адреса во ФЛЭШе? Тему прочитайте - динамическое выделение/освобождение (и т.п.) участка памяти в ОЗУ! Проблема была актуальна для некоторых задач на персоналках во времена ДОСа. И чем меньше ОЗУ тем проблема может быть сильнее выражена.

Satyr: ЯВА - язык высокого уровня. И, думается мне, что это практически всё что выше макро ассемблера.

zebrox: Если не увеличивать объём ОЗУ... Первое что приходит в голову это, как уже было сказано, модифицировать алгоритм работы с памятью, чтобы фрагментация не мешала. На мой взгляд, этот вариант должен быть по-проще чем следующий. Второе, это управлять памятью самому, и в нужный момент реорганизовывать память. Это далеко не простое решение, в смысле или надо писать свой менеджер памяти в самой программе, или лезть во внутренность avr-libc.

[a_skr]

может, я что-то не понимаю, но, скажите мне, ЗАЧЕМ в МК динамически выделять память??? а потом освобождать? и опять выделять? почему нельзя статически объявить нужное кол-во памяти?

[ARV]

может, я что-то не понимаю, но, скажите мне, ЗАЧЕМ в МК динамически выделять память??? а потом освобождать? и опять выделять? почему нельзя статически объявить нужное кол-во памяти?

а как можно статически выделять память, если заранее не известно, какого объема она потребуется?

[a_skr]

может, я что-то не понимаю, но, скажите мне, ЗАЧЕМ в МК динамически выделять память??? а потом освобождать? и опять выделять? почему нельзя статически объявить нужное кол-во памяти?

а как можно статически выделять память, если заранее не известно, какого объема она потребуется?

а как можно рассчитывать, что памяти хватит, если неизвестен предполагаемый максимальный объем? если известен максимальный - что мешает его объявить?

[Satyr]

i.MX233 интересная чтука. присмотритесь -)

[Jack_A]

Причем тут ява ?

Ни Ява, ни Панония, ни ИЖ с коляской тут не при чем. Я сказал ЯВУ - язык высокого уровня.

Jack_A: Какие адреса во ФЛЭШе?

Когда мы пишем :
.DSEG
.org 0x68
Alfa: .byte 1

а потом :
.CSEG
sts Alfa,r16

то при компиляции получим приблизительно такое

000035 9300 0068 sts Alfa,r16

дык 0068 - это и есть адрес переменной Alfa, который намертво до следующей перешивки засажен во флеш-память программ. Вот такие вот адреса во флеши. И динамически их не поменяешь никак. И, как принято говорить, прежде чем возмущаться, неплохо бы исходный вопрос почитать, не говоря уже об даташитах.
Хотя пишущие исключительно на ЯВУ до таких низких истин не опускаются. Черную работу делает компилятор, а мы воспарим.

[ARV]

а как можно рассчитывать, что памяти хватит, если неизвестен предполагаемый максимальный объем? если известен максимальный - что мешает его объявить?

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

[a_skr]

а как можно рассчитывать, что памяти хватит, если неизвестен предполагаемый максимальный объем? если известен максимальный - что мешает его объявить?

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

в общем, Вы все и подтвердили. правильно распределенные на этапе программирования указатели разных структур данных на смещения в объявленном куске памяти все решает, не так ли? вопрос: Вы ВООБЩЕ используете *alloc* в проектах на AVR? пс. с кривыми ручками тут делать нечего, и это не менеджер, тем более, "динамической" памяти, - это правильное распределение памяти и правильное планирование программы, дабы не использовать одновременно 1 большой массив и 5 маленьких в одной и той-же области памяти. если ручки кривые - выбирать памяти побольше, как было сказано выше, но использование в МК *alloc* многократно в процессе выполнения мне кажется абсурдом, извините...

[ARV]

использование в МК *alloc* многократно в процессе выполнения мне кажется абсурдом, извините...

не всегда, не всегда... но в общем и целом ваш подход я приемлю. только вот "грамотное совмещение в одном куске" вряд ли прибавит читабельности коду... такой стиль я не одобряю

[a_skr]

использование в МК *alloc* многократно в процессе выполнения мне кажется абсурдом, извините...

не всегда, не всегда... но в общем и целом ваш подход я приемлю. только вот "грамотное совмещение в одном куске" вряд ли прибавит читабельности коду... такой стиль я не одобряю

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

[Goldsmith]

как можно "сжать" все используемые переменные в начало срама?

Никак. Чтобы безопасно переместить объект в куче, нужно перестроить все указатели на этот объект в новое положение. С обычными указателями C это выполнить не удастся, поскольку мы не знаем, сколько указателей на этот объект в данный момент существует.

Можно, конечно, реализовать "умные" указатели на C++, но такая реализация съест больше ресурсов, чем сэкономит. А вообще полноценный "сборщик мусора", подобный тем, которые имеются в исполняющих системах Java и .NET, - весьма тонкая и сложная система, никак не для нескольких килобайт ОЗУ.

классическая проблама, можно ли ее решить в мк?

Есть простое решение, естественно, довольно ограниченное в силу простоты. Я подсмотрел его в исполняющей системе очень упрощенной реализации Pascal для PDP-11. В ней деаллокатора не было вовсе. Взамен имелись два примитива для работы с кучей - Mark и Release.

Вызовом Mark помечалась верхушка кучи в текущий момент. Затем все динамически создаваемые через new объекты размещались на верхушке кучи. Вызов Release возвращал верхушку кучи обратно в точку, помеченную последним вызовом Mark, тем самым уничтожая разом все динамические объекты, созданные между Mark и Release. "Блоки" Mark/Release могли быть вложенными.

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