Изучаем STM32 Cortex M3

[omercury]

а если - "специальной инструкцией"

откуда тогда операторы сдвига?

на одну строчку промахнулись (выходные же)

Да вроде не промахнулся.
Там эти команды есть и на них указано количество тактов на инструкцию. И сносочка "с". Вот расшифровка этой "с" и есть пункт 3.3.2, с примерами.
А "как повезёт" означает всего лишь выполняются инструкции конвейерно либо нет. Соответственно скорость выполнения их будет разной. В случае последовательного чтения/записи либо потокового чтения либо записи вы экономите по такту на каждую следующую после первой инструкцию.

[tempora]

откуда тогда операторы сдвига?

Какие ещё операторы сдвига? При пересылке данных, сдвиги?

[omercury]

При пересылке данных, сдвиги?

Ну хватит уже изворачиваться.
Вы прекрасно поняли, что пересылка тут ни при чём.

[nahimovv]

Какие ещё операторы сдвига? При пересылке данных, сдвиги?

Хорошая практика, кстати! Ускоряет заметно! Можете проверить самостоятельно.

[tempora]

Ну хватит уже изворачиваться.
Вы прекрасно поняли, что пересылка тут ни при чём.

Это, пардон, кто изворачивается?! И как она может быть "ни при чём", если именно её эффективность для данных разного размера и вызвала вопросы?!
Вопрос был задан - именно о пересылке данных. Меня стали уверять, что данные выравненные на границу, пересылаются отнюдь не с одинаковой эффективностью:

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

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

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

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

- Расскажите нам о рыбах.
- У рыб нет шерсти... но если бы она у них была, то в ней водились бы блохи. А блохи - это такие ................

Ну так, и кто изворачивается?
Вам, повидимому, "ноблесс" местного знатока не позволяет признать свой промах. Ладно, не буду настаивать - мне это неважно. А ответ, пусть косвенно, всё же прозвучал. И на том спасибо.
Всего доброго.

[nahimovv]

"Сама сказала, сама обиделась! (С)
tempora, чего вас колбасит? К чему все эти ковыряния в тактах? Может и имя байтам давать начнёте? Типа, "Байт Васю послали на...".
Напишите что-то простое, осознанное и поиграйтесь с размерностю, сразу всё станет ясно. А то читать ваш бред про выравнивание, ну ей богу смешно. Выравнивать нужно там, где это к месту, иначе утоните в собственном мракобесии, а лучше не станет.

[tempora]

чего вас колбасит?

Странный вывод... или - удобный кому-то?

Меня не колбасит, я отвечал Dosikus'у сотоварищи на их предположение, что битовые поля не у дел, и что они - "синоним" булевой переменной. Отвечал, поскольку оба эти предположения неверны. Вы вмешались в этот разговор со своей собственной темой про эффективность операций, а теперь заявляете, что это сделал я:

ваш бред про выравнивание

Смешно, ей богу.

Но я к этим обвинениям отношусь спокойно, колбасит, со всей очевидностью, кого-то другого.

[nahimovv]

Смешно, ей богу.

Соглашусь, пожалуй, с:

Ну хватит уже изворачиваться.

[omercury]

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

Итак, смотрим...

Смотрите!

Попробовал сам. Keil 5.1.0.0 + STM32F103ZET6
Симулятор 8/16/32 бита соответственно
2260
2258
1258
Житаг от Сеггера в камне
3016
2507
1759
Симуляцию в железе, я думаю, можно опустить, так как что оно там насимулировало, вряд ли кому ведомо...
Итого в сухом остатке разница есть, но не такая убийственная. Для первых двух пациентов на уровне погрешности (nop вероятно посчиталься), а у третьего виден явный отрыв, что и неудивительно, глядя на результат компиляции.

    24: __NOP(); 
    25:      
    26: while(f) 
    27:  { 
    28:   f--;    
    29:  }         
    30:  
