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

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

[singlskv]

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

джиттер это не толко разброс min/max тактов MCU при входе в прерывание,
для конкретной задачи куда более важным является разброс в min/max тактов
между возникновением события и реакцией на него.
В общем случае, этот разброс для проги на С++ ,будет больше...,
а в частных случаях, если не пользоваться C++ функциональностью(то есть пишем на C++ как на С),
результат будет точно таким же как в С.
Тока тогда нужно говорить примерно так: Пишу проги С++... на С.

[dxp]

джиттер это не толко разброс min/max тактов MCU при входе в прерывание,
для конкретной задачи куда более важным является разброс в min/max тактов
между возникновением события и реакцией на него.
В общем случае, этот разброс для проги на С++ ,будет больше...,
а в частных случаях, если не пользоваться C++ функциональностью(то есть пишем на C++ как на С),
результат будет точно таким же как в С.
Тока тогда нужно говорить примерно так: Пишу проги С++... на С.

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

Да вот именно с этим у меня и проблемы пока.

Книги перечитывал уже не раз. И с Delfi работаю давно. Вроде всё понимаю и основные понятия объектного программирования чётко знаю, но пока на душу не легло.

Как zltigo где-нибудь в графике применить бы смог. Там это понятно. Но создание объекта "фильтр" пока из души не идёт и кажется притянутым за уши. (мне естественно. Я совершенно не утверждаю что это неправильно). Вот, к слову (извините за отступление, но уж если начали) прислал мне один молодой программист текст проги. Я ему слегка завидую, потому что я бы такое не написал не в жизь. Прошу прощение что на дельфях, но я думаю для большинства это не проблема. Главное не реализация а само чуство объекта. Итак может ли мне кто-нибудь наглядно пояснить в чём (в приведенном примере) объектная реализация удобнее (или какие преимущества имеет).

Я не буду оригинальным, просто повторю, что говорят авторитетные дядьки вроде Г.Буча и Б.Страуструпа. Самое главное при объектном подходе - это сопоставлять классы и объекты объектам реального мира. Мир в восприятии человека представляется дискретным - человек выделяет в нем более-менее законченные целостные объекты, понятия, которыми он оперирует, строя модели. Так вот объектные (и объектно-ориентированные) языки позволяют на уровне средств языка оперировать типами, отображаемыми на объекты реального мира. Просто старайтесь вычленить в своей программе и прежде всего в той предметной области, которую описывает программа, эти самые законченные (на достаточном уровне абстракции, конечно) объекты и понятия, а после этого уже можно спокойно описывать эти объекты у себя в программе. Этот подход позволяет при разработке программы сразу думать на уровне объектов, а не разрозненных переменных, связи между которыми при отсутствии тех же классов разработчику приходится держать в голове. Понятно, что думать на уровне объектов реального мира намного проще, чем на уровне гораздо большего количества неких в разной мере абстрактных переменных встроенных типов.

Попробуйте думать над программой на уровне объектов реального мира, это совсем не сложно, тогда реализация ляжет на классы почти сама собой. Например, упомянутый вами фильтр является вполне законченным и целостным объектом реального мира, даже не вникая в его суть. У него есть вход, есть выход, есть (опционально) настроечные параметры-функции. Исходя из этого, даже не вникая во внутренности, можно написать:

Код

typedef TFilterIn ...;   // входной объект для фильтра
typedef TFilterOut ...;  // выходной объект фильтра

class TFilter
{
public:
   TFilter();    // конструктор по умолчанию, создает объект фильтра с параметрами по умолчанию
   TFilter(...); // 1-й конструктор с параметрами - создает объект фильтра с какими-то спец. свойствами
    ...
   TFilter(...); N- й конструктор с параметрами - создает объект фильтра с какими-то спец. свойствами

    void in(TFilterIn x); // принимает объект для фильтрации
    TFilterOut out();     // отдает результат фильтрации  
    void execute();       // выполняет собственно фильтрацию


private:
   ...
}

