Организация памяти.

[STM32F0]

когда у вас зрение станет таким,
что вы не увидите 0.25 мм,тогда захотите к старым пикам.DIP.

Какое может быть зрение в моём возрасте? Однако к ПИКам не тянет, от слова совсем. Хотя я с ними и был когда-то на ТЫ (вот же время летит!).

[locik_1]

ню-ню.посмотрим что дальше будет.

[STM32F0]

Да по барабану

... и по литаврам! Сейчас Марк ещё чего выстрелит. И опять себе прямо в ногу!

[my504]

И что изменится? Ну прочитаю ноль с целого порта, какой верёвочкой эРэМВэ к нему привязывать? Ась?


Датышо! Порты это периферия от СТМ и никакого отношения к ядру не имеют. У Ф1хх порты медленнее, у Ф2хх - быстрее. А ядро у них одно и тоже - М3 ! Вот это поворот, да!?

А в чём? В твоих незнаниях?

За умом тебе к доктору или на базар на мясные ряды.

Доступ к портам ничем не отличается от доступа к ОЗУ.
Порты сидят на матрице шин и никаким образом бит не может быть изменён отдельно от порта. Линия выборки одна на минимальное слово доступа, сиречь байт. Фокус с бит-бендингом состоит в формировании псевдоадреса в виде той же маски RMW.
И в этом СТМ ровно такой же АРМ, как и иные производители.

[AR_Favorit]

Да по барабану

и по литаврам!

[STM32F0]

Доступ к портам ничем не отличается от доступа к ОЗУ.
Порты сидят на матрице шин и никаким образом бит не может быть изменён отдельно от порта.

Да неужели? У Ф0 нет битбэндинга, а установка бит порта есть, как и сброс. У одних СТМ гарвард, у других фонньюман. У одних СТМ время установки порта 2 такта, а у других - 1 такт, Карл! А у тебя всё из одной ямы!

Линия выборки одна на минимальное слово доступа, сиречь байт.

Датышо! А мужики из СТМа то и не знали! У них слово 32 бита или 4 байта, как и порты! Всё остальное относится к методам доступа.

Фокус с бит-бендингом состоит в формировании псевдоадреса в виде той же маски RMW.
И в этом СТМ ровно такой же АРМ, как и иные производители.

И что? Так есть там атомарность в атомарности, или нет? уж определись как нибудь!

[H4LF]

то, что стоит до __schedule_barrier(), гарантированно будет выполнено раньше того, что стоит после него.
Там же ссылки на __force_stores() и __memory_changed() (тот же самый барьер плюс гарантированный апдейт в памяти измененных до этого момента переменных, в первом случае внешних для функции, в которой применено, во втором - как внешних, так и локальных).

Спасибо, скачал оттуда DUI0472M_armcc_user_guide.pdf в нём искать проще. Хотя я не настоящий программист и вообще в C нуб, так что не очень понял к какому компилятору это относится... Я сейчас использую GNU Tools ARM Embedded 5.4 2016q3 для STM32F103 и все эти __schedule_barrier() он не понимает. Это для другого компилятора или опции какие-то надо включить?
Зато есть вот эти:

__ISB()
__DSB()
__DMB()
__asm volatile ("" ::: "memory");
__sync_synchronize(); 

Причём первые три - это именно команды процессора (с соответствующей мнемоникой). И они, видимо, как раз для упорядочивания выполнения процессором. Не до конца ясно что и как они делают, но вроде бы понимание начинает приходить...
Четвёртая - барьер компилятора.
Пятая - даже не знаю...

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

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

[H4LF]

Ничего я не перепутал... А while(0) выбрасывается и без оптимизации.
Пример с while - эт для примера того, что Си может делать то, что от него не ожидается, причем один и тот же код может работать по-разному, в отличие от ассемблера. Коль уж разговор о том, какие ошибки можно допустить на Си, которых нельзя сделать на ассемблере.
Тут не только с while проблема. Для не-volatile переменных вообще выброшены арифметические операции, если компилятор видит, что других операций с переменной нет. Может, пример с while был не слишком удачным, но я хотел показать, что ошибки на Си можно делать еще более разнообразные, чем на ассемблере.

Пример не то что неудачный, а совсем ошибочный - компилятор в нём[примере] делает ровно то, что от него[компилятора] ожидается. Даже с пустым while(1), не говоря о полном. Так что плохо получилось показать. И если Вы не перепутали, значит просто не умеете признавать своих ошибок. Или мне попался особенный компилятор(причём и для AVR и для ARM).
А я только заметил, что утверждение - "на ассемблере программы без ошибок" особенно по сравнению с программами на C/C++ и других ЯВУ, просто нелепо.

[AR_Favorit]

Зато есть вот эти:

А про эти я уже и забыл... Да, есть же и процессорные инструкции. Причем функции, генерирующие их в скомпилированном коде, должны работать, даже если целевая платформа этих инструкций не поддерживает (в этом случае они вырождаются в барьеры компилятора).

Вот на эту тему пдф-ка, http://infocenter.arm.com/help/topic...D_acle_2_1.pdf

И эти функции, и те, что я перечислил, по идее, должны присутствовать во всех компиляторах для ARM, но, исходя из написанного выше, возможно, в GNU Tools ARM Embedded исключили фактическое дублирование...

[ilyamp]

Атомарность в STM только через танцы с бубном с использованием регистров установки/сброса бит порта и только на установку или сброс бита, на инверсию не получится. Ребята из STM подстраховались на случай прихода прерывания, разрывающего RMW инструкцию. В ПИКе прерывание RMW инструкцию, кажется, не рвёт, соответственно "атомарность" там такая же при использовании защёлки.