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

[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, кода на С++ пока не обнаружил

[zltigo]

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

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

этот код это единственное непереносимое место в проге,

Отнюдь, использование регистров глобально, наносит неизгладимый отпечаток на весь код.

Несомненно для этой этой задачки нужен ARM мегагерц на 200 и С++

Нет, хватит микромощного 16-ти битовика, С (С++ по настроению) и немного чистого ASM, там, где нужно.

[singlskv]

Если Вы намекаете на свои исходники, то это не умение, это нагромождение голых трюков ясно показывающее неумение нормально продумывать решение задачи. Об этом-же говорят еще и полученные Вами дикие (2mks) цифры реакции на прерывание (да и еще до кучи к нему нечто называемое Вами джиттером того-же порядка)

Вы похоже меня с кем то перепутали, читайте внимательнее посты,
у меня джиттер несколко получше, 1 такт процессора, при 16Мгц это ~60нс

, при попытке написать что-то более серьезное, нежели перекладывание байтиков.

Ну если говорить об этой проге, то там не только "перекладывание байтиков".
Там еще и 16 входных цифровых каналов с фильтрацией практически произвольно перемешанные
по PINB, PINC и PIND, 2 канала ADC с фильтрацией, 1-2 PWM, SPI, ну и еще
обмен на 400КГц по I2C (реальная скорость передачи ~25Кбайт/с.
Конечно перекладывание байтиков, но байтиков было много...

Отнюдь, использование регистров глобально, наносит неизгладимый отпечаток на весь код.

Ну как Вам сказать, реально задействованными оказались только R0-R9 и R14-R31,
R10-R13 компилятору просто не понадобились.

Нет, хватит микромощного 16-ти битовика, С (С++ по настроению) и немного чистого ASM, там, где нужно.

MSP430 ?
Правильная AVR при правильном использовании тоже бы подошла,
тока Вы их похоже просто принципиально не используете, даже если для
конкретной задачки их использование будет выгоднее...

[zltigo]

Вы похоже меня с кем то перепутали,

Простите, это действительно так

у меня джиттер несколко получше, 1 такт процессора, при 16Мгц это ~60нс

Не все команды AVR за один такт выполняются, без вызовов/возвратов Вы едва-ли обошлись, по этой причине 4 такта
процессора будут реальной величиной.

Правильная AVR при правильном использовании тоже бы подошла,

Нет.
- Режимы энергосбережения много лучше;
- Контроллер LCD;
- 16bit много предпочтительнее для работы с 12bit значениями.
Посколько я не связан обязательствами использовать какой-либо один контроллер и способен достаточно легко переходить, то могу выбирать не только среди "правильных", но и "самых правильных" .

[singlskv]

- 16bit много предпочтительнее для работы с 12bit значениями.
Посколько я не связан обязательствами использовать какой-либо один контроллер и способен достаточно легко переходить, то могу выбирать не только среди "правильных", но и "самых правильных" .

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

Обязательствами я тоже не очень связан.

Не все команды AVR за один такт выполняются, без вызовов/возвратов Вы едва-ли обошлись, по этой причине 4 такта
процессора будут реальной величиной.

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

[zltigo]

Да, Вы правы, RET действительно присутствует, так что джиттер 4-1=3 такта.

И без "-1", ибо при удачном стечении обстоятельств ждать окончания текущей команды вообще не придется, а при неудачном все 4 такта.

тока асм там точно будет нужен...

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

[singlskv]

Да, далеко мы уже удалились... от темы,
единственно что радует, модератор вряд ли забанит за оффтоп

И без "-1", ибо при удачном стечении обстоятельств ждать окончания текущей команды вообще не придется, а при неудачном все 4 такта.
ASM проблем нет, если надо. А из нужного, еще неплохая аналоговая начинка присутствует.

Т.к прерывание синхронное (таймер), джиттер имеет смысл рассчитывать только при
попадании на середину команды, то есть максимумтактов-1.
Если бы все команды были однотактовые то джиттера небыло бы вобще.