Конечно, это псевдокод, в реале все может быть гораздо скромнее (не иметь обилия конструкторов) или наоборот гораздо обширнее (скажем, иметь пачку функций для настройки параметров фильтра). В частности, вместо трех функций in(), out(), execute() скорее всего можно оставить одну:

Код

TFilterOut execute(TFilterIn);

Объекты типов TFilterIn и TFilterOut могут быть просто указателями на массивы данных, а могут тоже быть объектами классов, если удобно представлять эти данные в виде законченных объектов. Это уже зависит от предметной области и предпочтений разработчика.


Можно даже вместо обычных функций перегрузить операторы, чтобы использование фильтра выглядело так:

Код

TFilter Filter;
TFilterIn fi = ...;
...
TFilterOut fo = Filter << fi;

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

Развивая вышесказанное, следует отметить, что С++ позволяет легко сместить акцент на проектирование программы. Если хорошо представляете себе предметную область, в контексте которой разрабатывается программа, то можно взять лист бумаги (хотя лучше это делать в каком-нить редакторе вроде Visio ) и нарисовать на нем структурную схему, в которой квадратиками обозначить все имеющиеся прототипы объектов реального мира, реализуемых в программе - это будут классы, а связи (стрелки) между квадратиками - это не что иное, как открытые (public) функции-члены этих классов, т.е. их интерфейс. Далее можно уже просто спокойно по этой схеме набивать "скелет" программы, т.к. он фактически на этой структурной схеме представлен в графическом виде. Таким образом, подход к проектированию программы во значительной мере является формализованным, что весьма облегчает процесс ее разработки.

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

[singlskv]

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

Давайте,
код на Gcc для AVR:

Код

// регистровые переменные для работы прерывания системного таймера

register BYTE ADCL_            asm("r2");
register BYTE ADCH_            asm("r3");
register BYTE ADMUX_           asm("r4");
register BYTE ADCSRA_          asm("r5");
register BYTE SYSTICKSTART_    asm("r6");
register BYTE PINB_            asm("r7");
register BYTE PINC_            asm("r8");
register BYTE PIND_            asm("r9");

//-------------------------------------------------------------------
// Прерывание системного таймера
//   используются только регистровые переменные
//   никакие регистры не сохраняются
//   SREG не сохраняется
//-------------------------------------------------------------------

void TIMER2_COMP_vect(void) __attribute__((signal)) __attribute__((naked));
void TIMER2_COMP_vect()
{
  ADCL_  = ADCL;       // читаем результат последнего преобразования
  ADCH_  = ADCH;
  ADMUX  = ADMUX_;     // новый канал
  ADCSRA = ADCSRA_;    // запускаем новое преобразование
                       // информируем о начале нового цикла
  SYSTICKSTART_= ADCSRA_;     // записью значения ADCSRA в SYSTICKSTART_
                              // сбрасывается в 0 в основном цикле
  PINB_  = PINB;       // читаем порты
  PINC_  = PINC;
  PIND_  = PIND;
  __asm__ __volatile__ ("reti" ::);  // выходим
}

8 команд + вход и выход, джиттер 1 такт
Конечно это не голый C, но для микроконтртроллеров он и не бывает без
всяких примочек типа прагм, указаний где лежат данные, и т.д.

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

Интересно, по Вашему линух это достаточно большая программа для того что бы ее
уже необходимо было писать на С++ ?
Почему авторы предпочли писать линух на С ?

[zltigo]

Конечно это не голый C...

Это вообще не 'C'. По сравнению с этими телодвижениями заколачивание гвоздей микроскопом выглядят более чем разумно .

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

Позвольте об этом судить тем, кто умеет пользоваться инструментом.

[singlskv]

Это вообще не 'C'.

Это С для микроконтроллеров, в частности Gcc для AVR.

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

Вы хотели сказать что неоптимальненько написан данный кусок ?
Ждем ваших решений.... на С++

Код Си библиотек написаный на С смотрели ?
Там таких микроскопов завались

З.Ы. этот код это единственное непереносимое место в проге, зато все очень быстро и без
заметного джиттера.

