Názory k článku Architektura mikroprocesorů OpenRISC (dokončení)
-
atarist (neregistrovaný)
Čistě teoretická otázka pro zamyšlení. Pokud se někdo rozhodne udělat multicore čip z RISC-V nebo OpenRISCu, bude to díky veřejnému review odolné vůči těm chybám a útokům, o kterých si můžeme přečíst například hned v článku vedle? Nebo je prostě multicore (se sdílenou L2/L3 cache) vždycky "odsouzen" k tomu, aby tam byly mezi jádry info leaky?
-
Petr M (neregistrovaný)
Díky veřejnému review rozhodně ne. Že to vidí víc očí neznamená, že si někdo chyby všimne a pokud autor připomínky ignoruje a stejně si to udělá podle sebe, bude tam i odhalená chyba. Navíc opravou jedné chyby se dá nadělat několik dalších a stane se toho nikdy nekončící cyklus. Navíc lidí, co znají HDL jazyky, není tolik, jako těch, co znají C a další jazyky pro SW, takže jich tam asi moc koukat nebude.
Pak je otázka, jak by se to všechno propojilo. Mám tady třeba Cortex-M4 s extra 64kB SRAM, dostupnou jenom z jádra (ani DMA se tam nedostane). Pokud by L1 náležela jádru, L2 byla připojená stejně jako ta CCM, bude to jiný, než když do L2 a L3 můžou oba.
No a mimo sběrnice existuje i plno dalších možností. Třeba se jedno jádro může interně skrz periferní registry, zmocnit debug unit a vysávat data... Takže taková debata bez konkrétních lidí, konkrétního use case a konkrétního designu je hodně, hodně teoretická.
-
atarist (neregistrovaný)
No já jsem to myslel spíš tak, že komunita okolo OpenRISC a RISC-V není tlačena k tomu, aby například na další kvartál vydala nový čip, takže (opět například) nápady ohledně HT může odložit s tím, že se to musí odsimulovat a nechat chvíli uležet. Tedy pokud má HT opravdu takový význam u risců, asi ne. S tou Lx cache je to pravda, tam je to asi problém by design od začátku :/
-
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ý.
ČLÁNKY DO MAILU