Ами ръчно разписан алгоритъм винаги ще трябва да работи с 64 битови числа, няма как. Като брой цикли/инструкции най вероятно няма да има кой знае каква разлика с едно просто шифтване бит по бито - ама идеята ме грабна и ще го разпиша да видя как ще стане. Мисля, че GCC ще генерира страшно сбит код за нормални 32 битови ARM, но за Thumb2 ме съмнява да е толкова елегантно. Ще го видим, на работа не ми се занимава с това, довечера докато си почивам

сигурен съм...

Проблемът не е в това, че имат бъг... всеки допуска бъгове. Проблемът е, че това е версия на функциията в случай че не се използва компилатора на АРМ и че тоя бъг като гледам не съм открил аз и други са го видели и са писали и реакция никаква. Да не говорим че и това дето са го сътворили е адски неефективно. Worst case е поне 150-200 клока. При условие, че в АРМ блога някой си играл да напише статия и е предложил версия с 14 клока.

Нямаше да го кажа това, ако беше единичен случай. Аз почнах сам да си ги правя нещата още от АРМ7. Там няма инструкция за деление, ок. Стандартно деление отнема 400-500 клока. Да, обаче има редица случаи, в които се дели на константа. Примерно в printf като печаташ число и го преобразуваш в десетично ползваш деление на 10. Това е особен случай на деление, тъй като константата може да се разложи на полином и делението може да се сведе до 12 клока мисля бяха. И това беше документирано в референс мануала на кура. Няма как да не го види човек, ще ти извади очите...
Познай обаче как правят printf - за всяка цифра от резултата викаха по два пъти стандартното деление... Демек printf("%u", 12345) може да ти изяде 5000-10000 клока. Недай си боже като мен да ползваш трейсове в интеръпти и всичко ти отива в киреча...
При М3 добавиха инструкция за делене и чат-пат нещата се позакърпиха, стига обаче да не ползваш 64-бит. Щото като няма инструкция за 64-бит компилаторът си търси съответнта функция от стандартната библиотека и като я няма там и си слага цикълчето от 60-те години със събиране и изваждане. И айде пак стигаш до супер неефективно деление, при условие че 64-бит деление може да се сведе до няколко 32-бит операции за които има инструкции и всичко да стане за няколко (до десетки) вместо за хиляди клокове...
Така че проблемът със стандартните библиотеки не е от вчера... Виж в CMSIS добавиха разни DSP библиотечки, което е супер. Само че защо не оправят прости стандартни библиотечки? Дали не е защото техния компилатор не ги ползва? Честно казано не знам как стоят нещата с техния компилатор, знам само че си има собствени библиотечки за тия неща... а и наскоро се вдигна голяма патаклама, че се опитаха и да му вдигат цената на 20к евро за работно място. Та на тия цени предполагам трябва да са се постарали и да са си написали читави библиотечки. Няма лошо, нека да си ги продават, само че някак си не върви хем да правиш евтини процесори, хем скъпи компилатори.

и... за къв чеп на някой ще му трябва да брои водещите нулeви битове? даже не знаех, че има такава функция
нещо FIR специфично ли е?

и за къв чеп им е

да не говорим за самия int32_t

Ми Дедо или съм бил тъп на времето или сега правя простотия да ползвам M0, ама така или иначе в някои драйвери ползвам CLZ. Примерно в STM-а като ми дойде прекъсване трябва да проверя от кои линии, че там gpio-exti lines си ебало мамата. Та да не цикля бит по бит съм ползвал CLZ което за М3/4 е 1 инструкция за 1 клок.
И те така... сега или трябва да си преправям драйверите или да добавя CLZ, ама така или иначе за съвместимост е редно да имам всички стандартни неща. Така че сега първо добавям CLZ и т.н. пък после ще видя дали да оптимизирам местата дето го ползват.

Иначе в CMSIS гледам го ползват при изчисление на "1/x". Което пак поставя същия проблем дето имам аз - дали да се пренапише функцията или не, щото това CLZ някой го е сложил уж за ускорение, а на М0 ще стане забявяне....

Не виждам какъв е проблема !?

Аз често ползвам собственни типове и то точно с цел лесното им предефиниране според платформа, оптимизации и т.н.

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

в случая няма никакъв смисъл да се ползва q31_t вместо, още почвече, че внася неяснота. поне мен ме озадачи какво е q31 и питах гугъла, за да разбера. да, може би има някакъв резон за се полва int32 или uint32, но поне при него няма да се чешеш, където не те сърби.

програмите се четат от хора. на компилатора му все тая. и когато се налага да се ровиш в чужд код, това обикновено е при някаква авария и не си настроен философски, пред камината и чаша хенеси в ръка. пък понякога се налага и сам да си ровиш в твоя код и не би трябвало да ти минават мисли от рода на "кой идиот го е писал ТОВА!"

миро, сори за офтопика.

Това, че не можеш да схванеш смисъла на нещо - не го прави непременно глупаво и безполезно!

Гледай си хардуера - дано там се оправяш по-добре

По принцип CLZ трябва да е с unsigned, a не signed параметър. Поне така е дефинирана функцията и инструкцията в останалите курове. Някои компилатори и статик анализатори държат на тия подробности!
Освен това предефинирането на типове трябва да се прави с някаква цел. Безцелното преименуване само прави кода нечетим и води до грешки. Да не говорим. че стандартните функции трябва да са декларирани със стандартни типове. Обратното означава че функцията не е стандартна!

едит: да обобщя:

1. Бъг в алгоритъма
2. Бъг в типа на параметъра
3. Стандартна функция с нестандартен параметър
4. Ненужна смяна на тип
5. Неефективен алгоритъм

колко още неща могат да се объркат във функция от 5 реда?

Няма за какво, човек да се хаби ... хакерите всичко са измислили вече:
http://www.hackersdelight.org/hdcodetxt/nlz.c.txt
Има и други интересни алгоритми, полезно ...

Там е работата, че всяка архитектура си има особености... горното може да е ефективно за x86, обаче за М0 е много далеко от истината

За CLZ най-бърз е варианта с таблица както е обяснен тук

аз съм го опитимизирал още малко (смъкнах от 1-6 клока):



Без таблица е нещо такова:


за по-нагледно на Ц изглежда така:


и така без таблица


Не съм ги тествал още, може да има правописни грешки

В линка не е специфичен х86 код - даже на много от функциите си пише колко инструкции са за RISC
Най оптималното е с таблица и умножение по шантава константа?!
Е на тая скопена Cortex-M нещата са си различни, но виж на АРМ32 със условното изпълнение на инструцкии си е красота да го гледа човек на асемблер ...

Миро, браво за онагледяването.

To самото >> 16 се изпълнява за кой знае колко цикъла..
I386+ инструкциите май го имаха вградено търсенето на първият сенат бит? Но и там една инструкция се изпулнява аз колкото водещи нули има такта

При ARM, всъщност при почти всички RISC шифтването е 1 клок. Останалите куртекси имат броене на водещите нули също за 1 клок и поради тая причина го имам заложено в сорсовете дето сега компилирам за М0.
Другото дето са оптимизирали при М0 и ме мъчи, че за различки от всички останали АРМ-чета не може да комбинира шифт и аритметична/логична операция в 1 клок. Работата с флагове също е много скопена... ама такъв е живота, не може да очакваш супер-дупер за 1$

както винаги цитираш отделни пасажи и почваш да философтваш !

ето го оригиналния ми пост - в него няма нищо към теб:


коментара ми е за това, че :
- само "блондинка програмист" ще тръгне да търси деклация на тип с гугъл (при положение че има сорсовете)!