[jcxz 186]

1 минуту назад, haker_fox сказал:

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

Я согласен с Rst7. Ошибка с LDREX/STREX слишком груба и очевидна. Причём - противоречит только что приведённой выдержке из какого-то материала, объясняющего работу механизма эксклюзивного доступа.

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

Раз автор допустил её - значит похоже совсем не разбирается в том, о чём вещает. Скорей всего он надёргал материала из каких-то чужих источников (иностранных?), сам толком даже не поняв их. Пользы от таких статей ==0.

[haker_fox 60]

8 minutes ago, jcxz said:

Ошибка с LDREX/STREX слишком груба и очевидна.

Ладно, двое против одного) Сдаюсь)))

8 minutes ago, jcxz said:

Пользы от таких статей ==0.

И всё же нет. Я же смотрю статью полностью. Да, иногда если красивую картину рассматривать вблизи - видны огрехи. Но на той же хабре полно всяких материалов из IT, которые порядком поднадоели. Я имею в виду всякие вебчики, ботики и прочую хренотень. Статьи от "lamerok" и другие подобные отличаются чем-то родным. Да, я иногда люблю почитать хабру. Мозг разгрузить, так сказать.

[AHTOXA 14]

А мне статья понравилась. Ну лажанул автор с LDREX/STREX, бывает. Исправит.

И студентам его всяко повезло больше, чем большинству других, которым до сих пор преподают микропроцессорный комплект КР580.

[haker_fox 60]

10 minutes ago, AHTOXA said:

А мне статья понравилась.

О, нас уже двое) Имхо, "lamerok" активно эксперементирует и это радует.

10 minutes ago, AHTOXA said:

которым до сих пор преподают микропроцессорный комплект КР580.

А по мне так пусть преподают. Но на адекватном уровне. А потом, желательно, переход к современным SoC. Зато будут понятны и шины, и АЛУ и прочая требуха)

[jenya7 0]

1 hour ago, jcxz said:

Пользы от таких статей ==0.

это вопрос :))

1 hour ago, jcxz said:

Пользы от таких статей =0.

а это утверждение :))

[ViKo 1]

В 19.02.2020 в 09:42, DASM сказал:

так же как и от языка "D" и от ИИ вместо программеров, от полетов на Марс, термоядерного пром. реактора, доступных Amoled мониторов , лекарства от всего, .... короче я слишком стар верить в эти сказки ))

Таки вы дождётесь!
https://habr.com/ru/company/yandex/blog/488588/

[Kabdim 0]

23 часа назад, haker_fox сказал:

Так это, наверно, проблема gcc...

Так это нарушение стандарта...

Почему, если в соотвествующем разделе стандарта, всё отдано на откуп того как придумают авторы компилятора? Там не совсем прямолинейно с volatile было, когда сел разбираться всё становилось вполне логичным, а битовые поля всё меньше нравились.

17 часов назад, Сергей Борщ сказал:

Хотелось бы увидеть конкретный пример. Довольно часто работаю с регистрами, описанными как битовые поля и ни разу с подобным поведением gcc не сталкивался. Может я что-то делаю не так, или может что-то не так с вашими примерами?

А я их определяю как union из безымянной структуры с битовыми полями и целого соответствующего размера. Работаю и с полями и с битовыми масками - где как удобнее.

Это довольно сложно, мало того что нужно найти конкретный комит, найти соотсвующее железо - проверить, суметь его как-то миниммизировать причем это все равно оставит вопросы по раскрытию корптайны, так еще как-то понять точную версию gcc с которой это произошло (у нас их много, прошу не спрашивать зачем). Прошу прощения, понимаю ваше желание разобраться и с удовольствием бы поучаствовал бы в этом если бы эта ошибка была у меня здесь и сейчас. Тем не менее тратить время на настолько "остывшую" проблему смысла не вижу. И заметьте, я не говорю что все кто использует битовые поля делают что-то что обязательно приведет к проблемам, а лишь то что по стандарту никто ничего не должен гарантировать по реализции битовых полей.

Тут вы конечно можете сказать что бремя доказательства лежит на утверждающем, а я в свою очередь кивну на куций раздел в стандарте. Который буквально говорит что каждый компилятор может делать что бог на душу положит. И мы конечно же будем правы, каждый на свой манер. :)

21 час назад, jcxz сказал:

Я тут на днях как раз разбирался с USB-device на XMC4xxx. Разбирался по драйверу нижнего уровня IO (xmc_usbd.c) из "XMClib v2.1.6 - XMC Peripheral Driver Library".

Так там вся работа с портами IO зачем-то построена на битовых полях (регистры USB-контроллера определены структурами с битовыми полями). Остаётся только посочувствовать тем несчастным, не заглядывающим внутрь используемых "либ", которые захотят скомпилить сей драйвер с помощью GCC.  

Эти ребята наверное могут практически гарантировать что код будет компилироваться конкретным компилятором и начиня от какой-то конкретной версии. Так что владея такой убежденностью возможно они и правы. Конкретно у них с битовыми полями может и не быть проблем.

[DASM 0]

7 hours ago, ViKo said:

Таки вы дождётесь!
https://habr.com/ru/company/yandex/blog/488588/

