Sanyok писал(а):
Ну, существуют сторонние разработчики компиляторов. Например,
Keil Software и незабвенный
IAR Systems. Опять же, компилятор GNU C/C++ вроде как поддерживает разные платформы.. Кстати, если кто-нить пользовался этими его особенностиями - будте любезны, поделитесь - очень интересно узнать результаты (он что, действительно код для TMS320 генерит?
)...
По моему опыту, выход GCC для IMS805
был неудовлетворителен. И мне пришлось кромсать имевшийся компилятор. Ключевое слово здесь однако -
был. Скорее всего, стал лучше.
Сие заявление не есть попытка лягнуть GCC - просто кодогенератор на каждой платформе свой, и его (его качество) надо тестировать отдельно. А разработчики встроенного софта нервно относятся к качеству оптимизации. И если нет кодогенератора для Вашей платформы - кусаете локти (соседу).
Sanyok писал(а):
И все-таки... я, когда писал программу для контроллера M30624FGP (ныне их выпускает Renesas) на сях (у меня был фирменный компилятор C), однажды попробовал использовать malloc. Я был поражен объемом получившегося кода... Я не знаю, почему так происходит, но похоже, менеджер памяти - довольно сложная программа. И на мой взгляд, использовать динамическое распределение памяти (new/delete, malloc/free), ежели самой памяти мало... непозволительная роскошь. Можно запросто не уследить, хватает ее или нет... В-общем, я сторонник эмпирического подхода!
Встроенные системы обычно емеют повторяющийся цикл выполнения. Это значит, что количество памяти можно теоретически оценить сверху - a la
Debiloid. Но хотите ли Вы это делать - Ваш вопрос.
Неиспользование динамической памяти - проектное решение. Как и всякое проектное решение, оно зависит от условий, от размеров системы в частности. К примеру, мне нужны буфера для пакетов Ethernet. Я знаю, что имею право терять пакеты, если их накопилось больше десяти. Я могу отвести массив из десяти буферов статически, или я могу захватывать их динамически. В первом случае я должен выписать ручками систему управления буферами. Но это - рудиментарная система управления памятью. Хорошо, пойдем чтуь дальше. А если у меня таких пулов буферов - несколько? И при определенной сложности системы я уже устаю от всех этих микро-менеджеров памяти. И говорю - хрен с ним, ставим общий.
Другим (важным) недостатком является перерасход памяти. Хочешь - не хочешь, а при статическом распределении памяти на каждую нужду выделяется по ее, нужде, максимуму. Т.е., если поддерживается 20 типов шрубамбасов, каждый из них захватывает память по максимальному числу своих каналов. А то, что физически общее число каналов ограничено - каждому шрубомбасу до фени. Итого, статический раход памяти растет.
Здесь нужно оговориться - все это относиться, в основном, к захвату памяти в момент старта / конфигурирования контроллера. (Часто в этом случае работает жадный аллокатор, который никогда не возвращает память. Его стоимомсть - константная и близка к нулю.) А не к стратегии размещения объектов. Может, я плохо пишу, но в маленьком контроллере у меня объектов кот наплакал. Я вообще не склонен (в отличии от Жабы и Рубина) считать все что не попадя объектом. Отношусь к этому как-то спокойнее. Если удобно - пишу функционально, если удобно - объектно, если нравиться - процедурно. И если работает хорошо, то чего же еще желать...
. Так что программирование не литературное.
