К знатокам, Локальные переменные. Опции

[SasaVitebsk]

Пишу достаточно простую прогу. Пытаюсь оптимизировать.

Столкнулся с одной бедой. Попробую описать.

Построено на прерываниях. Между прерываниями разные промежутки. Есть короткие, есть длинные. Как назло именно короткое прерывание сильно загружено. Дабы разгрузить его я пытаюсь часть вычислений вынести в предыдущее не загруженное прерывание. Уже полностью перешёл на указатели, но всё равно шляпа получается.

Проблема в том, что я не могу ввести локальные переменные на два прерывания. Таким образом я ввожу статик. Но тогда во втором прерывании компилятор пытается сохранить значения. А мне это не надо ни капельки. Чтобы этого избежать я ввёл локальные переменные и во втором прерывании выполнил присваивание локальным статик. Код получился значительно компактнее, но всё равно выполняется никому не нужное присваивание. А это 6 указателей!

Теперь сам вопрос.
Могу ли я указать компилятору что можно разрушать переменные в данном прерывании. То есть что не надо их хранить. Или как это сделать. Надо типа переобъявить статические переменные локальными. Не знаю как выразится. Надеюсь поняли.

[SasaVitebsk]

Тут проскочила чья-то фраза, что компилятор лучше работает со структурами чем с массивами. И я решил проверить некоторые моменты моей проги.
Выводы просты - казалось бы мелочи, но они имеют важнейшее значение. И, главное, если вдуматься и проанализировать, то всё это лежит на поверхности!

Например я обрабатываю 6 шаговых двигателей. По каждому из шаговых двигателей имеется несколько значений типа положение/тек.положение,скорость/тек.скорость и т.д. В первой редакции проги всё выглядело примерно так

uint16_t Speed[MAXDVG],SpeedReal[MAXDVG],State[MAXDVG],StateReal[MAXDVG];

Теперь переписал примерно так

struct
{
uint16_t Speed, SpeedReal...
} Dvg[MAXDVG];

там где идёт единичное обращение к конкретному полю конкретного двигателя, - естественно ничего не изменилось, но там где в цикле идёт работа с двигателями и сравниваются различные поля одного двигателя - там код уменьшился раза в два!

Переписал таки же образом работу с АЦП.

Если вдуматься, то это медленный дрейф к объектам и его свойствам и к С++ как дальнейшее развитие этих идей.

Похоже надо более полно изучать С++ и постепенно переходить.

[singlskv]

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

А вот здесь я бы на Вашем месте сильно не спешил.
Дело в том, что любой код на С++ может быть преренесен на С без потери скорости/компактности,
а обратное к сожалению не верно, те код на С перенесенный на С++ гарантированно будет
не меньше/не быстрее чем исходный.
Собственно часть компиляторов так и работает, считая код на С++ препроцессорной
надстройкой над С...
Хотя конечно иногда удобно, тока нужно четко себе представлять в каком месте будет оверхед.

[dxp]

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

С++ на С не переносится в принципе, т.к. С является подмножеством С++ (хотя и не 100% совместимым). А вот С-код на С++ переносится достаточно легко, в некоторых случаях даже делать ничего не надо, он сразу работает. И по эффективности тут никаких потерь нет. Попробуйте какую-нибудь С программу, написанную под IAR С скомпилить тем же IAR'ом в С++ режиме. Сравните результат.

Собственно часть компиляторов так и работает, считая код на С++ препроцессорной
надстройкой над С...

Это вы про С с классами говорите, который компилировался С front. Ну, так это еще не полноценный С++, а его предтеча. Давайте уже оперировать реалиями сегодняшнего дня.

А зря не верится. И я тоже не верил. Более того, когда писал на асме вообще не использовал данные команды. Считал их бесполезными. Оно и понятно. Применение команд типа LDD где используется смещение делает прогу на асме фактически нечитаемой. К чему обращаешься - непонятно.

Ну, это как писать. Сделайте смещения именованными и все сразу станет понятно. Когда-то, когда я в целях тренировки кое-что еще писал на асм для AVR, делал так (писано было еще в 1998 году, пакет - незабвенный IAR 1.40 ):

Код

