Hlavní navigace

Názor k článku Programovací jazyk BASIC na osmibitových mikropočítačích (dokončení) od klusacek - S tou cachi mate pravdu, skutecne je mozne ji...

  • Článek je starý, nové názory již nelze přidávat.
  • 3. 7. 2010 14:59

    klusacek (neregistrovaný)

    S tou cachi mate pravdu, skutecne je mozne ji dost zoptimalizovat. Neni to jen tou pravidelnou strukturou ale taky tim ze se nam tom velmi intezivne pracovalo (protoze je to univerzalnejsi vec nez ALU (ktera je kazda trochu jina), SRAMka se pouziva i v registrech CPU (sice viceportova, uznavam) takze meli vetsi motivaci to vyresit jako ‚knihovnu‘, kterou pak vsude pouzivaji.
    Se statickou spotrebou mate pravdu, ale dnes uz se proti tomu dela opatreni, ze se snizuje napajeci napeti tech bloku cache ktere se nebudou pozivat. Tim vyrazne klesne i spotreba, data to porad udrzi ale neni mozne je cist a zapisovat. Pred pristupem k bloku se napeti prechodne zvysi. Rika se tomu drowsy cache.


    Amigu s 386kou bych neporovnaval, amiga byla ve vyhode ze mela blitter, takze kdyz 386ka tlacila data pres pomalou ISA-bus do videokarty, cimz vyplytvala temer veskery cas, mohla amiga v klidu pocitat. Kdybyste je treba nechal pocitat FFT (predpokladam ze mate na mysli Amigu 500 bez acceleratoru) tak by to vyhrala 386ka. Ale oboji maji vlastne spatne procesory. Kdyz to porovnate s Acornem Archimendem, tak ten mel CPU na 8MHz s vykonem kolem 6 MIPS, kdezto Amiga na teze frekvenci mela neco jako 0.7 MIPS, spis 0.6. Pritom 68000 obsahovala asi 70k transistoru, kdezto ARM byl postaven jen z 25k transisotru (min nez Z80!) — a nemel mikrokod.


    S tim mikrokodem je to tak ze driv pomoci nej byly implemetovany vsechny instrukce tim ze se rozdrobily do elementarnich operaci s ALU, registry a budici sbernic. To melo vyhodu ze se to dalo snadno menit, mohl jste si snadno pridat dalsi instrukci, ale nevyhodu ze to nemohlo jednoduse pracovat paralelne – vzdy se zpracovavala jen 1 mikroinstrukce ktera byla soucasti 1 CPU instrukce.


    Kdyz se pozdeji prislo na to ze takto vlastne vyuzivame v nejlepsim 1/3 CPU (bud nacitame a dekodujeme instrukci, nebo pracuje ALU, nebo se vysledky ukladaji zpet do pameti) napadlo Johna Cockeho (a nezavisle taky Seymoura Craye) jak zaridit aby se tyhle akce prekryvaly a vsechny casti procesoru byly pokud mozno stale vytizene. Aby se z toho nezblaznili tak zjednodusili instukcni sadu, zavedli LOAD/STORE model a pri tom zjisitli ze radic muzou udelat primo obvodove a mikroinstrukce nepotrebuji. Krom toho, moderni kompilatory nemaji radi kosate instrukcni sady, mnohem lepsi je pravidelna a jednoducha sada, lip se pro ni totiz optimalizuje. Takze nakonec to neni nevyhoda, pokud nepocitame ze prelozeny kod pro RISC procesory zabere trochu vic v pameti nez ten samy program pro CISC.


    Dnesni CPU, jako treba AMD, neco jako mikrokod maji ale tam se pouziva na emulaci slozitych instrukci (jako REP MOVS), ktere stejne nikdo nepouziva protoze nakonec pracuji pomaleji nez kdyz je rozepisete slozene ze zakladnich operaci. Je to jen pro kompatibilitu. Pak taky jsou v nem implementovany ruzne context-switche a podobne veci.


    Abych predesel flamum tak je potreba rict ze i nektere RISC procesory maji neco cemu rikaji mikrocode (treba SPARC), ale tam jde spis o to ze cinnost radice (ktery ridi jak vykonavat tech nekolik instrukci zaroven) neni pevne zadratovana ale je ulozena v pameti flash kde je definovan konecny automat jehoz vykonavani pak nastavuje patricne ridici draty do jednotlivych vykonnych jednotek. Nejspis to tak maji proto aby mohli snaze opravovat chyby, nebo od urcite slozitosti radice to vyjde mensi na chipu (protoze jak jsme rekli, pamet umi narvat do maleho mista, na rozdil od v podstate libovolne logiky obvodoveho radice)


    Implementovat browser na CM by nepochybne slo (meli tam lisp), ale asi by to nebylo moc pohodlne, jednotlive nody mely dost malou pamet. Co se tyka dneska, tak masivne paralelni pocitace maji nody prinejmensim srovnatelne s PC, takze zkratka by browser bezel na jednom z nich (nema cenu neco paralelizovat kdyz to bezi dost rychle na single-cpu).


    K tomu CRAY-1, z dnesniho pohledu byl pomalej — takt 80 MHz, vykon 140 MFLOPS. Blbej Intel Atom ma nejmin 3GFLOPS. Krome toho mel dost malou pamet, neco jako 8MB (postavenou ze statickych RAMek). Prvni modely dokonce nemely ECC (‚parity is for farmers‘), takze stredni doba bezporuchoveho provozu byla neco kolem dvou hodin (to se to muselo programovat). Ale abych to neshazoval, uz v roce 1985 mel CRAY-2 vykon 1.9 GFLOPS.


    Zpozdovaci linky se v analogovy televizi (PAL) pouzivaji normalne, jsou potreba k obnoveni barvy, protoze Y-R se prenasi jen v lichych a Y-B jen v sudych (mozna opacne) radcich pulsnimku.
    Aby to nedelalo ‚Hanover Bars‘ (http://en.wikipedia.org/wiki/Hanover_bars) tak je tam zpozdovaci linka (vyrobena z kremenyho krystalu, po kterem se siri povrchova akusticka vlna) ktera slouzi na zapamatovani analogove informace z predchoziho rad­ku.