Сопоставление проектов С и АСМ, Немного цифр Опции

[SasaVitebsk]

Написал сначала проект на ASM в AVR Studio, а позже очень похожий на Си. И там и там вылизывал по скорости. Точнее особо не вылизывал. В обоих случаях камни с большим запасом. Естественно во втором проекте было всё намного грамотнее построено. Вопервых дробление шагов на основе ШИМ с большим коэффициентом, во вторых более красивое движение стрелок обеспечено. 18 скоростей с плавным переключением. Фильтрация более красивая. Обработка CAN некоторое место занимает. Тем не менее сравнивать можно

Результаты достаточно любопытны для неопределившихся. Попробовал свести в небольшую таблицу.

Код

Камень       ! atmega8 ! at90can128 !
язык         !   asm   !    IAR C   !
-------------+---------+------------+
Число ШД     !    6    !     6      !
управл.      ! дрб 6   ! ШИМ дрб 16 !
Вх аналоговые!    6    !     3      !
Вх частотные !    0    !     1      !
Вх CAN       !    0    !     2      !
Цифр. флтр   !    +    ! + более слж!
Плавность    !    -    ! спец алг   !
Авар         !    +    !+ более слж !
-------------+---------+------------+
Размер кода  !  5019   !   6901     !
без доп табл !   -     !    672     !
Итого        !  5019   !   6229     !
Итого %      !   81    !    100     !
RAM          !  241    !    415     !
Итого %      !   58    !    100     !
-------------------------------------

Несколько попозже буду перетаскивать Этот проект на м8. То есть можно будет сопоставить практически 1 к 1 (с учётом значительных улучшений).

[Непомнящий Евген...]

По-моему, с heap основная проблема в том, как рассчитать максимальную загрузку. И что делать, если память кончилась - допустимо ли отклонить запрос. Например, пример defunct - в 99% времени обработчику нужен только 1 пакет. Если таких обработчиков 5 - то какая куча нам нужна? На 10 пакетов? В этом случае мы не выигрываем по сравнению со статическим выделением памяти. А если, к примеру, на 6 пакетов - то что делать в ситуации, когда пакетов 7. Или можно доказать, что ни в один момент времени не будет больше 6 пакетов...
Следующий нюанс - если вы храните объекты разного размера, то можно получить ситуацию, когда из-за фрагментации невозможно будет разместить новый объект при наличии значительного кол-ва свободной памяти. Тут по-ходу придется мастерить что-то свое, стандартные механизмы работы с кучей не подойдут.
Лично я использую "самописную" кучу для пользовательского интерфейса - например, есть основной экран, из него можно попасть в меню, из него - в другое меню, оттуда - в настройку параметра, из нее иногда - в настройку еще одного параметра. При этом объекты уничтожаются в порядке, обратном созданию, соответственно реализация очень проста и нет фрагментации.

[singlskv]

..............................

Примерно это я и имел в виду.
Просто в моих задачах выгоднее статически выделять память.
А про накладные расходы по работе с кучей я имел в виду не момент выделения памяти,
там действительно все быстро в случае если ее хватает и есть непрерывный кусок нужного
размера, а вопрос по сборке мусора после произвольных выделений/освобождений памяти,
и вот там совсем все не быстро/просто.

[SasaVitebsk]

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

Если динамическое распределение не нужно, то и не надо его за уши притягивать.
Я, к примеру, применять динамическое распределение при построении меню не стал бы, а вот Непомнящий Евгений реализовал и, как видите, доволен результатом. Это говорит, что мы все разные. А нужный инструмент выбирает программист исходя из видения своего проекта. А качество реализации зависит от того, как программист этим инструментом пользуется.

А знания, я в этом совершенно убеждён, никогда не являются лишними. Если ты знаешь, то точно можешь ответить, надо им пользоваться или нет. А если не знаешь, то не можешь и оценить.