Hlavní navigace

IBM a sedm trpaslíků (osmá část)

Pavel Tišnovský 15. 2. 2011

V předchozí části seriálu o historii výpočetní techniky jsme se seznámili se základními parametry sálových počítačů Burroughs B5000. Dnes popis těchto počítačů dokončíme – budeme se věnovat práci s daty, organizaci operační paměti a taktéž tím, jak se na těchto počítačích pracovalo s jazykem ALGOL.

Obsah

1. Operační paměť počítačů Burroughs B5000

2. Deskriptory a segmenty

3. B5000 – první počítač s virtuální pamětí

4. Operační systém – Master Control Program (MCP)

5. Nízkoúrovňové a vysokoúrovňové programovací jazyka na mainframech

6. Jednoprůchodový překladač ALGOLu na platformě B5000

7. ALGOL namísto assembleru?

8. Programovací jazyk ALGOL na dalších sálových počítačích

9. Odkazy na Internetu

1. Operační paměť počítačů Burroughs B5000

V předchozí části seriálu o historii výpočetní techniky jsme si řekli základní informace o sálových počítačích B5000, které byly na počátku šedesátých let minulého století zkonstruovány a následně vyráběny společností Burroughs Corporation. Architektura těchto mainframů v několika ohledech předběhla svoji dobu, protože počítač Burroughs B5000 patřil mezi první počítače s virtuální pamětí, možností rychlého přepínání procesů a taktéž se jednalo o platformu nabízející hardwarovou (obvodovou) podporu vyšších programovacích jazyků, především pak programovacího jazyka ALGOL, jehož syntaxe a sémantika se stala inspirací pro mnoho dalších programovacích jazyků (právě kvůli tomu se mnohdy mluví o takzvané „algolské větvi“ programovacích jazyků). V následujících kapitolách se s některými výše zmíněnými vlastnostmi platformy Burroughs B5000 seznámíme podrobněji. Nejdříve začneme popisem organizace operační paměti, protože právě struktura této paměti a způsob jejího ovládání do značné míry ovlivnila i další vlastnosti těchto počítačů.

ibm04

Obrázek 1: Bubnovou paměť můžeme z technologického hlediska považovat za předchůdce dnešních pevných disků, i když se u některých počítačů používala jako sice relativně pomalá, ale zato poměrně rozsáhlá operační paměť (popř. jako sekundární oblast operační paměti, což je právě případ mainframů Burroughs B5000). Na rozdíl od pevných disků se u bubnových pamětí používala pro každou stopu samostatná sada čtecích a zápisových hlav, což zjednodušilo konstrukci paměti (nemusel se totiž konstruovat mechanismus pro vystavení hlav, které byly ostatně mnohem těžší než hlavy pevných disků, což by vystavování činilo mnohem složitějším) a současně se umožnil paralelní zápis či čtení dat ze všech stop současně.

Již minule jsme si řekli, že paměť počítače Burroughs B5000 byla rozdělena na dvě konstrukčně zcela odlišné oblasti. První oblast byla představována bubnovou pamětí (popř. i několika jednotkami bubnové paměti), která sice měla poměrně velkou kapacitu, ovšem přístup k datům nebyl zcela náhodný – doba čekání na čtení či zápis dat se lišila podle toho, kde byla data na bubnové paměti uložena a jak byla tato oblast v daném okamžiku vzdálena od čtecích či zápisových hlaviček. Druhá oblast paměti byla představována feritovou pamětí, tj. pamětí vytvořenou mřížkou vodičů, v jejichž průsečících se nacházela toroidní feritová jádra (pro každý bit bylo vyhrazeno právě jedno jádro). Tato paměť měla sice menší kapacitu a současně i větší cenu za každý uložený bit než paměť bubnová, ovšem na druhou stranu tato paměť umožňovala skutečně náhodný přístup ke čteným či zapisovaným datům. U počítačů Burroughs B5000 neměli programátoři umožněn přímý přístup do paměti (tj. do jednotlivých 48bitových slov), což je sice na jednu stranu poněkud omezující, na stranu druhou to však umožnilo vyvinout poměrně novátorský způsob práce s programovým kódem a daty uloženými v jedné z paměťových oblastí.

Obrázek 2: Sálové počítače Burroughs pracovaly se slovy o šířce 48 bitů, které byly na bubnovou paměť ukládány způsobem zobrazeným na tomto nákresu.

2. Deskriptory a segmenty

Při popisu organizace operační paměti sálových počítačů B5000 nám pomůže nákres struktury této paměti, který je zobrazený na třetím obrázku umístěném pod tímto odstavcem. Na tomto nákresu můžeme vidět především oblast nazvanou Master Control Program, což není nic jiného než paměť rezervovaná pro jádro operačního systému, nazývané taktéž zkráceně MCP. Ovšem zajímavější jsou oblasti nazvané Program Reference Table, které byly (operačním systémem) vytvořeny pro každý spuštěný proces. Na ilustračním obrázku zobrazeném pod tímto odstavcem jsou alokovány tři oblasti Program Reference Table, protože je zde zobrazena struktura paměti ve chvíli, kdy byly v počítači spuštěny tři procesy. V těchto oblastech paměti byla uložena řídicí slova známá pod jménem deskriptory (ostatně není bez zajímavosti, že slovo descriptor použila poprvé v tomto kontextu právě firma Burroughs při popisu platformy B5000). Každý deskriptor popisoval jeden datový segment, programový segment nebo segment používaný pro vstupně-výstupní operace.

