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 читается/пишется переставленный мусор, и все это МОЛЧА. Такая низость в самом деле имеет место, или я чего-то недопонимаю?

[GetSmart]

Понятно, хочется переложить на процессор собственные баги. Причём хочется чтобы в процессе эксплуатации программа именно зависла, но нельзя допустить чтобы она исполнялась на 1% медленнее, но без багов

Достаточно короткий вариант отлова ошибок:

Код

tst   r0,#3
swine 100
ldr   r1,[r0,#+0]

И не говорите, что он будет тормозить проц. Два такта проверки в дополнение к 3 тактам чтения рамы это ничто.

Не знаю, как эту проверку автоматизировать на Си, но на Асме это делается легко.

[defunct]

Понятно, хочется переложить на процессор собственные баги. Причём хочется чтобы в процессе эксплуатации программа именно зависла, но нельзя допустить чтобы она исполнялась на 1% медленнее, но без багов

Не передергивайте. Допустим мы последовали Вашему бесплатному совету. В debug наставили assert'ов и отладили. Затем сбилдили release, с отключенным assert'ами. Код получился незащищенным. При определенных обстоятельствах получили нештатную ситуацию в real-time скажем через n-лет работы, и весело по-тихому обработали невыровненный блок, - это может привести к плачевным последствиям...

И не говорите, что он будет тормозить проц. Два такта проверки в дополнение к 3 тактам чтения рамы это ничто.

Два доп. такта к трем - это минус 40% быстродействия. Неужели неочевидно?