Názory k článku Architektura mikroprocesorů OpenRISC

Skvělý článek, díky!

No hezky no.
Ale ja jen, ze datasheet treba k stm32f4 ma 1800 stranek a z 90% je to popis registru....takze ocekavam serial s poctem dilu adekvatnim brazilske telenovele...

stm32f4 je urcite postavenej na jadru ARM, ne OpenRISC. neco malo s tim cipem mam co do cineni a je to ... hmm ... proste klasicke STM. Ruznych modulu spousta, cena ok, ale zrovna dokumentace pokulhava :(

Tak koukám zrovna do DS. O jádru tam není nic, registr ani jeden. Jestli ty nemyslíš "STM32F4 Reference Manual", to ale není datasheet a týká se to periferek, ne jádra.
Pokud jde o jádro k STM32F4, zatím nejlepší zdroj, na který jsem narazil, je http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Cihgjeed.html

Netvrdím, že jsem to prolétl zcela pozorně, ale proč jsou jména všech instrukcí uvozená "l." ?

Hezký sen: Koupit si základní desku s touto CPU a nainstalovat běžné Linuxové distro :-)
Je vůbec šance, že by se mohl splnit?

s touto architekturou nevím, ale s podobnou ano
https://www.root.cz/clanky/hi-five-unleashed-prvni-linuxovy-pocitac-s-procesorem-risc-v/

prečo nie - predstavte si open source CPU - ktorému môžete veriť - narozdiel od zabugovaných Intel CPU.

Bugy dokážu pochopit, navíc je sporné, zda věci jako Meltdown apod. jsou bugy nebo spíš vlastnost architektury(kolik těch dnešních chytráků by takové možné postranní kanály před desítkami let napadly...)
Horší jsou záměrně vestavěné redundantní záležitosti, kdy si nemůžete být jist, co vám v tom procesoru ještě kdesi na pozadí, běží. Fakt mě neteší, když vím, že tam jede dokonce celý Minix. Co dělají ty procesy, které obsluhuje? Nikdo neví...až na pár lidí, vázaných NDA... A můžete se jen dohadovat, jaké to má cíle.
To by se otevřený procesor opravdu hodil. Může být klidně dražší.

Úplně mu můžete věřit jen do výše vlastních znalostí. Pak už musíte jen věřit ve schopnosti těch, kteří provádí audity procesoru.

Ale zatloukání problému je vzhledem k otevřenosti téměř nemožné.

Jedna věc je návrh ve VHDL, druhá věc je návrh masek pro výrobu, třetí věc je, jestli někdo použije tyhle, nebo jiný masky...

Spíš než zapojení bych kontroloval chování. Zapojení, rozhraní, traffic třeba na Ethernetu, pokud je na čipu ETH_MAC,... A pak ověřit zdrojáky systému a sám si to sestavit ověřeným kompilátorem s ověřeným linkerem a uchovávat jenom na SSD s auditovaným firmwarem. Btw, co uděláme s firmwarem ve WiFi modulu a periferkách?

zaujímavý postreh - open source hardware by bol riešením - ale otázne je či by bol dostupný ohľadne všetkých komponentov/pe­riférií.

To můžeš a mělo by se to u kritických aplikací nějak takto dělat. Jenže tím neodhalíš situaci, kdy třeba Ethernetové rozhraní čeká na konkrétní rámec, který ale například dorazí až ve chvíli, kdy pro někoho začnete být zajímaví, tedy klidně za několik let po nasazení čipu na zakázkách.

Btw můžeme věřit čistému FPGAčku? pokud jo (no...), tak si tam můžeme syntetizovat klidně i ten ethernet.

asi nemame tak kvalitni fet jako mate v hornich uhrech... ale patrne zalezi jak definujete duveru...

Možná byste u vás ve východním Německu měli začít brát něco kvalitnějšího asi vám to svinstvo vyvolává nějaký kognitivní problémy.

Na hraní "stačí" například DE0-Nano Development and Education Board (link nedávám, Petr to nemá rád :-). Poměr cena/výpočetní výkon je samozřejmě u FPGAčka horší než u optimalizovaného SoC, ale skutečně se s tím dá vyhrát dobře.

Není ta tabulka v sekci 3 špatně? Třetí řádek by měl mít podle mě "Zachován při volání" hodnotu "ne", protože "pracovní registry, mohou se změnit". Teda přišlo by mi to takto logické :)

Ktery FPGAcko nebo primo ktery kit jste zkouseli prosim? VHDL s OR jsem si stahnul, ale nikde jsem se nedocetl, jestli to treba pujde na icoBoardu, ktery asi budeme mit na skole.