Obrázek 3: Oblasti vytvořené v paměti sestavené z feritových ja­der.

Deskriptor datového segmentu obsahoval především velikost tohoto segmentu, počáteční adresu segmentu v paměti, adresu téhož segmentu v bubnové paměti, číslo bubnové paměti (pokud bylo použito více jednotek bubnových pamětí) a v neposlední řadě taktéž bit, který určoval, zda byl tento segment uložen pouze v bubnové paměti nebo i v paměti feritové (jádrové). Prakticky stejné informace byly ukládány i u dalších dvou typů segmentů. Povšimněte si, že na rozdíl od některých dalších architektur nemusela být velikost segmentů konstantní – bylo tomu právě naopak, protože například překladač programovacího jazyka ALGOL vytvářel pro každé alokované pole nový segment, což mimochodem vedlo k tomu, že se hardwarově kontrolovalo, zda se při indexování prvků pole nepřekračuje jeho alokovaná velikost (nikoli ovšem to, zda je překročena mez indexů nižších dimenzí u vícerozměrných polí). Navíc se díky tomu, že jednotlivé typy segmentů byly odlišeny takzvaným tagem, mohlo zajistit (opět na hardwarové = obvodové) úrovni, aby se v datovém segmentu nesnažil někdo spustit kód a naopak – s programovým segmentem se nedalo v uživatelských programech nijak manipulovat, protože jeho obsah byl určen pouze pro čtení. Právě tyto vlastnosti činily z B5000 jednu z nejspolehli­vějších a nejbezpečnějších platforem své doby.

Obrázek 4: Jedna z dobových konstrukcí feritové paměti. I přesto, že tyto paměti byly poměrně velké a měly nevýhodný poměr cena/bit, byly (a pravděpodobně doposud jsou) tyto typy pamětí používány například v družicích, protože feritové paměti jsou odolné vůči kosmickému záření. U některých typů počítačů a dalších specializovaných zařízení bylo taktéž využito další vlastnosti: feritová paměť jednou zapsanou informaci „zapomene“ až po poměrně dlouhé době a nikoli ihned po výpadku napájení.

3. B5000 – první počítač s virtuální pamětí

V předchozí kapitole jsme si řekli, že každý deskriptor datového, programového nebo I/O segmentu obsahoval i jednobitový příznak určující, zda je tento segment uložen v paměti tvořené feritovými jádry, nebo pouze v některé z bubnových pamětí (tento bit byl poměrně názorně nazvaný presence bit). Aktuální hodnota tohoto bitu byla hlídána obvodově, což znamenalo, že při pokusu o přístup do segmentu uloženého pouze v bubnové paměti byla vyvolána na hardwarové úrovni výjimka (přesněji řečeno došlo k přerušení vedoucí později ke vzniku výjimky), která mohla být obsloužena operačním systémem, a to poměrně jednoduše – systém zkopíroval obsah segmentu z bubnové paměti do paměti feritové (popř. předtím nějaký segment naopak uložil do bubnové paměti, aby se uvolnila potřebná kapacita v paměti feritové). Tuto kopii mohl systém provést celkem jednoduše, protože měl všechny potřebné informace k dispozici v deskriptoru segmentu, kde byla uložena – jak již víme z předchozí kapitoly – délka dat či délka programu, číslo bubnové paměti, počáteční adresa segmentu na bubnové paměti a počáteční adresa segmentu v paměti feritové.

Obrázek 5: Data a taktéž programy mohly být ukládány na vícestopé magnetické pásky. Na této fotografii je zobrazena magnetopásková jednotka dodávaná firmou Burroughs Corporation ke svým mainframům.

Díky obvodovému řešení sálového počítače Burroughs B5000 (konkrétně kvůli hlídání stavu bitu presence s podmíněným vyvoláním přerušení) a podpoře pro kopie obsahů segmentů v jeho operačním systému MCP byla tato platforma s velkou pravděpodobností prvním počítačem s virtuální pamětí. V praxi se existence virtuální paměti projevila tak, že tento počítač nebo některý z jeho následovníků, dokázal mít v jeden okamžik spuštěný proces nebo i více paralelně běžících procesů, které mohly pracovat s daty, jejichž objem mohl být v součtu větší, než byla celková kapacita jádrové paměti. Programátoři se přitom vůbec nemuseli (a v podstatě ani nemohli!) starat o to, jakým způsobem operační systém zajistí, aby byly všechny potřebné informace přístupné. Paradoxní přitom je, že například na platformě IBM PC se ještě v osmdesátých letech minulého století (tj. 20 až 25 let po konstrukci B5000!), museli programátoři v DOSu explicitně starat o to, jakým způsobem budou pracovat s objemnými daty, které mohly být uloženy například v pamětech typu XMS, EMS či na disku nebo disketě. Teprve příchod chráněného režimu vývojáře od této povinnosti odstínil.

