Jump to content

    

Kabdim

Свой
  • Content Count

    739
  • Joined

  • Last visited

Community Reputation

0 Обычный

1 Follower

About Kabdim

  • Rank
    Знающий

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

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