Некоторые моменты при изучении любого вопроса выпадают из поля зрения. У меня по крайней мере. Видимо мозги "отбрасывают" то что считают "несущественным". А определить что "существенно", а что нет - на этапе изучения предмета практически невозможно. Вот и получается ...

Когда Си изучал, маленький раздел про дополнения в версии С99 - мозг выкинул. С stdint начал работать потому, что увидел в какой-то из библиотек GCC и мне понравилось. Даже не догадался, что эта библиотека есть в IAR. Работал тогда с AVR, а библиотека эта только в DLIB. То есть по умолчанию она не подключена. Поэтому я выдрал библиотеку из GCC, доработал напильником и пользовался.
В детали не вникал.

Сейчас, в одной из веток, zltigo обратил внимание на типы int_least8_t и я бросился читать. Оказалось буквально 10 строк, которые я упустил. На книгу не фиг пенять. Просто, чтобы понять, надо через себя пропустить. Осмыслить необходимость и потом уже применять.

Но ведь таких моментов много.

Для AVR, я, на первом этапе, просматривал результирующие листинги, чтобы понять как писать на Си, чтобы компилятор генерил прогу найболее эффективно. Это неплохой способ изучения, но слишком долгий. Пока нарабатываются приёмы и появляются знания.
Сейчас перехожу к ARM. Понятно что есть особенности архитектуры. Они явно сказываются. Например вызов п/п совершенно по другому построен. Количество регистров другое и это сказывается. Система комманд и прочее.

Хотелось бы услышать рекомендации спецов, активно работающих с этими процами. Для повышения производительности результирующего кода.

1) Ну например. Для AVR передача параметров в п/п осуществляется ч/з регистры. Если не влазит, то ч/з стек. В связи с этим нецелесообразно было передавать большое количество параметров и оперировать с длинными параметрами. В некоторых случаях, я "укорачивал" параметры перед передачей ну и так далее. Хотелось бы узнать как эффективнее поступать здесь.

2) Стоит ли работать с "промежуточными типами" ну например int16. Насколько это усложняет жизнь процу?

3) Насколько хорошо проц работает с табличным пересчётом? В AVR я часто пользовался этим при сложных логических операциях, чтобы ускорить получение результата. Здесь я вижу система команд неплохо заточена под сложные операции. Например, то что у AVR отвратительно реализуется - это сдвиги на N разрядов. Здесь - песня. У меня этого много в проекте.
Вот например получение CRC8 таблично будет быстрее или медленнее чем прямым пересчётом. И на сколько.

Хотелось бы услышать советы, мнения выссказывания или ссылки.
Заранее благодарю.

В певом приближении так-же. Вообще передавать большое количество параметров зачем? Эта функция вызыватсся много раз? Нет? Тогда лююое количество параметров и инлайнить. Либо у меня в таких кусках со многими перемеными хорошо используются макросы.

В общем случае, естественно, нет.

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

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

В ответ на вопрос о промежуточных типах:




Дело обстоит не так. Два простых примера для иллюстрации: (VS2008 ARM)



компилируется в:
а

в

Разница на лицо.
Это же относится к 8-битным типам.

Ну и что не так? Стоит пользоваться промежуточными типами - ответ мною дан - НЕТ.
Приводим пример обратного и возражаем "дело обстоит не так"? Так о чем мы это?

Именно. Первый код - унылое гуано с точки зрения портабельности. Надо пользовать int_fast16_t. Пользовать регистровые переменные размером меньше регистра нужно только в самом крайнем случае (например, арифметика по модулю 2^16 при размере регистра 32).

Кстати, это же относится и к портированию с 32хбитного камня на 64хбитный. Опять изобретение - int остался 32хбитным... Значит, надо пользовать int_fast32_t. Нет в жизни счастья...

И одновременно типичнейший код (ну будет char) для писателей на восьмибитниках в подвляющем числе случаев переносящих сию привычку и на другие платформы

Уважаемый гуру!

Я понимаю, что мы все с этим программированием потихоньку забываем русский язык, особенно письменный. Вы внимательно перечтите две строчки, на который даете ответ:

Вопрос: "Стоит ли работать с "промежуточными типами" ну например int16. Насколько это усложняет жизнь процу?"
Ответ: "В общем случае, естественно, нет."

Вопрос стоит у последнего предложения. Соответственно, на него и ответ: "Процу жизнь в общем случае, естественно, нет". Значит не усложняет.

Это меня сильно удивило, потому и привел пример.

Мне кажется, Вы неверно выбрали приоритет. На мой взгляд (исходя из личного опыта) читаемость/понимаемость кода в подавляющем большинстве случаев важнее, чем его скорость. Тут уместно вспомнить об известном высказывании Дональда Кнута о преждевременной оптимизации (если не в курсе, советую поискать).
ARM хорош тем, что для многих задач производительности достаточно при использовании языка Си без "доработки напильником". Этим надо пользоваться. Лучше быстро и эффективно решать реальные задачи, чем бесконечно ковыряться в отдельных инструкциях процессора, выжимая из него ещё одну микросекунду. Это тем более актуально, так как "традиционный Си для десктопов" хорошо исполняется на ARM - ведь это 32-разрядный процессор.
Конечно, есть применения, где нужно выжать из процессора всё до последнего такта. Но это редкость. Руководствоваться такой философией при обычных разработках - вредно.

Наверное, я недостаточно знаю правила русского языка , в какой-то степени это мне простительно . Ответ давался на ПЕРВЫЙ вопрос а не на его повтор c уточнением на другой лад.
Сочетание "Стоит ли работать с "промежуточными типами - В общем случае, естественно, нет". Вполне нормально звучит.
А фраза "Насколько это усложняет жизнь процу - В общем случае, естественно, нет." Уже звучит не совсем как-то законченной по-русски . Или мне кажется, что при ответе утвердительно на вторую часть таким образом поставленного вопроса принято слегка переповторять? Првильно - "усложняет/не усложняет". И вообще ответ "Нет" для ответа на вопрос "Насколько" не подходит

Для локальных переменных(и параметров функций) всегда нужно стремиться к 32бит unsigned,
все остальное менее важно и Вы это поймете в процессе освоения...

Главное, что автору топика все объяснили, в конце концов.

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

Тем не менее вопрос задаётся не применительно к проекту, а применительно к процессору. Знания нужны безотносительно к текущей задаче. Они всегда нужны. Например, для более эффективного написания следующего проекта. Кроме того, некоторые знания сложно или долго получать прямым способом. Так как для этого надо произвести исследования. Править и измерять многократно. Это отнимает массу времени и есть вероятность того, что кто-то этот путь уже прошёл. Вот поэтому я обратился к спецам.

И меня они понимают, так как, наверняка, сами оценивали эти вопросы. Возможно неоднократно.

Чтобы понять насколько вы неправы приведу отрывок описания версий при отладке. History так сказать


Если сравнить верх и низ, то видно что поначалу процессор вообще не справлялся с задачей (загрузка 148%), а в последствии, благодаря изменению алгоритма и оптимизации справлялся с запасом на выбраной тестовой задаче (загрузка 32%).