one_eight_seven

А почему он вообще игнорирует API? И есть ли вообще тот самый API? Когда мы писали с коллегами ПО для микроконтроллеров, первое, что мы сделали - это был уровень драйверов железа. После него был уровень протоколов, а ПО уже работало c уровнем протоколов. И атомарность, разделение ресурсов, и т.п. были сделаны на низких уровнях. А такой код от программиста выскокого уровня выглядит диковато. Всё-равно что попытка прямого управления устройствами из лузерспейса в линупсах. И ООП тут ни при чём. С другой стороны, может быть ваш руководитель придерживается одного очень мудрого правила: И прямо сейчас даёт вам много времени, чтобы исправить? P.S. для придания культурности дискуссии, можно "сделать через жопу" заменить на "agile".

Это говорит о вас, а не о мипс.

Двухзатворные транзисторы. Реже, конечно, встречаются, чем обычные (оно по-другому и быть не может), но всё-же не экзотика.

https://lmgtfy.com/?q=dexerials+chemical+fuse

Я такого не видел в исполнении компилятора, но на мой взгляд передача данных через CPU будет весьма эффективна с использованием регистров FPU (memcpy, например).

Hennessy, Patterson "Computer Architecture: A Quantitative Approach"

Судя по интернетам, эта проблема - известная для EWARM, решения нет. Понимаю, интересно разобраться и т.п., но вас правда интересует проблема кластеризации и как именно IAR её реализует и использует для оптимизации? Сравните размер кода с этой птичкой или нет, и решите, устраивает ли вас результат без птички. В общем, самое время применить принцип целебного болтополагания.

Выглядит, как неполное цитирование. Наверняка перед этим что-то, навроде #ifdef lint, а второе суперопределение (наверняка, сводящееся к аттрибутам с подчеркиваниями) будет после #else. Ну или у вас неоригинальный файл. Просто настолько маловероятно, что об этом пишется в вопросах и ответах, в документации, а в гугле не находятся проблемы, связанные с __packed, эта проблема решена и в GCC и в IAR, но только в armcc - заявлено, что функционал есть, но по факту он отсутствует.

Ну так и? Греп по установке не показывает заголовочник, где это определено?

Да где же специфика IAR, если я вам прямую ссылку прислал на ARM Compiler'овскую документацию, а там всё очень похоже. Но вы, судя по вашему ответу, отказываетесь делать так, как сказано в документации, и пишете, что это глупость.

вот тут http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html Пишут, что __packed нужна и слева от знака равно, и справа.

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

Согласен, у меня в assert лишнее разыменование. assert( (src & 0x3) == 0 ); Вот когда оно проходит, тогда всё и выровнено. А когда не проходит - происходит невыровненный доступ. А поведение при невыровненном доступе - отдельный разговор. Чуть ниже мы с VladislavS это обсуждаем. Нет. char * p = "aligned"; // assume address is 0x30000000 char * not_necessary_aligned = aligned_p; // 0x30000000 ++not_necessary_aligned; // 0x30000001 char my_char = *not_necessary_aligned; // my_char == 'l' uint_32t my_word = *( (uint_32t*)not_necessary_aligned ); // unaligned access. May cause HF, if core is set to do so

В Cortex-M4 используется AHB-Lite. В ней нет невыровненного доступа. Поэтому, для такого доступа нужно использовать обходные пути. Собственно, поддержка этого в ядре появилась с ARMv6, M4 - это ARMv7, значит, там это есть. Как конкретно это делается, я сказать не могу - у меня нет этого ядра, чтобы посмотреть, что там именно творится на шине. Но также есть и бит в регистрах конфигурации, который вызовет исключение при невыровненном доступе. Не знаю, надо это включать, или это включено по умолчанию. Не исключено даже, что в разных микроконтроллерах эта настройка будет выполнена по-разному. Бит, если что CCR.UNALIGN_TRP.

Это зависит от шины, которую ядро использует для доступа к памяти. Некоторые шины при этом дадут "испорченные" данные, потому, такой доступ, выданный напрямую в шину должен сделать одно из двух - либо вернуть недостовеные данные, либо HF. Другое дело, что есть обходной путь. Если компилятор умеет его делать, то хорошо, если не умеет, то я бы выбрал HF, а не испорченные данные.