Вопросы по С/С++ (СИ)

[Z_h_e]

Можно особо критичные к скорости функции перенести в ОЗУ, коли ARM.

[Reflector]

[uquote="Z_h_e",url="/forum/viewtopic.php?p=3269240#p3269240"]Можно особо критичные к скорости функции перенести в ОЗУ, коли ARM.[/uquote]
Разве что в CCM, из обычного ОЗУ исполняется медленнее.

[Z_h_e]

Что такое CCM я не знаю, однако я тоже когда то считал что медленнее, приводил доводы по этому поводу и провел эксперимент, который мои доводы и опроверг. Конечно эксперимент был проведен на определенном камне (т.е. нельзя говорить за все), но скорость обуславливается шинами и скоростью памяти. Шины для конкретного ARM одни и те же, не важно в каком он камне, а флеш однозначно медленнее ОЗУ,

[arkhnchul]

[uquote="ARV",url="/forum/viewtopic.php?p=3269232#p3269232"]если тип должен быстрее всего обрабатываться, то переменная этого типа должна попасть в такую область хранения[/uquote]
нет, это просто тип, без storage class-а.

компилятор по сути один

не то чтобы

[Reflector]

[uquote="arkhnchul",url="/forum/viewtopic.php?p=3269267#p3269267"]не то чтобы [/uquote]
Я пробовал компилить gcc небольшие примеры сишного кода и если их компилить как С++, то часто получался точно такой же бинарник.

[uquote="Z_h_e",url="/forum/viewtopic.php?p=3269265#p3269265"]Что такое CCM я не знаю, однако я тоже когда то считал что медленнее, приводил доводы по этому поводу и провел эксперимент, который мои доводы и опроверг. Конечно эксперимент был проведен на определенном камне (т.е. нельзя говорить за все), но скорость обуславливается шинами и скоростью памяти. Шины для конкретного ARM одни и те же, не важно в каком он камне, а флеш однозначно медленнее ОЗУ,[/uquote]
Ок, проведем эксперимент:

Код: Выделить всё

volatile uint64_t a = -1;

for (int i = 0; i < 20; i++)
{
	a /= 7;
}

F429, работающий на 300MHz (6WS) выдает 2801 тактов при работе из флеша и 3440, для RAM, у которой никаких WS нет...
Для F103, работающего на 72MHz, получается 3516 vs 3627, все равно из флеша быстрее выполняется, даже без ART Accelerator.

[uk8amk]

Всем спасибо за высказывание мыслей.
Перечитав ответы, подумал ещё раз, пересмотрел код и пришёл к следующему итогу:
1. Действительно, первый вариант кода моего примера проще к восприятию.
3. Перечитал статьи в интернете, кое-что вспомнилось про квалификатор volatile.
2. В настоящий момент нет острой необходимости к ускорению вычислений. На тактовой 24МГц прерывание может "съесть" до 30мкс. При текущих оборотах энкодера это вполне допустимо(есть хороший запас). Если обороты возрастут и задержка станет недопустмой, то перейду на проц F103 72МГц. Также может освободится ресурс если пересмотреть сам алгоритм вычислений вместо попытки вручную оптимизировать переменные volatile.

Теперь ответы на вопрос почему много вычислений происходит в прерываниях:
1. Сигнал с энкодера имеет не совсем обычный вид(см рис.). Поэтому аппаратный интрефейс обычного энкодера не подходит.
2. Энкодер генерирует мало импульсов на оборот. Для отслеживания позиции используется экстраполяция с учётом ускорений диска. Ожидаемый интервал корректируется программой с каждым новым импульсом.

[Z_h_e]

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

Чтобы не оффтопить, создал новый топик по этому поводу.

[ARV]

нет, это просто тип, без storage class-а