Obrázek 6: Zařízení pro zápis informací na děrné štítky, které bylo taktéž dodáváno k mainframům firmy Burroughs.

4. Operační systém – Master Control Program (MCP)

Firma Burroughs Corporation dodávala svým zákazníkům kromě vlastního sálového počítače a jeho periferních zařízení i operační systém Master Control Program (MCP), o němž jsme se ostatně již několikrát zmínili v předchozích kapitolách. Ovšem zatímco v současnosti se operační systémy (většinou) vyvíjí a upravují na již existující hardwarovou platformu, byla situace u firmy Burroughs v mnoha ohledech odlišná, protože řídicí obvody počítače, jeho instrukční sada i operační systém byly navrhovány současně, a to takovým způsobem, aby byl zajištěn co nejrychlejší ale současně i co nejbezpečnější běh uživatelských aplikací. Typickým příkladem vzájemného přizpůsobení hardware a software (operačního systému) je například instrukce LLLU (linked-list lookup) navržená takovým způsobem, aby zjednodušila a urychlila správu paměti operačním systémem. Dalším příkladem vzájemného přizpůsobení je elektronický obvod zajišťující, aby se při příchodu přerušení nejenom uložil stav běžícího procesu na zásobník (což je dnes ostatně zcela běžné), ale aby se i automaticky spustila dříve zaregistrovaná funkce, samozřejmě s předáním všech potřebných parametrů – a to bez nutnosti zásahu operačního systému, což ve výsledku umožnilo, aby byl přerušovací subsystém počítačů Burroughs B5000 velmi rychlý.

Obrázek 7: Rychlá řádková tiskárna používaná u mainframů Burroughs B5000 k vytváření tiskových sestav atd.

Zajímavé a ve své době i neobvyklé bylo, že operační systém Master Control Program nebyl napsán ani ve strojovém kódu ani v assembleru, ale ve vyšším programovacím jazyce nazvaném ESPOL (Executive Systems Programming Oriented Language), což byla upravená verze ALGOLu. V současnosti již jsme, zejména díky existenci různých větví Unixu, zvyklí na to, že i operační systémy jsou naprogramovány ve vysokoúrovňových programovacích jazycích, ovšem v šedesátých letech minulého století se stále jednalo spíše o výjimku. Poznámka: v dalších kapitolách se zmíníme o tom, že instrukční sada i struktura samotného procesoru mainframu B5000 byly optimalizovány pro běh přeložených programů napsaných v ALGOLu, ovšem stejné tvrzení samozřejmě ještě ve větší míře platí i pro programovací jazyk ESPOL. Na tomto programovacím jazyku je navíc zajímavé i to, že prakticky každá instrukce z instrukční sady procesoru mainframu B5000 měla svoji přímou obdobu v některé konstrukci jazyka ESPOL, což je opět jedna z odlišností od dnešní dominantní architektury i386/x86_64, kde je mezi instrukční sadou a některým vyšším programovacím jazykem dosti velká „sémantická mezera“.

Obrázek 8: Tiskárna používaná pro tisk zpráv posílaných operačním systémem. S touto tiskárnou je spojena i klávesnice, takže celek vlastně tvořil operátorskou konzoli (terminál).

5. Nízkoúrovňové a vysokoúrovňové programovací jazyka na mainframech

Vývojáři, kteří vytvářeli programy v padesátých a začátkem šedesátých let minulého století (v některých zemích však i mnohem později), měli k dispozici poměrně omezené prostředky. Při použití nižších (tj. nestruktu­rovaných) programovacích jazyků se řešený algoritmus nejdříve navrhl pomocí vývojových diagramů. Posléze se takto popsaný algoritmus převedl do assembleru a v této podobě se zapsal na děrné štítky. Po překladu byl výsledný objektový kód většinou zapsán na magnetickou pásku a páska byla uložena pro opětovné načtení programu do operační paměti počítače. Tvorba programů ve vyšších (strukturovaných) programovacích jazycích byla sice jednodušší, ale stále se jednalo o poměrně zdlouhavou práci s mnoha kroky. Program musel být nejdříve napsán na připravený formulář, který byl následně na děrovačce přenesen na děrné štítky. Právě zde se ukázala nutnost používat programovací jazyk se striktní syntaxí, aby se případné chyby při děrování štítků odhalily (ostatně některé chyby neodhalené při překladu jsou dnes považovány za jednu z největších známých programátorských chyb – viz často citovaná záměna čárky za tečku ve Fortranu).

Obrázek 9: Na tomto obrázku je zobrazen bitový formát dat ukládaných na magnetickou pásku mainframů Burroughs. Z obrázku se však dá vyčíst i mnohem více údajů; například to, že znaková sada měla pouze 64 znaků (2 zónové bity + 4 numerické bity) a taktéž to, že se nejednalo o sadu ASCII, ale o sadu uzpůsobenou potřebám programovacího jazyka ALGOL.

