Ассемблер для STM32. Сложно ли, стоит ли пытаться?

jcxz

GCC и нет проблем.

Думаете - он компилит оптимальнее?

Реклама

SII

Несколько лет назад GCC давал отвратительный код; не думаю, чтобы что-то сильно изменилось. Кейловский (родной, не Кланг) куда лучше выдавал, но там другая проблема: АРМ забила на свой компилятор и переключилась на Кланг, который нередко выдаёт менее качественный код. Вообще, не помнить содержимое регистров и повторно производить загрузки или же заниматься бесполезными пересылками из регистра в регистр -- это нынче норма жизни для компиляторов.

Реклама

NStorm

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

jcxz

NStorm писал(а):

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

Например вот вчера наткнулся:

Код:

 uint c = 3 - Pval(PIN_PRND_F);                        
0xF8D5 0x2524      LDR      R2,[R5, #+1316]       
0xF3C2 0x2280      UBFX     R2,R2,#+10,#+1        
0xF1C2 0x0203      RSB      R2,R2,#+3             
 c -= Pval(PIN_PRND_B) * 2;                       
0xF8D5 0x3624      LDR      R3,[R5, #+1572]       
0x005B             LSLS     R3,R3,#+1             
0xF003 0x0302      AND      R3,R3,#0x2            
0x1AD3             SUBS     R3,R2,R3

Pval() - это у меня макрос чтения состояния одного бита порта GPIO (этот макрос для PIN_PRND_B должен развернуться в
(*(u32 volatile *)IO_ADDR >> 0 & 1).
Как видно - строчку "c -= Pval(PIN_PRND_B) * 2" я написал специально с таким расчётом, чтобы компилятор после LDR сделал всего две команды: выделение бита из считанного слова и вычитание его из c (думал помочь ему :roll:

). Но он зачем-то влепил 3 команды. :facepalm:

Реклама

Эиком - электронные компоненты и радиодетали

VladislavS

jcxz, а можно твой вариант, как ты хотел чтобы было?

Реклама

NStorm

Дык volatile же. Поэтому всё строго. Сначала свдиг, потом И.

Реклама

VladislavS

После чтения из IO в регистр никакого volatile больше нет.

jcxz

VladislavS писал(а):

jcxz, а можно твой вариант, как ты хотел чтобы было?

Ну как минимум для строчки "c -= Pval(PIN_PRND_B) * 2" я ожидал чего-то типа:

Код:

LDR      R3, [R5, #+1572]
AND      R3, R3, #0x1
SUBS     R3, R2, R3, LSL #1

или:

Код:

LDR      R3, [R5, #+1572]
UBFX     R3, R3, #0, #1
SUBS     R3, R2, R3, LSL #1

т.е. - 2 команды, по 4 байта каждая.
А в идеале я конечно хотел бы увидеть:

Код:

LDR      R3,[R5, #+1572]
LSLS     R3, R3, #31
ADDS     R3, R2, R3, ASR #30

т.е. - 2 команды, 2+4 байта. Но на такое я уже не надеялся практически. Так только человек сможет оптимизировать.

Добавлено after 11 minutes 30 seconds:

NStorm писал(а):

Дык volatile же. Поэтому всё строго. Сначала свдиг, потом И.

volatile действует только на операции доступа к памяти - не должен меняться их порядок. А к содержимому регистров отношения не имеет. Что и подтверждается компиляцией того же самого кода в режиме максимальной оптимизации, при которой компилятор создаёт те же самые команды, только вначале ставит обе LDR одна за другой, а потом после - все остальные арифметические команды:

Код:

 uint c = 3 - Pval(PIN_PRND_F);                   
0xF8D5 0x2524      LDR      R2,[R5, #+1316]  
 c -= Pval(PIN_PRND_B) * 2;                  
0xF8D5 0x3624      LDR      R3,[R5, #+1572]  
0xF3C2 0x2280      UBFX     R2,R2,#+10,#+1   
0x005B             LSLS     R3,R3,#+1        
0xF1C2 0x0203      RSB      R2,R2,#+3        
0xF003 0x0302      AND      R3,R3,#0x2       
0x1AD6             SUBS     R6,R2,R3

Это High-Balanced оптимизация (то что выше было на Medium). Как видно - ума она компилятору не добавила, он просто переставил команды и всё.

VladislavS

jcxz писал(а):

т.е. - 2 команды, по 4 байта каждая.

Размер кода тот же. Биться об заклад не буду, но что-то мне подсказывает, что и выполняться он будет за то же время.

Реклама

jcxz

VladislavS писал(а):

Размер кода тот же. Биться об заклад не буду, но что-то мне подсказывает, что и выполняться он будет за то же время.

В смысле "тот же"? Кто с кем?

SII

jcxz писал(а):

VladislavS писал(а):

jcxz, а можно твой вариант, как ты хотел чтобы было?

Ну как минимум для строчки "c -= Pval(PIN_PRND_B) * 2" я ожидал чего-то типа:

Код:

LDR      R3, [R5, #+1572]
AND      R3, R3, #0x1
SUBS     R3, R2, R3, LSL #1

или:

Код:

LDR      R3, [R5, #+1572]
UBFX     R3, R3, #0, #1
SUBS     R3, R2, R3, LSL #1

т.е. - 2 команды, по 4 байта каждая.
А в идеале я конечно хотел бы увидеть:

Код:

LDR      R3,[R5, #+1572]
LSLS     R3, R3, #31
ADDS     R3, R2, R3, ASR #30

т.е. - 2 команды, 2+4 байта. Но на такое я уже не надеялся практически. Так только человек сможет оптимизировать.

Что касается последнего варианта, то он не всегда оптимален: зависит от конкретного варианта конкретного ядра. Дело в том, что многоразрядный сдвиг за 1 такт требует соответствующего сдвигателя, а им могут пожертвовать для уменьшения размеров проца. И тогда LSLS будет сдвигать по одному биту за такт

Зато если есть гарантия, что сдвиг будет за 1 такт, он действительно лучший (те же 2 такта, не считая собственно выборки из памяти, но 6 байтов, а не 8 ).

Мурик

Результат GCC.

Код:

   uint32_t c = 3 - Pval(PIN_PRND_F);
   ldr   r2, [pc, #108]   ; (0x20000338 <main+112>)
   ldr   r3, [r2, #0]
   ands   r3, r1
   rsb   r3, r3, #3

   c -= Pval(PIN_PRND_B) * 2;
   ldr   r0, [pc, #104]   ; (0x2000033c <main+116>)
   ldr   r4, [r0, #0]
   ands   r4, r1
   sub.w   r3, r3, r4, lsl #1

Shuspano

А вот хотел спросить, вообще есть какая нибудь книга, или руководство по программированию этих стм32 на Си, вроде Фрунзе и Магды для 8051, или Ревича и Белова для AVR?
Я так понимаю, про комповый Си (как и про комповый ассемблер) читать бесполезно, там все по-другому.

Eddy_Em

А чем же "комповый" С отличается от "железячного"?
Абсолютно одно и то же!

Shuspano

Eddy_Em писал(а):

А чем же "комповый" С отличается от "железячного"?
Абсолютно одно и то же!

Разьве? Разьве там есть такое?

Код:

        RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);
        GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;
        GPIO_InitStructure.GPIO_Mode  = GPIO_Mode_Out_PP;
        GPIO_Init(GPIOC, &GPIO_InitStructure);

Мурик

Shuspano писал(а):

Разве там есть такое?

Разве в комповом Си нет функций и структур?

То что вы спрашиваете относится не к языку Си, а в библиотеке SPL.

Shuspano

Мурик писал(а):

Shuspano писал(а):

Разве там есть такое?

Разве в комповом Си нет функций и структур?

То что вы спрашиваете относится не к языку Си, а в библиотеке SPL.

Да мне пока без разницы. Щас пока беспокоит вопрос: где и как узнать, что собственно писать, где описаны эти инструкции.

jcxz

SII писал(а):

Что касается последнего варианта, то он не всегда оптимален: зависит от конкретного варианта конкретного ядра.

Мы обсуждаем работу компилятора при создании кода для конкретного ядра CM4F (указанного в свойствах проекта). Компилятор имхо должен проводить оптимизацию под конкретное ядро, а не под коня в вакууме. А в CM4F все использованные команды (кроме LDR) - однотактные.

Добавлено after 15 minutes 29 seconds:

Мурик писал(а):

Результат GCC.

Неправильно скомпилили.
Во-первых: Если посмотреть на тот код, что я приводил, видно что PIN_PRND_B - выделяет 0-й бит из некоего IO-порта, а PIN_PRND_F - 10-й бит из другого IO-порта. у Вас в обоих случаях выделяется 0-й бит. Поэтому компилятор выполнил оптимизацию, видимо поместив #1 в R1.
Во-вторых: Где-то до этого кода должна быть загрузка #1 в R1 (MOVS R1, #1) которую Вы не привели - а это ещё одна команда.
В-третьих: Странно что компилятор у Вас выполнил загрузку #1 в R1, а потом сделал AND с R1. В сумме это требует 3 команды, в то время как с константой #1 в коде команды это можно было сделать за 2 команды. Или у Вас включена оптимизация по размеру, а не по скорости, или выбрано неправильное ядро (не CM3, CM4F).
В-четвёртых: Компилятор у Вас зачем то перегружал повторно указатель, потратив на это лишние команды LDR. Возможно как-то неправильно объявлен указатель на IO-порт. Хотя это уже и не относится к вопросу....

Добавлено after 2 minutes 8 seconds:

Shuspano писал(а):

Да мне пока без разницы. Щас пока беспокоит вопрос: где и как узнать, что собственно писать, где описаны эти инструкции.

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

protoder

>> Читать мануал на желаемый МК, мануал на ядро и посмотреть примеры программ для данного МК. Ну и подучить си конечно.

Я так понял, человек не про это спрашивает. Интересует что-то, где хорошо описывалось бы программирование для STM со всеми его библиотеками и периферией.

Shuspano

Фух... вроде мигает. Да, от знания асма толку никакого вообще. Ну да ладно.
мне вот интересен еще момент. Почему если подпрограмму пишу где нить внизу листинга, а вызываю ее где нибудь вверху, например:

Код:

while (1)
{
...
delay(8000000);
...
}

void delay(uint16_t time)
{}

то транслятор ругается. Транслирует, но в итоге задержка не работает. А в асме это не разу не проблема.