sifadin 0 1 июля, 2011 Опубликовано 1 июля, 2011 (изменено) · Жалоба Есть программа размером под 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 как быть? Весь код туда не влезет Изменено 1 июля, 2011 пользователем sifadin Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vadimuzzz 0 1 июля, 2011 Опубликовано 1 июля, 2011 · Жалоба а как у вас с кэшем инструкций? я так понимаю, это должна быть его работа. Tightly Coupled Memory обычно имеет смысл под обработчики прерываний использовать. да, а как меряли время выполнения? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sifadin 0 1 июля, 2011 Опубликовано 1 июля, 2011 (изменено) · Жалоба а как у вас с кэшем инструкций? я так понимаю, это должна быть его работа. Tightly Coupled Memory обычно имеет смысл под обработчики прерываний использовать. да, а как меряли время выполнения? 4 к кэша измерял По осцилографу. Зациклил код и в конце поставил обращение к внешнему устройству (высокоскоросному). По стробу записи смотрел частоту обращений Пробовал закоментировать код разница впечатляет с кодом около 1МГц, без 20МГц (устройство дает такты ожидания) Теоретически при таком раскладе он должен работать из кэша может сдвиговые операции съедают время Какие опции компилятора надо включить чтобы он оптимизировал код по быстродействию? Да дело было в оптимизации включил -O3 время уменьшилось на порядок Не знал что это такая сильная штука Изменено 1 июля, 2011 пользователем sifadin Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vadimuzzz 0 1 июля, 2011 Опубликовано 1 июля, 2011 · Жалоба для того кода время дикое. при 4к кэша зацикливаемый кусок наверняка исполняется не с DRAM, Tightly Coupled Memory тут не поможет. посмотрите промежуточный ассемблер (в objdump). можно еще сигналтапом посмотреть. -O3 - это чревато, лучше -O2 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
id_gene 0 5 июля, 2011 Опубликовано 5 июля, 2011 · Жалоба +1 смотрите листинг. Можно промоделировать, если ресуры позволяют. Поковырял свои старые коды, вот такая строчка у меня есть (переложил одну функцию во флешку) void my_init (void) __attribute__ ((section (".cfi_flash_2.txt"))); Почему с txt - не помню При этом строчка это в файле заголовков (при декларации), а не при описании функции. Как называются секции в вашем случае можно посмотреть в _syslib/Release/system_description/generated.x Но лучше, конечно, разобраться, почему так медленно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sifadin 0 8 июля, 2011 Опубликовано 8 июля, 2011 · Жалоба с O3 время того куска составляет 100нс вроде это соответствует А чем череват O3? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vadimuzzz 0 8 июля, 2011 Опубликовано 8 июля, 2011 · Жалоба А чем череват O3? есть риск получить нестабильную программу. имеет смысл только в приложении к какому-то конкретному коду, иначе все эти разговоры - сравнение теплого с мягким. на одних задачах может дать падение производительности, на других - прирост, на третьих - вообще глюки. т.е. для конкретной программы можно поиграться с флагами (-O* это еще не все), поглядеть на результат. еще это зависит от версии компилятора. вот на пальцах: http://www.insidepro.com/kk/231/231r.shtml Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sifadin 0 8 июля, 2011 Опубликовано 8 июля, 2011 · Жалоба есть риск получить нестабильную программу. имеет смысл только в приложении к какому-то конкретному коду, иначе все эти разговоры - сравнение теплого с мягким. на одних задачах может дать падение производительности, на других - прирост, на третьих - вообще глюки. т.е. для конкретной программы можно поиграться с флагами (-O* это еще не все), поглядеть на результат. еще это зависит от версии компилятора. вот на пальцах: http://www.insidepro.com/kk/231/231r.shtml Спасибо, посмотрю Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
WitFed 1 8 декабря, 2011 Опубликовано 8 декабря, 2011 (изменено) · Жалоба Я думаю, что сам исходник: 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 получается ;) Изменено 8 декабря, 2011 пользователем WitFed Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться