Odd address trap и LPC23xx, А что, LPC не генерит unaligned access exeption? Опции

[VslavX]

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

Код

{
    ungigned long *p;
    dprintf("\r\nNon aligned DWORD read.. ");
    dflush();
    p = (unsigned long*)(0x209 + LPC_ISRAM);
    dprintf("%08X", *p);
}

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

[meister]

В-общем, красота - при невыравненном адресе - на LPC23xx читается/пишется переставленный мусор, и все это МОЛЧА. Такая низость в самом деле имеет место, или я чего-то недопонимаю?

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

Код

If the memory address is not word-aligned, the value read is rotated right by 8 times
the value of bits [1:0] of the memory address. If R15 is specified as the destination, the
value is loaded from memory and written to the PC, effecting a branch.

[VslavX]

Код

If the memory address is not word-aligned, the value read is rotated right by 8 times
the value of bits [1:0] of the memory address. If R15 is specified as the destination, the
value is loaded from memory and written to the PC, effecting a branch.

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

[zltigo]

Очень весело отлавливать такие проблемы при портировании 200К строк С-шного кода с 8-битника, например.

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

NXP - "низачот", первый раз такой облом вижу. В 70-ых на PDP такое счастье как OAT было, а вот в 21-ом веке - не судьба.

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

[defunct]

(кстати для 8bit это число строк кода СИЛЬНО СИЛЬНО надуманное - "урежте осетра" как минимум на порядок, тогда еще где-то в 64-128K бинарника поверю )

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

И вообще с этим хорошие компиляторы хорошо справляются - warning-ов хватает, если, конечно перворначальный код не совсем через заденпроходное отверстие писан, то незачем такое и портировать.

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

[zltigo]

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

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

[defunct]

Отнюдь. В реальности буфера под фреймы выделяются выровненые а нормальная разборка ведется по наложенной структуре.

Это все так, но давайте рассмотрим случай когда пакеты идут с разных интерфейсов. Eth и PPP-Link (у одного перед IP header'ом 14 байт eth заголовка, у второго длина ppp заголовка зависит от настроек канала и может быть от 1 байта и выше... И там и там "по-умолчанию" IP заголовок получается невыровненым относительно начала пакета. А мы хотим проверить по маске быстро (чтобы "одной" командой):

Код

*(U32 *)(packet + offset)   &  mask

Вот тут недостача align exception'а может сыграть злую шутку

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

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

Что у NXP есть по поводу misalign'a - как они предлагают обрабатывать такие ситуации в run-time (какие-нить их доки на этот счет)?
Может быть есть сводка в каких NXP чипах align exception поддерживается, а в каких нет?