Комментарии (7)

1. 

   beeruser

   29.01.2016 13:48

   #8755927

   +1

   >> Все процедуры не портят регистры!
   Какой в этом смысл?
   
   Прелесть асма как раз в том, что не нужно соблюдать стандартный 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
   
   >> кстати, никто не занимается написанием текстовых редакторов? очень хочется среду разработки с…
   
   А чем все существующие не подходят, интересно?

   
   

   1. 

      beeruser

      29.01.2016 19:00

      #8756341

      Опс. Думал про BIC, а написал AND
      BIC R4, R3
      ORR R4, R2
      =)

      
      

      1. 

         VitGo

         01.02.2016 10:58

         #8757515

         Такую проверку координат не хочу:
         

         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]
         

         
         
         постараюсь попробовать сегодня вечером!

   
   

   1. 

      VitGo

      01.02.2016 17:12

      #8757937

      в общем реализовал ваш алгоритм со сдвигом
      
      правда с небольшими уточнениями
      

      .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 тактов на рисование третьего слайда)

1. 

   VitGo

   29.01.2016 14:09

   #8755963

   По поводу 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) Отладка (пока не понимаю как, но как задача висит)
   

   
   

   1. 

      beeruser

      29.01.2016 19:25

      #8756349

      >> на счет других же — абсолютно не согласен! процедуры тогда и только тогда хороши — когда не нужно думать о том что будет после них
      Ну как хотите. Используйте стандартный ABI хотя бы. По крайней мере можно будет работать с другими языками.
      http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html
      
      >> у меня вот получился следующий список желания
      Ну этого вы до скончания веков будете ждать =)
      
      

      
      

      1. 

         VitGo

         29.01.2016 19:50

         #8756363

         на счет стандартного ABI — спасибо за подсказку, посмотрел, подумаю…
         просто на асме я давно программирую (это на ARM недавно стал смотреть по серьездному), и у меня всегда низшие регистры являются расходными…
         а вот сколько их будет — я себя не ограничиваю…
         
         на счет списка желаний — если бы нашелся программист на Delpi (я как то очень давно писал на нем немного) и если бы мне хотябы каркас дали — то я бы дописывал потихоньку…
         самому конечно разбираться не очень хочется с нуля, потому что тут что то одно — либо в асме разбираешься и максимально погружаешься либо во что то еще…
         
         в принципе список за исключением некоторых пунктов не такой уж и сложный, по крайней мере у меня в голове задача структурируется, и я потихоньку функциональность напишу… но вот что касается интерфейса программы — то тут я точно не смогу :-((( (ну по меньшей мере пока не начну погружаться по серьездному)