[defunct 0]

Дам бесплатный совет. В режиме отладки ставьте ASSERT или любую проверку. В режиме Release уберите проверки и получите быстродействие ещё больше чем в SAM7, т.к. проц быстрее.

Как для бесплатного - совет хороший. Но как быть с неординарными ситуациями в run-time? Оставить Release вообще без шанса выявить критическую ошибку и потом по последствиям искать?

[GetSmart 0]

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

 

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

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

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

 

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

[defunct 0]

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

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

 

 

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

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

[GetSmart 0]

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

Против такой математики я бессилен