Ассемблер (ASM) для AVR в вопросах и ответах

[B@R5uk]

Народ, кто-нибудь пробовал сдвиг многобайтной величины на 4 бита вправо реализовывать через операцию SWAP? Можно ли выжать чутка быстродействия по сравнению с реализацией в лоб через RORы?

Добавлено after 10 minutes 48 seconds:
Судя по всему можно:

Спойлер

Код:

;============
mov     tmp1,   val1
mov     tmp2,   val2
mov     tmp3,   val3
lsr     tmp3
ror     tmp2
ror     tmp1
lsr     tmp3
ror     tmp2
ror     tmp1
lsr     tmp3
ror     tmp2
ror     tmp1
lsr     tmp3
ror     tmp2
ror     tmp1
;============
mov     tmp1,   val1
swap    tmp1
andi    tmp1,   0x0F
mov     tmp2,   val2
swap    tmp2
eor     tmp1,   tmp2
andi    tmp2,   0x0F
eor     tmp1,   tmp2
mov     tmp3,   val3
swap    tmp3
eor     tmp2,   tmp3
andi    tmp3,   0x0F
eor     tmp2,   tmp3
;============

Добавлено after 7 minutes 12 seconds:
Правда выигрыш всего в две операции, и он не растёт, если наращивать число байт в величине.

[BOB51]

Это в пределах одного байта красиво смотрится.
А при многобайтовой цепочке придется промежуточный регистр да маски применить.
По итогу может и чуток быстрее, но сожрет дополнительные ресурсы в виде буфер-регистра.

[B@R5uk]

BOB51 писал(а):

...но сожрет дополнительные ресурсы в виде буфер-регистра.

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

Добавлено after 6 minutes 50 seconds:
Впрочем, получится. На месте свапами тоже прекрасно шифтится:

Спойлер

Код:

;============
lsr     val3
ror     val2
ror     val1

lsr     val3
ror     val2
ror     val1

lsr     val3
ror     val2
ror     val1

lsr     val3
ror     val2
ror     val1
;============
swap    val1
andi    val1,   0x0F

swap    val2
eor     val1,   val2
andi    val2,   0x0F
eor     val1,   val2

swap    val3
eor     val2,   val3
andi    val3,   0x0F
eor     val2,   val3
;============

[motorist82]

Добрый день! Помогите пожалуйста!
Имеем пятибайтную константу, например

.equ NAME=0xE7E6E5E4E3

Как из неё взять старший байт для загрузки в РОН?

[ПростоНуб]

motorist82, боюсь, никак. Я просто не знаю 64-битного ассемблера для AVR. А 32-х битный с такой константой ничего сделать не сможет.

[Starichok51]

вот так:
ldi R16, byte5(NAME)

[motorist82]

Starichok51 писал(а):

вот так:
ldi R16, byte5(NAME)

Так не получится. Нет такой функции byte5. Придется сохранять константу в Flash. Хотя студия не ругается на

.equ Name= 0xE7E6E5E4E3

Наверное все что свыше 32 бит просто игнорируется.

[ПростоНуб]

Starichok51, А что это за ассемблер? Гнушный as меня конкретно посылает фразой "Error: bignum invalid"
Ну и про byte5 он ничего не знает.

Добавлено after 1 minute 30 seconds:
motorist82, пока константа в .equ - она для ассемблера просто строка для подстановки. Разбираться с ее содержимым он будет только при использовании имени из .equ

[motorist82]

Спасибо
Вот макрос который суёт константу во Flash:

#define Address(v,w,x,y,z) NRF24_Addr: .db $##z, $##y, $##x, $##w, $##v

Используем так:

Address (E7,E6,E5,E4,E3)

Достаём из Flash:

ldZ (NRF24_Addr*2)
ldi R17, 5

Get_NRFAddr_Loop: lpm R16, Z+
dec R17
; Тут сохраняем R16 в какой-нибудь буфер для дальнейшего использования
brne Get_NRFAddr_Loop
[/code]

[Starichok51]

извиняюсь, я это "с потолка" взял.
byte4 работает, и я решил, что и byte5 будет работать.

[B@R5uk]

motorist82 писал(а):

.equ NAME=0xE7E6E5E4E3

Как из неё взять старший байт для загрузки в РОН?

А выражение

Код:

(NAME >> 32) & 0xFF

не взлетит?

[Starichok51]

если сделать
(NAME >> 32)
то
& 0xFF
уже не нужно делать.

[akl]

B@R5uk писал(а):

А выражение

Код:

(NAME >> 32) & 0xFF

не взлетит?

Не взлетит. AVR-студия заносит 0xFF. Если через BYTE5, то заносит 0x00.

Код:

.equ   NAME=996011271395
;.equ   BYTE5=NAME/4294967296
;.equ NAME=0xE7E6E5E4E3

.cseg
RESET:
   RJMP   START
CONST:
;.DB   0,BYTE5,BYTE4(NAME),BYTE3(NAME),BYTE2(NAME),BYTE1(NAME)
;.DB   0,NAME >> 32,BYTE4(NAME),BYTE3(NAME),BYTE2(NAME),BYTE1(NAME)
.DB      0,(NAME >> 32) & 0xFF,BYTE4(NAME),BYTE3(NAME),BYTE2(NAME),BYTE1(NAME)

START:
   LDI   ZH,HIGH(CONST*2)
   LDI   ZL,LOW(CONST*2)

   LPM   R10,Z+
   LPM   R11,Z+
   LPM   R12,Z+
   LPM   R13,Z+
   LPM   R14,Z+
   LPM   R15,Z


   RJMP   START

[DimKra]

Вопрос знатокам: В AVR есть такой скрытный зверёк - регистр "PC", счётчик инструкций. Хотел узнать о нём поподробнее, как то например по какому физическому адреcу он сидит, можно ли его прочесть напрямую из программы ? Гугль молчит как партизан, неужели нигде нет подробной информации на этот счёт?

[WiseLord]

А зачем Вам знать это? Всё равно попытка прочитать этот регистр из программы давала бы как раз номер той инструкции, которой этот регистр читается. Что чуть менее чем бесполезно.

[DimKra]

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

[ПростоНуб]

DimKra, через CALL на следующую после него инструкцию и два (три для некоторых AVR) POP можете его значения получать. Но толку с него действительно немного.

[Demiurg]

Практического смысла нет. Смотрим описание этого регистра. Работает с командами rjmp, jmp, rcall, cal.

Код:

rjmp pc +\- x

Глухое зацикливание программы rjmp pc + 0.
Так как команды бывают двух и четырех байтные, заманаешься вручную высчитывать насколько команд нужно прыгнуть. Именно по этой причине крайне не рекомендуется работает вручную. Только по меткам.

Код:

Label_1:
bla-bla
rjmp +\- Label_x
bla-bla
Label_2:


[Alexeyslav]

Он-то регистр, но недоступен для чтения напрямую. Но с ним можно работать некоторыми командами - всевозможные команды перехода и возврата из подпрограммы.
Толку его читать? Он всегда указывать удет на ту инструкцию которой его прочитаешь, а это известно и так на этапе компиляции(переносимый по адресному пространству код под AVR я не видел).

[BOB51]

DimKra
Модификация содержимого PC производится "подстановкой адреса возврата через стек", командами call, jmp, коротких условных переходов и косвенных переходов ijmp, icall с подстановкой адреса из регистровой пары R31:R30 (она же Z).
Чтение... в принципе в некоторых случаях может иметь смысл (к вопросам отладки например) - тогда выполняем любой вызов call и считываем точку входа из верхушки стека.