I mezi hackery můžeme rozlišovat mezi hackerem, opravdovým hackerem a Opravdovým hackerem. Mel byl Opravdový hacker. Ed Nather měl to štěstí s ním nějakou dobu pracovat...
Toto léto si připomeneme velmi oblíbený seriál článků, který na Živě.cz vyšel před více než sedmi lety. Týká se hacků, hackerů, crackerů a podobných záležitostí, které jsou ale stále aktuální. V historických souvislostech si připomeneme, kdo byli původní hackeři a jakými kousky se proslavili.
Vždy, když na tento známý příběh narazím, napadne mne jedna myšlenka, kterou jsem četl v některé z knížek A.C Clarka. „Já jsem byl jedním z posledních lidí, kteří měli tu úžasnou možnost číst všechno. Nikdo již nikdy nebude schopen číst všechno.“ Clarke mluvil pochopitelně o literatuře science fiction, nicméně Mel a jeho vrstevníci by totéž jistě mohli prohlásit o počítačích. Již zřejmě nikdy nikdo nebude mít tu úžasnou možnost vědět o nějakém počítači „všechno“ – znát každý šroubek, spoj, bajt v paměti. Na jednu stranu je to dobře, je to neklamná známka pokroku, na stranu druhou byste si ale mohli nostalgicky postesknout, že je to vlastně docela škoda.
A když už mluvím o autorech sci-fi, nemohu si nevzpomenout na dalšího velikána, Arthurova kamaráda Isaaca Assimova a jeho výrok, který má jistě s následujícím příběhem hodně co do činění. „Nejúžasnější věta, kterou můžete slyšet ve vědě, ta, která provází skutečné objevy, není ,Heureka!` (Mám to!), ale ,Tohle je ale legrační...` “
Příběh o Melovi
Tento příspěvek poslal do Usenetu Ed Nather 21. května 1983 jako reakci na větu „Opravdoví programátoři píší ve FORTRANu.“
Dneska možná ano, v této upadající éře lehkého piva, kapesních kalkulaček a „uživatelsky přátelského“ software, ale v oné dávné Zlaté éře, když ještě termín „software“ zněl legračně a Opravdové počítače byly vyrobeny z bubnů a vakuových trubic, tehdy psali Opravdoví programátoři ve strojovém kódu. Ne ve FORTRANu, ne v RATFORu. Dokonce ani ne v assembleru. Strojový kód. Surová, neuspořádaná, nevyzpytatelná hexadecimální čísla. Přímo.
Aby mladí programátoři nevyrostli v nevědomosti o těchto nádherných starých dnech, zkusím překonat propast mezi generacemi a co nejlépe popsat, jak Opravdový programátor psal kód. Budu ho nazývat Mel, tak se jmenoval.
Poprvé jsem Mela potkal, když jsem začal pracovat v Royal McBee Computer Corp., později zaniklé dceřiné společnosti firmy vyrábějící psací stroje. Vyráběly se tam LGP-30 – malé a levné (na tu dobu) bubnové počítače. Právě se začal vyrábět i RFC-4000, o hodně vylepšený, o hodně větší, lepší a rychlejší počítač s bubnovou pamětí. Pevné disky byly tehdy příliš drahé, a stejně se nedaly sehnat. (Proto jste o té společnosti ani počítači zřejmě nikdy neslyšeli.)
Bubnový počítač LGP-30
Byl jsem najat, abych pro nový stroj vytvořil kompilátor FORTRANu a Mel byl mým průvodcem po světě krás toho všeho. Mel však překladače neschvaloval. „Když nemůže program přepsat vlastní kód,“ ptal se, „k čemu to je vlastně dobré?“
Mel napsal (v hexa) nejpopulárnější program, který společnost vlastnila. Fungoval na LGP-30 a hrál s potenciálními zákazníky na počítačových show blackjack. Bylo to vždy napínavé. Na každé show měli LGP-30 a kolem stáli obchodníci a mluvili spolu. Jestli to opravdu bylo důvodem, proč se naše počítače prodávaly, nebo ne, o tom jsme se nikdy nebavili.
Nikdy nevíte, kam to věci uloží
Mel dostal za úkol přepsat tento program pro RPC-4000 (Portovat? Co to je?) Nový počítač měl adresovací mechanismus jedna-plus-jedna a každá instrukce byla mimo adresy operandu následována ještě jednou adresou, která udávala, kde se na otáčejícím bubnu nalézá další instrukce. Řečeno dnešním jazykem, každá instrukce byla následována jedním GO TO. Zkuste to v Pascalu a vychutnejte si to.
Bubnový počítač RPC 4000
Mel RPC-4000 miloval, protože mohl optimalizovat kód. Skládal instrukce na bubnu tak, že hned, jak byla jedna hotova, druhá zrovna přijížděla pod čtecí hlavu a byla připravena k okamžitému zpracování. Měli jsme tehdy program, který tohle dělal, – „optimalizující assembler“ – ale Mel ho odmítal používat.
„Nikdy nevíte, kam to věci uloží,“ vysvětloval, „takže byste museli používat ještě oddělené konstanty.“
Tuhle poznámku jsem pochopil až mnohem později. Protože Mel znal numerickou hodnotu kódu každé instrukce, a mohl si sám vybírat adresy, které bude přidělovat, mohl považovat jakoukoliv instrukci i za numerickou konstantu. Mohl vzít nějakou dřívější instrukci, která měla vhodnou numerickou hodnotu, třeba „add“, a násobit s ní.
Porovnával jsem Melovy ručně optimalizované programy s programy optimalizujícího assembleru a ty Melovy byly vždy rychlejší. To proto, že ještě nebyla vynalezena metoda návrhu programu „odshora dolů.“ Mel by ji stejně nepoužíval. Vždy psal nejprve nejvnitřnější smyčky programu, aby mohly být umístěny na optimálních místech na bubnu. Optimalizující assembler nebyl dost chytrý na to, aby to tak dělal také.
Mel nikdy neprogramoval čekací smyčky. Dokonce ani když potřeboval Flexowriter ke korektní funkci prodlevu mezi výstupem jednotlivých znaků, Mel čekací smyčku stejně nepoužil. Prostě jen umístil instrukce na buben tak, aby vždycky ta následující byla těsně za čtecí hlavou a buben tak musel vykonat celou další otáčku, než mohl počítač v programu pokračovat. Vymyslel pro tenhle postup nezapomenutelný název. Ačkoliv je „optimální“ absolutní termín, stejně jako třeba „unikátní,“ začal se používat jako relativní: „ne úplně optimální“, „méně optimální“, nebo „málo optimální.“ Mel tedy tyto velmi pomalé části programu nazýval „nejpesimálnější“.
Záhada smyčky
Když program na hraní blackjacku dokončil a podařilo se mu jej spustit („Dokonce i spouštěč je optimalizovaný“, prohlašoval pyšně), požádalo ho obchodní oddělení o změnu. Program používal elegantní (optimalizovaný) generátor náhodných čísel k posouvání karet a tahání z balíku. Někdo z obchodního oddělení si ale myslel, že to je příliš férové, protože zákazník občas prohrál. Chtěli po Melovi, aby modifikoval program tak, aby bylo možné stisknutím tlačítka na konzole „náhodu“ pozměnit a nechat zákazníka vyhrát.
Mel se vzepřel. Cítil, že to bylo přímo ukázkově nečestné, taky že bylo, a že to neprávem zasahuje do jeho programátorské práce. Odmítl to tedy udělat. Mluvil s ním vrchní marketingový manažer, nakonec i sám Velký šéf; tomu se jen tak někdo nevzepře. Mel se do práce nakonec pustil a kód napsal. Podmínku však omylem otočil, takže když byl přepínač sepnut, program podváděl a vždy vyhrál. Mela to velmi potěšilo, napadlo ho, že je jeho podvědomá mysl přísně etická, a odmítl chybu opravit.
Poté, co Mel odešel z firmy na jiné, lépe placené místo, požádal mě Velký šéf, abych se do kódu podíval, zkusil najít místo, kde je ta podmínka, a obrátil ji. Neochotně jsem přeci jenom souhlasil, že se podívám. Probírat se kódem Mela bylo opravdové dobrodružství.
Často jsem cítil, že je programování uměním, kterého pravou hodnotu dokáže ocenit jen někdo, kdo je také v takovém umění zběhlý. V takovém kódu jsou překrásné drahokamy a nádherné obraty, které jsou samotnou podstatou procesu programování často úplně skryty před lidským obdivem.
O člověku se můžete hodně dozvědět i jen tím, že budete číst jeho kód – dokonce i v hexadecimálních číslech. Mel byl opravdový génius.
Můj největší šok přišel, když jsem našel neškodnou smyčku, která v sobě neměla žádný test. Žádnou podmínku. žádnou. Selský rozum mi napovídal, že to musí být uzavřená smyčka, ve které by se program zacyklil. Navždy, donekonečna. Přesto k ní program dorazil, prošel jí, a bezpečně pokračoval na druhé straně dál. Trvalo mi dva týdny, než jsem záhadu rozluštil.
Na posvátné se nesahá
RPC-4000 měl takovou vymoženost nazývanou indexový registr. To programátorovi dovolovalo používat indexové instrukce – při každém průchodu smyčkou se k indexovému registru přičetla jednička a to číslo pak bylo přidáno k adrese takové instrukce, takže popořadě četla vždy nová data. Stačilo vždy indexový registr zvýšit. Mel jej však nikdy nepoužil.
Místo toho načetl instrukci do strojového registru, přidal k její adrese jedničku, a zapsal ji zpět. Modifikovanou instrukci poté zavolal přímo z registru. Smyčka byla napsána tak, že počítala s tímto dodatečným strojovým časem, který to zabralo. Hned jak instrukce skončila, již přijížděla k hlavě bubnu další, připravená k vykonání. Ve smyčce ale nebyla jediná podmínka.
Začal jsem si to uvědomovat, až když jsem si všiml bitu indexového registru. Bitu, který ležel v instrukčním slově mezi adresou a kódem operace. Byla v něm jednička. Mel nikdy indexový registr nepoužil, vždy jej ponechával na nule. Když mi to došlo, skoro mě porazilo.
Mel uložil data, na kterých pracoval, blízko vrcholu paměti – nejvyšší adresy, kterou mohla instrukce zpracovat – takže poté, co byla všechna zpracována, došlo inkrementací adresy k jejímu přetečení. To přidalo jedničku k operačnímu kódu, a změnilo jej na následující instrukci v pořadí: instrukci skoku. Další instrukce programu byla přirozeně na adrese nula, a program vesele pokračoval dál.
„Hned jak jsme začali programovat, k našemu překvapení jsme zjistili, že uvést programy do správné podoby nebude tak jednoduché, jak jsme čekali. Debugování muselo být nejprve vynalezeno. Přesně si pamatuji ten okamžik, kdy jsem si uvědomil, že strávím velkou část života hledáním chyb ve vlastních programech,“ píše o programování Maurice Wilkes, designer EDSACu, v roce 1949. |
Již jsem se s Melem nesetkal, takže nevím, jestli se někdy vzdal té záplavě změn, která se přehnala přes techniky programování od těch dávno odvátých dob. Rád bych se mýlil. V každém případě to na mě udělalo tak velký dojem, že jsem již přestal hledat ten obrácený test a řekl jsem Velkému šéfovi, že to nemohu najít. Nevypadalo to, že bych ho nějak překvapil.
Když jsem společnost opouštěl, program stále ještě podváděl, kdykoliv jste stiskli ten pravý přepínač. A myslím, že to tak i mělo být. Necítil jsem se pohodlně při hackování kódu Opravdového programátora.
Pozn: Jargon File udává, že Melovo příjmení bylo zjištěno v roce 1999. V manuálu k LGP-30 se našel odkaz na Mela Kaye z Royal McBee.