У меня в тестовой прошивке есть такой небольшой чудный кусочек кода:


Назначение этого кусочка - протестировать работу соответствующего обработчика исключения. Код прекрасно отработал на S3C44BOX, S3C2410, IXP42x, SAM7xx, PXA2xx/3xx и много лет все было чудесно. И вот, "понимаете, в машине в которой мы ехали, случайно, совершенно случайно, оказался цемент" ©. Я "совершенно случайно" запустил этот код на LPC2388, и... не увидел свой любимый "ODD ADDRESS TRAP".
Смотрим документацию, "усер мануал" на LPC23xx вообще не содержит слова "unaligned". В-общем, красота - при невыравненном адресе - на LPC23xx читается/пишется переставленный мусор, и все это МОЛЧА. Такая низость в самом деле имеет место, или я чего-то недопонимаю?

Имеет, еще на LPC21xx налетал. Впрочем, это не низость, а скорее вариант нормы

Я бы сказал, что это - весьма и весьма "нетрадиционный" "вариант нормы". Норма - это список ARM-ом в моем первом посте. А так выглядит как очередная подляна от NXP, причем - совершенно необъяснимая . Само исключение есть, генерируется извне ядра контроллером шины, почему бы не проконтроллировать еще и адрес - непонятно .
P.S. Надо будет на их новые Кортексы глянуть - может там исключение добавили.

в кортексах вообще нет проблемы обращения к невыравненным адресам

Да есть такая фигня при чтении.
Посмотрите еще и запись.

Угу, спасибо - заинтересовался и посмотрел, наконец, описание M3 - ничего, вкусненько. Будем ждать LPC17xx.

У меня есть файл arm7tdmi_instruction_set_reference.pdf, там написано следующее:

Именно это я подразумевал под словом "переставленный". Для ARM7TDMI, который работает только в LE - будет такой вариант как Вы отцитировали. Для старших ARM-ов работающих в BE/LE вполне могут быть и отличия.
В любом случае - в результате невыравненного доступа получаем отнюдь не тот результат какой ожидали, а поскольку исключения нет - то "дорогая не узнает, какой у парня был конец" ©. Очень весело отлавливать такие проблемы при портировании 200К строк С-шного кода с 8-битника, например. NXP - "низачот", первый раз такой облом вижу. В 70-ых на PDP такое счастье как OAT было, а вот в 21-ом веке - не судьба.

А Вы ожидайте "правильный" (в соответсвии с абзацем, который я процитировал). Вдруг Вам так и надо было. "Такие дела" ©.

Сообщение отредактировал meister - Jan 16 2009, 09:05

Вообще-то "это отлаживать" - Вам "низачет", ибо нужно не с последствиями бороться а банально этои 200К строк (кстати для 8bit это число строк кода СИЛЬНО СИЛЬНО надуманное - "урежте осетра" как минимум на порядок, тогда еще где-то в 64-128K бинарника поверю ) хоть мельком, но просмотреть. И вообще с этим хорошие компиляторы хорошо справляются - warning-ов хватает, если, конечно перворначальный код не совсем через заденпроходное отверстие писан, но незачем такое и портировать.

Тут странное дело - когда давно поверял работу своего обработчика exception на чем-то вроде LPC2114 - точно работало, а потом на свежих чипах как-то исчезло, хотя недавно переписывал слегка и некоторым удивлением обнаружил, что на одном из китов с LPC2148 тоже отработал!

Я прочитал как 200KB
200K строк действительно многовато.



Компиляторы не помогут когда адрес вычисляется диамически.
Например, сравнение IPшника приятого пакета с сетевой маской.

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

Увы, не надуманное. "У меня линейка есть" - поэтому я абсолютно спокоен.
Самый старый проект был начат в 1992-ом, пережил asm x86, BCC3.1, Watcom, IAR AVR 1.30, IAR MSP, Softune LX16, GCC ARM, GCC PPC, сотни две вариаций и моделей, десяток языков (рус, укр, англ, нем, ...), сотни флагов условной компиляции. Так что 200К - это весьма и весьма скромно, могу Вас заверить. Много лет это "утаптывали ногами" в 128К меги - ей просто не было даже близкой конкуренции по цене, и там _очень_ много финтов направленных на "лишь бы влезло" и "хто украл 10 байт RAMы" - хроника одного байта - во всей красе. На проектах на ARM-ах - еще веселее - 200K - " это только лицо" ©, т.е. приложение. Сейчас моя "зона ответственности" - системный софт - HAL + TN + TCP + FAT + USB-host за 100К грозит играючи перейти. Впрочем, сложность - понятие относительное, посмотрим на исходники Линукса - там никакой "линейки" хватит.


Да это все понятно, компилятором ловится 95% проблем, потом на других ARM-платформах отловили еще 3-4%. А вот вчера меня программеры ткнули носом в листинг - "ldrh R0, [R4, #0x209]" и спросили - "почему бнопня лезет?". И пришлось мне, "случайно, совершенно случайно", стряхнуть пыль с теста обработчика исключения. Профтыкал-с, признаю. И вот этот оставшийся 1% - самое трудное. В сумме несколько десятков человек тестировало пару месяцев изделие, а вот на баг только вчера попали .


Да, интересно. Само исключение есть, и работает - я ж обработчик таки при написании проверял. (как оказалось по черновым тестам - записью невыравненного слова во флеш - по адресу 1) . Но, судя по доке, возникает при обращении к несуществующей памяти и при записи во флэшку. Есть плата на свежем 2148revB и есть китовая от MT на 2148rev- - попробую на них.

P.S. Таки купили Вы меня на "надуманное", ну и ладно, сделаю вид что провокации не было


IP-шник - неудачный пример. И вообще протоколы для "внешних сношений". Если учитывать endianess, то разбор такой структуры все равно макросами надо делать, и в них aligment учесть. У меня, например, в TCP в итоге получилось 4 варианта макроса считывания поля IP - BE/LE + aligned/unaligned.
А вот со своими внутренними структурами - там да, некоторый unaligned трабл у прикладников был. Вот еще беспокойство есть насчет оставшегося 1% . Предполагался сценарий - "odd address trap" -> "bug report" -> e-mail -> база ошибок. Увы, мечты были грубо разрушены злобным NXP

"Работало", это как, DABT? В том абзаце, что я привел, ничего про DABT написано не было, там написано, что работает, но "специфически".

Все верно, у меня практически такие-же вещи по полной программе, НО все это не делалось единовременно вдруг с 8 на 32. При переходе ровным счетом ни одной проблемы в работе, именно с выравниванием не вызвало. Все отсеялось в процессе портирования при работе с исходниками.

Посторяю - 200K чего? Кода или сишных строк??? Вот прям сейчас сижу в начале обычного проекта: ARM 94 файла 40767 текстовых строк из них всего 21943 стороки с кодом. Бинарник 134504 байта. Процентов 15% пришло с 8bit. Еще 20% вообще сразу живут на всех платформах. Будет развиваится и раздуваться еще несколько лет. Естественно есть и уже перевалившие за 300K бинарника. Говорите, что у Вас "200К строк С-шного кода" причем, как ранее говорили, для чего-либо врезультате влезающего в AVR128 и затем портированых? Так вот не верю.

Никаких провокаций - просто удивился. Полагаю обосновано.