да эти уже варятся в своем котле. Я иногда почитываю их хабровские измышления... "и как мы раньше жили без перемщающего присваивания &&" , и как мы жили без лямбд.. Да нормально жили то. Линукс вот вообще на С голом написали, все пользуются и хвалят. А на ваших этих блямбдах много чего? Кровавый рушащийся энтерпрайз написан? Или игры, которые раньше шли на одноядернике 800 мгц, а сейчас с меньшей зрелищностью фпс проседает на 16 ядерном, да вы их и занять не можете? Ну их в баню короче. И да - С++ сейчас - это не столько языковые специи и сладости, сколько тесная связь с STL - а оный в эмбеддед ниже пары хотя бы мегов ОЗУ не пойдет, по причине очень уж непредсказуемого жора этого самого ОЗУ. Все - мое имхо.

[haker_fox 60]

1 hour ago, Kabdim said:

всё отдано на откуп того как придумают авторы компилятора?

Ничего не понял. Что всё?

1 hour ago, Kabdim said:

а я в свою очередь кивну на куций раздел в стандарте.

Ссылочку. плиз. Если всё так, как вы говорите, то невозможно вообще гарантировать работу с регистрами и их полями. Однако, такого не происходит.

1 hour ago, Kabdim said:

а лишь то что по стандарту никто ничего не должен гарантировать по реализции битовых полей.

Да чего там невозможно гарантировать? Битовое поле... всё просто: сверху вниз от младешго бита к старшему.

1 hour ago, Kabdim said:

Прошу прощения, понимаю ваше желание разобраться и с удовольствием бы поучаствовал бы в этом если бы эта ошибка была у меня здесь и сейчас.

Да, желание разобраться есть. Вдруг, действительно, есть что-то неизвестное для нас. Но вы закидали нас шапками, а по делу сказать нечего. Ну как это называется?

[Kabdim 0]

13 минут назад, haker_fox сказал:

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

Напомню что форум это просто место для обмена мнениями, ни у кого нет обязанностей по переубеждению конкретного человека. Да мне сложно представить вам доказательства конкретно моего случая, настолько сложно что я не хочу на это тратить свои ограниченные ресурсы. По-моему это нормально услышав чье-то мнение взять и проверить по томуже тексту стандарта и сделать выводы самому. Ссылки на что? На стандарт и на раздел в нем что ли? А если желание и правда есть, неужто в гугле найти черновик стандарта и по оглавлению нужный разде так сложо?

[Darth Vader 0]

51 minutes ago, haker_fox said:

сверху вниз от младешго бита к старшему.

Вот этого как раз и не гарантируется. Зависит от реализации. Может от старшего к младшему. Как big endian vs little endian.

На счет непрерывности следования битовых полей друг за другом (без зазоров) и расположения строго в последовательности объявления - не помню. Но может тоже быть не стандартизировано. Тогда вообще ни в чем нельзя быть уверенным.

[haker_fox 60]

7 hours ago, Darth Vader said:

Как big endian vs little endian.

Ну это понятно, но я в основном с little endian работаю.

7 hours ago, Darth Vader said:

Тогда вообще ни в чем нельзя быть уверенным.

Кстати, это самое правильное утверждение!

[Kabdim 0]

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Цитата

 

N1570 Committee Draft — April 12, 2011

§6.7.2.1

An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in astructure shall be packed into adjacent bits of the same unit. If insufficient space remains,whether a bit-field that does not fit is put into the next unit or overlaps adjacent units isimplementation-defined. The order of allocation of bit-fields within a unit (high-order tolow-order or low-order to high-order) is implementation-defined. The alignment of theaddressable storage unit is unspecified.

 

Отсюда

Цитата

 

3.14 Memory location:

1. Memory location
   Either an object of scalar type, or a maximal sequence of adjacent bit-fields all having nonzero width

2. NOTE 1 Two threads of execution can update and access separate memory locations without interfering with each other.

3. NOTE 2 It is not safe to concurrently update two non-atomic bit-fields in the same structure if all members declared between them are also (non-zero-length) bit-fields, no matter what the sizes of those intervening bit-fields happen to be.

 

 

 

Собственно вот из-за этого битовые поля c volatile - шляпа, которая не обязана работать так как ожидается. Т.е. никаких гарантий ни с тем как они выравнены, ни с тем что правильно будет работать атомарный доступ.

[haker_fox 60]

22 minutes ago, Kabdim said:

The order of allocation of bit-fields within a unit (high-order tolow-order or low-order to high-order) is implementation-defined.

Как я понимаю, зависит от little или big-endian. Во всяком случае заголовчники для микроконтроллеров строятся на этом принципе и работают. Более того, обмениваемся битовыми полями, изготовленными двумя разными компиляторами: IAR и GCC. Но за документ спасибо!

26 minutes ago, Kabdim said:

которая не обязана работать так как ожидается.

Но, на удивление, работает. А что вы используете вместо полей? Кстати я использую поля активно не только для доступа к регистрам. Очень удобная штука. Пока не подводила.

[esaulenka 5]

On 2/20/2020 at 1:15 AM, Rst7 said:

Там еще и дичь про LDREX/STREX написана

Объясните, пожалуйста. Посмотрел код - вроде б всё правильно работает (избыточно, ну да ладно...).

Я, правда, так никуда этот подход и не применял...