Изучаем STM32 Cortex M3

[tempora]

Сообщение от tempora

Так в чём-таки разница?

В командах.

Очень интересно, можно уточнить, где именно она находится?
Ищу отличия, вариант 1:

• "CMP R5,#+0"
• "CMP R6,#+0"
• "CMP R7,#+0"

вариант 2:

• BEQ.N ??main_1
• BEQ.N ??main_3
• BEQ.N ??main_5

вариант 3:

• SUBS R5,R5,#+1
• SUBS R6,R6,#+1
• SUBS R7,R7,#+1

вариант 4:

• B.N ??main_0
• B.N ??main_2
• B.N ??main_4

Хотите сказать, что инструкции в группах исполняются за разное время?

А вообще, любой МК работает лучше с той разрядностю данных, для которой он и предназначается, в случае STM32 это 32 бита.

На уровне "вообще" - согласен. А вот в частностях пока ясность не достигнута.

[nahimovv]

А UXTB, UXTH и ---- куда делось?

[omercury]

А вот в частностях пока ясность не достигнута.

Да просто логику включить.
Не умеют МК делать математические операции с половиной или четвертью регистра...

[tempora]

А UXTB, UXTH и ---- куда делось?

Замечательно. Итак, одинаковые инструкции исключаем из рассмотрения и с оставшимися UXT* разберёмся.
Выходит, что в них каким-то образом заключается ответ на вопрос, появившийся в начале этой ветки темы:

Речь шла о пересылке по шине, какие команды в связи с этим нужно посмотреть?
Пересылка данных выравненных на границу, кратную ширине шины, будет одинаково эффективна для байта, слова и полуслова

Неужели? Накидайте простой пример, тот же цикл, и посмотрите.

Согласно совету, я накидал три цикла с обращениями к трём массивам (байтов, int-ов и битовых полей), но там команды доступа к элементам массивов оказались одинаковыми.
Пришлось повторить свой вопрос:

... смотрим...
Получилось такое сравнение: ...
Что здесь такое разное в пересылке элементов массива? На что нужно было обращать внимание?

Ответ был дан в виде куска кода, вообще без доступа к памяти - ведь UXTB, UXTH лишь приведение к слову, не так ли?
Так всё-таки, если Вы утверждаете, что выравнивание байтовых, словных и полусловных переменных на 4-х байтовую границу не уравнивает эффективность доступа к таким переменным, то поясните, почему это так?

Да просто логику включить.

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

[omercury]

Тогда может быть Вы дадите ответ на вопрос о разнице в эффективности доступа к выравненным переменным?

Легко.
МК STM32 оперирует словом шириной в 32 бита. Ни больше, ни меньше.
Для того, чтобы выполнить какие либо действия с переменной шириной менее этого значения, её необходимо переместить в свободную ячейку памяти либо регистр. Далее её необходимо выровнять, для чего служат операторы циклического сдвига, влево или вправо, не суть. Ядро построено таким образом, что осуществляет операцию сдвига на произвольное количество бит за один такт. Это выравнивание. Далее осуществляется действие над переменной, обратное выравнивание и перенос её в исходное хранилище.
Здесь мы и получаем различие в выполнении команды.
Ядро STM32 может выполнять некоторые операции с данными непосредственно в ячейке памяти, а некоторые только в РОН. Отсюда и разница во времени выполнения Ваших СИшных инструкций.

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


P.S.
Неважно, насколько выровнена переменная по отношению к байту - её выравнивание происходит за одинаковое время для кратного и некратного байту значения. Главное, чтоб оно было кратно единице, которой оперирует ядро, а это 32 бита или 4 байта. Для максимально возможной скорости выполнения кода, Вам желательно придерживаться этой ширины, но тут возникает другая засада - за переполнением чисел шириной меньше 32-х бит надо следить вручную... Вот и выбирайте - либо всё "летает", но Вы самостоятельно следите за типом переменных, либо отдаёте это на откуп компилятору, но миритесь с полуторакратной "тормознутостью" всего кода...

[tempora]

Неважно, насколько выровнена переменная по отношению к байту

Вообще-то, речь шла о выравнивании на границу именно слова, а не байта.

её необходимо переместить в свободную ячейку памяти либо регистр. Далее её необходимо выровнять ...

И таки речь шла о данных, уже выравненных на словную границу.

Для того, чтобы выполнить какие либо действия с переменной шириной менее этого значения,

Речь шла не об обработке данных, а только о пересылке их:

Сообщение от tempora

... Пересылка данных выравненных на границу, кратную ширине шины, будет одинаково эффективна для байта, слова и полуслова.

Неужели? Накидайте простой пример, тот же цикл, и посмотрите.

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

[omercury]

И таки речь шла о данных, уже выравненных на словную границу.

Откуда Вы об этом узнали?
От Прокруста?

Речь шла не об обработке данных, а только о пересылке их:

Теоретически, они могут находиться в нескольких ячейках

О том, что обработка переменных разного размера может занимать разное время, я, слава богу, знаю

Ну мало ли...
Выходные.

[tempora]

Откуда Вы об этом узнали?

Если Вы вдруг не заметили (выходные же), я автор этого условия, поэтому мне узнавать не потребовалось. Повторю ссылку:

Сообщение от tempora

... Пересылка данных выравненных на границу, кратную ширине шины, будет одинаково эффективна для байта, слова и полуслова.

Неужели? Накидайте простой пример, тот же цикл, и посмотрите.

Теоретически, они могут находиться в нескольких ячейках

При условии выравнивания на границу слова, это также не повлияет - для данных не превышающих одного слова - одно обращение к памяти, для данных до двух слов размером - два обращения и так далее.

[omercury]

При условии выравнивания на границу слова

Вы их лично выравнивали?

для данных не превышающих одного слова - одно обращение к памяти, для данных до двух слов размером - два обращения и так далее.

А это как повезёт...
http://infocenter.arm.com/help/index.../CHDDIGAC.html

[tempora]

Вы их лично выравнивали?

Что значит "лично"? Если это значит "вручную", то нет конечно, а если - "специальной инструкцией", то есть варианты:

• для битовых полей это обычно выполняется автоматически, т.к. их базовый тип имеет именно такое выравнивание,
• для более сложных ситуаций существуют директивы выравнивания #pragma data_alignment, #pragma pack и модификатор __packed.

А это как повезёт...

За ссылку спасибо. Я так понимаю, Вы на одну строчку промахнулись (выходные же) и на самом деле хотели указать на "3.3.2 Load/store timings", так? Я там никаких "как повезёт" не нашёл.
Правда, я уже тоже успел вкусить от выходных, поэтому завтра посмотрю ещё раз (на свежую голову), но пока вижу только пенальтиз от обращения к невыравненным на границу слова данным:

Unaligned word or halfword loads or stores add penalty cycles. A byte aligned halfword load or store adds one extra cycle to perform the operation as two bytes. A halfword aligned word load or store adds one extra cycle to perform the operation as two halfwords.
A byte-aligned word load or store adds two extra cycles to perform the operation as a byte, a halfword, and a byte.