Hlavní navigace

Názor k článku Programovací jazyk BASIC na osmibitových mikropočítačích (dokončení) od klusacek - Tak pripravuji se MRAM, nizsi kapacita (okolo 1MB)...

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

    klusacek (neregistrovaný)

    Tak pripravuji se MRAM, nizsi kapacita (okolo 1MB) se uz da i koupit, ale porad se jim nedari dostat se na hustotu dnesnich DRAMek, castecne proto, ze na high-tech vyrobni linky je nikdo nechce moc pustit protoze tyto chrli flasky a DRAMky.
    Krome toho to ma i nevyhodu, kdyz k takovy pameti nekdo prilozi neodymovej magnet tak ji smaze, mozna i znici. Na druhou stranu ji ale tolik nevadi ionizujici zareni.


    Cray-1 nepocital vektory paralelne, pouze pipelinovane. Mel sice vektorove registry ale na rozdil od dnesnich SIMD instrukci (ktere kdyz scitaji 4prvkovy vektor tak tam jsou 4 scitacky, pro kazdou slozku 1) mel jenom jednu ALU (zabrala asi 1/10 te skrine, protoze CRAY byl postaven z diskretnich 4 a 5tivstupych NOR-hradel a 1Kbit SRAM pameti – dnes by se cely i s pameti v klidu vesel na jeden chip a nejspis by zabral vyrazne min plochy nez dnesni CPU).


    Je jasny ze vzhledem k technologii nemohl mit vic nasobicek a scitacek, takze je aspon vyuzival tak ze kazdy takt se zpracovalo 1 cislo a scitacka mohla pracovat zaroven s nasobickou. Data se cetla z vektorovych registru, ktere na rozdil od dnesnich SIMD pocitacu byly celkem dlouhe: 64 polozek. Takze se da rict ze to zhruba je ekvivalentni efektivite superskalarniho CPU bez SIMD instrukci, napr. R10000. Jinak doporucuju kouknout do manualu, je to zajimavy cteni: http://195.113.26.193/~klusacek/Cray1.pdf


    Jak to bylo s OS u CDC 7600 nevim, ale pro CRAY OS rozhodne nepsal, ten vytvarelo mnoho lidi a trvalo jim to pomerne dlouho a postupne jich vzniklo nekolik (ten prvni ani nemel time-sharing, ono se neni co divit, udelat context-switch kdyz mate v registrech nekolik kilobytu dat je docela zdrzeni).


    S tim mikrokodem Vas nechapu, zvlast jak chcete mit vic radicu… Abyste nahodou nevynalezl timto zpusobem multi-core CPU ;) Krom toho mikrokodovani (v tom starem smyslu, kdy je mozne primo rict korespondenci mezi instrukcema a mikroinstrukcema) je hloupost. Prinasi to pouze dekompozici problemu pri navrhovani CPU. Jeden team navrhuje ALU, registry a radic a specifikuje mikrokod a jiny team si pak vymysli instrukce a implementuje je mikrokodem. Vysledek je bloated design, staci se podivat na 286ku jaky mela instrukce.
    Podle me to navrhovali lidi co nikdy neprogramovali a podle toho to dopadlo.
    Tim ze byste si mohl menit mikrokod a pridavat nove instrukce vetsi rychlosti nedosahnete, spis vetsi kompaktnosti kodu, ale na tom dnes prilis nezalezi.
    Aby byl CPU rychlej tak nesmi byt moc slozitej, k cemuz mikrokod prispiva. A slozitosti myslim hloubku logicke funkce pocitane v jendom taktu (lidove: kolik hradel je ‚za sebou‘). Treba Cell ma tusim tuhle hloubku 10 nebo 11 hradel, coz vychazi na propagation delay na 1 hradlo (+draty) okolo 290ps. Starsi CPU mely daleko vic (proto zase mohly mit kratsi pipeliny).


    Navic paralelismus na urovni jednoho jadra CPU je uz celkem saturovany. Vsechno se pipelinuje, nezavisle instrukce muzou bezet zaroven, pracuje se s vektory atd. Tam uz to moc nezrychlite (lepe receno nevyplati se to). Spis by pomohlo odstranit cache a dat pocitaci rychlou pamet (v chipech nalepenych na CPU). Ale ani to nebude o moc (spis to pouze snizi latenci), protoze cache docela fungujou.


    Takze jde o to jak zpracovavat ulohu na mnoha CPU, ale tam je zase problem s komunikaci (aby se nezahltila) a aby byly jednotlive procesory stale dostatecne vytizene. To vubec neni trivialni a podle me je to stale nevyresene.