Vlákno názorů k článku Architektura mikroprocesorů OpenRISC (dokončení) od Petr M - Pěknej článek, ale měl bych pár připomínek. Je o...
-
Petr M (neregistrovaný)
Pěknej článek, ale měl bych pár připomínek.
Je o OpenRisc. Hned v 1. kapitole se píše "To, že výpočet některých operací trvá déle, než jeden strojový cyklus, představuje poměrně velký problém, zvláště pro RISCové procesory. Při návrhu různých RISCových architektur se inženýři s tímto problémem vypořádali různými způsoby. Pěkným příkladem může být řešení použité u architektury MIPS-I, ..." a v tom okamžiku ujede od OpenRISCu ke všemu a už se to nevrátí. Takže v článku o OpenRISCu se dozvíme víc o implementaci v MIPS, SPARC a starých ARMech. Nakonec nevíme ani jakým způsobem se výsledek hodí do registrů (násobení 32x32b dá 64b), ani jak se vlastně s tím zpožděním CPU vyrovnává. Tohle téma by si rozhodně zasloužilo samostatný článek s porovnáním této problematiky.
Kapitola 12, týkající se Risc-V v článku o OpenRISC je nějakým omylem?
O SIMD a saturaci už s tady podrobně před pár lety psalo, netřeba kopírovat vlastní dílo, stačil by úplně odkaz. A že jich pro studium je:
- https://www.root.cz/clanky/podpora-instrukci-typu-simd-na-mikroprocesorech-arm/
- https://www.root.cz/clanky/instrukce-typu-simd-na-mikroprocesorech-risc/
- https://www.root.cz/clanky/instrukce-typu-simd-na-mikroprocesorech-risc-2-cast/
- https://www.root.cz/clanky/instrukce-typu-simd-na-mikroprocesorech-risc-3-cast-mips-3d-a-vis/
- ... -
Ono je spousta zajímavých řešení toho problému. Někdy před 15ti lety jsem dokonce pracoval s DSP, které to zpoždění neřešilo v hw, ale v kompilátoru.
Byla to super věc, člověk věděl, že v prvním taktu zpracování se dekóduje instrukce, pak někdy ve třetím se načítají operandy z registrů a tak to pokračovalo a každá instrukce měla detailní popis toho, co kdy na které vnitřní sběrnici procesoru a s kterou částí alu v jaké fázi zpracování dělá. Takže šlo napočítat, jak za sebe naskládat instrukce, aby to běhalo rychle a aby ty instrukce mezi sebou nekolidovaly na vnitřních sběrnicích procesoru.
Instrukce se načítaly a řadily do fronty po jednom taktu. A pokud by docházelo ke kolizím, tak kompilátor vkládal nopy, aby nechal dalším instrukcím prostor k nějaké činnosti. -
Jj, TMS320C6xxx, nevzpomenu si už přesně, tuším TMS320C67xx. Určitě umělo počítat ve floating pointu.
A ještě přihodím popis, kdyby to někoho zajímalo. V datasheetech mají běžně vnitřní strukturu rozkreslenou dost nepřehledně, na straně 5 tady: http://www.ti.com/lit/an/sprabf2/sprabf2.pdf je docela hezkej vysokoúrovňovej pohled. A ano, má dvě datové cesty, kde každá má vlastní sadu registrů a 4 prováděcí jednotky, které pracujou nezávisle na sobě. Datové cesty si navzájem i vidí do registrů, pokud je to potřeba.
-
Pavel TišnovskýZlatý podporovatelDík za info. Tyto DSP mi jsou sympatické, člověk se na nich aspoň pořádně naučí C (a odnaučí se předpokládat, že některé věci jsou "přece jasné" - například šířka charu atd.)
-
Mě jsou taky sympatické. Řadu věcí vyřešili atypicky a přesto dobře. A to se netýká jen procesoru jako takového, mají řadič DMA, co dokáže dělat i složitější operace, jako třeba transpozici matice (umí cykly, offset v každém kroku a offset po každém cyklu).
A současně mají i solidní výpočetní výkon, nízkou spotřebu, vývojové prostředí se dá používat, jsou k tomu knihovny a rtos, vývojový kit není superdrahý, ..Dneska, kdybych chtěl zkoušet něco nového, tak bych zkoušel asi ty dsp od parallelly, mají pořešenou kompatibilitu s linuxem a pythonem. Jenom jsem zatím nedal dost času do zjišťování, jestli lze jejich dsp (součástky) nějak rozumně koupit a tak už několik let odsunuju nákup a pokusy.
-
oprava: parallella se jmenuje deska, dsp je epiphany, http://adapteva.com/docs/epiphany_arch_ref.pdf
-
Pavel TišnovskýZlatý podporovatel
Díky za feedback a připomínky. Ono to vzniklo tak, že jsme se na OpenAltu bavili o článcích a někdo nadhodil, že jsem sice napsal o OpenRISCu, ale proč ne o RISC-V, který samozřejmě už byl popsán (tuším 3 články?). A že by bylo dobré ty návrhy nějak porovnat, protože se - i když se v obou případech jedná o RISCy s 32bitovými instrukcemi s tříadresovým kódem a 32 GPR - od sebe tyto čipy jinak dost odlišují. Asi budu fakt spíše linkovat starší články :-) Ono toho totiž k OpenRISCu už není moc co dodat, protože komprimovanou instrukční sadu zatím nenavrhli a i FP je poměrně jednoduchý a přímočarý.
