[VslavX 0]

А вообще, тут все забыли одну вещь касательно Data Abort при невыровненных словах. Где-то читал, что в LPC он возникает только если проц работает в USER MODE. Во всех остальных MODE, в частности в SYSTEM MODE он специально заблокирован, так как все остальные режимы предназначены для системы. Так что, господа песатели, отлаживайте свои проги в USER MODE, а когда уже всё отладите можете переносить код в другие режимы

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

[GetSmart 0]

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

 

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

 

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

Изменено 17 января, 2009 пользователем GetSmart

[defunct 0]

Паранойя?! Вы ещё совсем недавно всё на AVR песали и не жаловались на быстродействие.

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

Не понимаю, Вы пытаетесь защитить/оправдать остуствие exception'a в LPC?!

 

LPC раз в 5 быстрее AVR, и если на нём побайтово из буфера собирать Long, то особых тормозов не будет заметно. Дальше спорить не буду. Я всё равно останусь при своём мнении.

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

 

А вообще, тут все забыли одну вещь касательно Data Abort при невыровненных словах. Где-то читал, что в LPC он возникает только если проц работает в USER MODE. Во всех остальных MODE, в частности в SYSTEM MODE он специально заблокирован, так как все остальные режимы предназначены для системы.

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

[zltigo 0]

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

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

[defunct 0]

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

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

 

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

 

на SAM'е мне ничто не мешает там где нужна скорость написать:

*(U32 *)<произвольный адрес> = x;

т.к. есть полная уверенность в том, что даже если произвольный адрес неправильный я это не пропущу.

 

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

 

if (<произвольный адрес> & 0x3)
{
   slow implementation
}
else
{
   fast
}

[aaarrr 63]

т.к. есть полная уверенность в том, что даже если произвольный адрес неправильный я это не пропущу.

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

[iShustov 0]

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

 

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

 

if (<произвольный адрес> & 0x3)
{
   slow implementation
}
else
{
   fast
}

 

Ну вообщем то так и делается :) И не только для LPC

Например, в WinCE'шных драйверах упомянутого выше самсунга...

[zltigo 0]

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

 

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

 

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

 

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

[VslavX 0]

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

 

if (<произвольный адрес> & 0x3)
{
   slow implementation
}
else
{
   fast
}

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

{
   ASSERT(((DWORD)adr & (sizeof(DWORD)-1)) == 0, "Ugly unaligned pointer");
   fast implementation
}

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

[defunct 0]

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

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

 

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

Чтобы ответить на этот вопрос, позвольте мне определить рамки в которых плаваем. Дано:

1. буферы, содержащие некие типизированные данные, например IP заголовок;

2. предполагается, что для любого буфера, IP заголовок может находиться с произвольным смещением от начала буфера;

3. предполагается, что начало IP заголовка всегда на границе 32 бит. (напр, программируем DMA так, чтобы он нам клал пакет не с начала буфера, а с некоторого смещения, так чтобы IP заголовок получался выровненным).

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

 

Теперь собсно ответ на вопрос:

С наличием exception'a - я буду работать с полями IP заголовка как с U32 без проверок на выровненность.

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

 

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

...

ASSERT(((DWORD)adr & (sizeof(DWORD)-1)) == 0, "Ugly unaligned pointer");

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

Проверка останется все равно.

[GetSmart 0]

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

Проверка останется все равно.

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

 

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

 

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

Изменено 18 января, 2009 пользователем GetSmart

[zltigo 0]

А не вылетание в аборт при невыровненном чтении имеет свои плюсы. Жаль, что IAR это делать не умеет, но эта фича даёт возможность прочитать.....

 

 

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

[aaarrr 63]

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

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

[zltigo 0]

генерация аборта включается битом в CP15. Здесь могли бы сделать так же.

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

[VslavX 0]

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

 

Moderator:

 

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

 

VslavX:

 

Да ничего страшного, бывает.

Если найдется время - таки фрагменты листингов выложите, плз - интересно, неужели "в самом деле все качели погорели" ? :)

Я над темой доступа к невыравненым данным немало размышлял, может тут что новое любопытное появится.