Для батарейных девайсов на первый план выходит время вхождение в прерывание? Даже не подозревал .
Нет, но вскоре видимо буду. Предстоит замена-Upgrade одного старинного электомеханического девайса. Причем AVR там стоять не будет - слишком в полуспящем режиме батарейка маленькая и задачи опять-таки не битики сбрасывать, а все-таки немножко в цифре фильтровать, LCD управлять опят-таки нужно.....

Позвольте об этом судить тем, кто умеет пользоваться инструментом.

Вот именно, ТЕМ КТО УМЕЕТ пользоваться инструментом и выжать из него
все что только можно.

немножко в цифре фильтровать...
LCD опять-таки управлять...
Несомненно для этой этой задачки нужен ARM мегагерц на 200 и С++

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

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

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

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

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

Эээ..., ну как Вам сказать ....
Нет, ну конечно Вы правы, там еще довольно много платформозависимого кода на асм.

З.Ы. Время от времени пересобираю линух для AVR32, кода на С++ пока не обнаружил

[dxp]

Это С для микроконтроллеров, в частности Gcc для AVR.

С - это С. Не бывает С для микроконтроллеров. Бывают расширения компилятора для конкретной платформы.

Вы хотели сказать что неоптимальненько написан данный кусок ?
Ждем ваших решений.... на С++

Звучит примерно так: есть код

out PORTB, r16

Ждем реализацию на С++.

Ну я же сразу же предупредил что это С в приложении к микроконтроллеру.

См выше.

На асм не проще по той причине что дальше в проге идет переработка данных
полученных в прерывании и выгодно их хранить в виде С переменных но хранящихся в регистрах.

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

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

Так мы сравниваем С vs. C++ или асм (хотя и в фантике из синтаксиса С) vs. С++? Давайте нормальный С код, а не хаки.

Похоже надо просто садится и писать. Во всяком случае пробовать. А то по книжкам всё равно не дойдёт. В книгах детали. Перебороть себя и начинать работать.

Истинно так! Сразу, конечно, не так все гладко будет получаться, как на словах, тут некоторая практика нужна (как и в любом деле), но через короткое время все придет. То самое "чувство объекта". После этого по-старому (по процедурному) уже думать вряд ли захочется.

Если нужно много достаточно быстрых ADC преобразований, то тогда
MSP c его 16 регистрами памяти ADC конечно рулит,
тока асм там точно будет нужен...

Не более, чем для AVR.

Обязательствами я тоже не очень связан.
Да, Вы правы, RET действительно присутствует, так что джиттер 4-1=3 такта.
Просто в первоначальной реализации, в момент возникновения прерывания, у меня были
команды максимум в 2 такта, но потом по некоторым причинам пришлось переделать и
вставить вызов функции.

Я что-то не пойму - в программе только одно прерывание? Других нет? Если есть еще прерывания, то про какие один-два-три-четые такта джиттера входа в данное прерывание может идти речь?

[singlskv]

А если писать на С, то надо предоставить компилятору оптимизировать, включив соответствующую оптимизацию.

Хорошо, почти убедили, конечно это в некоторой степени хак,
НО, без этого хака производительность всей проги будет существенно ниже.
Компилятору таки нужно помагать делать правильный код.

Так мы сравниваем С vs. C++ или асм (хотя и в фантике из синтаксиса С) vs. С++? Давайте нормальный С код, а не хаки.

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

Не более, чем для AVR.

Честно говоря не понял что Вы имели в виду под "не более".

Я что-то не пойму - в программе только одно прерывание? Других нет? Если есть еще прерывания, то про какие один-два-три-четые такта джиттера входа в данное прерывание может идти речь?

Да, в этой проге только одно прерывание, все остальное реализуется поллингом,
т.е. обмен с внешней переферией по SPI, запись в EEPROM и быстрый обмен по i2c в режиме slave...
Так что с джиттерами там все точно

P.S. Да, и если не сложно, дайте ссылочку про использование С++ для драйверов и
кода ядра линух, интересно оценить почему и зачем они там С++ использовали.

