Проблема ми е следния:

Имам STM32F103... и сложна сметка.
Естествено като стар пикоборец, първата ми мисъл е, правя си предварително сметките и резултата в таблица. После си вадя от таблицата. Стар и изпитан метод... да ама не.
Подробности:
В таблицата има крива, описана с 16384 16 битови стойности. Изчисляването на кривата в реално време не е по силите на тоя процесор. Стойностите трябва да са 16 битови, а броя на елементите евентуално може да се намали 4 пъти ако е належащо.

Проблема. Ами обръщението към таблицата стават много бавно. Предполагам, че забавянето идва от това, че процесора изпълнява код от флаша от едно физическо място и после трябва да чете променлива от флаша от съвсем друго място, което със сигурност е далече от първото. Това омазва кеширането на четенето от флаша и заради това процеса се забавя...

Дали съм прав?
И дали имате някакви предложения по въпроса как може да се оптимизира подобен проблем?

Колко е кеша на контролера ти?

Ами колко е никъде не мога да намеря. То реално не е и кеш ами е някакъв Bus Matrix който така и не мога напълно да разбера, а се опитвам отдавна...

Аз го мисля така, а нищо чудно изобщо да не съм прав.
Флаша е един общ и за инструкции и за константи. Достъпа до флаша става на честота по-ниска от честотата на ядрото, и предполагам че от флаша се извличат няколко инструкции на едно четене /и се записват някъде - на което аз му викам кеш/, така че тези инструкции да са налични за няколкото следващи такта на ядрото. Ако щом достъпа до флаша не е клетка по клетка, това означава че ако в момента чета инструкции и ми трябва константа от съвсем друго място, тогава трябва да прочета от другото място - ама понеже чета няколко клетки на веднъж а ми трябва само една, останалото го хвърлям. Предполагам и че четенето на константите от флаша опуква и наличните инструкции, които след малко пак ще ми трябват и на ново трябва да ги чете и тях след това. Даже достъпа да става през тоя Bus Matrix който така и така не разбирам, пак отделните четенета, трябва да се чакат едно друго и от там идва забавянето...

juzisound, ползване на таблица в паметта с предварително сметнати данни вместо процесора да смята риълтайм е стандартна и то много добра практика, въобще не е свързана точно с пикоборството. Та сигурен ли си, че го правиш както трябва, защото колкото и цикъла да губи, за да зарежда инструкциите наново (ако въобще това е проблема, защото на мен много не ми се вярва) те ще са доста по-малко от необходимите цикли за пресмятане на резултата, ако го правиш със сметка. Та чекни пак нещо друго да не бърка работа . Може примерно да има някаква връзка с големината на масива, т.е. да е извън обхвата на адресацията на инструкциите, които се ползват и да стават някакви сложнотии, за да се осигури достъп до данните. пробвай примерно да го разбиеш на няколко по-малки масива или пък пробвай само с част от масива да видиш няма ли да се забърза работата.

И аз като Димитър подозирам, че разговорникът (компилаторът де) е източник на
забавянето, освен ако не става дума за 2-3 клок цикъла вповече, които му трябват
на флаша.

Ако все пак има някаква тъпотия и няма как да стане освен "много бавно" от флаш,
можеш да намалиш таблицата няколко пъти и да интерполираш между точките (местейки
таблицата в RAM или някака друга по-малка, но работеща памет).
Едно време CPU32 дори имаше една инструкция за целта, "table lookup and interpolate",
tblun или нещо такова се казваше. Безсмислица де, делението отнема многото време.

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

Имах предвид, че е безсмислица да го отделят в една 16 битова инструкция както
беше там.
Инак варианти много, разбира се, че може и делението да го съшие човек с някаква
вършеща работа точност във втора таблица.
Но в случая почти сигурно става дума за някой-друг порядък забавяне благодарение на високото
ниво, ама това е положението. Хората си губят години в блъскане да научат разговорника
вместо (много по-лесно) да научат езика, нали всички така правят .

Влача го тоя проблем от доста време. Не е като да не съм го борил. Какво ли не опитвах - неще и неще. Стигне ли се до ползване на масива и ела виж какво става...

