Совет хороший, и стал бы еще лучше если бы Вы его ссылкой подтвердили. А то документация производителя и google как-то скромно умалчивают про приведенные Вами факты.

Прямо скажу, я за 3 года об АРМах столько всего начитался, что уже не помню когда и где читал. Но скорее всего где-то в разделе об ограничениях USER MODE. Точно помню, что в этом режиме нельзя изменить младшие биты регистра флагов, отвечающих за текущий режим и за запрет прерываний. Мне сейчас лень искать всем желающим нужную им инфу. Подсказки я дал. Все желающие - на поиски!!!

А не вылетание в аборт при невыровненном чтении имеет свои плюсы. Жаль, что IAR это делать не умеет, но эта фича даёт возможность прочитать 32 бита с любого нечётного адреса всего за две команды LDR. Например читая слово с адреса 1 в регистр прочитаются правильно сразу три байта. Старший байт нужно будет прочитать в другой регистр из адреса 5. Потом по маске их объеденить. Браво LPC!!!

Потестировал это дело на LPC2134/01 но не срабатывает исключение ни в SYSTEM, ни в USER. Абыдно А может где-то флажок стоит, управляющий этой фичей.

Сообщение отредактировал GetSmart - Jan 17 2009, 08:58

Я и до сих пор под AVR/C51 много чего пишу, и не жалуюсь на быстродействие. Но там у меня задачи нетребовательные к быстродействию.
Не понимаю, Вы пытаетесь защитить/оправдать остуствие exception'a в LPC?!

В таком случае SAM7 "порвет" LPC по производительности (т.к. не нужно будет собирать Long побайтово).


Если можно - более подробно на этот счет. Где читали? ;>

Вы, это, простите о чем???

О том что мне совесть не позволит в проц в котором нет exception'a вставить опасный код.

Следовательно придется добавлять проверки, а они будут тормозить.

на SAM'е мне ничто не мешает там где нужна скорость написать:
*(U32 *)<произвольный адрес> = x;
т.к. есть полная уверенность в том, что даже если произвольный адрес неправильный я это не пропущу.

на LPC будет как минимум:

А есть уверенность, что когда произвольный адрес станет неправильным от изменения совсем в другом месте, Вы этого не пропустите?

Ну вообщем то так и делается И не только для LPC
Например, в WinCE'шных драйверах упомянутого выше самсунга...

Ну и как это новое утверждение соотностится с Вашим предыдущим



, которое и вызвало моой вопрос. Повторяю вопрос - как наличие exception приводит к результату "не нужно будет собирать Long побайтово"

ИМХО, при неработающем исключении лучше бы написать так:

ASSERT программно сгенерит недостающее исключение. Но беда в том, что я предпочитаю "традиционный вариант нормы" - то есть работающее исключение, и на такую подлянку никто не рассчитывал и, соответственно, этот ASSERT по коду не "раскидан".

ну.. так сказать "прямопропорционально". На SAM'е будет быстрый опасный код, на LPC - медленный и безопасный.


Чтобы ответить на этот вопрос, позвольте мне определить рамки в которых плаваем. Дано:
1. буферы, содержащие некие типизированные данные, например IP заголовок;
2. предполагается, что для любого буфера, IP заголовок может находиться с произвольным смещением от начала буфера;
3. предполагается, что начало IP заголовка всегда на границе 32 бит. (напр, программируем DMA так, чтобы он нам клал пакет не с начала буфера, а с некоторого смещения, так чтобы IP заголовок получался выровненным).
(отступ от последнего условия - есть ситуация неординарная, возникающая возможно при фатальной ошибке программы).

Теперь собсно ответ на вопрос:
С наличием exception'a - я буду работать с полями IP заголовка как с U32 без проверок на выровненность.
Без exception'a мне придется либо предусмотреть его программную генерацию, либо - побайтовую сборку/копирование полей с требуемым выравниванием. Оба варианта будут пагубно сказываться на быстродействии (лишний код и все-таки).


Согласен, однако это не сделает реализацию такой же быстрой как без assert'a
Проверка останется все равно.

С такой паранойей надо писать на ассемблере и ничего не бояться Т.к. любители структурированного программирования на Си без забот выносят часть кода в отдельную процедуру, что сказывается на быстродействии ещё хуже чем сборка одного Long побайтово. А уж если программа написана на C++, то жаловаться на замедление просто смешно.

Дам бесплатный совет. В режиме отладки ставьте ASSERT или любую проверку. В режиме Release уберите проверки и получите быстродействие ещё больше чем в SAM7, т.к. проц быстрее. Но даже если LPC будет собирать Long побайтово, то по скорости он всё равно (!) не уступит SAM7. Хочу подчеркнуть, что я предлагал собирать побайтово Long только для быстрой проверки какого-либо условия в буфере. Если же нужно выгребать множество слов из буфера, то как правильно писал zltigo, сперва нужно через memcpy скопировать буфер и выровнять его начало. Можно даже не тратить дополнительную память и скопировать внутри текущего буфера на 1, 2 или 3 байта назад. Или вперёд.

Как там говорится: в чужом глазу соринку... в своём глазу бревно...

Сообщение отредактировал GetSmart - Jan 18 2009, 06:32

Сейчас попробовал переписать один относительно критичный кусочек работающий (никаих проблем не было - компилятор, естественно, сам разруливал) в кольцевом буфере с 16bit данными под описаный стиль "корреция результата после чтения по невыровненному адресу" результат мне понравился. Если до этого я в принципе пребывал на позициях - особо без разницы есть аборт или нет, то теперь чаша весов (если действительно требуется выжимать быстродействие) склоняется к безабортовому варианту.

А оптимальное решение где-то посередине: на ARM920, 926 и т.п. генерация аборта включается битом в CP15. Здесь могли бы сделать так же.

Ну без вариантов вот оно счастье!

Имхо, это уж совсем клиническая ситуация - "невыровненный кольцевой буфер 16-битных слов" - такого я еще не встречал.

Moderator:

Извините! Совершенно случайно промахнулся и отредактировал Ваш пост удалив большую его часть ...

VslavX:

Да ничего страшного, бывает.
Если найдется время - таки фрагменты листингов выложите, плз - интересно, неужели "в самом деле все качели погорели" ?
Я над темой доступа к невыравненым данным немало размышлял, может тут что новое любопытное появится.