Zamyšlení kam směřovat s výukou předmětu Architektury procesorů.
V první řadě děkuji všem za zájem o předchozí zápisek a kultivovanou diskuzi. Takto velký zájem jsem vůbec nepředpokládal. Velmi mě potěšily příspěvky s názory na výuku a i mě těší, že se ukázalo, že se na ABClinuxu schází lidé se zájmem o programování a diskuze se přirozeným způsobem přenesla k technickým tématům, která zajímala diskutující nejvíce. Jediný ne zcela korektně napsaný příspěvek byl, co se týče informační hodnoty, také k věci. Naplňuje mě to optimizmem.
V tomto zápisku chci prezentovat, jak jsme Architektury počítačů (APO) učili v minulosti a otevřít diskuzi jakým směrem se vydat dále.
Byl bych rád, pokud se kromě hodnocení a kritiky v diskuzích objeví i nápady, které by nám pomohly výuku zlepšit. Vzhledem k tomu, že tento článek píši právě pro získání zpětné vazby, nikoliv jako předchozí odlehčený zápisek z výletu, tak by mi pomohlo, pokud se diskuze udrží u tématu. Pokud se vyvine diskuze k tématu výrazně nesouvisejícími, prosím, založte někdo další zápisek a přidejte odkaz, kde v diskuzi pokračovat.
I na základě zpětné vazby studentů, jsem se již pokusil v roce 2017 diskuzi k předmětu otevřít na diskuzním fóru naší fakulty. I přes přidání odkazů do odpovědí anket k výuce se nikdo (ani z těch kritizujících) ze studentů do diskuze jak pomoc v pochopení a absolvování předmětu svým následovníkům (nebo i sám sobě v případě opakovaného zápisu) nezapojil. I nyní se mohou studenti a kolegové zapojit do diskuze na fóru. Ale na základě vlastně všech mých příspěvků někdy od roku 2006 na ABClinuxu předpokládám mnohem cennější diskuzi zde.
Kormě prostoru pro diskuzi chci dále zápiskem nabídnou i možnost se výuky našeho předmětu i pro zájemce mimo ČVUT FEL zúčastnit jako studenti v rámci kurzů celoživotního vzdělávání (zápisné do předmětu B3B35APO je 3250 Kč) nebo jako cvičící.
(Převzato převážně ze zápisku na fóru FEL z 24.09.2017)
Moje zkušenost a představa studia (již od opuštění gymnázia) a výuky na vysoké škole vychází z modelu, že na školu přichází studenti, kteří si chtějí rozšířit/získat znalosti v určitém, ideálně širším, směru. Na základě zkušeností, odhadu jejich možností a potřeb základů pro zvládnutí dalších předmětů je pak zvolený určitý okruh znalostí, který pokryje do akreditace zařazený předmět. Stejně tak je zvolená požadovaná úroveň minimálních znalostí a naopak, co může a má předmět poskytnout k rozvoji těch, kteří patří k těm nejlepším a do budoucna mohou obor rozvíjet dále za omezené hranice znalostí a schopností jejich současných učitelů.
Přitom v žádném případě nelze kýženého výsledku dosáhnout přístupem, jsem zákazník, nakupuji znalosti, a je na vás, vyučujících, abych je měl.
Přemýšlení v daném oboru je trénink a přesto, že rozhodčím pro daný předmět jsme my, jeho vyučující, tak se více považuji za partnera studentů, který investuje spolu s nimi úsilí do získání vědomostí, překonání nastavené laťky a osobního rozvoje tak daleko, jak to danému studentovi jeho schopnosti umožňují. Jsem přesvědčený, že ta část studentů, která na tento model přistoupila, byla i s naším předmětem, tak jak jsme ho koncipovali, spokojená. Do kurzu se nám přihlásilo i několik studentů z magisterského studia, kteří předmět APO neabsolvovali a cítili potřebu znalosti získat a to i přes to, že již řešili jiné, náročné projekty, a věděli, že vstupují do náročného kurzu, kterému budou muset čas věnovat.
Ano, není ideální, že rozhodčím kurzu jsou přímo jeho vyučující, jak vím od kamarádky, která vyučuje jazyky, tak v jejich smluvně placené výuce je zvykem, že úspěšnost firmami nasmlouvaného studia prověřují jiní lektoři, někdy i školící firmy, než prováděli vlastní výuku. Přitom u nás je požadovaná úroveň k absolvování jednotlivých testů i celku přibližně 50% správných odpovědí/znalostí. Byl jsem překvapený, že při studiu čínštiny neznalost třeba 2% z tisíců znaků znamená neuspěl. Ano náš obor je náročnější na logické myšlení atd. ale i tak je 50% velmi nízká hranice.
Na druhou stranu jednotlivou zkoušku na vysoké škole stejně považuji spíš jen za měřený trénink, reálným měřítkem je úspěšnost v profesním životě, v menším měřítku pak připravenost a znalost základů pro další kurzy, zvládnutí samostatného vývoje, výzkumu v rámci řešení absolventských prací, případně poměření sil v studentských soutěžích a testech. A mezinárodní konkurence je na vysoké úrovni, když se program OI zaváděl, studovali jsme radou předložené příklady z Computer Science Test Practice Book (GRE). A byli jsme překvapeni náročností otázek a hloubkou požadovaných znalostí pro oblast HW, které musí mít i studenti především programátorsky zaměřených oborů. Pokud vím, tak rada OI i našim studentům testy po absolvování OI bakaláře před lety zaplatila, ale ukázalo se, že v konkurenci obstáli hůře, než jaký byl předpoklad. Za roky, co kurz APO s kolegy vedeme a rozvíjíme, rozšiřujeme materiály atd. se úroveň požadavků mírně zvedá, ale stále si myslím, že zdaleka nedosahujme úrovně, která je nutná k efektivnímu využití současného HW a ani perfektnímu zvládnutí GRE testů.
Dnes děti na základní škole odmítnou rodiči nabízený čtyřjádrový mobilní telefon, a raději rozbijí prasátko, aby si mohly doplatit cenu a koupit osmijádrový (reálná zkušenost kolegy). Přitom největší nezájem o předmět vnímám právě u studentů, kteří se vidí jako budoucí významní programátoři mobilních a webových aplikací a cloudových technologií. Neumím si představit, jak chtějí tito, často na svoje schopnosti až příliš spoléhající, programátoři takovéto aplikace navrhovat.
Předmět APO nabízí opravdu jen ty základní nezbytné znalosti nutné k pochopení běhu a ovlivnění výkonu aplikací na jednom procesoru. Z paralelismu se zabýváme jen překrývajícím se/zřetězeným zpracováním na jednom procesoru a v otázkách se omezujeme v podstatě jen na jeden pětiřezový model určený pro jednu architekturu. O problémech souvisejících s využitím více procesorů v rámci jedné aplikace, případně pro běh operačního systému se zmiňuji jen přehledově v druhé části přednášek a to spíš proto, aby studenti se zájmem věděli, kde hledat, případně mohli navázat na námi předané znalosti v rámci některého dalšího předmětu. Přitom ignorování fyzikálních základů, pravidel dostupnosti dat z různých jader, omezenosti vyrovnávacích pamětí atd. obvykle vede k zásadní degradaci výkonu při použití více procesorových jader (10x, i 100x). Je celkem pravděpodobné, že špatně implementované programy a nevhodně vybrané algoritmy (to je již spíše mimo náš předmět) mají za následek zbytečnou potřebu 50% ale možná i 80% celkové energetické spotřeby výpočetní techniky na světě. Takže kromě toho, že si i samotní kritici potřeby námi nabízených znalostí určitě ztěžují i na své vlastní telefony za malou výdrž a pomalou práci, tak jsou špatní programátoři i reálnou světovou ekologickou hrozbou. Podle některých odhadů již spotřeba výpočetní a komunikační techniky přesáhla 10% celosvětové spotřeby elektrické energie a číslo se bude zvyšovat. Například v autonomním vozidle zbytečně plně zatížený systém Nvidia Drive PX2 spotřebuje 250W. To je podle mého velmi hrubého odhadu na tuto jedinou jednotku více než 1% až 2% výkonu nutného pro udržování rychlosti 100 km/h.
Přitom techniky pro dobrou škálovatelnost algoritmů vyžadují dobré znalosti paměťového modelu procesorových architektur při návrhu knihoven a běhových prostředí a pak znalost jak přenositelně, efektivně a správně tyto základy používat. To druhé je důležité pro každého programátora, to první jen pro ty nejlepší, kteří mají na to se zúčastnit vývoje takových prostředí a operačních systémů. Předpokládám ale, že ČVUT nechce být jen generátorem levných kodérů aplikací na míru, ale chce aby její nejlepší studenti zvládli vyvíjet nové technologie, programovací jazyky, operační systémy a rozvíjet obor.
Historicky na Elektrotechnické fakultě existovaly dva týmy spolupracující na výuce procesorové techniky na Karlově náměstí. Pro obor Elektrotechnika a informatika tým na Katedře řídicí techniky vedl pan docent Jiří Bayer a pan docent Jan Bílek (přespříští týden slaví 80. narozeniny, tak mu zde chci popřát hodně zdraví a budu rád, pokud se další přidají). Na Katedře počítačů pak po odchodu kolegů na Fakultu informačních technologií pak s relativně omezeným týmem setrval pan docent Miroslav Šnorek (díky za knihu Připojování periferií k PC, podle ní jsem si nadrátoval ISA kartu se sériovým portem pro myš a navíc s budičem RS-485, počátek projektu uLAN). Při přípravě oborů Kybernetika a robotika (KyR) a Otevřená informatika (OI) se dohodlo spojení sil pod vedením pana docenta Šnorka. Na přípravě jsem se sešel s Michalem Štepanovským. Panem docentem byla za základ kurzu zvolená učebnice Computer Organization and Design, The HW/SW Interface (CA) kterou napsali páni profesoři Patterson a Henessy. Při přípravě materiálů pan docent komunikoval i přímo s autory a pro procvičení a pochopení základních principů procesorové činnosti byl zvolený simulátor Mips It, jehož instalační soubory byly i na CD přiloženém ke knize.
Náplň předmětu se zaprvé odvíjela z prostudování podobných kurzů na světových univerzitách a dále pak především od požadavků ke státním zkouškám oboru OI a ty vycházely z požadavků na studenty na amerických a kanadských univerzitách ‒ Computer Science Test Practice Book (GRE). Dostali jsme k dispozici materiály k přednáškám a prezentacím autorů knihy.
Výsledná náplň není zaměřená na předvádění novinek (na mírně pokročilejší techniky, které jsou základem zpracování instrukcí na moderních procesorech je zaměřený předmět Pokročilé architektury počítačů ‒ B4M35PAP), pár zajímavostí je jen pro motivaci uvedeno v úvodu. Za zásadní cíl předmětu si bereme ukázat studentům základy odpovídající návrhu a vzestupu RISC procesorů po roce 1980. Právě tyto základní znalosti jsou nutné pro schopnost alespoň pochopit techniky pokročilejší a bez nich není možné porozumět alespoň základním faktům při čtení technologických novinek pro veřejnost o procesorech jako je Ryzen nebo RISC-V, natož vědeckým článkům nebo se dokonce do vývoje zapojit. Je trochu s podivem, že principy RISC byly používané již dříve v šedesátých letech minulého století (CDC 6600 ‒ počáteční počiny Seymoura Craye), ale nebyly takto nazývané. Později byly tyto principy opuštěné. Důvodem byly velmi omezené možnosti prvních integrovaných obvodů integrujících celé mikroprocesory. Dále pak snaha o snížení toku objemu načítaných instrukcí vedla ke kombinaci přístupů do paměti s aritmetickými operacemi v jedné instrukci a tím vzniku komplexních (CISC) procesorů s nutností využít mikrokód a až zpětně dochází ke korekci vývoje směrem k RISC a SIMD. Velmi dobrou ukázkou je vývoj architektury x86, u které lze ale předpokládat, že díky kompatibilitou fixovanému kódování instrukcí nelze mnoho chybných rozhodnutí již napravit.
Schopnost porozumnět dokumentaci a informacím o současných procesorech je jen jedním z cílů, další je naučit i budoucí programátory ve vysokoúrovňových prostředích a jazycích, jak se vyvarovat základních chyb, které vedou ke zbytečnému zpomalení programů. Znalosti poslouží i těm, kteří se chtějí zabývat stavbou vlastních, na mikroprocesorech založených, řídicích jednotek (například pro roboty nebo do automobilů).
Vlastní přednášky začínají seznámením s reprezentací dat, především numerických, čísel v paměti počítače (APO:Susta19:1, APO:PisaStepanovsky18EN:1, ODP). Vysvětlené je počítání s čísly bez znaménka a se znaménkem v binární soustavě a poté reprezentace (podmnožiny) reálných čísel (plovoucí řádová čárka a IEEE-754). U počítání s čísly v plovoucí řádové čárce (APO:Susta19:2, dříve v 1) ukazujeme vznik nepřesností a chyb. Odpovídající kapitola knihy ‒ CA:3 - Arithmetic for Computers. První kapitolu (CA:1 Computer Abstractions and Technology) částečně pokrývá velmi rychlý úvod a přehled. V běhu LS 2018/2019 přidal doktor Richard Šusta základní informace z kapitoly CA:2 Instructions: Language of the Computer do přednášek (APO:Susta19:2). Dříve jsme spoléhali na pochopení jazyka symbolických adres (assembleru) z výkladu vystavění jednocyklového procesoru dohromady s materiály a vedením studentů na cvičeních. Postupem zespoda nahoru je z jednotlivých funkčních bloků podle požadavků na prováděné operace vystavěný procesor (CA:4 The Processor)(APO:Susta19:3, APO:PisaStepanovsky18EN:2, ODP). Přednáška končí přechodem od hardwardské architektury na architekturu se společnou pamětí, která již umožňuje nahrání programu operačním systémem běžícím na shodném procesoru. Zvětšení a vyjmutí paměti z čipu vede k problémům s její rychlostí a nutnosti se zabývat hierarchií pamětí (CA:5 Large and Fast: Exploiting Memory Hierarchy).
Po vyhovujícím (vyžaduje kvalitně napsané programy, správně volené algoritmy a datové struktury) vyřešení problémů s rychlostí pamětí (APO:Susta19:5, APO:PisaStepanovsky18EN:3, ODP) se vracíme k urychlení vlastního vykonávání instrukcí ‒ zpoždění na kombinační logice lze rozdělit do stupňů a překrýt výkon za sebou jdoucích instrukcí ‒ zřetězené zpracování (opět CA:4 The Processor) (APO:Susta19:7, APO:PisaStepanovsky18EN:4, ODP). Dále se zabýváme predikcí skoků (opět CA:4 The Processor)(APO:Susta19:8), voláním funkcí (APO:Susta19:10, APO:PisaStepanovsky18EN:9, ODP) tak aby bylo možné předávat argumenty a návratové hodnoty mezi funkcemi, zkompilovanými různými kompilátory například do knihoven nebo běhových prostředí. Další krok v oddělení aplikací od běhového prostředí je použití operačního systému. Systémová volání jsou vysvětlena na příkladu jejich implementace v jádře systému GNU/Linux.
Protože procesorový systém lze smyslupně využít pouze tehdy, pokud je možné do něj data pro dávkové zpracování nebo ze senzorů dopravit a poté výstupy nějak reprezentovat nebo aplikovat na aktuátorech tak přidáváme popis vstupně výstupního systému (APO:Susta19:, APO:PisaStepanovsky18EN:5, ODP). Nejdříve v nejjednodušší formě periferie mapované do paměťového adresního prostoru, poté již s obecnějším systémem PCI, který umožňuje vkládat karty s možností automatického zjištění jejich typu a požadavků na adresové rozsahy. Řídicích registry karet jsou adresované topologicky (podle pozice ve slotu). Adresové rozsahy/mapování funkčních skupin registrů a pamětí se nastavuje přes řídící registry. Není tedy potřeba používat žádné manuální nastavování propojkami jako v předchozí generaci počítačů se sběrnicí ISA. V rámci výkladu funkce sběrnic se zabýváme klasickou paralelní sběrnicí PCI (APO:Susta19:12, APO:PisaStepanovsky18EN:6, ODP). Ta sice již není v klasické paralelní variantě příliš používaná, ale lze na ní názorně vysvětlit principy arbitrace a adresování, které se používají a budou stále používat například při návrhu vlastních procesorových a periferních obvodů (sběrnice AXI, APB, Avalon, Wishbone) ať již přímo v podobě křemíkových čipů nebo systémů využívajících programovatelné obvody FPGA. Na nich se sice již nepoužívají obousměrné linky, ale problémy s čekáním na připravenost periferie, její odpověď a serializaci přístupů z více nadřazených procesorů a periferií s přímým přístupem do paměti zůstávají. Naopak pro propojení obvodů a funkčních celků se již přechází ze série slov posílaných paralelně po více vodičích na posílání vlastních symbolů sériově po jedné nebo více diferenčních jednosměrných linkách. Důvody přechodu na sériové propojení demonstrujeme na standardu PCI Express i s ukázkou zachování programového modelu.
Dále se zabýváme architekturou x86 (APO:PisaStepanovsky18EN:11, převzato Dr. Konstantin Levit-Gurevich, Intel Israel), která stále je a pravděpodobně ještě 10 let bude dominantní v oblasti personálních počítačů a běžných serverů. Na této architektuře předvádíme jak zrychlit multimediální operace využitím SIMD instrukcí. Nakonec přichází krátký souhrn vývoje procesorových architektur (APO:Pisa19:13, APO:PisaStepanovsky18EN:12, ODP) se zaměřením na příklady některých důležitých inovací, které vedly ke zvýšení výpočetního výkonu. Závěr je pak věnovaný výhledu do budoucna a přehledu perspektivních směrů a architektur. Vše ve velmi omezené míře tak, aby bylo možné si alespoň základní představu odnést i s těmi omezenými znalostmi, které jsme schopní v rámci jednoho kurzu předat. Vlastní zkouškové testy se z tohoto výkladu zaměřují opravdu jen na několik základních faktů, nikde se neptáme na konkrétní registry, typová označení, instrukce zahrnuté do jednotlivých instrukčních sad.
V loňském běhu jsme přešli na vlastní simulátor architektury MIPS (QtMIPS, ke stažení, video, preznetace, webová verze). Simulátor nahradil dříve používaný Mips It, který existuje jen ve verzi pro Windows a je tak starý, že se již i na nich pouští problematicky. Náš simulátor jsme začali v loňském letním semestru používat i přesto, že množtví funkcí bylo potřeba doprogramovat za běhu.
Postupně byla přepracovaná tabulka pro dekódování základních i dalších instrukcí a doprogramované zvýrazňování slov paměti, která jsou v dané chvíli pro procesor dostupná z vyrovnávací paměti.
Dále přibyly některé periferie odpovídající VHDL návrhu periferií k výukovému kitu MZ_APO na bázi Xilinx Zynq navrženého primárně pro výuku předmětu Programování systémů reálného času a další pokročilejší projekty. Protože se jedná o relativně drahý systém, není možné poskytnout každému studentovi kit domů a právě přidání periferií do simulátoru (sice s jádrem MIPS na rozdíl od ARM pořípravku) jsem viděl jako pomoc v řešení semestrálních projektů.
Dále byl přidaný sériový port, který datovými a řídicími registry odpovídá sériovému portu z emulátorů QtSPIM a MARS tak jak jsou popsané v knize Computer Organization and Design, The HW/SW Interface (CA) od profesora Pattersona a Henessy.
Zde se někdo může zeptat, proč nepoužíváme tyto velmi povedené simulátory vyvíjené již desetiletí. Když jsme s Karlem Kočím prováděli analýzu jestli se vydat vlastní cestou nebo rozšířit tyto simulátory, dospěli jsme při analýze jejich implementací názoru, že doplnit/přepsat jejich jádra tak, aby poskytovaly signály a obecně stav odpovídající zřetězenému zpracování instrukcí znamená v podsatě přepsat kompletně jádro simulátoru. Přitom přepis cizího kódu se zachováním výsledné funkce by byl náročný a bez delšího jednání s autory by byla šance na začlenění mizivá. Kompletní rozbor je součástí diplomové práce Graphical CPU Simulator with Cache Visualization Karla Kočího.
Protože jsme věděli, že naše síly jsou velmi omezené, rozhodli jsme se, že simulátor nebude obsahovat vlatsní editor kódu a bude nahrávat spustitelné sobory ve formátu ELF MIPS32 big endian generované vývojovým řetězcem GNU.
Během diskuze na výstavě Maker Faire, iniciované kolegy z naší ketedry, byl náš přístup kritizovaný s tím, že v dnešní době nikdo nechce instalovat binární program (přesto, že máme podporu pro GNU/Linux, Window i Mac OS) a vše má běžet přímo z Internetu v prohlížeči. Od kolegy Františka Vacka jsem se dozvěděl, že Qt5.13 přidávají podporu běhu přes WebGL v prohlížečích, které podporují "instrukční sadu" (ISA z pohledu APO) WebAssembly. Nainstaloval jsem tedy překladač Emscripten postavený nad LLVM a překompiloval Qt5.13 (viz dokumentace) i náš simulátor. Výsledek sice není dokonalý, ale pro mnoho úloh je již použitelný.
Při použítí v prohlížeči omezuje použití externího kompilátoru vlastní tvorbu, lze sice nahrávat binární přiklady distribuované se simulátorem, ale modifikace je obtízná. Proto jsem do aplikace přidal i editor a jednoduchý jednoprůchodový asssembler, který překládá přímo do datové struktury reprezentující paměť simulovaného systému.
Pro překlad byl implementovaný jednoduchý systém pro zpracování a vyhodnocování výrazů.
Po skončení přemětu i na základě sledování velké zátěže na studenty i hardware, kdy měli problém se vystřídat u vlastních výukových kitů, jsem připrogramoval i emulaci jednoduchého grafického výstupu (framebuffer), který odpovídá formátem RGB 565 displejům použitým na kitech.
Simulátor dále implementuje i emulaci základní sady systémových volání MIPS O32 ABI používané jádrem Linux a základní podporu koprocesoru COP0. Jím je možné předvést na simulátoru i zpracování přerušení a teoreticky i po vypnutí emulace O32 ABI i vlastní implementaci systémových volání.
Náš dlouhodobější cíl je pak přejít s výukou i simulátorem na otevřenou architekturu RISC-V. O té jsme uvažovali již před začátkem projektu, ale příprava všem materiálů (přednášky, generátory sekvencí pro zkouškové testy, cvičení) bude vyžadovat tolik času, že jsme zvolili v počáteční fázi pouhou náhradu implementace simulátoru.
Naopak o náš projekt je zájem i na dalších fakultách a univerzitách i v zahraničí, takže věříme, že se nám i díky tomuto projektu podaří sestavit tým zájemců natolik silný, že bude možné provést přípravu pro výuku na architektuře RISC-V na světové úrovni. Stejně, jako příprava tohoto simulátoru a záměru inovace MipsIT sahá pět let zpět, tak i další kroky jsou na roky. Tedy zpět k výuce.
Předmět je zařazený jak do programů Kybernetika a robotika (KyR) a Otevřená informatika (OI) a byl naplánovaný pro čtvrtý semestr. Vzhledem k potřebě znalostí v navazujících předmětech operační systémy a dalších byl v rámci poslední úpravy akreditace přesunutý do druhého semestru. Vlastní logické operace a základ Boolovy algebry by již studenti měli mít probraný v předchozích předmětech. V programu OI mají studenti již probraný programovací jazyk C, v programu KyR bereme ohled na to, že se studenti jazyk C učí paralelně s naším předmětem. S kompilací jednoduchého programu v jazyce C pro výpis hodnoty z paměti se sice studenti setkají již na prvním cvičení, ale důraz je kladený na reprezentaci čísel v paměti a jazyk C je vlastně jen prostředek na zobrazení několika hodnot a k demonstraci k na tabuli probraným příkladům počítání s plovoucí řádovou čárkou. Dále pro první dvě třetiny cvičení vystačíme se schopností kombinovat sekvence několika málo instrukcí v assembleru.
Na dalším cvičení si studenti vyzkouší jednoduchý výpočet součet dvou proměnných z paměti, součet dvou vektorů, jeho nároky na počty přístupů do paměti podle parametrů a způsobu využití vyrovnávací paměti, implementaci jednoduché rekurzivní funkce (předávání parametrů podle MIPS O32 ABI) Fibonacciho posloupnosti. Další příklad na pochopení vlivu vyrovnávací paměti je algoritmus jednoduchého třídění. Po probrání faktorů limitujících maximální hodinovou frekvenci sekvenční logiky (jednocyklového procesoru) je na simulátoru předvedené zřetězené zpracování instrukcí. Zřetězení sice přináší zvýšení propustnosti, ale přináší problémy s dopravením výsledků z ještě nedokončených instrukcí do následujících instrukcí. Simulátor nabízí konfiguraci, kdy není problém závislostí/hazardů ošetřený. Studenti si tedy mohou vyzkoušet, jak přizpůsobit sekvence strojových instrukcí pro vyřešení tohoto problému na softwarové straně. Kromě procesorů DSP většina dnešních architektur sice řeší závislosti na straně hardware, ale často s penalizací výkonu a moderní kompilátory se rozplánováním instrukcí podle počtu funkčních jednotek a jejich zpoždění a vzájemných propojení musí pro dosažení dobré propustnosti zabývat. Vysvětlení hardwarového ošetření na přednáškách je možné v praxi otestovat na simulátoru (jak pozastavení, tak přeposílání).
V souladu s postupem přednášek přecházíme na propojení systému s vnějším světem. Nejdříve jen čtením otočným voličem mastaveného čísla z adresy v paměťovém prostoru a jeho výstupem na "RGB LED" (na přípravku MZ_APO již skutečné RGB LED) a do výstupního slova (na přípravku MZ_APO pak realizovaného řadou 32 malých SMD LED diod). Dále je možné vyzkoušet výstup na sériový port a to jak v režimu dotazovacím tak s přerušením (architektura MIPS je simulovaná včetně základních funkcí koprocesoru COP0).
Podle schopností studentů lze již tyto příklady demonstrovat v jazyce C a přejít i k volání služeb jádra operačního systému. Studenti s hlubším zájmem si mochou vyzkoušet i obsluhu systémového volání přímo ve vlastním kódu, protože simulátor umožňuje vypnout zachycení a emulaci systémových volání.
Poslední až třetina cvičení je věnovaná přechodu k programování shodné sady periferií realizované v námi připraveném VHDL návrhu pro výukové kity MZ_APO. Zde se již programuje plně v jazyce C. Pro zjednodušení ladění se programy pouští v uživatelském prostoru a pro přístup k periferiím je využito mapování periferií s využitím systémového volání mmap() do virtuálního adresního prostoru procesu. Pro všímavé studenty je to i příklad na využití překladu virtuálních adres na fyzické, které je probrané na přednáškách.
První domácí úkol slouží k procvičení kódování numerických hodnot do paměti (little-endian, big-endian), jednoduchých operací v pevné řádové čárce a procvičení ručního převodu hodnot do a z formátu plovoucí řádové čárky. Přitom na operaci s reálnými čísly je předvedený i vliv zaokrouhlení při operacích. Ti studenti, kteří úkol vyřeší pečlivě a mechanizmy pochopí by pak neměli mít potíže ve zkouškových příkladech zaměřených na kódování. V případě plovoucí řádové čárky jsou pak generované příklady, které pro uložení reálných čísel využívají menší počet bitů, okolo 11, aby bylo možné příklady počítat i z hlavy nebo na papíře bez potřeby využít kalkulátor.
Druhý úkol je zaměřený na optimalizaci/minimalizaci počtu výpadků vyrovnávací paměti při realizaci algoritmu ostření obrázku. Tento úkol již vyžaduje základní znalost programovacího jazyka C. Termín odevzdání je volený tak, že i studenti, kteří se učí programovací jazyk C paralelně s naším předmětem by již potřebné základy měli mít probrané. Vlastní vyhodnocení úkolů v odevzdávacím systému provádí kontrolu práce s pamětí programem Valgrind. Stejný program je pak použitý pro vyhodnocení náročnosti implementovaného algoritmu na počet přístupů do paměti. Opět, kdo se nad úlohou zamyslí, by neměl mít problémy s mnohem jednoduššími otázkami k efektivitě využití paměti ze zkouškového testu.
Třetí úkol je zaměřený na zřetězené zpracování instrukcí a řešení dodržení závislostí mezi instrukcemi změnou pořadí instrukcí a po přidání hardwarové podpory i analýzou potřebných pozastavení v případech bez a s přeposíláním výsledků. Opět přímo odpovídá obdobným analýzám sekvencí (jiných) kódu ve zkouškových testech. Modul v jazyce Python, který analyzuje a vyplňuje správné výsledky při generování zkouškových testů je již od jeho prvního použití v testech k dispozici jako opensource (git clone https://github.com/ppisa/apo-simarch).
Analyzátor kódu je schopný i jednoduché sekvence instrukcí odsimulovat včetně práce s pamětí a provádět permutace pořadí instrukcí při zachování jejich vzájemných závislostí. Studenti si stěžují na nedostatek materiálů a nedostatečnou přípravu ke zkouškové písemce. Ale zde mají jak domácí úkol tak i nástroje na přípravu vlastních cvičných úloh. Připadá mi celkem smutné, že neuronová síť tvora, který se cítí na vrcholu vývojového řetězce, prohlašuje za nadměrný výkon postavit se jednoduchému logickému algoritmu, který zvládá několik řádek kódu v jazyce Python. Analýza vzájemné závislosti dvou instrukcí je vyřešená ve funkci depanalyze() na 13 řádkách kódu. Kompletní analýza sekvence instrukcí je bez použití přeposílání vyřešená ve funkci analyze() na 26 řádkách kódu. Pro případ s přeposíláním ale s latencí jeden cyklus mezi načtením a dostupností hodnoty čtené z paměti pak ve funkci analyze_stall_forward() pak vychází na 43 řádek kódu, ale pro tvora vybaveného přirozenou inteligencí je ještě jednodušší než předchozí případ. Komu činní potíž mechanizmus pochopit z ilustrovaného popisu na přednáškách (slide 37 až 45 přednášky o zřetězeném zpracování) a šestého cvičení (Pipeline a hazardy), tak si může prostudovat algoritmus. Vše je vyučované i zkoušené na stále jednom a tom samém modelu pětistupňového zřetězeného procesoru, který si lze do detailů "osahat" na grafickém simulátoru QtMIPS a případně se zeptat i na cvičeních.
Poslední úkol je již náročnější, jednoduché programy pro zpracování textového vstupu a jeho přeposlání na výstup jsou zkompilované pro cílovou architekturu x86 32 bitů a MIPS O32 ABI ve formě programů pro operační systém GNU/Linux. Úkolem studentů je z výpisu v assembleru těchto architektur nalézt volání mezi hlavním programem a jednou funkcí. Dále vyhledat veškerá systémová volání, přitom ta jsou do programu vložená v jednoduché podobě přímo do sekvencí instrukcí funkcí s využitím extended assembleru GCC. Díky tomu není potřeba analyzovat knihovní funkce a propojení hodnot na argumenty systémových volání je minimálně v případě MIPS zcela zřejmé. Odevzdává se seznam nalezených systémových volání a k funkci binárního programu ekvivalentní program v jazyce C. Zdrojový kód je odevzdávacím systémem zkompilovaný do 64 bitového režimu x86, poté jsou ladící informace analyzované ladícím programem GDB. Nalezený prototyp volané funkce je porovnaný proti výsledku analýzy původního binárního programu. Přitom při porovnání datových typů ukazatelů i přímých číselných argumentů se nekontrolují shoda na použití znaménkového typu a další nepodstatné rozdíly. Nakonec dojde k záznamu sekvencí volaných systémových volání pro různé vstupní soubory programem strace. Sekvence jsou porovnané proti sekvencím získaným při volání 32 bitové binární varianty programů (zadání). Na příkladu je demonstrovaná i přenositelnost programů mezi různými architekturami (MIPS big-endian, x86 little-endian, 32 bitový a 64 bitový procesor).
Původní přípravky pro předmět realizovaly jednoduchou periferii připojenou ke sběrnici PCI Express. Byly založené na programovatelném obvodu FPGA a instalované do PC počítačů v laboratoři. Pro PCI rozhraní i připojené periferie jsme naimplementovali i jejich simulaci v emulátoru QEMU. Jednalo se o pokračování diplomové práce Prostředí pro výuku vývoje PCI ovladačů do operačního systému GNU/Linux Rostislava Lisového.
V létě roku 2016 probíhala diskuze o předmětěch v rámci nové akreditace OI studia. Sám jsem prosazoval na schůzkách použití nebo návrh vlastního malého a levného procesorového kitu, který by bylo možné získat v potřebném počtu tak, aby minimálně na celý semestr měl každý student jeden kus k dispozici.
V současné době použitý hardware s FPGA a velkým procesorem jsem vybíral pro diplomové prace a pro použití v předmětu Programování systémů reálného času. Pro tyto případy se jedná o excelentní volbu. S direktivním rozhodnutím použít nakoupená procesorová jádra MicroZed pro předmět APO, jsem nesouhlasil, přesto jsem vznesený deklarativní vyjádření pana profesora Zdeňka Hanzálka v mé firmě (PiKRON) s kolegou (Ing. Petr Porazil) vyrobit kyty použitelné i pro předmět APO splnil. Možnosti navrženého kitu (MZ_APO) jsou široké, používáme ho i v projektu otevřené implementace (CTU CAN FD) automobilové komunikační sběrnice. Umožňuje řídit motory (GNU/Linux a řízení po sběrnici CAN s využitím generovaného kódu a FPGA Video, Prezentace), pro kity máme připravené i stereokamery a v rámci BP nebo DP by bylo možné navrhovat zpracování obrazu s využitím FPGA. K dispozici jsou i serva a řízení laserového paprsku a další zajímavé náměty na DP a BP. Zajímavá je i možnost navrhnout RISC-V jako koprocesor v FPGA části řízený z nadřazeného GNU/Linux systému běžícího na architektuře ARM. Minimálně ještě jeden, dva běhy budeme kity i pro předmět APO používat.
Investujeme ale i čas do výběru nebo návrhu vlastní cenově dostupné platformy založené v ideálním případě na architektuře RISC-V s možností alespoň zapůjčit kit každému studentovi.
I na základě diskuze budeme uvažovat o kompletním přechodu na malé kity nebo ponechání možnosti použít plnohodnotný systém se zajímavými periferiemi například jen pro obor KyR. Případně nabízet kit jako alternativu pro schopné studenty se v rámci semestrálního projektu rozvíjet na kompletním systému s možností programovat vlastní periferie a koprocesory. Studenty, pro které je předmět jen zdrojem nejnutnějších základních znalostí pro další studium, nechat pracovat jen s levnými malými kity. U nich bych však byl rád, aby si vyzkoušeli práci na úrovni OS, zvažujeme NuttX nebo RTEMS, se kterými mám značné zkušenosti včetně příspěvků do vývoje jejich jader.
Tento zápisek shrnuje koncepci předmětu Architektury počítačů. Vykládá jak obsah vznikal, vazbu cvičení, přednášek a domácích úkolů atd. Náš zájem je, abychom v předmětu předali znalosti potřebné pro další studium (pro předměty Operační systémy, Programování systémů reálného času, studium kompilátorů, antivirů i třeba pro návrh nových procesorových architektur a jejich implementací) a aby absolventi díky znalostem chování procesorů, vyrovnávacích pamětí i vstupně výstupních subsytémů programovali aplikace s větší propustností, menšími nároky na pamět, energii (baterie) atd.
Do budoucna máme zájem kurz aktualizovat a pro výuku využívat otevřenou procesorovou architekturu RISC-V. Hledáme i studenty a kolegy kteří se do dalšího vývoje zapojí (BP, DP, atd.). Pokud Vás oblast procesorových systémů zajímá, může pro Vás být zajímavý i předmět Pokročilé architektury počítačů.
Hledáme i spolupracovníky, kteří by měli zájem se do výuky nyní/časem zapojit třeba i jako externisté z firem a využít možnosti udržovat i nadále vztahy s fakultou a případně motivovat další studenty k získání znalostí a třeba i práci na zajímavých projektech firem, pro které budete pracovat, v rámci dalších DP a BP.
Budu velmi rád za kultivovanou diskuzi a připomínky, jak předmět zlepšit. Velmi mě zajímají názory studentů, kteří již předmět absolvovali. Nejvíce mě pak zajímají názory těch, kdo již měli možnost znalosti využít v praxi. Především pro studenty a i ty, kdo jsou ochotní přispět k hodnocení předmětu a přispět k jeho směřování odpovědí na otázky jsem na jednom svém pomocném serveru zprovoznil systém Odoo (nechci dávat všechna data k analýze jedné velké společnosti). Všechny odpovědi na otázky jsou volitelné, není potřeba odpovídat na vše. Adresa dotazníku http://pisa-virt.felk.cvut.cz:8069/survey/start/dfe330a7-83e3-44ca-95e2-ee576677ccf2
Zápisek je celkem dlouhý a neměl jsem na jeho pečlivou kontrolu dostatek času, přitom ho potřebuji kvůli koordinaci přípravy cvičení publikovat již nyní. Prosím, na překlepy mě upozorněte v soukromých zprávách. Text budu pravděpodobně i na základě diskuze mírně upravovat.