[jcxz 184]

2 минуты назад, Kabdim сказал:

Вы серьезно? Ну не хотите говорить по существу и ладно.

Ну если вы не хотите думать, то говори не говори - толку не будет.

[Kabdim 0]

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

[jcxz 184]

18 минут назад, Kabdim сказал:

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

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

Во-вторых: где именно "грубость и оффтопик"? Если вы продолжаете повторять одно и то же ложное утверждение, сказать об этом - "грубость и оффтопик"???

Цитата

Для остальных, участник форума jcxz утверждал что произойдет ошибка компиляции, но затем переобулся в прыжке.

В чём именно я "переобулся"?

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

 

Ещё раз: Ваш исходный пост вызовет ошибку компиляции. Кроме того в нём содержится ложь, что указанное там выражение скомпилится в одну команду STRB неким мифическим компилятором.

Так понятнее?

Или пруфы в студию: где и как оно скомпилится в одну STRB!

[Kabdim 0]

Линус тоже не любит битовые поля.

@jcxz я вспылил, т.к. для меня это выглядело как редактирование после ответа. Приношу свои извинения. По поводу конкретной расстановки битовыех полей, видимо я плохо запомнил тот случай. По ссылке выше другой пример (я прямо это пишу что бы вы потом не написали что я притяиграю его за уши к своему) где бит филд генерирует байтовые команды.

[Arlleex 131]

10 минут назад, Kabdim сказал:

Линус тоже не любит битовые поля.

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

[Kabdim 0]

19 минут назад, Arlleex сказал:

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

Вообще действительно больше похоже на ошибку.

Вопрос в том какая будет реакция на к примеру:

struct S {

   volatile uint32_t b1:8, b2:1;

}

s.b2 = 1;

 

 

Еще одна забавная особенность с полями volatile. Некоторые компиляторы считают себя вправе их оптимизировать если вся структура не volatile.

[Сергей Борщ 119]

20 минут назад, Kabdim сказал:

А по существу, без придирок?

По существу: каждый сам себе злобный буратина. Цитата из стандарта:

Цитата

6.7.2 Type specifiers

Constraints

5 Each of the comma-separated multisets designates the same type, except that for bitfields, it is implementation-defined whether the specifier int designates the same type as signed int or the same type as unsigned int.

С объявлениями типа 

struct S 
{
    uint32_t b1     : 8;
    uint32_t        : 2;
    uint32_t b2     : 6;
    uint32_t b3     : 2;
};

S volatile s;

проблем не возникает.

[Kabdim 0]

Он ведь что так что так для 32битного контроллера - unsigned int.

[Forger 17]

Должно быть так по идее:

struct S 
{
    unsigned b1     : 8;
    unsigned        : 2;
    unsigned b2     : 6;
    unsigned b3     : 2;
};

 

А еще желательно добавить в код compile time ASSERT на sizeof(S), на всякий случай.

[Сергей Борщ 119]

2 минуты назад, Kabdim сказал:

Он ведь что так что так для 32битного контроллера - unsigned int.

Как видно, для битовых полей почему-то сделано исключение.

[Arlleex 131]

Я, кажется, понял, о чем говорит @Kabdim. ARM Compiler 6.14 (CLang), код

struct S
{
  u32 b : 8;
};

int main(void)
{
  volatile S s;
  s.b1 = 1;
}

дает

MOVS r1, #0x01
STRB r1, [r0, #0x00]

Лечится

struct S
{
  u32 b : 8;
  u32   : 24;
};

LDR  r0, [sp, #0x04]
MOVS r1, #0x01
ORRS r0, r0, r1
MOVS r1, #0xFE
BICS r0, r0, r1
STR  r0, [sp, #0x04]

[jcxz 184]

3 минуты назад, Arlleex сказал:

Я, кажется, понял, о чем говорит @Kabdim. ARM Compiler 6.14 (CLang), код

struct S
{
  u32 b : 8;
};

int main(void)
{
  volatile S s;
  s.b1 = 1;
}

дает

MOVS r1, #0x01
STRB r1, [r0, #0x00]

 

По идее - тоже должно дать ошибку компиляции.

 

PS: Или я один не вижу, что такое b1??? 

PPS: Совсем не собирался грубить ежли что.....

Просто невозможно понять - что имел вв виду автор.

[Arlleex 131]

2 минуты назад, jcxz сказал:

По идее - тоже должно дать ошибку компиляции.

Да просто когда пишу пост, попутно в окошке рядом код, но ради простоты убрал все лишнее в редакторе. s.b = 1, конечно же.

[Kabdim 0]

В целом обсуждение убедило меня в том что запомнившийся момент - ошибка компилятора. Как на память я вляпался в регрессию в версии 4.7 описанную здесь. Почему 4.7 - потому потом в gcc была регресия на размер кода для cortex-m0, из-за чего один из проектов перестал помещатся во флеш и пришлось сидеть на старой версии довольно долго.

Всем спасибо, и повторно прошу извинения за излишнюю эмоциональность. Да я такой. Бит-филды мне по прежнему не нравятся большим кол-вом нюансов, которые нужно помнить и тем что парни из gcc только из недолгого поиска ломали их взаимодействие с volatile 3(!!!) раза. Сидеть на бочке ожидая 4 (или какого там еще) не хочется.

Всем спасибо, особенно за посты по существу ) .

15 минут назад, Arlleex сказал:

Я, кажется, понял, о чем говорит @Kabdim. ARM Compiler 6.14 (CLang), код

Мда, не думал что шланговцы тоже. Хотя 6.14 довольно старая версия.

[Arlleex 131]

Это всего лишь Форум. Всего лишь площадка для общения и выражения мыслей. У каждого участника свой стиль общения, и далеко не всегда через текст можно передать интонацию. Одно и то же (даже безобидное) сообщение можно прочитать с негативным подтекстом и посчитать уже наездом со всеми вытекающими. В этом нет ничего такого странного, на мой взгляд. Более того: при прямом общении с коллегами или кем-то из сферы зачастую споры достигают такого апогея, что никакие форумные перепалки не переплюнут. Это Вы еще @zltigo не застали, или @EvilWrecker (этот еще вроде тусуется иногда тут) - в спорах довольно колкие на язык (но в хорошем смысле) люди. Так что, миру - мир