Перейти к содержанию
    

Tightly Coupled Memory

Есть программа размером под 2Мб, которая выполняется из SDRAM

Столкнулся с тем что вот такой кусок кода

col1=*videomem;

 

if ((col1 & 0xff000000)!=0) return 1;

if (1) {

if ((col1 & 0xff000000)==0)

offset1=X1;

offset1=offset1*1024;

offset1=offset1+Y1;

offset1=(offset1<<2);

}

выполняется 1,5 мкс при частоте 100МГц

Решил повысить быстродействие, введением Tightly Coupled Memory под инструкции

И сразу столкнулся с трудностью - как запихнуть нужную мне процедуру в эту память

При объявлении

void PP () __attribute__ ((section (".onchip_memory2_0_s2")));

компилятор выдает ошибку relocation truncated to fit

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

в SDRAM

как быть? Весь код туда не влезет

 

Изменено пользователем sifadin

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а как у вас с кэшем инструкций? я так понимаю, это должна быть его работа. Tightly Coupled Memory обычно имеет смысл под обработчики прерываний использовать. да, а как меряли время выполнения?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а как у вас с кэшем инструкций? я так понимаю, это должна быть его работа. Tightly Coupled Memory обычно имеет смысл под обработчики прерываний использовать. да, а как меряли время выполнения?

4 к кэша

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

По стробу записи смотрел частоту обращений

Пробовал закоментировать код разница впечатляет с кодом около 1МГц, без 20МГц (устройство дает такты ожидания)

Теоретически при таком раскладе он должен работать из кэша может сдвиговые операции съедают время

Какие опции компилятора надо включить чтобы он оптимизировал код по быстродействию?

 

Да дело было в оптимизации включил -O3 время уменьшилось на порядок

Не знал что это такая сильная штука

Изменено пользователем sifadin

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

для того кода время дикое. при 4к кэша зацикливаемый кусок наверняка исполняется не с DRAM, Tightly Coupled Memory тут не поможет. посмотрите промежуточный ассемблер (в objdump). можно еще сигналтапом посмотреть. -O3 - это чревато, лучше -O2

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

+1 смотрите листинг. Можно промоделировать, если ресуры позволяют.

 

Поковырял свои старые коды, вот такая строчка у меня есть (переложил одну функцию во флешку)

void my_init (void) __attribute__ ((section (".cfi_flash_2.txt")));

 

Почему с txt - не помню :wacko:

При этом строчка это в файле заголовков (при декларации), а не при описании функции.

 

Как называются секции в вашем случае можно посмотреть в _syslib/Release/system_description/generated.x

 

Но лучше, конечно, разобраться, почему так медленно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А чем череват O3?

есть риск получить нестабильную программу. имеет смысл только в приложении к какому-то конкретному коду, иначе все эти разговоры - сравнение теплого с мягким. на одних задачах может дать падение производительности, на других - прирост, на третьих - вообще глюки. т.е. для конкретной программы можно поиграться с флагами (-O* это еще не все), поглядеть на результат. еще это зависит от версии компилятора. вот на пальцах: http://www.insidepro.com/kk/231/231r.shtml

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

есть риск получить нестабильную программу. имеет смысл только в приложении к какому-то конкретному коду, иначе все эти разговоры - сравнение теплого с мягким. на одних задачах может дать падение производительности, на других - прирост, на третьих - вообще глюки. т.е. для конкретной программы можно поиграться с флагами (-O* это еще не все), поглядеть на результат. еще это зависит от версии компилятора. вот на пальцах: http://www.insidepro.com/kk/231/231r.shtml

 

Спасибо, посмотрю

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я думаю, что сам исходник:

if ((col1 & 0xff000000)!=0) return 1;
if (1) {
if ((col1 & 0xff000000)==0)
offset1=X1;
offset1=offset1*1024;
offset1=offset1+Y1;
offset1=(offset1<<2);
}

должен выглядеть так:

  if ((col1 & 0xff000000)!=0) return 1;
 offset1=X1;
 offset1=offset1*1024;
 offset1=offset1+Y1;
 offset1=(offset1<<2);

Это эквивалентно и гораздо яснее. Вторичная проверка не нужна, да и вдруг оптимизатор её сам не выбросит.

Там на самом деле из всего получается простая формула:

offset1 = (X1<<12) + (Y1<<2);

, которую можно вычислять однострочно. Даже завести временные переменные с (X1<<12) и (Y1<<2), обновляемые в тех местах, где исходные меняются.

Может быть, это еще что-то ускорит на десяток тактов. Можно посравнивать сдвиги с умножением -- оно бывает аппаратное и на LE, сдвиги тоже им. Barrel можно настроить.

Само помещение кода в другой тип памяти вряд ли даст выигрыш -- в кэше он всю жизнь сидит при постоянном исполнении, а кэш из того же теста, что и пресловутая Tightly Coupled, да на вызов куча тактов пойдет. Легче само это тело текущей функции сделать inline-функцией, чтобы return-ов было поменьше.

Ну и, конечно, главная оптимизация уходом от -О0 получается ;)

Изменено пользователем WitFed

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...