Скоро опитвах да сведа масива до 2кб, колкото ми е разделението на флаша по страници в тоя проц - все тая. Опитвал съм и да направя достъпа до масива по различен начин: с индекси, с указатели... бе каквото съм се сетил. Неще и неще. Дори съм опитвал да извадя стойността от масива първо в локална променлива и после нея да си ползвам. Пак нищо. Вкарам ли масива в играта и става бавно.
Инак масива е една крива по която трябва да затихва аудио сигнал, за да му изглежда на човек, че затихва равномерно. Не е нищо особено, ама ваденето от масива става на семплъл рейд и като се съберат повече тонове едновременно затихващи и става мазало.

В крайна сметка израза е нещо от сорта:
sample_value = (sample_value * index)/65536; // това за линейно затихване - без масив
или
sample_value = (sample_value * array[index])/65536; // това за затихване по крива

Според мене е проблем с едновременен достъп до флаша за да се вадят и инструкции и данни. Това е основно по усет де. Чакам някой от големите глави тук да подтвърди че има такава вероятност или аргоментирано да го отрече като възможност, че да търся в друга посока някаква...

е явно разговорникът (компилаторът) подбира не тая фраза, която се надяваш
да подбере. По колко време отива на справка от таблицата?

Без да видиш генерирания машинен код няма как да разбереш какво става.
Веднъж видиш ли го почва надлъгването с разговорника да му уцелиш фразата, която
ще я преведе най-близко до това, което искаш - опити и грешки.

[edit] това деление дето си го сложил вместо шифт 16 пъти надясно сигурен ли си,
че компилаторът ще се сети да го оправи? [/edit]

Добре де, за какво забавяне иде реч?
Наистина, четенето на данни от флаша би трябвало да изпразва prefetch-буфера, т.е. вероятно се чака два пъти - веднъж при четенето на данните и след това при извличане на следващата инструкция. Ако това става прекалено често, процесорът ще работи все едно се тактува на 24MHz.
Можеш ли да измериш забавянето - например, може да направиш цикъл от 1000 операции (веднъж с линейно затихване и втори път - през масива). Пусни един таймер, отчети го в началото и в края на цикъла. Разликата ще ти даде представа за времето за изпълнение.
Не е излишно да разгледаш и асемблерския листинг - това може да те ориентира по-точно и какви инструкции се използват. Със сигурност зареждането от масива става на няколко паса - зареждане на адреса на масива, след това индексирано четене.
Провери и дали делението не се извършва като истинско делене, а не като шифтване надясно, което е доста по-бързо.

Edit: Четенето на данни не използва prefetch-буфера, така че не го изпразва. Т.е., самото четене просто изчаква програмирания брой цикли според тактовата честота. Най-вероятно времето се губи при останалите операции.

Освен ако ST не са осрали пейзажа не би трябвало да си прав

Кортекса е стандартна Load/store архитектура т.е. има два типа инструкции - за трансфер на данни от разни памети и всички останали интрукции. Като трансфера прави само трансфер без никакви аритметики. А пък аритметиките не могат да ползват трансфер, т.е. памет.
Тоя тип архитектура е направен с цел опростяване на нещата и АРМ изцяло запазват простата/простотията. За разлика от МИПС примерно, които вкарват малко по-сложен конвейер и по-сложна шина с цел да няма забавения заради трансферите.
При куртекса както казах е просто - инструкцията за запис изисква 2 клока, а четенето 3 клока. Демек като се извлече LOAD инструкция след това шината е 2 клока свободна, т.е. може да се ползва за трансфер на данни. Тук малка подробност е, че от страна на ядрото шините са 3 и инструкциите са извличат по една, а данните по друга шина. Но така или иначе когато флашът е един няма значение броя на шините. Въпросът е, че ядрото или извлича код или данни, но не го прави едновременно. И тъй като не го прави едновременно няма нужда от специални магии. Нито пък има значение дали данните са разположени в същата памет от която извличаш код.
Дотук го обясних без wait states. Нормално обаче (поне евтините) флашове са по-бавнички. За да се прикрие тоя факт често флашът е с повече от 32-битова шина и работи на 1/2 CPU clock (или още по-ниско). Така забавяне (wait state) за кода има само след преход. След това кода се кешира, като кеширането би трябвало да е на инструкшън шината на ядрото. Така че по никакъв начин да не се бърка от даннови трансфери.
При единичен трансфер на данни кеша или по-точно "ускорителя" се прескача, т.е. винаги се добавя поне един wait state към стандартните 3 клока за четене. При Load multiple вече се включва ускорителя и следващите трансфери са на далавера.

