Вопрос только подотчетен, а не вопрос мнения, потому что вы были конкретны в отношении цели и набора инструментов.Невозможно обобщить (и никогда не было).
В цепочке инструментов GNU ARM используется библиотека Newlib C.Newlib разработан, чтобы быть независимым от архитектуры и переносимым.Как таковой он написан на C, а не на ассемблере, поэтому его производительность определяется генерацией кода компилятора и, в свою очередь, параметрами компилятора, применяемыми при сборке библиотеки.Можно построить для очень конкретной архитектуры ARM или для более общего набора команд ARM;это также повлияет на производительность.
Более того, сам Newlib может быть собран с различными вариантами условной компиляции, такими как PREFER_SIZE_OVER_SPEED и __OPTIMIZE_SIZE__.
Теперь, если вы можете генерировать лучший код ассемблера ARM(и есть время), чем компилятор, то это здорово, но такие навыки кодирования кунг-фу становятся все более редкими и, откровенно говоря, все более и более ненужными.Достаточно ли у вас опыта ассемблера, чтобы победить компилятор;у вас есть время, и вы действительно хотите сделать это для каждой архитектуры, которую вы можете использовать?Это может быть преждевременной оптимизацией и быть довольно непродуктивным.
В некоторых случаях для целей с возможностью может быть целесообразно настроить передачу DMA из памяти в память.Компилятор GNU ARM не будет генерировать код DMA, поскольку он зависит от производителя микросхемы и не является частью архитектуры ARM.Однако memcpy является общим назначением для произвольного выравнивания размера копии и безопасности потока.Для конкретных обстоятельств, где DMA является оптимальным, лучше, возможно, определить новую подпрограмму с другим именем и использовать ее там, где это необходимо, а не переопределять memcpy и подвергнуть риску ее неоптимальность для небольших копий, которые могут преобладать, или для многопоточных приложений.
Например, реализацию memcpy() в Newlib можно увидеть здесь .Это разумная идиоматическая реализация и поэтому сочувствующая типичному оптимизатору компилятора, который обычно лучше всего работает с идиоматическим кодом.Альтернативная реализация может работать лучше при неоптимизированной компиляции, но если это «необычно», оптимизатор может работать не так хорошо.Если вы пишете это на ассемблере, вам просто нужно быть лучше компилятора - вы будете редким, хотя и не обязательно ценным (коммерчески) товаром.Тем не менее, глядя на эту конкретную реализацию, она выглядит гораздо менее эффективной для больших невыровненных блоков в реализации скорость-по-размеру.Можно было бы улучшить это за несколько небольших затрат, возможно, за счет более распространенных выровненных копий.