Компилятор не размещает. Размещает линкер. Где будут, а где не будут работать атомарные операции даже в даташитах на микроконтроллеры не найдете.
На самом деле я не собирался тут воевать со стандартом.
Я его не читал и не планирую читать.
И не стоит нагнетать вроде назовите "общие случаи когда нужно нарушать стандарт".
Мысль была о нарушении неких правил безопасности. Тут даже доля метафоричности есть.
Вы легко можете посмотреть в свой код и все это увидеть если вы пишете не под MISRA
В стандарте много чего можно понаписать.
А посмотрев поглубже обнаружишь необходимость ретаргетинга.
Т.е. вы сами и должны реализовывать фишки этого стандарта.
В курсе что атомарность в ARM-ах не на всех областях памяти работает?
Впрочем это тут тоже обсуждалось.
На марсоходе с VxWorks часто происходили зависоны. Оказалось не ставили мьютексы предполагая что запись в простую переменную атомарная.
Я тож люблю полагаться на знание об атомарности или изолированности доступа к переменным. Поскольку синхронизация дорогой процесс.
Первый раз слышу. В IAR не наблюдается зависимости времени компиляции от опции оптимизации.
Не надо так старательно передергивать. TCP стек в Wiznet для вас закрыт и ничего отладить там не можете. W5500 не поддерживает 80 mbit.
Повеселило их традиционное "Not support IP Fragmentation"
Эт вам еще предстоит куда нибудь тыркнутся со свом Wiznet, а он там не будет работать ни в какую.
Не думайте что вы здесь такой Колумб. Wiznet тут обсасывался еще 10 лет назад. Сам на нем обжегся.
80 там поддерживает только 100 ногий жрущий монстр W5300. Но набор протоколов у него никакой. IPv6 даже нет.
Идет с голым Socket API для bareboard.
Делайте выводы.
И еще.
Единственная заявленная совместимость с известными проектами у Wiznet есть только с mbed.
Но там mbed целиком располагается в их чипах W7500 с Cortex-M0.
Т.е. по честному разгрузить сторонний TCP стек с помощью Wiznet так просто не выйдет.
Это не считая невозможности отладки всего что ниже TCP.
Короче как был этот Wiznet довольно нишевым продуктом таким и остался.
Думаю Python к GUI тут за уши притянут.
Опыт применения чего либо в больших конторах, где десятки скрытых мотивов выбора того или иного инструмента ничем не может помочь индивидуальным разработчикам.
Вот реальный простой инструмент создания GUI - https://www.embedded-wizard.de/demo.html
Никаких питонов, скриптов и других сторонних языков. Даже С++ не нужен.
За бесплатно можно получить пакет для Raspberry Pi
Да не стоит волноваться.
uGFX достаточно монструозная система чтобы глаза на лоб вылезли у любого ассемблерного "оптимизатора".
Насколько вижу uGFX умеет использовать для рисования Chrom-Art Accelerator, который есть у некоторых STM-ов
Вот его использование действительно что-то ускорит.
Кстати у i.MX RT есть такая же штука и даже более функциональная, называется Pixel Pipeline (PXP)
Много ума не надо чтобы вставить код не по теме.
А вот соптимизируйте ка это
/* inverse of a 3x3 matrix */
void gl_M3_Inv(M3 *a,M3 *m)
{
float det;
det = m->m[0][0]*m->m[1][1]*m->m[2][2]-m->m[0][0]*m->m[1][2]*m->m[2][1]-
m->m[1][0]*m->m[0][1]*m->m[2][2]+m->m[1][0]*m->m[0][2]*m->m[2][1]+
m->m[2][0]*m->m[0][1]*m->m[1][2]-m->m[2][0]*m->m[0][2]*m->m[1][1];
a->m[0][0] = (m->m[1][1]*m->m[2][2]-m->m[1][2]*m->m[2][1])/det;
a->m[0][1] = -(m->m[0][1]*m->m[2][2]-m->m[0][2]*m->m[2][1])/det;
a->m[0][2] = -(-m->m[0][1]*m->m[1][2]+m->m[0][2]*m->m[1][1])/det;
a->m[1][0] = -(m->m[1][0]*m->m[2][2]-m->m[1][2]*m->m[2][0])/det;
a->m[1][1] = (m->m[0][0]*m->m[2][2]-m->m[0][2]*m->m[2][0])/det;
a->m[1][2] = -(m->m[0][0]*m->m[1][2]-m->m[0][2]*m->m[1][0])/det;
a->m[2][0] = (m->m[1][0]*m->m[2][1]-m->m[1][1]*m->m[2][0])/det;
a->m[2][1] = -(m->m[0][0]*m->m[2][1]-m->m[0][1]*m->m[2][0])/det;
a->m[2][2] = (m->m[0][0]*m->m[1][1]-m->m[0][1]*m->m[1][0])/det;
}
Это функция из библиотеки tinygl для рисования 3D сцен которая подключается к ugfx.
Интересная тема и похоже это будет линукс.
И даже может быть прямой потомок Azure Sphere
GUI массово сдвигаются к WEB технологии.
Так что GUI для малины сейчас пора делать в Muse и Dreamweaver.
Эт вам так кажется.
А посмотрите на пояснение к опции оптимизации "Type-based alias analysis"
Любой код больше 100 тыс. строк будет пургой. Хотя бы потому что его будут писать много людей и в разное время.
Нет смысла пенять на криворуких кодеров.
Опыт говорит - даже минимальный статический анализ выдает гору предупреждений на любой достаточно объемный код.
Потому что в C/C++ если не нарушишь правила безопасности, то не напишешь эффективный код.
Первая попавшаяся статья про тестирование хenomai http://kth.diva-portal.org/smash/get/diva2:1251188/FULLTEXT01.pdf
показывает, что время реакции будет раз так в 100 хуже чем у mbed.
Называть такое риалтаймом совесть надо не иметь.