для чего он введен? я так полагаю, что для тех платформ, где есть разные storage classes, с разным временем доступа, компилятор должен стремиться (очевидно, в зависимости от параметров оптимизации?) подбирать для переменных этих типов наиболее быстрый класс хранения... ведь auto - это значит "на усмотрение компилятора" в зависимости от контекста... вот как бы fast-типы это дополнительная подсказка компилятору. я не прав в своих предположениях?

[Oxford]

[uquote="Reflector",url="/forum/viewtopic.php?p=3269178#p3269178"][uquote="arkhnchul",url="/forum/viewtopic.php?p=3269167#p3269167"]или нет. Компилятор в общем случае не обязан этого делать[/uquote]
Этот register компилятор скорее всего проигнорит, т.к. в С++17 код с ним уже даже не компилится, а до этого он долго был depricated и игнорировался, потому учитывая общую кодовую базу компиляторов можно ожидать такое поведение и в С, но в том же gсс есть еще другая форма записи, с привязкой к конкретному регистру, вот тот register точно работает.[/uquote]

register это специфичная для компилятора функция. В KEIL (ARMCC) это позволяет использовать переменные именованные конкретным регистром на архитектуре ARM.

Синтаксис register unsigned int My_R0 __asm("r0");

Так же не забываем указывать директиву __inline или __forceinline для встраиваемой функции.

[arkhnchul]

[uquote="ARV",url="/forum/viewtopic.php?p=3269590#p3269590"]для чего он введен?[/uquote]
процессоры (и память/конвееры/предсказатели/черти рогатые) могут по-разному работать с переменными разного размера. К примеру, x86 обыкновенно работает с 32-битными числами в целом быстрее, чем с восьмибитными; 16 бит - самые медленные. На amd64 64-битные еще чуть быстрее 32-битных. Если скучно, можете потестировать
определения из gcc с линуксовым libc, x86-64:

Код: Выделить всё

arkhnchul@arkhost-scow:~$ gcc -E -dM -x c /dev/null | grep -E "INT_FAST[0-9]+_TYPE" | sort
#define __INT_FAST16_TYPE__ long int
#define __INT_FAST32_TYPE__ long int
#define __INT_FAST64_TYPE__ long int
#define __INT_FAST8_TYPE__ signed char
#define __UINT_FAST16_TYPE__ long unsigned int
#define __UINT_FAST32_TYPE__ long unsigned int
#define __UINT_FAST64_TYPE__ long unsigned int
#define __UINT_FAST8_TYPE__ unsigned char

там же, но 32 bit ABI:

Код: Выделить всё

arkhnchul@arkhost-scow:~$ gcc -m32 -E -dM -x c /dev/null | grep -E "INT_FAST[0-9]+_TYPE" | sort
#define __INT_FAST16_TYPE__ int
#define __INT_FAST32_TYPE__ int
#define __INT_FAST64_TYPE__ long long int
#define __INT_FAST8_TYPE__ signed char
#define __UINT_FAST16_TYPE__ unsigned int
#define __UINT_FAST32_TYPE__ unsigned int
#define __UINT_FAST64_TYPE__ long long unsigned int
#define __UINT_FAST8_TYPE__ unsigned char

[uquote="ARV",url="/forum/viewtopic.php?p=3269590#p3269590"]я так полагаю, что для тех платформ, где есть разные storage classes, с разным временем доступа, компилятор должен стремиться (очевидно, в зависимости от параметров оптимизации?) подбирать для переменных этих типов наиболее быстрый класс хранения[/uquote]
еще раз - нет, это только тип. Storage class - отдельная сущность.
[uquote="ARV",url="/forum/viewtopic.php?p=3269590#p3269590"]ведь auto - это значит "на усмотрение компилятора"[/uquote]
да, и компилятор стремится запихать любой тип в самую быструю память, какая у него есть.

register это специфичная для компилятора функция.

register это стандартный спецификатор, его обязаны понимать (не выполнять) все компиляторы.

[Oxford]

Я и говорю только специфичная функция в зависимости от компилятора, поддержка и реализация на конкретной архитектуре описана в мануале на компилятор.

