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 тоже отработал!

[VslavX]

Вообще-то "это отлаживать" - Вам "низачет", ибо нужно не с последствиями бороться а банально этои 200К строк (кстати для 8bit это число надуманное)

Увы, не надуманное. "У меня линейка есть" - поэтому я абсолютно спокоен.
Самый старый проект был начат в 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К грозит играючи перейти. Впрочем, сложность - понятие относительное, посмотрим на исходники Линукса - там никакой "линейки" хватит.

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

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

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

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

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

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

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

[zltigo]

Самый старый проект был начат в 1992-ом, пережил asm x86, BCC3.1, Watcom, IAR AVR 1.30, IAR MSP, Softune LX16, GCC ARM, GCC PPC, сотни две вариаций и моделей.....

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

На проектах на ARM-ах - еще веселее - 200K - " это только лицо" ©, т.е. приложение.

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

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

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

[VslavX]

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

Да, понятно, что на любом проекте крупнее среднего будет практически то же самое. Но у нас некоторая разница в подходах - Вы пишете что "все отсеялось" (ну так уж и все?), а я пишу - "1% остался". И вчера мне мои прикладники показали часть от этого "1%".

Посторяю - 200K чего? Кода или сишных строк??? Вот прям сейчас сижу в начале обычного проекта: ARM 94 файла 40767 текстовых строк из них всего 21943 стороки с кодом. Бинарник 134504 байта. Процентов

Дело было давно (в районе 2000-го) - из любопытства написал простой скриптик подсчета текстовых строк на Perl и прогнал на каталоге с исходниками для одной платформы (AVR, кажись). Тогда вышло около 150К - всех текстовых строк - с хидерами, C- кодом, комментариями, но без документации, makefiles и всяких вспомогательных скриптов (то отдельно все лежит). Сейчас не считал, по минимуму полагаю 200K.
Эти все 200К написаны прикладниками - без платформозависимого и системного кода, который пишу я. ИМХО, по стилю там тяжеловато - с комментами напряг, и макросов засилье изрядное, так что текст - "плотненький", сколько строк именно с кодом - не скажу, но тоже не менее 50%.

несколько лет. Естественно есть и уже перевалившие за 300K бинарника. Говорите, что у Вас "200К строк С-шного кода" причем, как ранее говорили, для чего-либо врезультате влезающего в AVR128 и затем портированых?

Это где я говорил что все 200К строк исходников одновременно влезают в 128К? Я сказал, что в сумме есть 200К строк из которых получается сотня различных вариантов путем условной компиляции.

Процентов 15% пришло с 8bit. Еще 20% вообще сразу живут на всех платформах

В-о-о-о-т. А у нас 75-90% пришло с 8-битника и эти же 75-90% живут на всех 8/32-битных платформах. Из оставшихся 10-25% для 32-битников - 80% (ОС, стеки) тоже живут на всех 32-битных платформах. Итого - у меня "не живущая" и заново пишущаяся для платформы часть составляет 2-5% - против Ваших 65%. Отсюда и Ваш совет - "при портировании надо пересмотреть код". Когда пишешь заново - не вопрос - само собой так получается, а вот когда оно уже написано, отлажено и работает - хто ж в здравом уме туда полезет?

Так вот не верю.

Чему именно? Что бывают проекты где 75-90% процентов платформо-независимо и может жить на 8/16/32?

Не, такое - не пойдет. Тормозить будет, т.к. будет LDRB вместо LDR.
Мы ж скорости хотим. - если скорость не нужна можно везде все упаковать и будет ARM как восьмибитник работать.

У меня эту проблему в общем случае решить не удалось. Для TCP/IP у меня такая реализация:

Код

LW_INLINE_FORCED
DWORD
lw_ipload(
    PLW_IP_ADDR ptr)
{
#if LW_ALIGNED_HDR
    //
    // Вариант перестановки для выравненного доступа
    //
    DWORD    v, t1, t2;

    v = *(PDWORD)ptr;

    t1 = v ^ ((v << 16) | v >> 16);        // t1 =  2143 ^ 4321
    t2 = (v >> 8) | (v << 24);            // t2 =  1432
    t1 = t1 & 0xFF00FFFF;                // t1 =  2043 ^ 4021
    return t2 ^ (t1 >> 8);                // 1432 ^ (0204 ^ 0402)
#else
    //
    // Вариант перестановки для невыравненного доступа
    //
    return  (DWORD)((PBYTE)ptr)[3]
         | ((DWORD)((PBYTE)ptr)[2] << 8)
         | ((DWORD)((PBYTE)ptr)[1] << 16)
         | ((DWORD)((PBYTE)ptr)[0] << 24);
#endif
}

Для PowerPC в bigendian это выглядит так:

Код

LW_INLINE_FORCED
DWORD
lw_ipload(
    PLW_IP_ADDR ptr)
{
    return *(PDWORD)ptr;
}

Если в проекте есть хоть один сетевой интерфейс для которого поле IP может быть невыравнено, то в кофигурации указан LW_ALIGNED_HDR нулевой. Но обычно есть только один ethernet, я стараюсь чтобы было выравнивание (гы, на SAM7X - получилось выровнять пакеты при приеме, на LPC - нет ) и работает выравненный вариант.

Пример работы с полем:

Код

{
    DWORD ip;

    ip = lw_ipload(&iphdr->ipsrc);
    //
    // Делаем с IP чего надо
    //
{

Но тут как раз проблема ловли исключений не так остро стоит - этот код свой и писался изначально под разные платформы с разной endianess и alignment. Проблема острее стоит в портированном "старье".