Пак да кажа не съм задълбавал много при ST, може и да са объркали нещо. Но аз лично бих проверил останалите хипотези преди да търся сериозен бъг в проца




На мен не ми стана ясно какво точно правиш и как реши че имаш проблем.
Едно е сигурно, че като вероятност на-малко вероятно е да си "претоварил" флаша. Ако не ти се вярва премести кода да се изпълнява в RAM, тогава няма да имаш абсолютно никакви конфликти (на различна шина е...). Ако работиш на ниски честоти (т.е. няма w.states) разлика трябва да е точно 0%. При по-голяма честота, подобрението трябва да е под 5% от това че ще махнеш wait при преходите.

Тъй де, дай по-конкретни данни. Примерно CPU на еди колко си мандахерца прави еди какъв си трансфер....

Иначе таблиците не винаги ускоряват.... Най-често срещания пример е AES кодирането. Там се ползва две таблици за право и обратно преобразуване. Тъй като всяка дума от таблицата се ползва 4 пъти шифтната оптимизираните кодеци за х86 всяка таблица я заместват с 4 таблици, така че да няма нужда от шифтвания.
Да, обаче подобна "оптимизация" приложена на АРМ е живо закопаване, защото шифтването може да се съчетае с xor-нията в една инструкция и реално излиза 0 (нула) допълнителни клока. Така че оптимизацията заменя 0 клока с една LOAD инструкция която е 3+ клока... И това се прави 4 пъти на всеки кодиран байт, отделно че заради повечето междинни резултати се изчерпват регистрите, т.е. още трансфери....

Това разбира се е фрапиращ пример, когато таблиците не само че не ускоряват нищо, ами забавят в пъти криптирането. В общия случай много зависи каква е математиката зад таблицата и дали има смисъл от таблица...

Че флаша е едно от тесните места в тия процесори - то е ясно. За какво иначе се напъват да се хвалят с новия си флаш акселератор в F4 серията, който в първата им ревизия даже не работи. С тях правят и китчетата , дето ги продават под себестойност едва ли не. На всякъде се хвалят като казват че от гледна точка на потребителя, в F4 серията все едно флаша работел с честотата на ядрото. Да - ама само така изглежда...
А иначе процесора ми работи на 72МХз, а флаша на 2 wait states.

Явно ще трябва да драсна една малка програмка - само с това вътре и едно таймерче да мери.
Хем ще видим и какъв код ще изкара компилатора.
Кода ще ви го покажа тук, че аз не му разбирам много...

ЕДИТ:
Имам някакъв спомен че от флаша се четат 64 бита на един път...

Я наистина най-добре вземи ни светни колко е това "много бавно", да не се окаже, че само си мислиш, че има забавяне .

Ами за да кажа колко е точното бавно, явно ще трябва да направя някакво измерване или да опитам да изкарам асемблерски код.

Инак от къде съдя че е бавно:
- имам обработка на осцилатори, която се извършва 48000 пъти в секунда. Обработката става в прекъсване. Прекъсването е с по-висок приорите от стартиращия го процес, тоест случва се веднага след като е инициирано от по-ниския приоритет.
Ако даден осцилатор е зает, се прави ваденето от таблицата.
Обработката на осцилаторите се стартира еднократно на всеки 1/48000 от секундата. Обработката на всички осцилатори трябва да завърши преди да е дошло времето за стартиране на новата обработка, инак инициирането на новата обработка не тръгва, тъй като се вдига флаг на прекъсване, който все още не е свален, тъй като същото това прекъсване все още не е завършило. Резултата на практика е пропускане на един такт без други странични ефекти. От музикална гледна точка ефекта се изразява в "падане" на звука /честотата/ с една отава надолу, тъй като се обработва всяка втора заявка.

Дано съм бил ясен.
Сега - при 8 работещи осцилатори, ако не се ползва таблицата /тоест не затихват по тая крива а линейно/ гарантирано всичките 8 осцилатора се обработват до следващата заявка. Ако се ползва таблицата, гарантирано работят само 6, при намеса на 7-мия, почват проблемите.

Ето и извадки от кода и асемплера в момента:
И от двата примера се изпълнява долната част от if-a - демек else частта.

П.С.
Сега видях че на тия извадки не се вижда съвсем добре. Утре ще направя нови...