Дам бесплатный совет. В режиме отладки ставьте ASSERT или любую проверку. В режиме Release уберите проверки и получите быстродействие ещё больше чем в SAM7, т.к. проц быстрее.
Как для бесплатного - совет хороший. Но как быть с неординарными ситуациями в run-time? Оставить Release вообще без шанса выявить критическую ошибку и потом по последствиям искать?
Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753
Понятно, хочется переложить на процессор собственные баги. Причём хочется чтобы в процессе эксплуатации программа именно зависла, но нельзя допустить чтобы она исполнялась на 1% медленнее, но без багов
Достаточно короткий вариант отлова ошибок:
Код
tst r0,#3 swine 100 ldr r1,[r0,#+0]
И не говорите, что он будет тормозить проц. Два такта проверки в дополнение к 3 тактам чтения рамы это ничто.
Не знаю, как эту проверку автоматизировать на Си, но на Асме это делается легко.
Понятно, хочется переложить на процессор собственные баги. Причём хочется чтобы в процессе эксплуатации программа именно зависла, но нельзя допустить чтобы она исполнялась на 1% медленнее, но без багов
Не передергивайте. Допустим мы последовали Вашему бесплатному совету. В debug наставили assert'ов и отладили. Затем сбилдили release, с отключенным assert'ами. Код получился незащищенным. При определенных обстоятельствах получили нештатную ситуацию в real-time скажем через n-лет работы, и весело по-тихому обработали невыровненный блок, - это может привести к плачевным последствиям...
Цитата
И не говорите, что он будет тормозить проц. Два такта проверки в дополнение к 3 тактам чтения рамы это ничто.
Два доп. такта к трем - это минус 40% быстродействия. Неужели неочевидно?
Odd address trap и LPC23xx, А что, LPC не генерит unaligned access exeption?
Jan 18 2009, 21:46
