Оптимизация проекта в ARM, Прошу советов, мнений, выссказываний. Опции

[SasaVitebsk]

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

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

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

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

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

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

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

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

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

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

[scifi]

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

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