Предимството на 32-та регистъра далеч не се изчерпва с това кодът да държи повече
променливи в регистри едновременно. Като следствие може да бъде удължен pipeline-ът,
има какво да цъка по многото му стъпала и къде да отиде докато стане готов поредният
цъкащ по стъпалата резултат. Като последица от удължаването се вдига скоростта/намалява
използваната площ силиций. В почти 16 (що 12 бе, мислех, че само PC в АРМ използва един
от GP регистрите?) регистъра няма много накъде да се разпрострат междурегистрови операции,
затова и АРМ току обясняват как конвееризацията не е толкова нужна и подобни глупости
(не помня къде съм го чел, май един техен дръвник дето постваше в comp.arch.embedded
пробутваше такива тъпотии, беше писал някакъв техен компилатор или нещо подобно).

На мене би ми било интересно и каква е била консумацията на двете ядра като си
правил тестовете, разпространеното мнение е, че АРМ са с ниска консумация ама
дали наистина е така като става дума за реално свършена работа/време? Декомпресията
е бая показателна за такива цели.

Давам ти конкретна ситуация в която куртекса е по-добър, а ти го четеш все едно съм казал че във всички ситуации куртекса е по-добър.. Ми освен тая ситуация съм дал и друга в която МИПС е по-добър. Това е преиначаване, щото ако твърдях че М3-ката е тотално по-добър нямаше да давам и примери за обратното.






Казах ти вече не че не съм специалист на МИПС. Ако някога бях твърдял такова нещо - ОК, щеше да е голяма излагация това че не знам за МИПС16 поддръжката в ПИК.
Има много неща които НЕ ЗНАМ. И ти предполагам не претендираш да знаеш всичко НАЛИ?
В случая обаче е важно дали знаем ДОСТАТЪЧНО за това което твърдим. Аз твърдях, че за основната операция при много криптирания - шифт регистър с обратни връзки куртекса е по-бърз защото в една инструкция може да прави по две операции, т.е. ще има по-малко инструкции (съответно брой цикли) и освен това НЯКОИ от инструкциите ще бъдат 16-бит, някои 32-бит.
И забележи, че ПРОДЪЛЖАВАМ да го твърдя. Не приемам твоя агумент че МИПС "може едновременно да използва и 16, и 32-битови инструкции". Това не е съвсем точно така. Виж как се сменя режима и ще разбереш. Или си на 16-бит или на 32-бит. Точно както беше при АРМ7/9. И пак да припомня че говоря за конкретна ситуация - функцията ти е или ще е изцяло 32-бит, или ще осереш пейзажа...

Ако още твърдиш твоята версия, че аз съм голям некадърник щом не знам всичко за МИПС и говоря наизуст - ми докажи го бе! При мен са 3 инструкции... дай да видим твоя МИПС код, надявам се няма да е много повече от 3 инструкции и няма да те затрудни.. И между другото тоя код е част от AES, т.е. ако тръгнеш да ми ползваш само 16-бит режим бъди така да ме убедиш че ще се справиш само с 8-те регистъра дето са ти на разположение... Според мен 10 са минимума, но ти винаги може да докажеш обратното





Аз не съм твърдял, че генерално е по-добър, . Освен ако съм почнал да забравям... ужас
А за ситуациите *в които* е по-добър писах надълго и нашироко....

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




Уф, колко пъти да казвам че това не го оспорвам! Усъмних в поставката ти да няма някакъв проблем за което съжалявам че се обадих, но това наистина няма връзка с това кой е по-по-най..
Единствената връзка беше, с това че не става с къв да е тест да се сравняват платформите. Като доказателство ти дадох и конкретна ситуация в която куртекса според мен ще е по-добър. Обясних и ЗАЩО. Затова и не приех предизвикателството ти "дай да си ги мерим"... Няма да е честно ако си ги мерим в натъмънена ситуация. Има си що-годе признати начини на тестване и там резултатите са ясни. Можем само да спорим кой тест е по-по-най... Аз най-много вярвам на Drystone, т.е. 20% разлика, ама изобщо не бих искал да споря... Мен повече ме интересува коя архитектура в какво е по-добра и къде куца, за да знам за какво мога да разчитам и кога трябва да я сменям

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

Сигурен съм че ако Майкрочеп си платят (достатъчно) нов редизайн ще смъкнат поне двойно консумацията.