Původní překladače vyšších programovacích jazyků, které byly tradičně používány na první a druhé generaci mainframů, byly většinou implementovány takovým způsobem, že se vlastní překlad prováděl ve třech krocích. To, zda byly tyto kroky prováděny před uživatelem skrytě, záviselo na konstrukci překladače a taktéž na tom, jakou kapacitu operační paměti měl překladač k dispozici (ostatně i dnes lze u některých překladačů nařídit pouze provedení některého kroku překladu). V prvním kroku se provádělo zpracování vlastního zdrojového textu, tj. parsing textu, tvorba tokenů a popř., v závislosti na překladači, i tvorba abstraktního syntaktického stromu (AST – Abstract Syntax Tree). Ve druhém kroku se transformovaný program reprezentovaný například AST či sekvencí tokenů znovu transformoval do vhodného mezikódu (intermediate code) – mohlo se například jednat o tříadresový kód, v pozdějších dobách se používal P-kód, zásobníkový kód atd. Teprve v kroku třetím skutečně došlo k vygenerování výsledného objektového kódu, který byl buď ještě zpracován linkerem, nebo se mohlo v některých případech jednat o výsledný spustitelný kód.

Obrázek 10: Jednoduchý program v ALGOLu, na němž je vidět bloková struktura tohoto programovacího jazyka, strukturované rozhodovací příkazy, statické typování a taktéž to, že se v programu vyskytovaly operátory zapisované pomocí znaků, které nepatřily do znakové sady ASCII.

6. Jednoprůchodový překladač ALGOLu na platformě B5000

„Here is a language so far ahead of its time that it was not only an improvement on its predecessors but also on nearly all its successors.“
C. A. R. Hoare

Tříkrokový postup překladu programů, o němž jsme se zmínili v předchozí kapitole, s sebou přinášel některé výhody. První výhodou bylo zjednodušení jednotlivých částí překladače, protože se oddělil jeho frontend od backendu a v některých případech bylo možné backend překladače spustit až po proběhnutí frontendu, což byl postup využívaný na některých platformách s malou kapacitou operační paměti. Dále bylo možné kompilovaný program optimalizovat již na úrovni AST a/nebo mezikódu, kde se některé typy optimalizací (zjednodušování aritmetických a logických výrazů, detekce invariantů v programových smyčkách, rozbalování smyček, použití inline funkcí atd.) mohly provádět jednodušeji, než při generování výsledného objektového kódu. Ovšem cena za tuto větší univerzalitu byla poměrně velká: především došlo k prodloužení doby překladu (zvláště citlivé téma v dobách, kdy se platilo za strojový čas počítače) a taktéž kvůli několika transformacím a mezipřekladům docházelo k takové změně výsledného objektového kódu, která znesnadňovala jeho ladění – jinými slovy to znamená, že mezi původním zdrojovým textem a výsledným objektovým kódem byly značné sémantické rozdíly.

ibm-5

Obrázek 11: Manuál k první verzi FORTRANu určeného pro mainframy IBM 704.

U mainframů Burroughs B5000 byla situace poněkud odlišná, protože se při návrhu instrukční sady tohoto sálového počítače jeho tvůrci zaměřili na to, aby se první dva kroky při překladu mohly sloučit do kroku jediného a krok třetí vlastně nemusel být proveden vůbec. Díky použití zásobníkového procesoru to bylo skutečně možné – zdrojový kód byl prakticky ihned po své tokenizaci přímo převáděn do strojových instrukcí, které svou sémantikou odpovídaly známé převrácené Polské notaci (RPN – Reverse Polish Notation). Není tedy divu, že překlad programů byl v porovnání s mnoha dalšími tehdy existujícími počítači velmi rychlý, což s sebou přineslo i jednu zajímavost – pro počítače B5000 neexistoval assembler, což znamenalo, že všechny systémové utility byly psány v ESPOLu či ALGOLu (konkrétně v ALGOLu 60), protože FORTRAN a v určitém ohledu i COBOL začaly být považovány za jazyky nevhodné pro tvorbu rozsáhlejších programů – navíc byl překlad programů psaných v ALGOLu nejjednodušší.

ibm-5

Obrázek 12: Jedna z populárních dobových učebnic ALGOLU 68.

7. ALGOL namísto assembleru?

In general I viewed ALGOL as a perfected version of BASIC and FORTRAN, sort of a programmer's dream language.

Vzhledem k tomu, že se programátoři na sálovém počítači Burroughs B5000 prakticky nikdy nesetkali s assemblerem ani přímo se strojovým kódem, byla zaručena i dopředná kompatibilita s dalšími počítači navrženými touto společností, které byly používány v následujících více než 25 letech – programy napsané ve vyšším programovacím jazyce ALGOL 60 nebo COBOL 61 bylo možné jednoduše přenést na modernější systémy, které mohly být teoreticky vybavené zcela odlišnou instrukční sadou (ve skutečnosti se instrukční sada v naprosté většině případů sice rozšiřovala, ale neměnila). Nejednalo se tedy o striktně binární kompatibilitu, s jakou se můžeme setkat především na některých mainframech IBM a samozřejmě též na platformě i386, ale o kompatibilitu zaručenou tím, že programátoři nikdy nemuseli a ve většině případů ani nemohli přistupovat přímo „na železo“.

ibm-5

