Hlavní navigace

Názory k článku Programovací jazyk BASIC na osmibitových mikropočítačích (dokončení)

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

    kvr kvr

    Trochu mě překvapilo, že za celou éru osmibitů i Basicu nebyla zmíněna kniha Programátorské poklesky (detail http://www.kfbz.cz/katalog/zaznam.php?detail_num=24462&strana=0&typhled=A&vers=9&lang=cze ).
    Ač se pro vysvětlení používá převážně Basic, považuju ji za literaturu silně nadčasovou a asi za vůbec nejlepší knihu o programování, kterou jsem četl. Vtipně a přesto poučně popisuje klasické programátorské hádanky, omyly, otrkávání programátora i historické chyby. Podobně jako dříve zmíněna literatura je doplněna spoustou v kontextu výstižných ilustrací a citátů. Neváhal bych ji otevřít ještě dnes.
    PS: Kdysi jsem ji někomu půjčil, a samozřejmě zapomněl, před pár lety ji ale vyřazovali z nějaké tovární knihovny, tak ji mám zase zpět. Asi se dnes lidi spokojí už jen s knihami se spoustou screenshotů ;)

  • 29. 6. 2010 11:04

    Pavel Tišnovský

    Diky za upozorneni. O teto skvele knizce jsem se chtel zminit i nafotit nejake povedene stranky, ale nemohl jsem ji doma najit – asi jsem ji taky nekomu pujcil. Byly tam skutecne jednoduse vysvetleny nektere klasicke problemy programovani (slozitost, numericke chyby, kupodivu i algoritmus hledani kriticke cesty) a asi nejvic mam v pameti rozdeleni aplikaci podle jejich „natury“ – bily trpaslik, melancholik atd.

  • 29. 6. 2010 12:35

    ondra.novacisko.cz (neregistrovaný) ---.seznam.cz

    Mimochodem, tohle označení: „bílý trpaslík“,„rudý obr“,„klepna“,„ka­nón na vrabce“,„modrý přízrak“,„ufo“ používám do dnes. Například ohledně některých linuxových aplikací používám označení „klepna“, tedy i když občas kecají hlavně do logů. Jo a na Ufo se mě neptejte, to jsem potkal několikrát. Zpravidla tehdy, když mám aplikaci prezentovat. Většinou se začne chovat jako Ufo. Pozdější analýza většinou ale odhalí, že program narazil a problém, který nastane maximálně jednou za 100let a z Ufo se stane Ifo :-)

  • 29. 6. 2010 13:18

    kvr kvr
    Jo, povahové vlasnosti (melancholik) byly podle komunikace s uživatelem (UI), cholerik mě inspiroval při psaní jednoho z maturitních příkladů :) Astronomické objekty obvykle podle efektivity algoritmu (ať už časové, kódové nebo paměťové).

    Dijkstra tam byl popsaný jako třešnička na dortu v poslední kapitole a samozřejmě jak jinak, i s chybou – když došlo na lámaní chleba a jelo se na výlet z Prahy do Ostravy, tak nejkratší cesta vedla přes Košice.

    V každém případě, pokud na tohle období ještě někdy dojde, můžu něco ofotit, případně knihu zapůjčit.

  • 29. 6. 2010 16:16

    D.A. Tiger

    Jj ta knížka je byla super. Kde jakou hovadinu typu programátorem za měsíc přetisknou desetkrát, ale takto užitečnou knihou už ne. Škoda…
    Mimochodem, logo dnešního článku je ofocený taky z docela dobré knížky o Basicu. Ještě ji někde doma mám :-)

  • 30. 6. 2010 14:24

    Techi (neregistrovaný) ---.106.broadband2.iol.cz

    Já jí zrovna minulej tejden vyhodil do recyklovanýho papíru. Nostalgie se u mě nekoná :D

  • 29. 6. 2010 12:23

    Jiří Svoboda (neregistrovaný) 83.167.228.---

    Jo, tak tuhle knížku mám, je skvělá, četl jsem ji několikrát. Nejvíc mi utkvěla v paměti pasáž, jak někdo tuším ve Fortranu zaměnil znak tečky a čárky. Nějaká raketa pak po startu skončila v moři. Vyprávění pak bylo završeno větou: „Kosmická sonda na dně moře je k ničemu, podmořský výzkum se dá provádět levnějšími prostředky.“
    A když jsme u těch knih, moje první „programátorská“ kniha byla „Hry s kalkulátory“, autor Jiří Mrázek. Vyšla v roce 1986, to jsem ještě ani neměl programovatelnou kalkulačku, naštěstí se dalo hrát i na těch „obyčejných“. Z té si zase pamatuju nějaký složitý výpočet ohledně vývoje těžby ropy. Zadávalo se, kolik se těží, kolik je na světě arabů atd. a pak vyšlo číslo „710.77345“. Chvíli mi trvalo, než jsem přišel na to, co to znamená. :-)

  • 29. 6. 2010 12:32

    Pavel Tišnovský

    Hry s kalkulatory – takova mala (A6?) zelena za cca 5 Kcs? JJ, to bylo taky dobry, tam jsem se poprve setkal s RPN, iterativne pocital cislo Pi ci druhou odmocninu atd. Btw k tomu prikladu – stacilo kalkulacku otocit ne :-)?

  • 29. 6. 2010 14:33

    klusacek (neregistrovaný) ---.net.upc.cz

    Programatorske poklesky je super knizka (a pokud ji budete skladovat pri teplote do 25 stupnu celsia, pri tlaku 101.5 kPa a relativni vlhosti do 80%, stane se nadlouho vasi milou spolecnici).


    Hry s kalkulatory — matne si vzpominam ze nekde na konci bylo ukazano jak pocitat druhou a treti odmocninu Newtonovou metodou. To mi pripadalo jako kouzlo, hlavne jak to uzasne rychle konvergovalo, s kazdym krokem dvakrat vic platnych mist.

  • 29. 6. 2010 9:06

    jarous (neregistrovaný) ---.suas.cz

    Úplně náhodou jsem narazil na „retrospec.sgn­.net“. Vůbec jsem o tom nevěděl. Paráda.

  • 29. 6. 2010 9:11

    PQK

    Pane Tišnovský,
    <PokusOHumor>
    můžete nám prozradit kolik vás je?
    Tohle kvantum informací v této kvalitě a tak často může vyprodukovat snad je multipersonalni entita ;-)
    </PokusOHumor>
    v každém případě (V|v)ám děkuji.

  • 29. 6. 2010 14:51

    klusacek (neregistrovaný) ---.net.upc.cz

    Mohl byste prosim jeste nastinit jak to bylo v BBC basicu s procedurami? Ani ty funkce mi nejsou uplne jasne, podle syntax highlighting na obrazku 6 to vypada ze prefix FN_ se chova jako klicove slovo a ze tedy vsechny funkce musi takto zacinat. Taky byste mohl rozvest jak vypadaly procedury a jestli treba bylo mozne predavat pole jen odkazem, nebo jen hodnotou nebo obojim.


    Budete taky popisovat HW pocitace ACORN BBC? Sice se u nas nevyskytoval ale podle toho co o nem zatim vim mi prijde jako nejlepsi 8bit. Udajne mel v OS neco jako OCR pro systemovy font. Kdyz jste oznacil text vypsany na obrazovku v grafickem rezimu tak ho to umelo prevest zpet na ASCII. Ten konektor na leve strane klavesnice byla tusim vyvedena systemova sbernice na kterou bylo mozne pripojit dalsi procesor. Takhle napriklad ozivovali procesor ARM a psali OS pro pocitac Archimedes jeste driv nez ho fyzicky postavili.

  • 29. 6. 2010 15:55

    An Onymous (neregistrovaný) 130.119.248.---

    to mi pripomnelo macpaint:
    „Bill decided to try to turn pixels back into characters when you selected them with the text tool. He wrote a lot of elaborate code, probably as much as for any other MacPaint feature. First, he wrote assembly language routines to isolate the bounding box of each character in the selected range. Then he computed a checksum of the pixels within each bounding box, and compared them to a pre-computed table that was made for each known font, only having to perform the full, detailed comparison if the checksum matched.“
    http://folklore.org/StoryView.py?project=Macintosh&story=MacPaint_Evolution.txt&topic=QuickDraw

  • 29. 6. 2010 16:55

    Substance242 (neregistrovaný) 213.151.209.---

    Teraz som zostal zarazený… prečo som toto nikdy nepoužil? Asi som to nepotreboval keďže pri programovaní som vedel čo kde mám vykreslené, ale tiež mi nie je jasné že som sa nad touto funkciou nepozastavil, že ako je to možné, ani neviem že by som o nej čítal v Komentovanom výpise ZX ROM (ktorý som samozrejme niekomu požičal a teraz mám prd).

  • 30. 6. 2010 13:32

    dex (neregistrovaný) ---.fnb.cz

    Má to nevýhodu – čte jen font, a neumí myslím rozeznávat UDG. Dále tento příkaz neumí zpracovávat kompilátory pro ZX SPectrum. A hlavně, používat obrazovku jako vstupní zařízení je koncepčně prasárna.

  • 29. 6. 2010 16:48

    Substance242 (neregistrovaný) 213.151.209.---

    Ten Acorn mi pripomenul, ako mi kedysi kamarát Raxoft spomínal, že u niekoho na RISC-ovom Acorn Archimedes pozerali akýsi program, majiteľ hovorí že je to v BASIC-u, oni otázka že či kompilovanom?, chlapík že nie, interpretovanom – také rýchle boli tie mašiny. A namiesto zaujímavej techniky sa rozmáhali x86 bez grafiky, zvuku, operačného systému. No nič, no. :-)

  • 29. 6. 2010 17:33

    Radovan (neregistrovaný) 88.146.198.---

    To je jen další z mnoha důkazů toho, že komerční úspěch není známka kvality. V Redmondu by mohli vyprávět :-D

  • 29. 6. 2010 21:39

    Praclovek (neregistrovaný) ---.anonymouse.org

    Bohužel :-(
    Také vám je tak smutno, když zavzpomínáte na tu pestrost tehdejší nabídky na Západě? Počítače nejrůznějších výrobců, provedení, výkonu, kapacity, tvarů :-) K nim obrovská řada možností, jak si vybrat periférie, spousta kvalitní literatury (i u nás) a kolem spousta sympatických lidí…
    Dnes z toho moc nezbylo. Všechno stejné s.áče z několika čínských fabrik, pořád ještě kompatibilní s tím směšným IBM PC, kterému jsme se tehdy smáli…prostě spotřební zboží, které se podařilo vnutit i lidem, kterým vpodstatě k ničemu není a nedokáží tu technologii docenit…Člověka už to občas skoro ani nebaví a chvílemi je mu to i odporné. To si pak raději sednu k editoru a datluju nějaký kód pro AVR nebo vezmu do ruky páječku…Javové slepence a další dnešní rychlobastlené obrovské nedodělky, kterými se člověk musí někdy zabývat, aby měl co jíst už žádnou radost nedávají…
    Někdy mám pocit, že pan Tišnovský vystoupil z nějakého časoprostorového tunelu. Tak se při čtení jeho článků cítím dobře. :-)

  • 30. 6. 2010 13:43

    Veterán (neregistrovaný) ---.perex.cz

    IBM PC vyhrálo i díky tomu, co se dnes tak oslavuje u Linuxu – otevřená konstrukce. Ostatní výrobci, i když kvalitnějších počítačů, si tak dlouho a radostně hráli na svém písečku, až se PC zdokonalilo a díky množství kompatibilních výrobců je převálcovalo napřed cenou příslušenství a postupně i kvalitou.
    Výhodu to má v tom, že nemusíte svůj program upravovat pro několik nekompatibilních zařízení, ale jedním výrobkem zahrnete velkou část trhu.
    U kvality programů je to jednoduché – levné, rychle, kvalitně – vždy jedna z těchto věcí je v přímém protikladu se zbývajícími. A lidé chtějí rychle a levně. Tak programy zrovna moc vnitřní kvalitou neoplývají.

  • 30. 6. 2010 15:59

    I/O (neregistrovaný) 147.32.68.---

    Uživatelé by chtěli kvalitně. Marketing (to je to oddělení, kam se hrnou lidi, kteří jsou na všechno leví a ničemu nerozumějí) chce levně a rychle.

  • 1. 7. 2010 20:31

    Radovan (neregistrovaný) 88.146.198.---

    Ano, byly doby kdy si člověk mohl (ne sice u nás) vybírat z desítek typů skutečně odlišných mikropočítačů, kdy nestačilo jen sednout a klikat, protože každou chvíli mohl (a musel) objevovat něco nového. A třeba zrovna s nějakou knížkou nebo časopisem v ruce. Kolikrát jsem překládal, nebo spíš luštil, programy otištěné v ABC z různých dialektů BASICu do toho mého… Byly to krásné časy a jsem rád že jsem aspoň jejich konec zažil.

    On ten IBM-PC možná původně nebyl až tak špatný nápad, jako kancelářský počítač, tedy něco jako kombinace psacího stroje s programovatelnou kalkulačkou a schopností nahradit třídičku děrných štítků, byl docela použitelný. Jenže se vecpal i tam kam neměl, do škol a domácností, do kterých původně směřovaly úplně jiné stroje, často s podstatně lepšími vlastnostmi. Jenže ty dojely nejspíš na to, že se pro ně nedaly tak snadno kopírovat hry ;-)

    Škoda že v tom osmdesátém roce někoho v IBM nenapadlo, místo toho aby napodobovali tehdejší omezené mikropočítače (omezené jsou dodnes), prostě našlapat šestnáctibitový System/360 do mikroprocesoru a vecpat ho do jedné bedny, tak jak se to o pár let později v Rusku stalo s PDP-11. Měli by pro něj hned několik operačních systémů a obrovskou hromadu programů, nemluvě o kompatibilitě s mainframy… Možná že kdyby se to stalo, měli bysme vícejádrové procesory o deset let dříve, Intel by dávno zkrachoval (neměl k tomu tenkrát daleko) a Microsoft by koupil Jobs :-D Akorát teda nevím jak by dnes vypadal web, kdyby se rozšířilo kódování EBCDIC!

    P.S. Pokud o tomhle chcete někdo napsat nějaké sci-fi, tak budu jen rád, když tenhle nápad použijete :)

  • 1. 7. 2010 22:07

    klusacek (neregistrovaný) ---.net.upc.cz

    No ja myslim ze IBM PC udelali jen ‚aby jim neujel vlak‘. Proto to taky dali ostatnim k okopirovani. Kdyby verili ze maji technologicky naskok tak by nebyl duvod to delat.
    Mezitim totiz pracovali na tomhle:
    http://en.wikipedia.org/wiki/ROMP
    tenhle CPU (vlastne IBM 801 on a chip) meli uz v roce 1981, ale tak se patlali se softwarem a porad to predelavali ze se to zacalo prodavat az nekdy v roce 1986
    http://en.wikipedia.org/wiki/RT_PC
    Jenze tou dobou uz byl problem ze to neni kompatibilni s PC, takze to nemohli cpat do kancelari, taky to bylo drahy, a jako UNIXova pracovani stanice se to tez neujalo protoze to melo pomaly FPU v porovnani s tim co uz v roce 1986 bylo (nakonec se jeste zjistilo ze CPU ma SQRT bug v FPU).
    Ale i tak to uplne nezahynulo, vznikla z toho architektura POWER, takze az budete nekdy na PS3 hrat hru tak si vzpomente ze nechybelo mnoho a IBM PC mohlo mit podobnou architekturu ;)
    Taky z toho plyne pouceni ze nekdy manageri udelaji opacnou chybu nez delaji obvykle (tedy predcasne uvedeni na trh) a nechaji vyzkumniky opravovat nedostatky tak dlouho az to nekdo jiny vyresi mnohem hur, ale driv. V tomto pripade jina divize teze firmy.

  • 2. 7. 2010 16:42

    Radovan (neregistrovaný) 88.146.198.---

    Škoda že nepracovali usilovněji, a nebo levá ruka nevěděla co dělá pravá, jako v Microsoftu… Na hraní mě sice neužije (ještě tak občas nějakou vykopávku v DOSBoxu), ale PS3 je zajímavá věc, nestyděl bych se za to, kdybych něco podobného měl v desktopu. A aby to mělo aspoň 256 bitů a harwardskou architekturu :-D

  • 2. 7. 2010 18:03

    klusacek (neregistrovaný) ---.net.upc.cz

    Tak zrovna SPUcka Cellu jsou jen 128bitovy (vektory 4*32 bitu), ale zase jich je tam 8 (i kdyz v PS3 vyuzijete jen 6). Jo a taky to neni harward, ale instrukce se z pameti ctou 512bitovou sbernici do nejakeho bufferu, takze kdyz moc neskacete (nebo jen blizko) tak muze procesor pamet pouzivat vetinu casu pro data (kde se pouzije jen 128 bitu). Podobne z/do DMA bufferu se data posilaji po 1024 bitove sbernici, takze probihajici DMA nerusi vypocet prilis casto.
    To je vyhoda SRAMky na chipu. Neni problem delat opravdu siroke sbernice.

  • 2. 7. 2010 19:20

    Radovan (neregistrovaný) 88.146.198.---

    Ony procesory jsou interně harwardské už dost dlouho, ale celkové koncepci mikropočítačů ta von Neumannova koule pořád ještě hodně tíží nohy. Možná to bude tím že jsou „mikro“, a skutečným počítačům se ani vzdáleně nemůžou vyrovnat ;-) S těmi sběrnicemi je to pravda, když si představím že bych jich měl na desce víc, a navíc těch 256bitových, tak by mi motherboard vycházel ve velikosti asi tak desky stolu :-D A nebo centimetr tlustý padesátitivrstvý tišťák!

    Existuje vůbec konstrukce (klidně i tak odlišná jako Connection Machine) která by mohla být alternativou a do budoucna PC, pocházející ze sedmdesátých let minulého století, nahradit? Třeba něco tak jednoduchého, z dnešního pohledu, jako byl Cray-1…

  • 2. 7. 2010 21:22

    klusacek (neregistrovaný) ---.net.upc.cz

    Mate pravdu, tim ze mame cache tak ma jadro pocit ze ma nezavisle sbernice pro instrukce a pro data. Ja prave chtel zduraznit ze SPUcka cache nemaji, maji jen tu von Neumannovskou 256KB SRAMku a i tak je ‚von-Neumanova koule‘ brzdi odhadem pouze o 10%.


    Normalni CPU tohle resi cachema coz mozna brzdi jeste min, problem je ze vetsinu plochy kremiku se zaplaca vyrovnavacima pametma a jejich managmentem. V tom mi prijde CELL zajimavej, ze misto velky cache ten kremik vyuzil pro vic vypocetnich jednotek a dedikovanych pameti.


    Jinak dnes je bezny 128bitovy interface mezi CPU a pameti na mainboardu (prece jenom to musi mit dostatecny bandwidth aby to stihalo krmit cache).


    Osobne myslim ze budoucnost je v lepeni chipu na sebe. Takze treba dole bude CPU a nad nim nekolik chipu DRAMky. Cekam ze nebude zas takovej problem udelat tam klidne 8192bitovou datovou sbernici, takze potom by CPU mohlo byt reseny podobne jako SPUcka Cellu, tj. bez cache (pouze nejake write buffery a instruction buffery), akorat ze by nemelo 256 KB, ale treba 4GB. Krome zjevnych vyhod mensich rozmeru by to taky melo mensi latenci a zjednoduseni (po logicke strance) radice pameti (dnesni RAMky, zejmena pak RAMBUS pripominaji komunikacnim protokolem spis disky nez pamet). Tim ze CPU nebude mit cache tak jich na chipu bude nekolik desitek (kazdy nad sebou bude mit svuj sloupecek RAMky, popripade treba vzdy 4 budou pamet sidlet, podle toho co se ukaze vyhodnejsi). Aby to cele pracovalo tak je potreba je propojit. K tomu IBM vyviji IR optickou komunikaci tak ze by se laserem vysilalo vnitrkem toho kremiku (okolo 1.55 um je pruhlednej) ve vlnovodech zanorenych pod transistory a propojenim. Tim by se usetrilo misto (napr. v Cellu asi 10% plochy chipu padne prave na propojeni SPUcek).


    Po architektonicke strance jsou zajimave rekonfigurovatelne pocitace. Predstavte si obri programovatelne hradlove pole ve kterem se pocitac ‚stavi‘ tesne pred prichodem dat a po jejich zpracovani se zase rekofiguruje pro dalsi data. Asi se to bude programovat uplne silene, ale slysel jsem ze nektere ulohy na tom jdou resit radove rychleji nez na GPUckach (ale mozna ze panove jenom prehaneji, prece jen prevne zapojena a optimalizovana ALU bude vzdy aspon 2* rychlejsi nez neco co si poskladam z univerzalnich bunek). Na druhou stranu, mozna ze efekt z dobreho vyuziti hradel (postavim si vzdy takovou ALU jakou potrebuju) tohle prevazi. Dovedu si predstavit ze treba pro kompresi/dekompresi (bitove manipulace), nebo sifrovani (prace s obrovskymi cisly) tohle muze byt velmi dobre.


    Nakonec, po fyzikalni strance jsou zajimave vratne pocitace. Pokud zaridite vypocet tak ze z vysledku pujde vzdy odvodit zadani tak takovy pocitac nemusi spotrebovavat energii kdyz pracuje (presneji receno, energie na 1 operaci lze libovolne snizit). Jakmile toto pocitac porusi (mazani dat z pameti) tak musi spotrebovat nejke minimalni kvantum energie. Kdyz ho nechame vypnuty (tedy bez vykonu ktery by pohanel vypocet vpred) tak bude konat nahodnou prochazku, chvili bude pocitat dopredu, chvili dozadu, ale pokud resime nejaky rozhodovaci problem typu ‚obarveni grafu N barvami‘ tak muzeme nastrazit `past' ktera ho zastavi a vyda vysledek pokud dojde ke kladne odpovedi. Takze teoreticky, v tomto pripade, by pocitac nemusel spotrebovavat vubec zadnou energii, krome te co bude predem ulozena v ‚pasti‘. Ovsem za cenu toho ze se vypocet z O(f(n)) zpomali na O(sqrt(f(n)), diky te nahodne prochazce. Taky to predpoklada ze implementace by musela byt opravdu exoticka, obvyhle obvody maji klidovy proud (neco jako prosakovani pres zavrene transistory (dnes 1/2 az 3/4 prikonu CPU)). Mozna neco supravodiveho by se dalo pouzit…
    Zatim, pokud vim, to ale neumi nikdo vyrobit, moznou nadeji je spintronika, ale netusim jak dlouho jim to bude trvat ani jak to chteji delat natoz pak jestli se k necemu vubec dostanou.
    Taky se tim lide zabyvaji uz od 80tych let (Benett, Tofolli, Feynmann) a porad nic, alespon pokud vim.


    Na uplny zaver bych chtel rict ze nema cenu se zabyvat architekturou bez alespon priblizne znalosti moznosti ktere mi dava technologie implementace. Jako je nesmysl stavet 8192 bitovou sbernici na desce tisteneho spoje tak se treba v 50tych letech jevilo nesmyslne mit 32bitova slova kdyz nemeli poradnou pamet a lecjaky pocitac pak byl 1bitovy (tedy mel treba N-bitova slova ale zpracovaval je seriove) protoze pamet (registry CPU) byly na magnetickem bubnu, nebo
    v akustickych zpozdovacich linkach (coz byly trubky naplnene rtuti (moc zdrave na psychiku programatoru) na jednom konci mikrofon na druhem reproduktor a mezi tim elektronkovy obnovovac/tvarovac impulsu).

  • 3. 7. 2010 9:45

    Radovan (neregistrovaný) 88.146.198.---

    Ty cache pomáhají fakt dost, zvlášť když jsou stokrát rychlejší než přímý přístup do paměti :) Ale i tak má smysl věnovat se nastavení parametrů paměti v BIOSu, v mojí bedně se mi povedlo zrychlit čtení z ní o 18% a bylo to sakra znát! To „vrstvení“ čipů už mě také napadlo, něco jsem o tom i četl, ale mám obavu jak se to bude všechno dohromady chladit, když dneska už potřebují chladič i RAMky… Asi bude potřeba opustit iluzi vysokých frekvencí, dobrou tak leda pro reklamu (viděl jsem kdysi jednu hru na 8MHz Amize chodit stejně jako na 25 MHz 386ce, která pro ní byla minimum), a vzít to za úplně jiný konec. Jinak ty cache sice zabírají dost místa, ale protože mají pravidelnou strukturu tak je jejich plocha lépe využitá, než třeba u ALU, která je proti jejich pravidelným mřížkám přece jen dost „kudrnatá“ :) Na druhou stranu si ty SRAM vezmou dost proudu i když nepracují (v tomhle ohledu jsou bezkonkurenční feritové paměti :-D), netuším kolik procent z celkové spotřeby procesorů to je, ale skoro bych si tipnul že většina, už jen kvůli tomu kolik tranzistorů v nich je! Myslím že dnešní nadupané herní mašiny už mají chlazení dost výkonné na to, aby se v nich nějaké ty supravodivé technologie začaly používat, možná že by se tím i pár wattů ušetřilo :-D

    Hradlová pole jsou hezká věc, jen asi pro běžné použití nebudou efektivně využitelná, ale samoorganizující počítače jsou pěkná myšlenka. Jen kdo to bude programovat, když většina dnešních programátorů má problémy i s paralelizací, já také :-D Ale já se tím aspoň neživím. A nebo se prostě počítače budou muset učit jako biologické mozky, pojem „počítačová škola“ by tak dostal úplně nový význam.

    Ale viděl bych tam jiný problém, jak na takové mašině provozovat třeba webový prohlížeč nebo přehrávač videa, prostě běžné činnosti dnešních mikropočítačů. Fakt teda netuším jak to na tom CM implementovat. Asi bych zatím zůstal u toho Craye, ten by pro to byl přeci jen použitelnější. A navíc by mi nevadilo mít ho ve zmenšeném (tak do 50 cm) provedení v koutě stolu, je to fakt nádherná věc. I když, když jsem stál vedle něj ve Science Museum, tak mě překvapilo že je o dost menší než jsem myslel, čekal jsem obludu přes dva metry vysokou a on byl o kus nižší než já. Spíš než ta hradlová pole by neškodilo uplatnit třeba mikrokódování jako měl System/370, tam se po startu počítače provedly testy, pak se do procesoru nahrály mikroinstrukce, a pak se teprve spouštěl operační systém. V podstatě se tak dal CPU nakonfigurovat podle potřeb, v roce 1972! Dnešní mikroprocesory stejně jedou v mikroinstrukcích, ale mají je zadrátované napevno, i když možná že zrovna na tohle by se ta hradlová pole dala využít velice dobře, ne přímo pro konstrukci ALU, ale pro dekódování instrukcí a samotný řadič. Nebo radši víc řadičů… Jen by to bylo trochu náročnější pro operační systém, buď by musel pro různé programy přepínat sady mikroinstrukcí (to by nebylo špatné pro emulaci), nebo by se musely programy před použitím překompilovat, třeba i z nějakého bytekódu. Ale v kombinaci s tím harwardem by mohly být opět odlišné šířky sběrnic i pamětí pro data a programy, tím bysme se zase dostali blíž k těm skutečným počítačům.

    Ty zpožďovací linky se ještě nedávnou používaly třeba v ruských televizích, akorát nevím jestli byly rtuťové nebo to byl jen nějaký slitinový drát. A s optikou bych to také zatím neviděl tak optimisticky, Japonci na tom kdysi dost tvrdě makali, a třeba tady jsem se kdysi dočetl že optické počítače páté generace budeme mít po roce 1990 :-( Ale na to propojení čipů by to snad už stačilo, aspoň. Asi bych za tu pátou generaci považoval spíš dnešní masivně paralelní stroje, než nějakou úplně novou technologii, zatím fungující spíš ve sci-fi. Také se měl místo křemíku začít používat uhlík, s tím sice měli v IBM nějaké drobné úspěchy, ale zatím se zdá že to má do sériové výroby asi tak daleko, jako Voyager k návratu na Zemi.

  • 3. 7. 2010 14:59

    klusacek (neregistrovaný) ---.net.upc.cz

    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.

  • 4. 7. 2010 11:59

    Radovan (neregistrovaný) 88.146.198.---

    To proměnlivé napětí cachí je fajn, ale na feritové paměti to pořád ještě nemá, u těch je příkon nevyužívaných bloků opravdu nulový :-D No, Amiga 500 s tou 386 byly současníci a konkurenti, proto jsem je srovnal. Navíc to mám osobně odzkoušené. Ten rozdíl byl daný jejich odlišnou koncepcí, však se na tom kromě schopností té 68000 podílelo hlavně to, že Amiga měla na každou ptákovinku koprocesor, zatímco ta 386 to musela všechno oddřít sama. O deset let později to konstruktérům PC konečně také došlo, ale dodnes to tak nějak není ono :-/ Stejně tak CM by určitě zvládl webovou stránku zobrazit, když se na tom dělaly animace, ale muselo by se na to jít hodně odlišně než u dnešních browserů. Fakt bych to radši programoval na tom Crayi…

    On Cray-1 měl sice jen 80 MHz , ale v roce 1976, kdy se osmibity drápaly k jednomu. Je fakt, že ty nepotřebovaly freonové chlazení. A navíc ty vektory počítal paralelně, plus pár dalších kouzel které tenkrát Seymour Cray použil, včetně toho že je „do oblouku“. Jen by mě zajímalo, jestli je pravdivá legenda o tom, jak nacvakal do CDC 7600 při prvním spuštění operační systém přes čelní panel zpaměti, nebo jestli to byl jen zavaděč, což se v té době dělalo celkem běžně ;-) Každopádně to byl borec. Ale dnešní PC paritu také nemají, a jak čím dál častěji narážím u známých na vadné a chybující paměti, myslím že by jim něco takového neuškodilo. Ony by pak i Windowsy padaly méně často.

    Jo, tak nějak jako to má ten SPARC jsem ten mikrokód myslel, jen by tam těch řadičů a pamětí mikrokódu mohlo být víc, už kvůli tomu aby se mohly využít všechny části procesoru nebo i ALU současně, když se budou třeba dva registry sčítat, další dva násobit a jiný porovnávat s něčím v paměti. Mohlo by to prospět i té optimalizaci, zvlášť že by si ty řadiče po sobě jdoucí instrukce rozebraly a zpracovávaly téměř nezávisle. A nakonec, mikrokódování měl už Charles Babbage u Analytical Engine, že bysme na něj pořád ještě neměli? :-P

    Ta zpožďovací linka co jsem viděl byla fakt smyčka z drátu, ale nic bližšího než že to bylo z ruské televize k tomu fakt nevím. Oni si ale na ty dráty potrpěli, třeba trasa letu v prvních verzích MiGu-25 se programovala protahováním drátu skrz zapojovací desku!

    A díky za doplnění a upřesnění, snad si z těch detailů něco zapamatuji :)

  • 4. 7. 2010 14:29

    klusacek (neregistrovaný) ---.net.upc.cz

    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.

  • 4. 7. 2010 14:38

    klusacek (neregistrovaný) ---.net.upc.cz

    Tedy propagation delay na hradlo je 29ps=1/(3.2GHz*11), nejak mi tam vlitla nula navic.

  • 7. 7. 2010 10:57

    Pavel Tišnovský

    Hlavne samotne IBM si kvuli PC samo pod sebou tak trosku podrezalo vetev, protoze lidi i ve velkych firmach zacali svoje textove terminaly (k serverum IBM) nahrazovat PCcky kde:
    1) puvodni ROM BIOS byl nahrazen nejakym klonem (AMI atd.)
    2) DOS od IBM byl typicky nahrazen za MS DOS
    3) vlastni HW se vyrabel nekde na Taiwanu, z toho nemela IBM ani $
    4) PC hardware od IBM taky docela zkomira(l) na ukor mnoha dalsich vyrobcu – klavesnice, harddisky, zakladni desky, pozdeji notebooky

  • 2. 7. 2010 16:51

    Radovan (neregistrovaný) 88.146.198.---

    Nojo, jenže tu neměli v jednaosmdesátém roce v desktopu :-P Ale je to dobrý příklad že to jde, jen houšť a větší kapky.

  • 30. 6. 2010 13:35

    dex (neregistrovaný) ---.fnb.cz

    BBC Basic byl rychlý i na osmibitech.
    Pokud se podíváte na dobové časopisy (Practical Computing, leden 1984), „benchmarkové testy“ tam byly realizovány tak, jak rychle zvládne počítač zpracovat daný program v Basicu.
    Osmibitové BBC s tříregistrovým 6502 procesorem v tehdejší době drtilo i 16bit IBM PC, které mělo od Microsoftu mnohem méně optimalizovaný Basic, takže jeho běh byl pomalejší, než na BBC.

  • 1. 7. 2010 21:02

    Radovan (neregistrovaný) 88.146.198.---

    Já jsem kdysi narazil na srovnání ZX81 a Spectra, kde vyhrál ten ZX81 :-D Ale jinak Microsoft nepřekvapuje.

  • 1. 7. 2010 0:36

    Mach (neregistrovaný) ---.adsl.tmcz.cz

    Jééé, to byla moje první kniha o BASICu ještě z dob Didaktiku Gama. To jsem se vyřádil. Žádný internet, vše hltat z knih. Slza ukápla.