[jcxz]

[uquote="uk8amk",url="/forum/viewtopic.php?p=3268855#p3268855"]Я подумал, а нельзя ли включить оптимизацию над этой переменной в обработчиках прерываний и выключить в главном цикле. Всё это затевается чтобы немного сократить время выполнения обработчиков.[/uquote]
На входе в функцию скопировать эту переменную в локальную: uint v = v16;
И при каждом изменении этой переменной внутри функции обновлять сразу обе: v16 = v = <expression>;
Конечно не забывая про размерности и связанные с ними эффекты.
И естественно так можно делать при условии, что данная функция не может быть прервана другой, имеющей внутри записи в данную volatile-переменную. Т.е. - если прерыван-ия (-ие) на время выполнения такого кода запрещены или если данное прерывание имеет наивысший приоритет из всех, где есть записи в данную переменную.
Я везде именно так и работаю с volatile-переменными.

Добавлено after 9 minutes 4 seconds:
[uquote="Reflector",url="/forum/viewtopic.php?p=3269329#p3269329"]F429, работающий на 300MHz (6WS) выдает 2801 тактов при работе из флеша и 3440, для RAM, у которой никаких WS нет...[/uquote]
Сказки рассказываете. Максимальная тактовая ядра для F429 == 180МГц.

Добавлено after 5 minutes 5 seconds:
[uquote="arkhnchul",url="/forum/viewtopic.php?p=3269684#p3269684"]x86 обыкновенно работает с 32-битными числами в целом быстрее, чем с восьмибитными; 16 бит - самые медленные.[/uquote]
Зависит от режима CPU. В 16-битном режиме как раз самыми быстрыми (в среднем) будут 16-битные операции (т.к. отсутствуют префиксы переопределения размера операнда).

[Голимый]

Частенько (все чаще и чаще) во всяких исходниках встречается записи такого вида: 1000000UL. Что это значит, что это вообще такое, и как с этим бороться?

[Reflector]

[uquote="jcxz",url="/forum/viewtopic.php?p=3270402#p3270402"]Сказки рассказываете. Максимальная тактовая ядра для F429 == 180МГц.[/uquote]
Серьезно? Даже на 181 уже работать не будет?

[arkhnchul]

[uquote="Голимый",url="/forum/viewtopic.php?p=3271289#p3271289"]Частенько (все чаще и чаще) во всяких исходниках встречается записи такого вида: 1000000UL. Что это значит, что это вообще такое, и как с этим бороться?[/uquote]
это значит, что программист пытается сказать "сия константа типа Unsigned Long". Некоторые (далеко не все) компиляторы его даже поймут.

[ARV]

Некоторые (далеко не все) компиляторы его даже поймут

огласите хотя бы часть перечня непонятливых компиляторов

[jcxz]

[uquote="Reflector",url="/forum/viewtopic.php?p=3271293#p3271293"][uquote="jcxz",url="/forum/viewtopic.php?p=3270402#p3270402"]Сказки рассказываете. Максимальная тактовая ядра для F429 == 180МГц.[/uquote]
Серьезно? Даже на 181 уже работать не будет? [/uquote]
Попробуйте открыть даташит.

[Reflector]

[uquote="jcxz",url="/forum/viewtopic.php?p=3271525#p3271525"]Попробуйте открыть даташит.[/uquote]
И я там увижу максимальную скорость на которой способен работать данный мк?

[jcxz]

[uquote="Reflector",url="/forum/viewtopic.php?p=3271538#p3271538"]И я там увижу максимальную скорость на которой способен работать данный мк?[/uquote]
Очевидно.

[Reflector]

[uquote="jcxz",url="/forum/viewtopic.php?p=3271544#p3271544"]Очевидно.[/uquote]
Ладно, а обычная рабочая частота тогда какая? Я так понимаю номинальная и максимальная частоты в твоем понимании совпадают?