Obrázek 13: Spolu s rozšiřováním Fortranu z mainframů firmy IBM na další architektury – včetně sálových počítačů Burroughs – se zvyšovala potřeba standardizace tohoto jazyka. Postupně vzniklo několik norem, například ANSI norma FORTRAN 66, FORTRAN 77, či ANSI/ISO standard Fortran 90 (názvy standardů jsou uvedeny správně – jméno jazyka se skutečně postupem času změnilo z „FORTRAN“ na „Fortran“).

Jak jsme se již zmínili v předchozím textu, byl překladač ALGOLu, přesněji řečeno jeho implementace na počítači Burroughs B5000, která se v několika maličkostech odlišovala od standardního ALGOLu 60, velmi rychlý. Čas překladu průměrně rozsáhlých programů se pohyboval v řádech desítek sekund až jednotek minut, zatímco u mnoha dalších platforem se programy v některých případech překládaly i několik desítek minut až hodin. Navíc se, především díky použití zásobníkového kódu, většina výrazů přeložila takovým způsobem, že ladění programů bylo snazší (u architektur používajících pracovní registry namísto zásobníku je v některých případech problematické zjistit, jak se vlastně nějaký aritmetický či logický výraz přeložil, protože některé registry musí být použity pro uložení mezivýsledků, popř. je pořadí některých operací přehozeno; zatímco u zásobníkového kódu tomu tak nemusí být a v případě B5000 tomu tak ani nebylo).

Obrázek 14: Na mainframech Burroughs B6700 byla použita mírně upravená verze ALGOLu 60.

Kromě programovacího jazyka ALGOL se na platformě B5000 poměrně často používal i programovací jazyk COBOL 61, takže si programátoři v závislosti na povaze řešeného projektu většinou vybírali mezi „algebraickým“ jazykem ALGOL a „konverzačním“ jazykem COBOL, v němž se původně prakticky všechny deklarace, příkazy a dokonce i výrazy zapisovaly pomocí sekvence anglických slov.

8. Programovací jazyk ALGOL na dalších sálových počítačích

Programovací jazyk ALGOL původně vznikl za účelem snadno pochopitelného algoritmického popisu matematických (především numerických) úloh, výuku programování a vývoj překladačů. Z tohoto důvodu například původní návrh jazyka (IAL – International Algorithmic Language, později přejmenovaný na ALGOL 58) neobsahoval žádné konstrukce pro vstup a výstup dat (ty ostatně ani nebyly součástí ALGOLu 60), ovšem se vznikem prvních reálných překladačů se množina konstrukcí jazyka postupně rozrůstala, takže ve standardu ALGOL 68 již jazyk obsahoval jak operace vstupu a výstupu, tak i podporu pro nenumerické úlohy aj. V programovacím jazyce ALGOL byly prakticky poprvé použity konstrukce umožňující strukturované programování – týká se to především programových smyček bez návěští, podmíněných příkazů, blokové struktury programu a též lexikálního rozsahu (viditelnosti) proměnných v závislosti na tom, ve kterém programovém bloku je proměnná deklarována (tuto vlastnost z ALGOLu převzal i programovací jazyk Scheme, který je v v mnoha jiných ohledech založený na LISPu).

Obrázek 15: Graf syntaxe smyčky FOR v ALGOLu. Povšimněte si toho, že pomocí této jazykové konstrukce lze vytvořit jak počítanou smyčku (což je dodnes dodržovaný úzus při použití klíčového slova FOR), tak i smyčku typu WHILE s podmínkou vyhodnocovanou na začátku těla smyčky.

Programovací jazyk ALGOL se využíval jak pro zápis programů v učebnicích a vědeckých článcích (mnohdy až prakticky do současnosti), tak i v každodenní programátorské praxi. V tištěné literatuře se používal poněkud jiný způsob zápisu, protože bylo možné použít typografické zvýraznění jednotlivých prvků jazyka i sadu znaků velké a malé abecedy, zatímco některé mainframy používaly pouze znaky velké abecedy. Jednou ze zajímavostí je, že se tento jazyk (resp. jeden z jeho dialektů) používal i v SSSR, mj. také v projektu raketoplánu Buran. Tato verze jazyka byla dokonce v SSSR standardizována takovým způsobem, že používala znakovou sadu definovanou v normě GOST 10859 (kromě toho vznikl derivát ALGOLu nazvaný ALGAMC). Existuje i čínská verze tohoto jazyka, ve které se namísto znaků z tabulek ASCII či EBDIC používají národní znaky. Programovacím jazykem ALGOL se inspirovali tvůrci mnoha dalších programovacích jazyků. Jedná se například o jazyky Simula, Pascal (i další jazyky navržené N. Wirthem) a v neposlední řadě též trojice na sebe navazujících jazyků BCPL, B a C. Na syntaxi céčka jsou postaveny další jazyky, zejména C++, Java a dokonce dynamicky typovaný JavaScript. Těmto jazykům se proto také někdy říká „algolské“ (Algol-like) nebo též jazyky patřící do algolské větve.

Obrázek 16: Programovací jazyk ALGOL byl používán nejenom na platformě B5000, ale například i o deset let později na sálových počítačích Burroughs B6700.

