Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
>> Все процедуры не портят регистры!
Какой в этом смысл?
Прелесть асма как раз в том, что не нужно соблюдать стандартный ABI.
Весь код не смотрел, но глянул LCD_PIXEL
Скажу что у вас там не асм, а скорее C сконвертированный в асм.
Более того, если бы это был чистый C, функция скорее всего просто была бы заинлайнена в вызывающий код и работала бы в 2 раза быстрее.
Вот это вообще неудачный код
MOV R3, 1
AND R0, R0, 0x07
LSL R3, R3, R0
CMP R2, 0x01
ITEE EQ
ORREQ R4, R4, R3
RSBNE R3, R3, 0xFF
ANDNE R4, R4, R3
RSB AND (&~) заменяются одной командой BIC.
Вся эта последовательность не более чем вставка битового поля, выполняемая инструкцией BFI
Можно сдвинуть R2 и потом
AND R4, R3
OR R4, R2
У M4 есть инструкции типа MLA, ROR, BFC, ORN, которых также нет в C
Можно, например написать так (не проверено):
r0 y
r1 x
r2 0/1
lcd_pixel:
push {r0,r1,r3,r4}
lsr r3, r0, #3
mov r4, #48
mla r3, r4, r3, r1
movw r1, #(48/8*84)
cmp r3, r1
blt 1f
ldr r1, =lcd_buff
add r3,r1
ldrb r1, [r3]
ror r1, r1, r0
rsb r0, r0, #0
bfi r1, r2, #0, #1
ror r1, r1, r0
strb r1, [r3]
1: pop {r0, r1,r3,r4}
bx lr
-5 инструкций
-1 бранч
-3 сохранённых в стеке регистра
Я под thumb2 праада не писал и не проверял, так что скорее всего не скомпиляется =)
Но тем не менее, посыл должен быть ясен — раз вы занялись асм-ом, используете возможности, которые предоставляет процессор.
Также не нужно сохранять то, что не меняется.
Даже если использовать сишный ABI, push/pop можно вообще убрать, а вместо r4 использовать r12
>> кстати, никто не занимается написанием текстовых редакторов? очень хочется среду разработки с…
А чем все существующие не подходят, интересно?
Какой в этом смысл?
Прелесть асма как раз в том, что не нужно соблюдать стандартный ABI.
Весь код не смотрел, но глянул LCD_PIXEL
Скажу что у вас там не асм, а скорее C сконвертированный в асм.
Более того, если бы это был чистый C, функция скорее всего просто была бы заинлайнена в вызывающий код и работала бы в 2 раза быстрее.
Вот это вообще неудачный код
MOV R3, 1
AND R0, R0, 0x07
LSL R3, R3, R0
CMP R2, 0x01
ITEE EQ
ORREQ R4, R4, R3
RSBNE R3, R3, 0xFF
ANDNE R4, R4, R3
RSB AND (&~) заменяются одной командой BIC.
Вся эта последовательность не более чем вставка битового поля, выполняемая инструкцией BFI
Можно сдвинуть R2 и потом
AND R4, R3
OR R4, R2
У M4 есть инструкции типа MLA, ROR, BFC, ORN, которых также нет в C
Можно, например написать так (не проверено):
r0 y
r1 x
r2 0/1
lcd_pixel:
push {r0,r1,r3,r4}
lsr r3, r0, #3
mov r4, #48
mla r3, r4, r3, r1
movw r1, #(48/8*84)
cmp r3, r1
blt 1f
ldr r1, =lcd_buff
add r3,r1
ldrb r1, [r3]
ror r1, r1, r0
rsb r0, r0, #0
bfi r1, r2, #0, #1
ror r1, r1, r0
strb r1, [r3]
1: pop {r0, r1,r3,r4}
bx lr
-5 инструкций
-1 бранч
-3 сохранённых в стеке регистра
Я под thumb2 праада не писал и не проверял, так что скорее всего не скомпиляется =)
Но тем не менее, посыл должен быть ясен — раз вы занялись асм-ом, используете возможности, которые предоставляет процессор.
Также не нужно сохранять то, что не меняется.
Даже если использовать сишный ABI, push/pop можно вообще убрать, а вместо r4 использовать r12
>> кстати, никто не занимается написанием текстовых редакторов? очень хочется среду разработки с…
А чем все существующие не подходят, интересно?
Опс. Думал про BIC, а написал AND
BIC R4, R3
ORR R4, R2
=)
BIC R4, R3
ORR R4, R2
=)
Такую проверку координат не хочу:
это не проверка координат а скорее проверка выхода за границы буфера экрана… да и при попытке задать допустимый параметр Y но не допустимый по X — потом замучаешься отлаживаться
а вот циклический сдвиг — это красивое решение!!!
постараюсь попробовать сегодня вечером!
lsr r3, r0, #3
mov r4, #48
mla r3, r4, r3, r1
movw r1, #(48/8*84)
cmp r3, r1
blt 1f
это не проверка координат а скорее проверка выхода за границы буфера экрана… да и при попытке задать допустимый параметр Y но не допустимый по X — потом замучаешься отлаживаться
а вот циклический сдвиг — это красивое решение!!!
ldrb r1, [r3]
ror r1, r1, r0
rsb r0, r0, #0
bfi r1, r2, #0, #1
ror r1, r1, r0
strb r1, [r3]
постараюсь попробовать сегодня вечером!
в общем реализовал ваш алгоритм со сдвигом
правда с небольшими уточнениями
прирост скорости 80%!!! (38225 тактов на рисование третьего слайда)
правда с небольшими уточнениями
.global LCD_PIXEL
LCD_PIXEL:
CMP R0, 48 @ проверим допустимость координат
BPL LCD_PIXEL_exit
CMP R1, 84
BPL LCD_PIXEL_exit
PUSH {R1, R3, R4}
@ вычисляем адрес пиксела
LDR R3, =LCD_BUFF
ADD R3, R3, R1 @ ADR + x
LSR R1, R0, 3 @ y >> 3
MOV R4, 84 @
MLA R3, R1, R4, R3 @ R3=(y>>3)*84+ADR+x
LDRB R1, [R3] @ читаем байт бита
@ новый вариант наложения маски символа (1 - ставим, 0 - стираем)
AND R4, R0, 0x07
ROR R1, R1, R4
RSB R4, R4, 32
BFI R1, R2, 0, 1
ROR R1, R1, R4
STRB R1, [R3] @ запись в буфер
POP {R1, R3, R4}
LCD_PIXEL_exit:
BX LR
прирост скорости 80%!!! (38225 тактов на рисование третьего слайда)
По поводу BIC / BFI — посмотрю, просто сам ассемблер только изучаю, и ресурсов в которых бы понятно объяснялась логика команд в сети от совсем мало до совсем нет (хотелось бы видеть примеры вида: на входе / на выходе, а везде только названия из которых не всегда понятно что они собой представляют) — на счет того что написано по Си-шному — в точку! со своего старого исходника на Си и делал! :-)
Теперь когда у меня появился вывод на LCD — у меня как раз запланировано изучение команд, я наметил себе следующую часть публикации именно по командам, чтобы полностью разобрать какая и как работает…
На счет сохранения регистров — ну по процедурам _INIT согласен, на счет других же — абсолютно не согласен! процедуры тогда и только тогда хороши — когда не нужно думать о том что будет после них… в том же драйвере дисплея есть подпрограммы проверки флагов, управления линиями управления дисплея — вот они регистры не сохраняют, и это уже моя забота была за этим следить… а все что отдается на .global — должно гарантировано не портить регистры (ну по крайней мере где это логично)
А какие из существующих подходят для ассемблера (я не про подсветку кода говорю это как раз низкоприоритетное желание)?
у меня вот получился следующий список желания (я еще не сортировал по очередности и нужности):
1) Подсветка кода ассемблера
2) Авто дополнение вводимого кода (PUSH -> POP, IT — IT Block, и т.д.)
3) Контроль глобальных и локальных меток
4) Подсказка по инструкциям ассемблера
5) Контроль параметров подпрограмм
6) Поддержка программ как модулей с возможностью их добавления и удаления
7) Контроль в редакторе опций условного исполнения
8) Перенаправление сообщений консоли на себя, компиляция и компановка при помощи GNU AS
9) Файлменеджер проекта с крупными значками
10) Закладки в файл менеджере (переход в нужную папку одним кликом)
11) Переход на метку программы в редакторе
12) Автоматическое формирование списка констант модуля и дописывание в начало
13) Система помощи по регистрам настройки микроконтроллера
14) Мастеркода (автосоставитель кода) — например для настройки GPIO, SPI, DCMI и т.д.
15) Эмуляция исполнения кода
16) Настраиваемые окна среды (все! а не только окно редактора)
17) Отладка (пока не понимаю как, но как задача висит)
Теперь когда у меня появился вывод на LCD — у меня как раз запланировано изучение команд, я наметил себе следующую часть публикации именно по командам, чтобы полностью разобрать какая и как работает…
На счет сохранения регистров — ну по процедурам _INIT согласен, на счет других же — абсолютно не согласен! процедуры тогда и только тогда хороши — когда не нужно думать о том что будет после них… в том же драйвере дисплея есть подпрограммы проверки флагов, управления линиями управления дисплея — вот они регистры не сохраняют, и это уже моя забота была за этим следить… а все что отдается на .global — должно гарантировано не портить регистры (ну по крайней мере где это логично)
А какие из существующих подходят для ассемблера (я не про подсветку кода говорю это как раз низкоприоритетное желание)?
у меня вот получился следующий список желания (я еще не сортировал по очередности и нужности):
1) Подсветка кода ассемблера
2) Авто дополнение вводимого кода (PUSH -> POP, IT — IT Block, и т.д.)
3) Контроль глобальных и локальных меток
4) Подсказка по инструкциям ассемблера
5) Контроль параметров подпрограмм
6) Поддержка программ как модулей с возможностью их добавления и удаления
7) Контроль в редакторе опций условного исполнения
8) Перенаправление сообщений консоли на себя, компиляция и компановка при помощи GNU AS
9) Файлменеджер проекта с крупными значками
10) Закладки в файл менеджере (переход в нужную папку одним кликом)
11) Переход на метку программы в редакторе
12) Автоматическое формирование списка констант модуля и дописывание в начало
13) Система помощи по регистрам настройки микроконтроллера
14) Мастеркода (автосоставитель кода) — например для настройки GPIO, SPI, DCMI и т.д.
15) Эмуляция исполнения кода
16) Настраиваемые окна среды (все! а не только окно редактора)
17) Отладка (пока не понимаю как, но как задача висит)
>> на счет других же — абсолютно не согласен! процедуры тогда и только тогда хороши — когда не нужно думать о том что будет после них
Ну как хотите. Используйте стандартный ABI хотя бы. По крайней мере можно будет работать с другими языками.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html
>> у меня вот получился следующий список желания
Ну этого вы до скончания веков будете ждать =)
Ну как хотите. Используйте стандартный ABI хотя бы. По крайней мере можно будет работать с другими языками.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html
>> у меня вот получился следующий список желания
Ну этого вы до скончания веков будете ждать =)
на счет стандартного ABI — спасибо за подсказку, посмотрел, подумаю…
просто на асме я давно программирую (это на ARM недавно стал смотреть по серьездному), и у меня всегда низшие регистры являются расходными…
а вот сколько их будет — я себя не ограничиваю…
на счет списка желаний — если бы нашелся программист на Delpi (я как то очень давно писал на нем немного) и если бы мне хотябы каркас дали — то я бы дописывал потихоньку…
самому конечно разбираться не очень хочется с нуля, потому что тут что то одно — либо в асме разбираешься и максимально погружаешься либо во что то еще…
в принципе список за исключением некоторых пунктов не такой уж и сложный, по крайней мере у меня в голове задача структурируется, и я потихоньку функциональность напишу… но вот что касается интерфейса программы — то тут я точно не смогу :-((( (ну по меньшей мере пока не начну погружаться по серьездному)
просто на асме я давно программирую (это на ARM недавно стал смотреть по серьездному), и у меня всегда низшие регистры являются расходными…
а вот сколько их будет — я себя не ограничиваю…
на счет списка желаний — если бы нашелся программист на Delpi (я как то очень давно писал на нем немного) и если бы мне хотябы каркас дали — то я бы дописывал потихоньку…
самому конечно разбираться не очень хочется с нуля, потому что тут что то одно — либо в асме разбираешься и максимально погружаешься либо во что то еще…
в принципе список за исключением некоторых пунктов не такой уж и сложный, по крайней мере у меня в голове задача структурируется, и я потихоньку функциональность напишу… но вот что касается интерфейса программы — то тут я точно не смогу :-((( (ну по меньшей мере пока не начну погружаться по серьездному)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
STM32F4: GNU AS: Подключение дисплея на PCD8544 (Часть 7)