Много ума не надо чтобы вставить код не по теме.
А вот соптимизируйте ка это
/* 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.
Называть такое риалтаймом совесть надо не иметь.
Тут не идеи нужны, а детерминизм входа и выхода у компилятора. Вот его в C/C++ и нету.
В Python или Java нет никакой специальной оптимизации и ничего живут.
Почему C/C++ не делают компиляцию с максимальной оптимизацией изначально? Вот в чем вопрос.
Думаю ответ в слабости отладочных движков.
А что такое "память процессора" или тем более "иерархии памяти"? Особенно когда в Cortex-M33 грозятся сделать кучу нативных сопроцессоров с огромным числом регистров и расширенной системой команд. Тут IAR легко может сопроцессор использовать под регистры процессора. А это считай та же память доступная DMA.
И тогда volatile ничего конкретно не означает, надо делать исследования.
Или так уверенно заявили про "ассоциативный буфер". А поинтересоваться какую такую память я имел в виду. А может это доступная через два шинных моста HyperRAM? У каждого моста свой буфер.
Когда несколько volatile применяют в одной точке следования - http://alenacpp.blogspot.com/2005/11/sequence-points.html
Хотя в последнее время IAR на это ругается, но пару лет назад вполне пропускал такое.
Потом volatile по отношению к структурам и объектам или просто сложным типам в ARM-ах легко приводит к гонкам. Безопасен только доступ к переменным не длиннее 4-х байт и выровненным.
Потом непонятно как с volatile будет в позиционно независимом коде.
Volatile создает ложное впечатление о прямом доступе к памяти, хотя если работает DMA то это не так. Надо кроме кэша процессора обходить и кэш собственно контроллера памяти, чего volatile не делает.
Короче volatile - это штука для профессионалов.
Если на прикладном уровне выше HAL встречается volatile то это не к добру.
Это все познавательно, но по прежнему не раскрыта интрига: так что это за оптимизации над переменной?
Оптимизируется не переменная, а наверно все таки код вокруг нее.
Так вот как далеко заходят пределы этой консервации оптимизации при встрече с volatile?
Может в этом скрытый смысл поднятой темы?
