малко оффтопик:

Интересно ми е за колко цикъла ARM дели float и double... и въобще компилаторите поддържат ли пълноценен double (64 бита)?

OFF: http://benchmarks.caxapa.ru/

абсолютно некоректен тест... Да тестваш операции с константи е все едно да тестваш колко глупав може да бъде един компилатор...
На повечето АРМ компилатори трябва да изключиш оптимизациите за да не ти разкара подобна простотия.
Да не говорим, че мат-библитеките си имат версии и версии... Aко искаш бърза математека, GCC-то с удоволствие ще ти наблъска 30-100К библиотеки...

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

Мдаааа много ме успокои ... има делене да, в цикъл .. и цикъла не е малък ... самаюо като се замисля колко се върти тоя цикъл .. мммм за скромното ми масивче от 1000 елемента ще се изпълни има няма 1 млн пъти, иначе деленето от сорта x%=y; в момента са double, но това щото е на РС, може да станат целочислени за контролера.

Какво се притесняваш. Нали каза че на PIC18 ка може да го подкараш стига да има достатъчно рам. И на деление arm-a e в пъти по производителен от PIC18 ката с умрелите и 10 8 битови мипса.

За 16bit-а, периферия и бьрзи сметки SAF-XC164SM на Infineon е интересна вьзможност. Не сьм гo и виждал, в момента работя/уча се на старата им 166 серия и мисля, че са добри контролери. Малко от характеристиките на XC164-ката

Цената обаче е висока за този проект, digikey го дават на 7.2$
Но е интересен µC за който вьобще не се е споменавало вьв форума.

P.S. Освен KEIL и TASKING има и модифициран Eclipse с вграден GNU XC16x Tool Chain

SAF-XC167 - също е интересна възможност(флаш вариант на 164-ката) - но още по скъпо(за България/Рутроник) за съжаление
но същите параметри (25 нано секунди цикъл... другите изредени параметри... ADC10 1.1Mega/samples и 500К за ADC12 - тествано от мен) се постигат и с dspic33 и pic24

@miro_atc - ти на кой бенч вярваш - на братушките(които са фенове на Атмел и АРМ) или на надутите каубойски бенч-маркове

тестбенча като сорс е що годе коректен.

volatile UInt8 result[4];
тук volatile кара компилатора да не прави оптимизации. Което пък от друга страна е вероятно да доведе и до неоптимален код при някои компилатори.

Но и на мен ми се виждат малко неправдоподобни някои от резултатите които са сложени там

Една малка корекция: XC164 е с Flash (има и две ROM версии). XC167 сьщо е с Flash, с по-разширена периферия, повече I/О, 16 канално ADC, I2C, повече памет и т.н.
Като сьм трьгнал с рекламата, на страницата на Infineon има и много добра DSP библиотека, и документацията им е добра

вярата както и църквата не ме влекат
Предпочитам да знам... и доколкото ми стигат познанията ти казвам че тоя тест изобщо не показва предимства или недостатъци на АРМ... Писан е от хора които очевидно не познават нито архитектурата нито компилаторите които използват.

Първо погледни за едни същи операции, когато се извършват върху 16-битови числа измерват 116 клока, когато се извършват върху 32-битови получават 67 клока. Операциите са от такъв характер, че би било глупаво да се пише различен код. Все пак кодът им не е еднакъв понеже са изключили оптимизациите и компилатора е вкарал безсмислен кастинг... По принцип 16-битовите опреции не само че не са по-бавни, но напротив - значително по-бързи поради по-малкия брой итерации при умножение и деление.

Като цяло да се твърди че АРМ прави едно събиране, едно умножени и едно деление за 60, 100 или 200 клока е несериозно!

Според алгоритмите на АРМ.com 32-бит деление в стандартната имплементация е мин 19, макс 370 клока. В подобрената версия (повече код) е между 22 и 148 клока (справка ARM DUI 0021A) като това не включва викането и връщането от функцията (защото обикновено то не се прави inline). Както и да е....



Тони, батка... май те изплаших прекалено... Истината е че АРМ и специално SAM7 са много добре балансирани контролери. Не знам какво точно ти трябва, но ако SAM не го постигне значи си в голяма беда.
Дори при 150 клока на деление имаш над 1MB/s обработени числа, като за разлика от повечето други контролери, SAM7 може само това да прави - всичките му периферии са на ДМА и нямат нужда от ЦПУ...
Все пак ако може да замениш делението с умножение би било още по-добре

Аха и аз така си мисля. Опита ми показва че в 90% от случаите деленето може да се оптимизира до умножение.

Да избираш контролер според това колко бързо дели... малко ми куцо, някакси.

Компилатор Keil, LPC2129, 40 Mhz,Thumb mode, без оптимизации. Според симулатора цикъла се изпълнява за по малко от 2 us. Коректен ли е подобен тест?

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

Да ... можр и на 18-ка и на 16-ка че и на 12-ка, но с малко компромиси както казах. Като цяло първоначално идеята беше да прехвърля продукт който работи но като РС софт. Значи като цяло сметките в РС са доста и са с float, за това приложение в оригиналния вид е крос корелация м-у два масива, всеки 4800 байта, като масивите са int16. значи от тук само минавам 8 к. Предвиждах да понамаля семпъл рейта и от там големината на масива. Като цяло ми хрумна и един друг вариант, с малко по малка точност, но в случая точноста не е от голямо значение, стига винаги отклонението да е еднакво, а в този случай е точно така. Та това ще ми позволи да семплирам с доста по ниска честота, съответно масива ще е по малък, обаче крос корелацията си остава. А варианта да мина с 16-ка или 18-ка е ако разкарам крос корелацията като цяло, но тогава вече изникват няколко други проблема, които ми се иска да избегна. Иначе реално и с 12-ка може да се реши, и с малко допълнителен хардуер, но точно тия проблеми остават.