Синхронность в данном случае дело абсолютно темное, поведение будет зависеть от сдвига и без знания потрохов судить о поведении невозможно.

zltigo, не юлите, даташит нам дает однозначный ответ на этот вопрос, джиттер
начнет возникать тока в момент непопадания момента прерывания на однотактовую команду.

[zltigo]

zltigo, не юлите, даташит нам дает однозначный ответ на этот вопрос, джиттер
начнет возникать тока в момент непопадания момента прерывания на однотактовую команду.

Такие интимные подробности описаны? Типа, что фронт прерывания от встроеного таймера чисто конкретно приходится на конец выполнения команды а не на ее начало? Честно говоря совсем не верю. Цитату не дадите?

[singlskv]

Такие интимные подробности описаны? Типа, что фронт прерывания от встроеного таймера чисто конкретно приходится на конец выполнения команды а не на ее начало? Честно говоря совсем не верю. Цитату не дадите?

Zltigo, вы знаете, собирался по честному процитировать Вам даташит, но уже не буду,
потому как видимо бессмысленно...
Чего то щелкнуло в голове и я решил пересмотреть Ваши высказывания:

.....
Такие длинные групповые команды можно просто не использовать, тогда самая длинная это 8 тактов. Итого, при необходимости быстрой реакции на прерывание получаем 15 тактов.
......
Ну а дальше можно считать сколько времени займет вход в обработчик FIQ у типичного 60MHz ARM. Считаем. Максимальная задержка = 250ns, ну джиттер соответственно 7 тактов (причем независимо от IRQ/FIQ) = 117ns.

Вот мне и интересно, 8 - (8-1=7)тактов для АРМ это норма а для AVR Вам нужна цитата ?
Как минимум, интересное замечание.
Если захотите оправдаться, не буду Вам мешать, но попробуйте сделать это как минимум достойно....

[zltigo]

Zltigo, вы знаете, собирался по честному процитировать Вам даташит, но уже не буду,

Дело Ваше, можете и не по честному, мне без разницы.

Вот мне и интересно, 8 - (8-1=7)тактов для АРМ это норма а для AVR Вам нужна цитата ?

Да, это норма, ибо у ARMов имеются семь тактов до начала процесса вклинивания

для AVR это 3(4-1) такта

Прерывание возникло за 1ns до окончания команды. Прерывание возниколо через одну наносекунду после начала 4x тактовой команды. Какая разница будет? Утверждается, что где-то документировано возниковение прерывания от внутреннего таймера сразу после начала исполнения команды, нежели такое документировано, то тогда действительно для случая внутренего таймера разница будет в 3 такта. В любом другом - 4.

Иначе дальнейшее обсуждение данного вопроса эээ... малоинформативно.

Оно уже абсолютно не информативно для хоть какой-либо невырожденной системы, ибо наличие более одного прерывания, или критической секции, времена ммеют совершенно другой порядок.
Еще более неинформативны, точнее 100% бессысленны, рассуждения о "джиттере" из-за использования C++ затеяные singlskv.

[singlskv]

Дело Ваше, можете и не по честному, мне без разницы.

Да, это норма, ибо у ARMов имеются семь тактов до начала процесса вклинивания.
Прерывание возникло за 1ns до окончания команды. Прерывание возниколо через одну наносекунду после начала 4x тактовой команды. Какая разница будет? Утверждается, что где-то документировано возниковение прерывания от внутреннего таймера сразу после начала исполнения команды, нежели такое документировано, то тогда действительно для случая внутренего таймера разница будет в 3 такта. В любом другом - 4.

Хм, а для АРМ это конечно все не так? да ?
Бред будем нести лишь бы не оказаться не правым?
ну-ну, и танк на встречу...

после начала 4x тактовой команды. Какая разница будет? Утверждается, что где-то документировано возниковение прерывания от внутреннего таймера сразу после начала исполнения команды, нежели такое документировано, то тогда действительно для случая внутренего таймера разница будет в 3 такта. В бессысленны, рассуждения о "джиттере" из-за испо
льзования C++ затеяные singlskv.

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