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

Еще одна ложка - скорее всего для исходной постановке задачи (8К и const) компилятор сам сооптимизирует код (те же LDM/STM).

Дык все верно, только эффективность нельзя оценивать по небольшому фрагменту, следует взять достаточно большой проект (не менее 3000-4000 Ц строк), написать его на Ц и АСМ, и сравнить. Вот только заниматься этим никто не будет...
З.Ы. Прикола ради попробовал табличный CRC16 - получился выйгрыш на 10% по скорости и 30% по объему

Где Вы увидели const? И покажите мне такой компилятор, который вместо понятного ему вызова тормозного memcpy станет извращатся с LDM/STM.

1) длина массива=const

2) Это не только от компилятора зависит, от программиста тож. Чувствовать надо (или знать), где он может сооптимизировать и при каких условиях.

Так речь не об особенностях оптимизации компилятора, а о том, что конструкцию с LDM/STM на Ц вообще реализовать не получится.

Не понимает...
Если, последовательно (не мешая в кучу). Функция memcpy (кстати чем она Вам не понравилась? Вы уверены, что там не через LDM/STM?) добавляет (как всякая функция) некие накладные расходы по передаче параметров. Мало-мальские приличные компиляторы для оптимизации при типичных ситуациях (например, длина массива - константа, массивы - глобальные переменные) заменяют вызов функции inline кодом, обходясь тем самым без вызова функции memcpy

Не понимаю!
1. Уверен, что не использует. Оперирует максимум только словами.
2. Еще раз прошу: покажите мне компилятор, который ведет себя хотя бы близко так, как Вы описываете.

Тогда еще раз условия задачи: процессор - ?, размер элемента массива - байт? и т.п.

IAR оптимизирует словами.



А нужно? Это весьма частный случай.

Да нет, если честно, нафиг не нужно. Просто мне упорно пытаются объяснить, что де хороший компилятор все это прекрасно оптимизирует. Ничего подобного!

Специально возможно и нет. Но возьмите типичную структуру кода. Циклы, управляющие структуры, функции (подпрограммы). Посмотрите, как эти структуры реализует компилятор, и насколько оптимальнее это можно сделать на асм. В завистимотси от процессора/компилятора проигрыш Ц будет от 0 до 50% в более или менее общих случаях. Все частные случаи накладывают сильные ограничения, и поэтому эти частные случаи трудносопровождаемы, шаг вправо, шаг влево - расстрел. Тот же LDM/STM потребует дополнительных телодвижений при отсутствия выравнивания на 4 и любого количества байт в блоке. И вся оптимальность тут уже начинает идти лесом на мелких блоках. То есть удел асма - вставки там, где действительно нужно выжать максимум быстродейтсвия, таких мест не очень много.



То есть как я и говорил, 1.3 раза по коду.

Хорошо. Условия задачи:
1. Процессор: ARM7
2. Размер элемента массива: 4 байта (слово)
3. Количество элементов: 2048
4. Источник и приемник выравнены по границе слова (ложка дёгтя здесь
отсутствует, но можно добавить - 4 байта из 8192 картину не испортят)
5. Оптимизация на скорость

Попробуйте решить это на Ц и сравните с АСМ

Опять слишком "жесткое" утверждение. Поймите и Вы, я тоже не цепляюсь именно к этому примеру. Но Ваши категоричные утверждения
Вы хоть знаете где Ваш компилятор (именно тот с которым Вы работаете) делает оптимизацию (и какие приемы лучше при этом использовать). Ну хотя бы такую классику ++j или j++. Или сравниваете C-программы и Asm-прог только по конечному результату?

Извините, если Вам показалось какое-то упорство с моей стороны (навеянное впрочем личным опытом, пусть и несколько уставревшим, и знания некоторых основ компилирования). Но ведь весь разговор в течении последнего часа - и поэтому выбранный тон - для лучшего взаимопонимания

От своей реплики с условиями задачи не отказываюсь

Хм, издержки реального времени (почти одновременные ответы).

Условия принимаю.