По порядку:
1. В своей подпрограмме вы не имеете права портить R5. Можно портить только R0-R3 и R12.
2. Результат должен возвращается в R0.



3. Вы передаете rezult как параметр, получить что-либо обратно в него нельзя.
Чтобы иметь возможность что-то вернуть, можно использовать указатель:

Спасибо. Сделал как написали все заработало
Но еще остался один вопрос:
Собственно в асм я полез в надежде ускорить выполнение программы, и попытался "ускорить" простые функции например функция умножения 32 на 32 бит и результат 32 бит:

#define MUL_F(A,B ) (real_t)(((int64_t)(A)*(int64_t)(B )+(1 << (31))) >> 32) // так она была сделана до меня

я сделал функцию:

static INLINE __asm real_t MUL_F(real_t x, real_t y)
{
smull r0, r1, r0, r1;
lsr r1, #31;
add r0, r0, r1;
lsl r0, #1;
mul r0, r1, #2;
BX lr ; Return.
}


в итоге проиграл 30 процентов(естественно при включении оптимизации по времени выполнения программы). Получается действительно компилятор в данном случае царь и бог или я чтото не так делаю?

Сообщение отредактировал drum1987 - Mar 21 2011, 12:34

С умножением компилятору точно не следует "помогать". Посмотрите и сравните дизассемблированный текст в обоих случаях.

Оптимизацию делают не так. Вот правильная методология:
1) Испытываем программу. Смотрим, хватает ли скорости.
2) Если не хватает, ищем медленные куски кода, собирая объективную информацию (время выполнения кусков кода).
3) Возможно, применение другого алгоритма позволит вписаться в требования по скорости выполнения.
4) Если ясно, что переписывание небольшого куска кода на ассемблере по-видимому позволит вписаться в требования по скорости выполнения, то так и делаем.

Если пропустите шаги 1-3, то рискуете потратить кучу времени на оптимизацию, которая не даст никакого полезного результата.
В данном случае потраченное время можно списать на изучение средств разработки.
Ну и, как заметил aaarrr, не нужно соревноваться с компилятором в умножении, от это и так хорошо умеет делать.