Na následujícím výpisu krátkého programu (jedná se o známý Bresenhamův algoritmus rasterizace úsečky) si povšimněte, že je celý program snadno pochopitelný i v případě, že jazyk ALGOL neznáte. Mnoho konstrukcí ALGOLu totiž skutečně „zdomácnělo“ i v dalších programovacích jazycích. Poznámka: zde je použitý dialekt ALGOL 68, při použití ALGOLu 60 by se například programové smyčky zapisovaly odlišným způsobem.

PRAGMAT READ "Basic_bitmap_storage.a68" PRAGMAT;

line OF class image := (REF IMAGE picture, POINT start, stop, PIXEL color)VOID:
BEGIN
   REAL dx = ABS (x OF stop - x OF start),
        dy = ABS (y OF stop - y OF start);
   REAL err;
   POINT here := start,
         step := (1, 1);
   IF x OF start > x OF stop THEN
      x OF step := -1
   FI;
   IF y OF start > y OF stop THEN
      y OF step := -1
   FI;
   IF dx > dy THEN
      err := dx / 2;
      WHILE x OF here /= x OF stop DO
         picture[x OF here, y OF here] := color;
         err -:= dy;
         IF err < 0 THEN
            y OF here +:= y OF step;
            err +:= dx
         FI;
         x OF here +:= x OF step
      OD
   ELSE
      err := dy / 2;
      WHILE y OF here /= y OF stop DO
         picture[x OF here, y OF here] := color;
         err -:= dx;
         IF err < 0 THEN
            x OF here +:= x OF step;
            err +:= dy
         FI;
         y OF here +:= y OF step
      OD
   FI;
   picture[x OF here, y OF here] := color # ensure dots to be drawn #
END # line #;

Následující příklad (převzatý ze stránek projektu Rosetta Code) vypočítá přibližnou hodnotu čísla Π metodou Monte Carlo. Opět se jedná o program napsaný v dialektu ALGOL 68. Povšimněte si především operátoru ** (mocnina) a taktéž +:= (displacement operator vracející původní hodnotu a současně provádějící inkrementaci):

PROC pi = (INT throws)REAL:
BEGIN
    INT inside := 0;
    TO throws DO
        IF random ** 2 + random ** 2 <= 1 THEN
            inside +:= 1
        FI
    OD;
    4 * inside / throws
END

