Для окончательного, окончательного ответа на этот вопрос, прыгните прямо вниз к разделу, озаглавленному « Окончательный ответ на мой вопрос ».
ОБНОВЛЕНИЕ 30 октября 2018 года: Я случайно ссылался на (слегка) неправильные документы (но в которых говорилось то же самое), поэтому я исправил их в своем ответе здесь.Подробности см. В «Заметках об изменениях 30 октября 2018 года» в нижней части этого ответа.
Я определенно не понимаю всех слов здесь, но Справочное руководство по архитектуре ARM v7-M ( Интернет-источник ; Прямая загрузка файла PDF ) (НЕ Техническое справочное руководство [TRM], поскольку оно не обсуждает атомарность) подтверждает мои предположения:
Итак ... Я думаю, что мои 7 предположений в нижней части моего вопроса верны.[30 октября 2018 года: Да, это правильно.Подробности см. Ниже.]
ОБНОВЛЕНИЕ 29 октября 2018 года:
Еще один маленький кусочек:
Ричард Барри, основатель FreeRTOS,Эксперт и основной разработчик заявляет в tasks.c ...
/ * Критический раздел не требуется, поскольку переменные имеют тип BaseType_t.* /
... при чтении изменяемой переменной "unsigned long" (4-байтовой) на STM32. Это означает, что он, по крайней мере, на 100% уверен, что 4-байтовые операции чтения и записи являются атомарными на STM32. Он не упоминает чтения с меньшими байтами, но для 4-байтовых операций чтения он абсолютно уверен.Я должен предположить, что 4-байтовые переменные, являющиеся собственной шириной процессора, а также выровненные по словам , имеют решающее значение для того, чтобы это было правдой.
С tasks.c, строки 2173-2178в FreeRTOS v9.0.0, например:
UBaseType_t uxTaskGetNumberOfTasks( void )
{
/* A critical section is not required because the variables are of type
BaseType_t. */
return uxCurrentNumberOfTasks;
}
Он использует эту точную фразу ...
/ * Критическая секция не требуется, потому что переменные имеют типBaseType_t.* /
... в двух разных местах в этом файле.
Окончательный ответ на мой вопрос:
Более того, при более внимательном рассмотрении TRM на p141как показано на скриншоте выше, я хотел бы отметить следующие ключевые предложения:
В ARMv7-M обращения к элементарному процессору в единственном экземпляре:
• все обращения к байту.
• все обращения к полусловам в расположениях, выровненных по полусловам.
• доступ ко всем словам в расположениях, выровненных по словам.
И, для этой ссылки , верно для "базовых типов данных, реализованных в ARM C и C ++" (то есть: на STM32):
bool / _Bool «выровнено по байту» (выровнено по 1 байту) int8_t / uint8_t «выровнено по байту»"(1-байтовое выравнивание) int16_t / uint16_t" выровнено по половому слову "(2-байтовое выравнивание) int32_t / uint32_t "выровнено по словам" (4-байтовое выравнивание) int64_t / uint64_t "выровнено по двойному слову" (8-байтовое выравнивание)) <- NOT GUARANTEED ATOMIC </li> float "выровнено по словам" (выровнено по 4 байта) double "выровнено по двойному слову"(С 8-байтовым выравниванием) <- НЕ ГАРАНТИРОВАННЫЙ АТОМ </li> long double «выровнен по двойному слову» (с 8-байтовым выравниванием) <- НЕ ГАРАНТИРОВАННЫЙ АТОМНЫЙ </li> - все указатели «выровнены по словам» (выровнены по 4 байта)
Это означает, что у меня теперь есть и я понимаю доказательства, которые мне нужны , чтобы окончательно утверждать, что все выделенные жирным шрифтом строки простовыше есть автомatic атомарный доступ для чтения и записи (но НЕ увеличивает / уменьшает конечно, что является несколькими операциями). Это окончательный ответ на мой вопрос. Единственное исключение из этой атомарности может быть в упакованных структурах, я думаю, что в этом случае эти иначе естественно выровненные типы данных могут не выравниваться естественным образом.
Также обратите внимание, что при чтении Технического справочного руководства «атомарность в единственном экземпляре», очевидно, просто означает «атомарность в одноядерном процессоре» или «атомарность в архитектуре с одним ядром».Это в отличие от «атомарности нескольких копий», которая относится к «системе многопроцессорной обработки» или архитектуре многоядерных процессоров.Википедия утверждает, что «многопроцессорность - это использование двух или более центральных процессоров (ЦП) в одной компьютерной системе» (https://en.wikipedia.org/wiki/Multiprocessing).
Моя архитектура, о которой идет речь, STM32F767ZI (сЯдро ARM Cortex-M7) - это одноядерная архитектура, поэтому, как я цитировал выше из TRM, применима, по-видимому, «атомарность одного экземпляра».
Дополнительная литература:
Примечания об изменениях 30 октября 2018 года:
- У меня была эта ссылка: ARMv7 TRM (Техническое справочное руководство), однако это неверно в двух отношениях: 1) Это вовсе не TRM!TRM - это краткое (~ 200 страниц) техническое справочное руководство.Это, однако, «Справочное руководство по архитектуре», а не TRM.Это намного более длинный и более общий документ, поскольку справочные руководства по архитектуре имеют порядок ~ 1000 ~ 2000 страниц, как выясняется.2) Это для процессоров ARMv7-A и ARMv7-R, но руководство, которое мне нужно для рассматриваемого mcu STM32, относится к процессору ARMv7-M.
- Вот правильная ссылка на Техническое справочное руководство по процессору ARM Cortex-M7.Онлайн: https://developer.arm.com/docs/ddi0489/latest. PDF: https://static.docs.arm.com/ddi0489/d/DDI0489D_cortex_m7_trm.pdf.
- Правильный TRM чуть выше, на p99 (5-36) говорится: «Для получения дополнительной информации об атомарности см. Справочник по архитектуре ARM®v7-M».Руководство."Итак, вот это руководство.Ссылка для скачивания онлайн: https://developer.arm.com/products/architecture/cpu-architecture/m-profile/docs/ddi0403/latest/armv7-m-architecture-reference-manual. PDF: https://static.docs.arm.com/ddi0489/d/DDI0489D_cortex_m7_trm.pdf. Здесь обсуждается атомарность на стр. 79-80 (от A3-79 до A3-80).