0 1
Е, козоеба поне ти обясни що е то прекъсване. И да не забравиш да сложиш reti накрая! :)
Иначе това с къндишънъл екзекюшън на всяка инструкция на arm отдавна го няма в новите архитектури. Най-близкото е векторните предикати в SVE.
P.S. Тези дни се забавлявам да се опитвам да пиша задачката от темата "neon" за SME за М4, но засега нямам особено голям успех. Имам имплементация, която би работила на SVE, но е доста бавна на SME-то защото използва скаларни регистри.
Да. Говорим за чипа в който се осъществява комуникацията с картата с всичките му там секюрити алгоритми. Та той си говори от една страна с картата, от друга страна с един голям SoC на който се търкаля андроид. И това не е шир потреба процесор а специално направен за тази цел от Броадком - май беше Кортекс А7. Защо бяха решили да е със Зефир РТОС още си нямам на идея ама в края на краищата трябва да правим за квото ни плаща клиента а не философстваме за екзестенциалния смисъл на това или онова. Та в този РТОС и без нищо да правиш вървят няколко нишки. Самите прекъсвания в повечето случаи се обработват в отделна нишка за да не бавят нещата и да се върнеш бързо от прекъсването. Писането на логове също не чака да се изпрати всичко през серийния порт а ги трупва в един голям буфер от който отделна нишка ги вади бавно един по един и ги праща през бавен сериен порт. В този чип е навряна и защитената памет в която се пазят разни секретни ключове ползвани при комуникация с чипа на картата и после със самата банка.
Исках да пиша добавя към по предния ми коментар още малко ама заради на Жони 2000-те таймери нямаше как та дописвам тук:
Отделен въпрос е, че на практика нямаш двойно сбиване на кога а по скоро се свива с около 30% заради по малкото регистри с които скопените инструкции оперират чест трябва да се добавя втора, че и трета инструкция за да емулираш това което би станало с една условно изпълнима 32 битова инструкция. Преходите също, често изискват 2-3 инструкции и 32 битови данни наврени около мястото от което искаш да направиш преход. Като пишеш на Ц тези неща са ти спестени. Но като погледнеш генерирания код като дебъгваш на асемблер направо се хващаш за главата.
Нещо невярно ли написах, или просто е заревала от самота, макяти проста мерзавска еничерска?
Да не си педал, тъй настървено имаш мерак да те унижават?
Ейпъл - чек!
Инокулация и 3 бустера - чек!
Лгбтк+++ - ???
Що са ви 32 битови, поне ти мож ли ми обясни? Що не 16 да речем.
сега пробвах - моя процесор е кортекс м0 и компилатора дава грешка ако махна thumb опцията (тартгета не поддържа арм режим вика), обаче като сменя на кортекс-а7 няма проблем и генерира 32битови инструкции, т.е. който иска кеф ти 32 кеф ти 16.
10: e590c008 ldr ip, [r0, #8]
14: e18cc002 orr ip, ip, r2
18: e580c008 str ip, [r0, #8]
1c: e590c010 ldr ip, [r0, #16]
20: e18cc002 orr ip, ip, r2
24: e580c010 str ip, [r0, #16]
аз все пак мисля че проблема който си наблюдавал е някакъв много много специфичен и е само за конкретния процесор, иначе това щеше да е известно и никой нямаше да ползва тхумб опцията
между другото пробвах каква най-голяма честота мога да докарам с пряко клатене на пин с тоя процесор и резултата е 6 мегахерца, като за целта трябва да пишеш в целия порт, а не в отделен бит. пиковете имат инструкция битсет/цлр която за микроконтролери е много полезна, ама на ти арм, нали е стандартен сет правен за нормални процесори, няма такива благинки.
кода който се генерира е:
18: 2100 movs r1, #0
1a: 2208 movs r2, #8
1c: 6019 str r1, [r3, #0]
1e: 601a str r2, [r3, #0]
20: e7fc b.n 1c <main+0x1c>
компилатора правилно се сеща да си кешира константите и така слиза до само 3 инструкции. честотата е точно 6 мегахерца, което значи че цикъла е 8 клока като нулата е видимо по-къса от единицата. това ще рече че прехода отнема време колкото две инструкции, а всяка инструкция се изпълнява за два клока.
Ааайде пак. Говорим си за генерални, принципни въпроси, или за няква малоумна имплементация на нещо-си, от която ти си правиш генерални изводи?
0 1