#define LASER_CODE           0
#define TPREVIOUS_POINT      2
#define STATE                4
#define NSPURIOUS            5
#define NSYMBOLS             6
#define FLASER_CODE_DONE     7

  rseg    UDATA0

     Laser_code:         ds   2   ; 0-1
     tPrevious_point:    ds   2   ; 2-3
     State:              ds   1   ; 4
     nSpurious:          ds   1   ; 5
     nSymbols:           ds   1   ; 6
     fLaser_code_done:   ds   1   ; 7
...

  rseg    RCODE
    ...
    ldi   r30, low(Laser_code)
    ldi   r31,high(Laser_code)
    ...
    ldd   r18,Z+TPREVIOUS_POINT        ;  load previous point
    ldd   r19,Z+TPREVIOUS_POINT + 1    ;
    ...
    ldd   r18,Z+STATE                  ; load state
    ...
    ldd   r18,Z+LASER_CODE   ; load laser code
    ldd   r19,Z+LASER_CODE+1 ;
    ror   r19                ; modify laser code
    ror   r18                ;
    std   Z+LASER_CODE,r18   ; store laser code
    std   Z+LASER_CODE+1,r19 ;
    ...
    std   Z+TPREVIOUS_POINT,r20   ; store current point as previous
    std   Z+TPREVIOUS_POINT+1,r21 ;
                             ;
    ldd   r18,Z+NSYMBOLS     ;
    inc   r18                ; inc nSymbols
    std   Z+NSYMBOLS,r18     ;
    ...
    ldd   r18,Z+NSPURIOUS              ;  inc nSpurious
    inc   r18                          ;
    std   Z+NSPURIOUS,r18              ;
    ...

и т.д. Как видите, все вполне читаемо и понятно. Код оптимален. По сути тут руками сделана оптимизация Clustering variables.

[singlskv]

С++ на С не переносится в принципе, т.к. С является подмножеством С++ (хотя и не 100% совместимым). А вот С-код на С++ переносится достаточно легко, в некоторых случаях даже делать ничего не надо, он сразу работает. И по эффективности тут никаких потерь нет. Попробуйте какую-нибудь С программу, написанную под IAR С скомпилить тем же IAR'ом в С++ режиме. Сравните результат.

Вы не внимательно читали мои посты, я говорил лишь о том что любую прогу
на С++ можно написать на С не менее эфективно(почти всегда более эфективно).
Правда, усилий может понадобится больше.
В конечном итоге это примерно такой же спор как насчет С vs ASM.
Очевидно что на ASM всегда можно написать лучше(быстрее/компактнее по коду) чем на С.
так же для меня вполне очевидно, что то же будет касаться С++ vs C.
Вопрос скорее в решаемой задаче и в количестве железных ресурсов которые
не жалко...
Ок, задам Вам такой вопрос:
как Вы относитесь к "прерываниям с классами" ?

Это вы про С с классами говорите, который компилировался С front. Ну, так это еще не полноценный С++, а его предтеча. Давайте уже оперировать реалиями сегодняшнего дня.

Да, это действительно был Cfront в редакции AT&T кажись..., подзабылось уже...
Тока тогда он уже был С++ с практически всеми атрибутами современных версий,
по моему, исключений еще небыло в современном виде, а шаблоны уже были...
Вобщем здесь уже спорить не буду, не помню всех деталей...

[dxp]

Вы не внимательно читали мои посты, я говорил лишь о том что любую прогу
на С++ можно написать на С не менее эфективно(почти всегда более эфективно).
Правда, усилий может понадобится больше.

Я внимательно читал. И обратное утверждение верно.

В конечном итоге это примерно такой же спор как насчет С vs ASM.

Нет, неверно. С и асм - это принципиально разные вещи, а С и С++ - это подмножество и надмножество. Все, что можно сделать на С, на С++ переноситься почти без изменений. Никто ведь не заставляет использовать исключения, RTTI, шаблоны, это их эффективность является препятствием к достижению цели. Все средства С в С++ есть, поэтому любая С программа почти автоматически является С++ программой.

Очевидно что на ASM всегда можно написать лучше(быстрее/компактнее по коду) чем на С.

Да. Хотя на практике случаи бывают и обратные.

так же для меня вполне очевидно, что то же будет касаться С++ vs C.

См выше.

Ок, задам Вам такой вопрос:
как Вы относитесь к "прерываниям с классами" ?

Что такое "прерывания с классами"?