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

[NewWriter]

А теперь поставьте что-нибудь между { } и посмотрите. Этот код будет безжалостно выкинут, потому что while(1) всегда true.
А теперь напишите
volatile int c;
c = 1;
while(c) { }
, даже не помещая ничего между {}, и посмотрите. А потом уберите volatile и снова посмотрите.

На Си можно набыдлокодить так, что мама-не-горюй, никаким ассемблерам и не снилось. Одни указатели чего только стоят... И особенно это касается расширений стандартного Си - навороченные макросы, атрибуты.

[H4LF]

NewWriter, Я нихрена не понял... Между какими { }?
Если между этими:

while(1)
{
какой-то код
}
другой код, который выкидывается. 

то он не выкидывается ни при каких оптимизациях - именно потому что 1 - всегда true. Иначе я бы заметил - у меня главный цикл так везде сделан.
Вот после него - выкидывается (только что смотрел), что с оптимизацией что без, и правильно выкидывается.
Вы ничего не путаете?

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

[AR_Favorit]

А теперь поставьте что-нибудь между { } и посмотрите. Этот код будет безжалостно выкинут, потому что while(1) всегда true.

Это вы с while (0) {...} перепутали

[H4LF]

AR_Favorit, и, видимо, с циклической(необязательно) проверкой не volatile переменной, которая может неожиданно для компилятора измениться - например в прерывании или в другом потоке в случае RTOS. Это как раз очень предсказуемо. Меня больше беспокоит синхронизация в условиях изменения порядка исполнения компилятором и даже процессором. Как то не очень представляю куда, как, в каких случаях и какие барьеры нужно вставлять... чтобы точно не получить какой-нибудь редкий гейзенбаг. Хорошо ещё, что нет необходимости так писать - всё только из интереса.

[my504]

многие современные микроконтроллеры оптимизированы для C и писать под них на ассемблере как-то не очень удобно.

Все с точностью до наоборот. Чем больше архитектура оптимизирована под С, тем проще писать на ассемблере. Патамушта на ассемблере нужно соблюдать все те же соглашения и правила, что и на Си. Только вручную. И без избыточного кода, который склонен генерировать компилятор с полным сохранением возможности отладки.

[AR_Favorit]

Меня больше беспокоит синхронизация в условиях изменения порядка исполнения компилятором

то, что стоит до __schedule_barrier(), гарантированно будет выполнено раньше того, что стоит после него.

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

Ну и невыкидываемый оптимизатором __nop(), который помимо собственно вставки NOP делает то же, что и __schedule_barrier().

и даже процессором

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

[NewWriter]

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

Другое дело, что пишут на нём намного меньшее количество людей, а кто ещё пишет - тот хоть с какой-то квалификацией, иначе сложнее мигания трудно что-то написать.

Ну я раньше на асме для пиков писал, и не только мигание светодиодами, но и с графическими дисплями. По большому счету, не шибко сложно, просто объем текста большой.
...PS.. О, все-таки нашел фотку - чистый ассемблер для пика, графика, текст, все навороты

Да и просто чтобы найти какую-нибудь программу написанную на асме для ARM - придётся потрудиться.

Где-то попадались, чел че-то пытался писакать там. Но как понял, дальше включения таймеров и мигания свдиодами это не пошло. Да и смысл напрягаться то. Можно делать короткие ассемблерные вставки в Си.

[STM32F0]

Чем больше архитектура оптимизирована под С, тем проще писать на ассемблере.

Марк, не гони! Твоя тяга к ассемблеру, из-за упоротой привязанности к ПИК24-33, здесь совсем ни при чём. Сейчас АСМ уже как дурной тон. Нафиг-нафиг!

[STM32F0]

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

На сайте АРМа вроде же всё растолковано что для чего.

[my504]

Марк, не гони! Твоя тяга к ассемблеру, из-за упоротой привязанности к ПИК24-33, здесь совсем ни при чём. Сейчас АСМ уже как дурной тон. Нафиг-нафиг!

Во первых, если я ничего не напутал, это ветка про ПИКи.
Во вторых, я отвечал на конкретную ЛОЖНУЮ сентенцию об усложнении применения АСМа при Си-ориентированной системе команд и архитектуре.
Ну и в третьих, каждый сам решает для себя по поводу целесообразности применения той или иной платформы, производителя и тулчейна. Упоротость в АРМ, причем конкретно СТМ, столь же смешна, как и любая другая упоротость...