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

[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 кажись..., подзабылось уже...
Тока тогда он уже был С++ с практически всеми атрибутами современных версий,
по моему, исключений еще небыло в современном виде, а шаблоны уже были...
Вобщем здесь уже спорить не буду, не помню всех деталей...

[zltigo]

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

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

Когда в 80x годах я взялся за C++, причем за именно ++, а не 'С', то с моей первой программой приключилась такая история - я выиграл спор . Потребовалась во времена IBM PC/XT для сугубо личных целей простенькая псевдографическая текстовая библиотечка. В общем ничего сверестественного открять окошко-(вывести текст) - еще несколько огошек, перекрытие, всплытие - все без особых затей. Ну и начал С++ изучать. Был у менгя парень, очень талантливый, уже несколько лет много пишущий на 'C' и виртуозно на ASM - он меня от плюсов отговаривал сильно, ну монстрально, тормознуто и т.д.... Я не отступал и он предложил мне доказать, написав библиотеку на 'C' и используя ее в одной и той-те тестовой программе убедиться в жуткой тормознутости C++. Причем в те времена 4,7 Mhz процессоров скорость прекрасно оченивалась невооруженным взглядом .
За несколько недель, вечерами-урывками почти за одинаковое время были написаны две библиотеки.
Напоминаю, это была моя первая программа! Моя C++ была меньше по размеру исходников, меньше по размеру кода и работала быстрее. Причем при этом я Турбодебагером не пользовался - ну просто некогда было изучать , да и само заработало, а коллега довольно плотно в отладке сидел. Случай, конечно, несколько вырожденный, ибо уж больно оконные задачи на плюсы хорошо легли... На самом деле обе работали очень медленно Пошли вставки на ASM, коллега уязвленный потратил массу времени на вылизывание сишного варианта, все находки были реализованы, листинги вычитаны... В конце-концов библиотека стала сишной с очень большими вкраплениями ASM. Но в принципе переход на C был обусловлен изрядной тупостью первого Борландячего плюсового компилятора. Уже в более поздние времена работая с Watcom явных претензий к реализации С++ не было. Да и Борланд попозже исправился, до того, что я стал старые Борландячие проекты (да и вообще все) компилить плюсовым компилятором - эффективнее получалось!

[singlskv]

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

Вот с этим соглашусь практически полностью,
ну на 50% процентов как минимум,
нужно тока рассматривать это относительно существуещего железа,
С действительно уже практически заменил АСМ,
C++ Еще совсем нет. То есть его уже как бы вполне можно использовать, но тока
пока не в критичных по времени выполнения процедурах.
Повторюсь, Вы используете "Прерывания с классами"?

[alexander55]

Повторюсь, Вы используете "Прерывания с классами"?

Извините меня за тупость, но я что-то не понимаю.
Есть класс. Часть его функций используется не в прерываниях, часть в прерываниях. Я это применяю и проблем никогда не имею.
А что такое "прерывания с классами" я не могу понять (может что-то новенькое).

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

А что такое "прерывания с классами" я не могу понять (может что-то новенькое).

Может имелся в виду вызов методов класса из прерываний?

Лично у меня очень часто, иногда - даже виртуальные ...

[singlskv]

Может имелся в виду вызов методов класса из прерываний?
Лично у меня очень часто, иногда - даже виртуальные ...

Примерно это и имелось в виду.

А на каком проце вы вызываете виртуальные методы классов из прерывания ?

Видимо джиттер в Ваших задачах несущественен ?

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

А на каком проце вы вызываете виртуальные методы классов из прерывания ?

Видимо джиттер в Ваших задачах несущественен ?

Atmega128-1280-2560. Сейчас сижу на этой линейке.
Там, где он существенен, я делаю методы класса встраиваемыми (и не использую виртуальные) - и никакого джиттера .
Тут надо соблюсти баланс между удобством и скоростью обработки. Там где скорость обработки может быть не сильно высокой, на первый план выходит удобство программирования и реюзабельность кода.

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

Какая связь между джиттером и виртуальными функциями классов?

Джиттер == оверхед или я чего не понял?

Если так - то самая прямая - расходы на вызов виртуальной ф-ции больше, чем на вызов обычной ф-ции -члена ...


Тока что прочитал: джиттер - нежелательные фазовые и/или частотные случайные отклонения передаваемого сигнала....
Тогда связь действительно малопонятна...

[dxp]

Джиттер == оверхед или я чего не понял?

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

Если так - то самая прямая - расходы на вызов виртуальной ф-ции больше, чем на вызов обычной ф-ции -члена ...

Дык виртуальный вызов, он и функциональность несет несколько иную. Это аналог косвенного вызова функции по указателю из таблицы. На С чтобы достичь функциональности виртуальной функции придется городить эти самые таблицы, извлекать оттуда нужный указатель и делать вызов. Накладные расходы ровно те же самые (т.к. механизм также ровно тот же), но делать все надо руками, что загромождает код и предоставляет поле для ошибок.

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

Оверхед по памяти действительно есть - это необходимость хранения vptr в объекте класса, но это реально очень небольшой оверхед по памяти - один указатель.

P.S. В терминах С++ термин "метод" является синонимом термина "виртуальная функция". Т.ч. невиртуальные фукнции - это не методы, это просто функции-члены. Предлагаю придерживаться этой терминологии, дабы не вносить путаницы.

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

P.S. В терминах С++ термин "метод" является синонимом термина "виртуальная функция". Т.ч. невиртуальные фукнции - это не методы, это просто функции-члены. Предлагаю придерживаться этой терминологии, дабы не вносить путаницы.

Я всегда считал, что функция-член == метод, а вирт. ф-ция-член == вирт. метод. Но не буду спорить

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

[dxp]

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

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

С другой стороны, в С++ достаточно написать слово virtual, что несколько развращает. Поэтому возникает желание запихивать виртуальные ф-ции во все дырки. Соответственно, растет и оверхед

Ну-у, вы еще шаблоны забыли - вот где возможность одним движением нагенерить мегатонны кода. Никто ж не спорит, что надо осмотрительно пользоваться средствами языка. А для этого надо прежде всего их знать. Т.е. изучать. Чем мы, кроме всего прочего, тут и занимаемся.

Я уверен, никто, кто работает с С++, не запутается, а если человек работает с С - то он даже не обратит на это внимания.

Ну, не знаю. Лично я, когда в контексте С++ вижу слово "метод", сразу понимаю под ним виртуальную функцию, т.к. это соответсвует терминологии, введенной по этому поводу Б.Страуструпом, а он для меня в этих вопросах авторитет.

[Maddy]

Ну, не знаю. Лично я, когда в контексте С++ вижу слово "метод", сразу понимаю под ним виртуальную функцию, т.к. это соответсвует терминологии, введенной по этому поводу Б.Страуструпом, а он для меня в этих вопросах авторитет.

Не флейма ради , а инфы для - _где_ он это писал ? Щаз пробежался по книжке - не углядел....