Всъщност куртексите имат едно предимство - те по принцип са проектирани с отделни клок и power домейни. "междукурова" комуникация и т.н. Стандартизирано е още на ниво инструкции от най-дребия куртекс така че и програмистите "да свикват" с мисълта. А и АРМ наистина са се постарали, не просто да отбият номера както при твоите архитектури дето гледах някакво РРС със "само" 1W sleep. Ебати слийпа

13 са реално... + стек + адрес за връщане + РС = общо 16.
Ако можеш без стек и без процедури стават 15




Излъгал те е, или ти не си го разбрал...
Като правиш само регистър-регистър операции може и да го направиш с по-малко степени.
Но когато ползваш load/store според шината ти трябват определн брой клокове докато цъфнат данните. Конкретно при AHB дето се ползва и при АРМ и при МИПС реално данните идват на 4-я клок като броиш от началото на влизане на load инструкцията в конвейера.
Убаво, ама при малките куртексчета конвейера е 3 степени, а данните идват на 4-я клок... Очевидно имаме "малък" проблем. Тарикатите от АРМ правят разни трикове, примерно ако не използваш данните в следващата инструкция не се стал-ва конвейра. Другия трик е с multiple load което се използва много често, т.е. имаш 1 клок загуба, ама само 1 за няколко трансфера. И разбира се има случаи в които няма избор - конвейерът трябва да спре.
Всичко това не е чак такъв проблем. По-големият проблем е, че не могат да си позволят по-сериозни операции с "пресни" данни. За сравнение при МИПС както казах е същото, но с 5 степенен конвейер. Не им се налага тарикатлъци, напротив могат да мислят по-сериозни инструкции. Аз дадох пример с strcmp - една инструкция зарежда, на следващата сравняват и правят преход.
Не че АРМ не са могли да вкарат сравнение и преход едновременно, те даже имат 1 такава инструкция. Но това би било полезно най-вече след Load, а пък заради тарикатлъците им в повечето случаи данните им още не са валидни. И да имаше такава инструкция тя щеше да блокира конвейера.

Та така... трябва им по-дълъг конвейер. И те го имат, просто не и в М3-ките

Нали си говорим за консумация и технологии... Ето какво твърдят от Samsung:

“From 28nm to 20nm we’re seeing about a 35% performance improvement at the same leakage level. We’re seeing about a 50% leakage reduction at the same performance.”

Интересно е, че тестват новата технология с .... Cortex M0

Едва ли ще го пуснат някога на пазара, но сравнено с познатите ни чипове на 90-130nm е доста впечатляващо като размер, консумация и т.н... прочетете цялата статия

на мен вече ми е трудно да следя различните видове АРМ-ове...
преди имаше приказка: за всеки влак ще се намерят пътници. с АРМ-а май стана "за всеки пътник ще се намери подходящ влак". само дето, докато изчетеш разписанието, може да стигнеш и пеша
многото варианти безспорно са богатство. за хората, които правят ядра. потребителите на ядра се предполага, че правят пари от други неща, и задълбаване в типа на ядрото е ресурс на минус в общия случай.
без изобщо да споменаваме проблеми в реализацията на едно и също ядро от различни печатари, периферии, бъгове, ерати, документация.
ужасно лесно е да се загубиш в гората

Без да се съобразявам с късния час и количеството изпит алкохол,ама.........

темтата ОГЛУПЯ!

това се случи преди време още ...

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

Това ще мога да го направя след около месец. По едно време я мерих на PIC32 , но трябва да се
ровя из записките, на STM32 не съм я въобще мерил, щото се храни директно от USB порта и трябваше
да режа писти по Primer2 платката им.



Виж, Мирославе, спри и не се излагай повече, мислех да си замълча, обаче ме подразва факта, че продължаваш да си
говориш хуморески. M4K може едновременно да използва 16 и 32-битови инструкции, като под едновременно разбирай в потока му от инструкции са миксирани 16 и 32-битови, дали микса е във функция, или извън нея, няма значение, GCC-то ги смесва коректно без да се интересува от това. При ARM7/9 може и да се "осира" пейзажа ( приемам го на доверие ), но при M4K не. Ето ти директно доказателство от кода на mp3 плеъра, компилатора е GCC 3.xx нещо си:

На втория и петия ред между потока от 16-битови инструкции се мъдрят 32-битови. Както се вижда от първата
колона адресите са последователни, т.е. няма допълнителна инструкция за превключване на режима в ядрото.
В конкретната ситуация въобще не ме интересува как го прави ядрото, става без намесата на програмиста, дали
са му нужни допълнителни тактове не знам. Ако това не може да го прави ARM7/9/Cortex, не е вината в моя
телевизор.

П.П. Всъщност втората 32-битова инструкция трябва да е на 4-ти ред, но това е особеност на GCC-то, не дава
в листинга инструкциите по реда на тяхното разполагане в паметта. Бях отворил такава тема преди време,
май няма лекарство срещу тази подредба. Но това не променя с нищо ситуацията по миксирането на 16 и 32
битов код от M4K.

Ето ти документацията на МИПС

Превключването на двата режима (виж стр.24) става само с определени инструкции като "JAL, JALR, JALRC..." точно както и при АРМ7/9.
Едва ли би искал по средата на криптираща функция да сменяш режими правейки излишни преходи. Поне аз не виждам как ще го направиш без да осереш пейзажа...

BTW това, което си постнал е 100% МИПС16 код и колкото да ти е странно някои инструкции се кодират с 32 бита, въпреки че инструкшън сета се води 16-битов. И при АРМ е така - Thumb режима също има инструкции дето се кодират с 32 бита, така е и при още един куп архитектури...

както и да е... честно казано не очаквам да си признаеш грешките!

Е не съм като тебе, признавам си когато съм сгрешил, но в случая става дума за една грешка, а не за грешкИ. Да, кода излиза, че е 100% MIPS16e, а не както си мислех миксиран, подведе ме LW инструкцията. Пейзаж не може да се осере, защото практически е невъзможно да превключиш по средата на функция от един режим на друг, понеже инструкциите които изреждаш JAL, JALR и т.н. са инструкции за извикване на подпрограма. Остава варианта с вградена функция да се прави, но там не ми е много ясно дали има опция на компилатора за такива нужди, може и да има, не ми е трябвало, надали и ще ми потрябва да я търся някога.

Peace?

Wait a minute, this is not a war nor dig measurement , а пък за резултатите, които обещах, ще ги има черно на бяло.
Кога не се наемам да дам срок, може би месец, два, не знам точно кога ще ми остане време.

Между другото днес хвърлих поглед на Dhrystone, какво да ти кажа, не знам какво намираш стойностно в него. Това е ала-бала тест от 1986г., копиране на целочислени числа и умножение на една матрица, друго смислено не видях в него. Coremark ми се вижда по стойностен, защото включва доста повече неща, като Linked list, Matrix multiply, State machine, MD5, AES, DES и CRC. Намерих Coremark портнат вече за STM32 и PIC32, ще използвам тях, ще портна и Dhrystone. Ще включа и любимата ни вече
MP3 декомпресия

Имаме различни стилове. Аз винаги се съобразявам с това какво ползвам, не се притеснявам да пиша повечко асемблер. А когато бачкам на Ц/Ц++ си подреждам структури и всичко, така че да пасне и на архитектурата и на компилатора.
Докато ти като като гледам не се интересуваш много от детайлите. В това няма нищо лошо, даже за програмист от високо ниво твоят подход е по-правилен. Като хванеш някоя задача трябва да се концентрираш върху нея. А не както мен да мислиш за проблемите на компилатора.

Съответно на теб ти върши повече работа коремарка, защото той показва как ще се изпълни един универсален код, такъв какъвто ти се стремиш да пишеш. На мен обаче не ми върши работа, щото както казах си падам по код, който е оптимизиран специално за конкретната платформа. Разликите често са драстични, примерно ако ползваш printf("%d") на АРМ7 стандартната имплементация е около 100 пъти по-бавна от оптимизираната. Няколко такива неща в теста и за мен резултатът е ташак работа. Докато Drystone мери проста изчислителна мощ. Него не мога да го излъжа, нито пък той може да ме излъже.
Единственият недостатък е че мери една стойност, а не спектър за различните типове операции. Силата на кортекса е в логически и аритетически операции, куца му работа с паметта. МИПС-а пък е силен в сравнения т.е. логика и работи по-добре с паметта. Иронично, но точно щото е по-добър в паметта не му са нужни повече регистри. Както сам сигурно си се убедил вече, кодът ти е компилиран за МИПС16 и работи само с 8 регистъра. Докато куртексът в твоя тест има 5 регистъра в повече, обаче както казваш не му помагат особено