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

[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 (с учётом значительных улучшений).

[_Pasha]

Вот это совсем другое дело!
Че-то WINAVR тормозит немного. А может я торможу - начитался мануалов, а уже все работает. Пойду проверю.
Насчет диспетчера кучи: я так понял, надо либо собрать все указатели, работающие с выделяемыми объектами, в одну секцию. Тогда при дефрагментации памяти сравнительно легко все перемещается. Либо не париться и держать дескрипторы.

[AHTOXA]

Вот это совсем другое дело!
Че-то WINAVR тормозит немного.

WINAVR как раз в этом очень сильно тормозит. Работа с флешом в нём сделана мегакриво. Так как в примере SasaVitebsk-а, не выйдет.

[_Pasha]

WINAVR как раз в этом очень сильно тормозит. Работа с флешом в нём сделана мегакриво.

... И похоже, что по политическим соображениям никогда не исправится.
Насчет кривизны:
Из предыдущего утомительного примера:

Код

static Cm_Xref_t Cm_Xref[Max_cmd+1]=
{
    {cm_Brief,0,0}, // version crc
    {cm_NetLocate,&Net_ID,EE_Fit+1},
    {cm_Set_Selector,&Selector,EE_Fit+1},
/*****************************************/
};
/******************************************/
uint8_t M;
M = Cm_Xref[2].ojsize;

Так constant propagation оно просчитывает. А стоит появиться адресному выражению - кирдык.

Попробуйте писАть на С, а не на asm сишными словами...

Блин, вот зацепил...до сих пор помню.

[defunct]

Блин, вот зацепил...до сих пор помню.

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

Проблемы-то начинаются с обращения к памяти программ за данными. Этот процесс нигде не автоматизирован, отсюда сложности.

да и на асм он не автоматизирован, ровно в той же степени.

[_Pasha]

Вернемся к нашей баранине. "Не умеешь-научим, не хочешь-заставим." Заставили. Дописал функцию записи в ЕЕПРОМ, в аккурат по шаблону eeprom_write_block() .

Код

void EE_Proof_Write_Block(const void *pointer_ram,
              void *pointer_eeprom,
              size_t n)
{
size_t j;
uint8_t *src,*dst;

src = (uint8_t*)pointer_ram;
dst = (uint8_t*)pointer_eeprom;

for (j=0;j<n;j++)
{
  if (eeprom_read_byte(dst) != *src)
      eeprom_write_byte(dst,(uint8_t)*src);
  dst++;
  src++;
}
return;
}

ИТОГО такое: +56 байт. Имея ввиду, что была исходная eeprom_write_block(), вычтем, скажем, байт 16. В добавок, это все можно обрезать, задаваясь размером блока не size_t a uint8_t, если уж очень хотца. Это еще минус байта 4-6. Короче, +32..36 байт. Оптимайзер рулит!!!
Может, мы доживем до тех времен, когда свопинг лишний чистится будет...
Кстати, кто-нибудь знает, почему многопроходовая оптимизация в GCC не в фаворе?

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

Боюсь, что не получится. Команд будет поболее - до 30 в полновесном варианте. И надо, чтобы в идеале доступ был не по индексу, а по LookUp, т.к. коды команд могут меняться. Так что от таблицы никуда не денешься. Впрочем, если Вы пальцем ткнете, я пойму, что имеется ввиду...

[singlskv]

Код

void EE_Proof_Write_Block(const void *pointer_ram,
              void *pointer_eeprom,
              size_t n)
{
size_t j;
uint8_t *src,*dst;

src = (uint8_t*)pointer_ram;
dst = (uint8_t*)pointer_eeprom;

for (j=0;j<n;j++)
{
  if (eeprom_read_byte(dst) != *src)
      eeprom_write_byte(dst,(uint8_t)*src);
  dst++;
  src++;
}
return;
}

Несколько моментов про Ваш код:
- вместо цикла for лучше использовать do..while c проверкой size_t n == 0 только в самом начале..
- написав отдельно src++ и вызывая стандартные функции Вы сами себя лишили возможности
пользоваться автоинкрементом при доступе к данным в RAM
- каждая из функций eeprom_xxx будет ждать флага освобождения EEPROM
- каждая из функций eeprom_xxx будет прописывать один и тот же адрес в EEAR

попробуйте это отрихтовать и удивитесь лаконичности полученого кода...

[_Pasha]

Несколько моментов про Ваш код:
- вместо цикла for лучше использовать do..while c проверкой size_t n == 0 только в самом начале..
- написав отдельно src++ и вызывая стандартные функции Вы сами себя лишили возможности
пользоваться автоинкрементом при доступе к данным в RAM
- каждая из функций eeprom_xxx будет ждать флага освобождения EEPROM
- каждая из функций eeprom_xxx будет прописывать один и тот же адрес в EEAR

попробуйте это отрихтовать и удивитесь лаконичности полученого кода...

Поменял for() на while() и убрал лишнее копирование параметра size_t n . Т.е. while(n){}
Дальнейшее улучшение усиливает зависимость от железа, поэтому в данном случае (не библиотечном) не имеет смысла.
Бухгалтерия -12 байт. Итого в гору не более 24 байт на "крайне нежелательную" на первый взгляд функцию.