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

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

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

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

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

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

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

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

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


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

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

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

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


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

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


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

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

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

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

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

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

Вы похоже меня с кем то перепутали, читайте внимательнее посты,
у меня джиттер несколко получше, 1 такт процессора, при 16Мгц это ~60нс
Ну если говорить об этой проге, то там не только "перекладывание байтиков".
Там еще и 16 входных цифровых каналов с фильтрацией практически произвольно перемешанные
по PINB, PINC и PIND, 2 канала ADC с фильтрацией, 1-2 PWM, SPI, ну и еще
обмен на 400КГц по I2C (реальная скорость передачи ~25Кбайт/с.
Конечно перекладывание байтиков, но байтиков было много...
Ну как Вам сказать, реально задействованными оказались только R0-R9 и R14-R31,
R10-R13 компилятору просто не понадобились.
MSP430 ?
Правильная AVR при правильном использовании тоже бы подошла,
тока Вы их похоже просто принципиально не используете, даже если для
конкретной задачки их использование будет выгоднее...

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

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

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

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

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


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

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



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

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

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



Но не от "джиттера" .
Продолжения про "джиттер" вносимый плюсами будет?

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


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

out PORTB, r16

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


См выше.


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


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



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


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


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

Дополнение по поводу книг. Обязательно почитайте Гради Буча (Grady Booch) "Объектно-ориентированные анализ и проектирование", там глава 2 "Объектная модель" и глава 3 "Классы и объекты" прямо как раз для вас написаны. Там все то, что я сказал расписано подробнейшим образом с хорошими примерами. Книжка хорошая, написана конкретно, читаеся легко.

А в книжках по С++ действительно львиная доля посвящена деталям языка. Видимо имеется в виду, что читатель с общими концепциями объектного и объектно-ориентированного программирования уже знаком. Хотя в основополагающем труде Б.Страуструпа "Язык программирования С++" целый раздел посвящен вопросам проектирования и вообще подходу к разработке ПО. Очень интересная глава даже если не быть большим специалистом по ++. Глава, кажется, 11, называется "Проектирование и развитие". Там тоже рассматриваются все эти вопросы, причем непосредственно в контексте С++. Настоятельно рекомендую.

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

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

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


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

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


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

1) определена она в пространстве имен класса;
2) имеет доступ к закрытым (private) членам своего класса.

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


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

Короче. Дискуссия вокруг да около меня что-то уже утомила, поэтому "раскрою карты" (скажу прямо):

1. основой эффективного писания на С является интенсивное использование составных типов данных (массивы, структуры), указателей, адресной арифметики;
2. исходя из этого, для того чтобы С код эффективно "ложился" на аппаратуру процессора, от последнего требуются средства поддержки косвенной адресации и адресной арифметики (аппаратные указатели, индексные регистры, режимы обращения со смещением и т.д.);
3. ключевым понятием С++ является класс;
4. механизм работы с представлением объектов классов осуществляется на основе указателя this, который содержит адрес "структуры" членов-данных класса;
5. из этого следует, что на любом процессоре, который имеет сколько-нибудь достаточно развитые средства косвенной адресации и адресной арифметики, код С++ получится по эффективности таким же, как и на С - близким к написанному вручную (имеется в виду код общего назначения - разного рода процессорно-зависимые навороты (типа multifunction instructions), реализуемые на асме, не рассматриваются);

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



Ну, вы упомянули, что для MSP430 потребуется асм для достижения эффективности, на это я и высказался, что не более, чем для AVR. При равной тактовой MSP430 на обработке данных быстрее, чем AVR. У MSP430 медленнее обращение по шинам из-за его фон Неймановости, но за счет 16-разрядности и более прямому ядру он обходит AVR. Только прошу тут тему AVR vs MSP430 не развивать, не топик тут это, да и высказывался я уже подробнейшим образом на эту тему, анализируя "кривые" моменты ядра AVR. Повторять не хочется.


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


В линухе не силен, но встречал людей на просторах FIDO (в частности в эхах su.c-cpp и ru.cpp), которые успешно писали драйвера для видны (vxd и sys) и линукса на С++. Это не удивило, т.к. объективных препятствий этому нет.

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

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