-
Постов
739 -
Зарегистрирован
-
Посещение
-
Плавный переход C -> C++ под МК
Kabdim ответил Arlleex тема в Программирование
Спасибо на добром слове. ) Обоих застал и даже успел с zltigo обменятся любезностями. Спорить люблю. Но предпочитаю побеждать не умением спорить, а силой знаний. ) -
Плавный переход C -> C++ под МК
Kabdim ответил Arlleex тема в Программирование
В целом обсуждение убедило меня в том что запомнившийся момент - ошибка компилятора. Как на память я вляпался в регрессию в версии 4.7 описанную здесь. Почему 4.7 - потому потом в gcc была регресия на размер кода для cortex-m0, из-за чего один из проектов перестал помещатся во флеш и пришлось сидеть на старой версии довольно долго. Всем спасибо, и повторно прошу извинения за излишнюю эмоциональность. Да я такой. Бит-филды мне по прежнему не нравятся большим кол-вом нюансов, которые нужно помнить и тем что парни из gcc только из недолгого поиска ломали их взаимодействие с volatile 3(!!!) раза. Сидеть на бочке ожидая 4 (или какого там еще) не хочется. Всем спасибо, особенно за посты по существу ) . Мда, не думал что шланговцы тоже. Хотя 6.14 довольно старая версия. -
Плавный переход C -> C++ под МК
Kabdim ответил Arlleex тема в Программирование
Он ведь что так что так для 32битного контроллера - unsigned int. -
Плавный переход C -> C++ под МК
Kabdim ответил Arlleex тема в Программирование
Вообще действительно больше похоже на ошибку. Вопрос в том какая будет реакция на к примеру: struct S { volatile uint32_t b1:8, b2:1; } s.b2 = 1; Еще одна забавная особенность с полями volatile. Некоторые компиляторы считают себя вправе их оптимизировать если вся структура не volatile. -
Плавный переход C -> C++ под МК
Kabdim ответил Arlleex тема в Программирование
Линус тоже не любит битовые поля. @jcxz я вспылил, т.к. для меня это выглядело как редактирование после ответа. Приношу свои извинения. По поводу конкретной расстановки битовыех полей, видимо я плохо запомнил тот случай. По ссылке выше другой пример (я прямо это пишу что бы вы потом не написали что я притяиграю его за уши к своему) где бит филд генерирует байтовые команды. -
Плавный переход C -> C++ под МК
Kabdim ответил Arlleex тема в Программирование
Заканчивайте уже со своей грубостью и оффтопом. Я вам больше не отвечаю, просто что бы не нарушать правила форума. Ну и править свои посты на которые уже написаны ответы - моветон, без обозначения правок. Для остальных, участник форума jcxz утверждал что произойдет ошибка компиляции, но затем переобулся в прыжке. -
Плавный переход C -> C++ под МК
Kabdim ответил Arlleex тема в Программирование
Вы серьезно? Ну не хотите говорить по существу и ладно. Для остальных открыты двери любого компилятора что бы подтвердить правоту одного или второго участника. -
Плавный переход C -> C++ под МК
Kabdim ответил Arlleex тема в Программирование
Поправил. А по существу, без придирок? Этот кейс кстати тоже забавный, без волатайл безымянное падинг поле можно, а с волатайл уже разом нельзя - логика. -
Плавный переход C -> C++ под МК
Kabdim ответил Arlleex тема в Программирование
Пардоньте мой пАфОс, я постараюсь не ослабять его поводок :] . Если есть конструкция вида struct S { volatile uint32_t b1 : 8, tempSpecialFor_jcxz: 2, b2 : 6, b3 : 2; }; S s; s.b2 = 3; то вот эта конструкция может сделать strb вместо перезаписи всего слова. -
Плавный переход C -> C++ под МК
Kabdim ответил Arlleex тема в Программирование
Слушайте, я в bit fields вляпался Н лет назад, с красноглазым разбором оптимизированного ассемблера. Мне хватило. К сожалению я не охотник и трофеи исходников не вывешиваю на стене что бы потом всем показывать. Давайте начнем с того что порядок битов в слове может быть любым по стандарту. И то что при записи в битовое поле компилятор волен выбирать байтовую запись даже если поле в стоставе volatile uint32_t. -
Плавный переход C -> C++ под МК
Kabdim ответил Arlleex тема в Программирование
Комитет не избавлялся ни от чего. Напомню что ++ ответивились от C98. И потом комитет лишь добавлял то что появлялось в последующих сях, а иногда не добавлял. Вопрос насчет разницы между конструкциями С и С++ очень интересный и в нём много интересных мозгокрутящих моментов. Но с практической точкии зрения мало нужный, считайте что ++ почти совместимы (за исключением именованных инициализаций, массивов переменной длинны в аргментах и тд). По поводу именовванных инициалзаций, понять комитет вполне возможно. Вместо них используйте конструкторы. Еще советую навсегда забыть про битовые поля (особенно в комбинации с volatile), если нет желания прыгать на граблях. -
Да, пожалуй вы правы. Нашел тред посвященный вопросу, там упоминается регистр ACTLR для stm, в котором (как утверждает автор поста) можно отключить прерывние strd. Регистр vendor-specific, а jcxz не указал какого производителя он использует, так что подойдет ли ему этот рецепт сказать невозможно.
-
Мне кажется что в не кастомизированом ядре strd будет атомарным в желаемом jcxz виде.
-
Тогда ваша проблема похоже не решается без ассемблерных вствок, потому как с точки зрения стандарта поведение компилятора на этот код - полностью правильное в обоих случаях, никаких гарантий "атомарности" всех присваиваний язык не дает.
-
Атомик будьте добры, протестируйте. Мне это интересно. Больше чем то что я неправильно угадал вашу цель в условиях вашего молчания по её поводу. :)