0x08000384 E001      B        0x0800038A
0x08000386 1E40      SUBS     r0,r0,#1
0x08000388 7008      STRB     r0,[r1,#0x00]
0x0800038A 7808      LDRB     r0,[r1,#0x00]
0x0800038C 2800      CMP      r0,#0x00
0x0800038E D1FA      BNE      0x08000386
    31: __NOP(); // 1249 cycles    
    32:   
0x08000390 BF00      NOP      
    33: while(g) 
    34:  { 
    35:   g--;    
    36:  }      
    37:  
0x08000392 E001      B        0x08000398
0x08000394 1E40      SUBS     r0,r0,#1
0x08000396 8048      STRH     r0,[r1,#0x02]
0x08000398 8848      LDRH     r0,[r1,#0x02]
0x0800039A 2800      CMP      r0,#0x00
0x0800039C D1FA      BNE      0x08000394
    38: __NOP(); // 1500 cycles 
    39:   
0x0800039E BF00      NOP      
    40: while(h) 
    41:  { 
    42:   h--;    
    43:  }      
    44:   
0x080003A0 6848      LDR      r0,[r1,#0x04]
0x080003A2 E000      B        0x080003A6
0x080003A4 1E40      SUBS     r0,r0,#1
0x080003A6 2800      CMP      r0,#0x00
0x080003A8 D1FC      BNE      0x080003A4
    45: __NOP(); // 1000 cycles 
    46: 

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

Вам, повидимому

Вот Вам и по-видимому...

tempora, приношу извинения за неверно интерпретированный вопрос.
В общем случае пересылка происходит одинаково, но варианты таки есть...

Да, и вот такая оговорочка попадается...

The number of cycles required for a pipeline refill. This ranges from 1 to 3
depending on the alignment and width of the target instruction, and whether the
processor manages to speculate the address early.

[tempora]

Да, и вот такая оговорочка попадается ...

Ещё бы не вытряхивать конвейер, если PC модифицируется. Но это, особый случай, я бы не стал ставить его в один ряд с обычным обменом с памятью.

Так вот, по поводу битовых полей, с высказываний о которых Артём'а, Dosikus'а, и, насколько помню, KBH-I это ответвление началось.
Почему-то, когда речь заходит о битовых полях, все помнят только формат ":1", который и в самом деле имеет сходное с bool и флагами применение:

в каком-то смысле bool тоже битовая переменная: возможные значения - true/false. Битовая: 1/0.

(хотя в примере, им же процитированном, было поле со значениями [0..3] )

Под те же флаги переменную состояния ...

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

Нет в Си никаких битовых переменных.

А это тогда что?

Код:

struct { uint16_t Work :1; ... } bits;

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

union {
    uint_16t      Word;
    struct  {
        uint_16t  LUN :6,           // Logical Unit Number
                  Sgnl:6,           // Signaling index
                  Cmd :4;           // Command code
    };
} ControlBus;

        // initialize LUNs
        ControlBus.Word = 0;
        ControlBus.Sgnl = WAKEUP;
        for (ControlBus.LUN = 0; ControlBus.LUN ‹ LUNs; ++ControlBus.LUN){          // enumerate LUNs

            ControlBus.Cmd = cmdPWRUP;                      // send "power LUN up ...
            SendToBus(ControlBus.Word);                     // command"
            ControlBus.Cmd = cmdFUNCL;                      // send "get LUN ready ...
            SendToBus(ControlBus.Word);                     // command"
        }

        // check for all LUNs/Signals are functional
        bErrState = false;
        for (ControlBus.LUN = 0; ControlBus.LUN ‹ LUNs; ++ControlBus.LUN){          // enumerate LUNS
            for (ControlBus.Sgnl = 0; ControlBus.Sgnl ‹ SGLs; ++ControlBus.Sgnl){   // enumerate signals

                ControlBus.Cmd = cmdQRY;                    // query LUN's error state ...
                SendToBus(ControlBus.Word);                 // command
                if ( bErrState |= ReadBus(ControlBus.Word) )// collect result
                        ReportLunErr(ControlBus.Word);      // report error
            }
        }

Использовать битовые поля в качестве флагов и я не стану, а вот в таких ситуациях, как выше, они бывают весьма полезны, прежде всего - с точки зрения чистоты кода и его сопровождения.
Что касается потерь производительности - на этапах чтения такой структуры и её записи, потерь производительности быть не должно, если данные выравнены на границу слова. Как я понимаю, вы это подтвердили (или по крайней мере OMercury подтвердил).

А обработка...

В каких-то вариантах использование битовых полей может не отличаться по эффективности - всё равно же сдвиги на границы отдельных битовых полей будут. Даже если пользоваться int'ами, а не битовыми полями - те же самые сдвиги придётся повторить перед выводом в порт, на котором висит устройство, понимающее структуру типа ControlBus. Да и счетчики циклов могут быть промежуточными int'ами, в общем, есть варианты.

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

Вот о чём я в действительности собирался сказать¹, пока не налетели некие товарищи, отягощённые своим величием. Не обижайтесь.

_______________________
¹

Скорость работы кода не единственный и чаще всего не главный критерий. ... А вот отсутствие ошибок, самодокументируемость, модифицируемость, переносимость - это даа...