Jen pro uplnost: Chapu to dobre ze M3 pro mod preruseni nema dedikovane registry takze sice se do prerusovaci rutiny dostanu za takt ale nez pak ulozim registry a nactu do nich promenne tak stejne tak nejaky ten takt ztranim?
Jeste mi neni jasne jak je zajistena prerusitelnost LDM a STM. To ma procesor ve stavovem slove jeste nejake bity ze kterych pak po navratu (a obnoveni stavu) zjisti kde ma pokracovat?
Nebo se to dela jako s nasobenim ze se rozpracovana instrukce zahodi a pote spusti znovu? To by ale znamenalo ze treba STM nesmim pouzit pro zapis dat do periferie, protoze by to opakovani mohla spatne pochopit.
U LDM a STM si myslím/jsem si téměř jistý, že se provede znova. Určitě to není jako na m68k10+/CPU32, kde se ve stavovém slovu ukládá bitmapa rozpracovaných registrů. LDM a STM se nesmí použít pro přístup k periferiím, kterým zopakování vadí. Zároveň mnoho ARMů již od ARM920TDMI obsahuje errata, kdy LDM bez zapnuté cache za určitých specifických okolností může selhat. Je zajímavé, že problém se myslím táhne až ke Cortexům-A.
Co se týče přerušení, tak Cortex-M provede uložení stavu na zásobník příslušný přerušovanému/původnímu režimu běhu (viz minulá diskuze o nemožnosti implementace stránkování i kdyby byla MMU). Dedikované shadow registry nemá. Do link registru se uloží speciální návratová adresa, samá F a na konci info o přerušeném režimu. Zároveň na zásobník se ukládají i ty registry, které jsou podle Thub-2/EABI clobbered/clobberable. Výsledkem je příjemné zjednodušení, že obsluhu přerušení lze psát jako běžnou C funkci. Normální pokus o návrat, přiřazení speciální hodnoty 0xffffff.. do PC vede k spuštění sekvence operací vedoucích k nastolení stavu CPU před přerušením. Málem by člověk řekl, že na drese 0xffffff.. je kousek ROMky, který tu sekvenci LDM s vyzvednutím stavu provede, ale přímo takto to nebude, je potřeba dekódovat tu stavovou část. Ale určitě je "mikrokód"/stav dekodéru isntrukcí, který operaci zápisu speciální hodnoty do PC na LDM převede,
Co se týče rychlosti, tak jsem prezentace jak je to extrémně rychlé někde viděl, je možné, že do taktu se začne přerušení řešit, ale ukládání bude trvat celkem dlouho a pokud zrovna cache (u M7 myslím může být) nebo akcelerátor (cache) na úrovni Flash nebo řadiče externí paměti nemá potřebnou polužku VIM tabulky a kód zapamatovaný z minule, tak to zase hezkou řádku cyklů přidá. Mimochodem, cachování na úrovni řadiče SDRAM se mi na NXP LPC docela líbí. Tím, že je to až na hranici čipu, tak i vnitřní periferie a DMA vidí obsah paměti přes cache, využijí burst načítání a nemusí se řešit koherence, ale je to jen 16x16 byte a dobré pouze pro malé čipy. Na velkých je naopak při více jádrech nebo opravdu rychlých koprocesorů nutné dostat cache (alespoň L1) přímo k jádrům, aby se snížila zátěž sběrnic.
Silicon Errata to MC9328MXS
Modules: ARM920T AHB Wrapper
Failure: LDM instruction fails to load non-cached data from memory.
Errata k Ti embedded chipu
ARM Core
Cortex-M3 / Cortex-M3 with ETM (AT420/AT425)
Errata Notice
382859: Secondary interruption may corrupt ICI continued Thumb-1 LDM with base-in-list.
Chip Errata for the i.MX 6Dual/6Quad
IMX6DQCE Rev. 5, 06/2015 ERR003730 ARM: 743623—Bad interaction between a minimum of seven PLDs and one Non-Cacheable LDM can lead to a deadlock
Jsem si téměř jistý, že jsem podobné problémy viděl v Erratech i když jsme vyvíjeli systém s iMX53 a dalšími. Obecně LDM z periferií a před tím, než je zapnutá cache tak i z hlavní paměti může mít za určitých podmínek problémy. Přímo jsem žádné naše problémy na tento mapovat nedokázal, ale je to věc souběhů často s takovými pravděpodobnostmi, že je to problém odchytit. Určitě použití LDM do periferií bych nedoporučoval.
Diky za odkaz. To je tedy prekvapeni. Celkove jsem zatim ARM povazoval za celkem cisty a spolehlive navrzeny procesor. Zajimalo by me jestli za to muze nekdo z vyvojaru ARMu, ze to spatne vymyslel, nebo jestli je to zpusobeno temi pridanymi periferiemi od FreeScale.
Jinak jsem si ted znovu osvezil ARM7TDMI technical reference a ARM v5 architecture reference manual a tam o LDM/STM do periferii normalne mluvi, jen se nesmi nacitat pres hranici 1KB, coz nejak souvisi s velikosti stranek pameti (kdyby jedna stranky byla cacheable a druha ne tak neni specifikovano poradi). Ale tak vetsina periferii stejne neni namapovana, takze to nevadi.
LDM/STM (a IT) ma stavove bity v EPSR, po navratu z preruseni se pokracuje tam, kde se prestalo
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/ch02s03s02.html