STM32 Ассемблер. Идеи и приёмы написания, Правила хорошего тона и макросы Опции

[allsettingsdone]

По ассемблеру для арм документации и разного рода примеров гораздо меньше для С. Начал осваивать и возникли сомнения, правильный ли подход частого использования макросов и где та грань, свыше которой не стоит заморачиваться с написанием кода. В ассемблера я не силён, в основном по-любительски пишу на С. Но вот раз начал осваивать асм, сделал несколько элементарных макросов для битовых операций, настройки и использования портов. Вопрос в том правильно ли это делать и использовать таким образом (когда в коде используются много макросов), или может быть есть более рациональный способ, как лучше писать на асме для арм. Вот примерчик:
STM32F100RB.
И что конкретно делает команда bfi R1,R2,#$Pin,#4 ?
Определение макросов:

Код

;--------------------------------------
;Start_GPIO_Conf $Port,$PinRange - начало настройки порта, где $Port - имя порта (GPIOA,..), $PinRange - верхняя/нижняя тетрада порта (GPIO_CR_H/GPIO_CR_L)
        macro
        Start_GPIO_Conf $Port,$PinRange
        mov32            R0,#$Port        ;загружаем в регистр "R0" имя порта (его код) из памяти
        ldr             R1,[R0,#$PinRange];загружаем в регистр "R1" значение по адресу из памяти "R0 + #GPIO_CR_H(0x00)" или "R0 + #GPIO_CR_H(0x04)"
        mend
;--------------------------------------
;GPIO_Conf          $Pin,$Mode - настройка ножек выбраного порта, где $Pin - номер ножки (CNF_Pin_0,..), $Mode - режим ножки (GPIO_OUT_50_PP,..)
        macro
        PinConfig         $Pin,$Mode
        movs             R2,#$Mode
        bfi             R1,R2,#$Pin,#4
        mend
;--------------------------------------
;End_GPIO_Conf      $Port,$PinRange - конец настройки порта, где $Port - имя порта (GPIOA,..), $PinRange - верхняя/нижняя тетрада порта (GPIO_CR_H/GPIO_CR_L)
        macro
        End_GPIO_Conf     $Port,$PinRange
        str             R1,[R0,#$PinRange];загружаем в память по адресу "R0 + #GPIO_CR_H(0x00)" или "R0 + #GPIO_CR_H(0x04)" значение "R1"
        mend
;--------------------------------------
;SetBit_GPIO    $Port,$Pin
        macro
        SetBit_GPIO        $Port,$Pin
        mov32            R0,#($Port + GPIO_BSRR)
        mov32            R1,#$Pin
        str                R1,[R0]
        mend
;--------------------------------------
;ResetBit_GPIO    $Port,$Pin
        macro
        ResetBit_GPIO    $Port,$Pin
        mov32            R0,#($Port + GPIO_BRR)
        mov32            R1,#$Pin
        str                R1,[R0]
        mend
;--------------------------------------

Использование в программе:

Код

;--------------------------------------
            Start_GPIO_Conf GPIOC,GPIO_CR_H
        PinConfig         CNF_Pin_9,GPIO_OUT_50_PP
        PinConfig         CNF_Pin_8,GPIO_OUT_50_PP
        End_GPIO_Conf     GPIOC,GPIO_CR_H
;--------------------------------------
        SetBit_GPIO        GPIOC,PIN9
        SetBit_GPIO        GPIOC,PIN8
;--------------------------------------

Пробный проект в Keil 5 прикреплен:

Сообщение отредактировал allsettingsdone - Jan 15 2014, 22:55

Прикрепленные файлы

 test11_ASM.7z ( 93.49 килобайт ) Кол-во скачиваний: 28

 

[Golikov A.]

ага или на асм ДСПешника со сдвоенным АЛУ,

помню там было много приколов с тем что branch делался 3 такта, и часто эти 3 такта шли на доп вычисления, типа 1 такт бранч, а потом еще 2 команды которые выполнялись до бранча. Или когда ффт на 2 алу раскидывалось в параллель. Примерно тогда я зарекся соревноваться в компилятором.

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

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

[jcxz]

помню там было много приколов с тем что branch делался 3 такта, и часто эти 3 такта шли на доп вычисления, типа 1 такт бранч, а потом еще 2 команды которые выполнялись до бранча. Или когда ффт на 2 алу раскидывалось в параллель. Примерно тогда я зарекся соревноваться в компилятором.

На TI C55xx если мне не изменяет память 6-тактный конвеер и переходы (не внутри RPT) 4-5-6 тактов.
Там я применял много способов оптимизации в том числе и конвееризацию вычислений внутри циклов, когда одновременно выполнялась голова цепочки команд обработки сэмпла в одном АЛУ в то время как
в те же самые такты выполнялся хвост этой цепочки команд для предыдущего сэмпла в другом АЛУ.
Что уж говорить про параллельные чтения/сохранения в ОЗУ.
И зря зареклись. Никогда ещё ни до ни после я по эффективности кода так не превосходил си-компилятор как тогда - мой код на асм получался в РАЗЫ меньше и быстрее.
Оптимизировав инструкции по размеру, спарив их, убрав все штрафы (stall-ы), раскидав выполнение по разным шагам конвеера, загнав цикл в RPTBLOCAL, использовав разные фичи типа циклической адресации и т.п. можно было в разы уделать компилятор
А вот на ARM выигрыш от такой оптимизации будет значительно меньше и смысл в ней значительно меньше.
Изредка, когда приходится что-то написать на асм для ARM/Cortex-M с оптимизацией времени выполнения, с тоской вспоминаю C55xx....