9. Odkazy na Internetu

  1. ALGOL in the early 1970s
    http://www.sim­nia.com/it/cly­cl/algol/algol­.htm
  2. Burroughs: IF (Dec, 1961)
    http://blog.mo­dernmechanix.com/2009/02­/10/burroughs-if/
  3. Burroughs B5000: Encyclopedia II – Burroughs B5000 – ALGOL
    http://www.ex­periencefesti­val.com/a/Burrou­ghs_B5000_-_ALGOL/id/4823149
  4. HOW ASCII GOT ITS BACKSLASH
    http://www.bob­bemer.com/BAC­SLASH.HTM
  5. Burroughs B5000 Computer
    http://www.cs­.uaf.edu/2010/fa­ll/cs441/proj1/b5000/
  6. Burroughs large systems (Wikipedia)
    http://en.wiki­pedia.org/wiki/Bu­rroughs_large_sys­tems
  7. Burroughs large systems instruction sets (Wikipedia)
    http://en.wiki­pedia.org/wiki/Bu­rroughs_large_sys­tems_instructi­on_sets
  8. William Seward Burroughs
    http://history-computer.com/Mecha­nicalCalculator­s/19thCentury/Bu­rroughs.html
  9. Burroughs Corporation (Wikipedia)
    http://en.wiki­pedia.org/wiki/Bu­rroughs_Corpo­ration
  10. Adding machine (Wikipedia)
    http://en.wiki­pedia.org/wiki/Ad­ding_machine
  11. Burroughs B-205
    http://www.an­gelfire.com/sci­fi/B205/
  12. Burroughs 205 Hardware Package Design
    http://tjsawy­er.com/B205Pkg­.htm
  13. ERA 1101 Documents
    http://ed-thelen.org/comp-hist/ERA-1101-documents.html
  14. Ukázkový program pro UNIVAC 1101/ERA 1101
    https://wiki.cc­.gatech.edu/fol­klore/index.php/En­gineering_Rese­arch_Associates_an­d_the_Atlas_Com­puter_(UNIVAC_1101)
  15. UNIVAC I Computer System
    http://univac1­.0catch.com/
  16. UNIVAC I Computer System
    http://univac1­.0catch.com/y­ellowpage.htm
  17. UNIVAC (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­nivac
  18. UNIVAC I (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­NIVAC_I
  19. UNIVAC II – Universal Automatic Computer Model II
    http://ed-thelen.org/comp-hist/BRL61-u4.html
  20. UNIVAC II (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­NIVAC_II
  21. UNIVAC III (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­NIVAC_III
  22. UNIVAC 1101 (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­NIVAC_1101
  23. UNISYS History Newsletter
    https://wiki.cc­.gatech.edu/fol­klore/index.php/Ma­in_Page
  24. UNIVAC Solid State (Wikipedia)
    http://en.wiki­pedia.org/wiki/U­NIVAC_Solid_Sta­te
  25. Bi-quinary coded decimal (Wikipedia)
    http://en.wiki­pedia.org/wiki/Bi-quinary_coded_de­cimal
  26. UNIVAC III Data Processing System
    http://ed-thelen.org/comp-hist/BRL61-u4.html#UNIVAC-III
  27. The UNIVAC III Computer
    https://wiki.cc­.gatech.edu/fol­klore/index.php/The_U­NIVAC_III_Com­puter
  28. UNIVAC III Photos
    http://jwstep­hens.com/univac3/pa­ge01.htm
  29. A History of Unisys Computers (kniha)
    http://www.lu­lu.com/produc­t/hardcover/a-history-of-unisys-computers/4627477
  30. UNIVAC III Instructions Reference Card
    http://www.bit­savers.org/pdf/u­nivac/univac3/UT-2455_UNIVACII­I_RefCd61.pdf
  31. Index register (Wikipedia)
    http://en.wiki­pedia.org/wiki/In­dex_register
  32. FLOW-MATIC, COBOL's Roots, Birth of COBOL…
    http://www.inf.fu-berlin.de/leh­re/SS01/hc/pl/co­bol.htm
  33. FLOW-MATIC
    http://en.wiki­pedia.org/wiki/FLOW-MATIC
  34. FLOW-MATIC Manual
    http://archive­.computerhisto­ry.org/resources/tex­t/Remington_Ran­d/Univac.Flow­matic.1957.102646140­.pdf
  35. Grace Murray Hopper
    http://cs-www.cs.yale.e­du/homes/tap/Fi­les/hopper-story.html
  36. Grace Hopper
    http://en.wiki­pedia.org/wiki/Gra­ce_Hopper
  37. Biographies of Women Mathematicians: Grace Murray Hopper
    http://www.ag­nesscott.edu/lrid­dle/women/hop­per.htm
  38. A-0 System
    http://en.wiki­pedia.org/wiki/A-0_programming_lan­guage
  39. Rosetta Code – Category:COBOL
    http://rosetta­code.org/wiki/Ca­tegory:COBOL
  40. COmmon Business Oriented Language
    http://foldoc­.org/COBOL
  41. COBOL Compilers
    http://www-01.ibm.com/sof­tware/awdtool­s/cobol/
  42. Cobol: Not Dead Yet
    http://www.com­puterworld.com/s/ar­ticle/266156/C­obol_Not_Dead_Y­et?intsrc=kc_rfavs
  43. The future's bright … the future's Cobol
    http://features­.techworld.com/ap­plications/3056/the-futures-bright–the-futures-cobol/
  44. COBOL Example Programs
    http://www.csis­.ul.ie/COBOL/e­xamples/defau­lt.htm
  45. Introduction to COBOL
    http://www.csis­.ul.ie/COBOL/Cou­rse/COBOLIntro­.htm
  46. COBOL programming – tutorials, lectures, exercises, examples
    http://www.csis­.ul.ie/COBOL/
  47. Wikipedia: COBOL
    http://en.wiki­pedia.org/wiki/CO­BOL
  48. Humor on Computers, Systems and Programming
    http://www-crypto.htw-saarland.de/we­ber/misc/program­ming.html
  49. OpenCOBOL
    http://en.wiki­pedia.org/wiki/O­penCOBOL
  50. OpenCOBOL.org
    http://openco­bol.org/
  51. OpenCOBOL FAQ
    http://openco­bol.add1tocobol­.com/
  52. TinyCOBOL
    http://tiny-cobol.sourcefor­ge.net/
  53. TinyCOBOL FAQ
    http://tiny-cobol.sourcefor­ge.net/docs/faq/
  54. JTC1/SC22/WG4 – COBOL
    http://ra.dku­ug.dk/jtc1/sc2­2/wg4/
  55. COBOL on COGS
    http://www.co­boloncogs.org/IN­DEX.HTM
  56. Cobol Coders: Going, Going, Gone?
    http://www.com­puterworld.com/s/ar­ticle/266228/C­obol_Coders_Go­ing_Going_Gone_
  57. BUNCH
    http://en.wiki­pedia.org/wiki/BUN­CH
  58. The Colossus That Works
    http://www.ti­me.com/time/ma­gazine/article/0,9171,9­49693–5,00.html
  59. Mainframe computer
    http://en.wiki­pedia.org/wiki/Ma­inframe_compu­ter
  60. United States Census Bureau
    http://en.wiki­pedia.org/wiki/U­nited_States_Cen­sus_Bureau
  61. Slideshow – More Core Memories
    http://spectrum­.ieee.org/com­puting/hardwa­re/slideshow-more-core-memories
  62. UNIVAC I Mercury Delay Line Memory
    http://ed-thelen.org/comp-hist/vs-univac-mercury-memory.html
  63. Digital Number System Part-III
    http://www.asic-world.com/digi­tal/numbering3­.html
  64. Excess-3 – Definition
    http://www.wor­diq.com/defini­tion/Excess-3
  65. Excess-3
    http://en.wiki­pedia.org/wiki/Ex­cess-3
  66. Method of complements
    http://en.wiki­pedia.org/wiki/Met­hod_of_comple­ments
  67. Univac documentation
    http://www.bit­savers.org/pdf/u­nivac/univac1/
  68. UNISERVO
    http://en.wiki­pedia.org/wiki/U­NISERVO
  69. John Mauchly
    http://en.wiki­pedia.org/wiki/Joh­n_Mauchly
  70. J. Presper Eckert
    http://en.wiki­pedia.org/wiki/J­._Presper_Eckert
  71. BINAC
    http://en.wiki­pedia.org/wiki/BI­NAC
  72. Delay line memory
    http://en.wiki­pedia.org/wiki/De­lay_line_memo­ry
  73. Paměť se zpožďovací linkou
    http://cs.wiki­pedia.org/wiki/Pa­měť_se_zpožďo­vací_linkou
  74. Description of the BINAC
    http://www.pa­losverdes.com/las­thurrah/binac-description.html
  75. UNIVersal Automatic Computer
    http://www.thoc­p.net/hardware/u­nivac.htm
  76. IBM 36-bit computers
    http://www.36bit­.org/ibm/
  77. Symbolics 36-bit computers
    http://www.36bit­.org/symbolic­s/
  78. IBM System 360/370 Compiler and Historical Documentation
    http://www.edel­web.fr/Simula/
  79. Who Was Who in IBM's Programming Research? Early FORTRAN Days
    http://www.tra­iling-edge.com/~bob­bemer/PRORES.HTM
  80. Control Data Corporation (CDC) 6600: 1966–1977
    http://www.cis­l.ucar.edu/com­puters/gallery/cdc/6600­.jsp
  81. Control Data Corporation (CDC) 7600: 1971–1983
    http://www.cis­l.ucar.edu/com­puters/gallery/cdc/7600­.jsp
  82. Cray History
    http://www.cra­y.com/About/His­tory.aspx?404;http:­//www.cray.com:80/a­bout_cray/his­tory.html
  83. Cray Historical Timeline
    http://www.cra­y.com/Assets/PDF/a­bout/CrayTime­line.pdf
  84. Company: Cray Research, Inc. (Computer History)
    http://www.com­puterhistory.or­g/brochures/com­panies.php?al­pha=a-c&company=com-42b9d5d68b216
  85. PDP-1 Web Pages
    http://www.pdp-1.org/
  86. PDP-1 Restoration Process
    http://pdp-1.computerhis­tory.org/pdp-1/
  87. Programmed Data Processor
    http://en.wiki­pedia.org/wiki/Pro­grammed_Data_Pro­cessor
  88. Digital Equipment Corporation
    http://en.wiki­pedia.org/wiki/Di­gital_Equipmen­t_Corporation
  89. PDP-1
    http://en.wiki­pedia.org/wiki/PDP-1
  90. Ancient Computing Machinery
    http://www.ee­.ryerson.ca/~el­f/ancient-comp/index.html
  91. Spacewar – The first computer video game. Really!
    http://www3.sym­patico.ca/mau­ry/games/space/spa­cewar.html
  92. Programmed Data Processor-1 Handbook
    http://www.dbit­.com/~greeng3/pdp1/pdp1­.html
Našli jste v článku chybu?
Vitalia.cz: „Připluly“ z Německa a možná obsahují jed

„Připluly“ z Německa a možná obsahují jed

120na80.cz: Bojíte se encefalitidy?

Bojíte se encefalitidy?

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

DigiZone.cz: Česká televize mění schéma ČT :D

Česká televize mění schéma ČT :D

Podnikatel.cz: Vládu obejde, kvůli EET rovnou do sněmovny

Vládu obejde, kvůli EET rovnou do sněmovny

Lupa.cz: Google měl výpadek, nejel Gmail ani YouTube

Google měl výpadek, nejel Gmail ani YouTube

DigiZone.cz: Sony KD-55XD8005 s Android 6.0

Sony KD-55XD8005 s Android 6.0

120na80.cz: Pánové, pečujte o svoje přirození a prostatu

Pánové, pečujte o svoje přirození a prostatu

Lupa.cz: Babiš: E-shopů se EET možná nebude týkat

Babiš: E-shopů se EET možná nebude týkat

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Vitalia.cz: Paštiky plné masa ho zatím neuživí

Paštiky plné masa ho zatím neuživí

Vitalia.cz: Chtějí si léčit kvasinky. Lék je jen v Německu

Chtějí si léčit kvasinky. Lék je jen v Německu

Lupa.cz: Propustili je z Avastu, už po nich sahá ESET

Propustili je z Avastu, už po nich sahá ESET

Lupa.cz: Avast po spojení s AVG propustí 700 lidí

Avast po spojení s AVG propustí 700 lidí

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

Vitalia.cz: Baletky propagují zdravotní superpostel

Baletky propagují zdravotní superpostel

Vitalia.cz: Tesco: Chudá rodina si koupí levné polské kuře

Tesco: Chudá rodina si koupí levné polské kuře

Lupa.cz: Proč firmy málo chrání data? Chovají se logicky

Proč firmy málo chrání data? Chovají se logicky

Měšec.cz: Finančním poradcům hrozí vracení provizí

Finančním poradcům hrozí vracení provizí