DŮLEŽITÉ UPOZORNĚNÍ!
Policie České republiky a šéfcensor Ústavu pro studium totalitních režimů Jaroslav Čvančara varují: citovat jakékoli texty z tohoto blogu způsobuje vážné nebezpečí trestního stíhání! Četba na vlastní nebezpečí!

14. 9. 2015

Thinking outside the box

Předpokládám, že úlohu, jež dala původ nadepsanému rčení, znáte: úkolem je spojit devět bodů uspořádaných do matice 3 x 3 souvislou čarou složenou z nejvýše čtyř úseček. Je řešitelná pouze tak, že úsečky leží mimo pravoúhelník vymezený danými body, ale najít řešení je pro většinu lidí obtížné, neboť intuitivně předpokládají, že úsečky musejí ležet pouze uvnitř pravoúhelníku – ačkoli zadání o tom ničeho nepravilo.

Stereotypy a automatismy v myšlení jsou zrádné, o čemž jsem se přesvědčil naposledy během uplynulého week-endu. Pojal jsem totiž úmysl, že pro svůj (na třetím blogu traktovaný) emulátor doplním emulaci mikroprocesoru Zilog Z80. To je, myslím, jediná elektronická součástka, kterou jsem v životě opravdu miloval, a i když jsem měl původně v úmyslu omezit se na tři emulované historické stroje – PMI-80, PMD 85 a IQ 151 – mít Z80 by mi umožnilo pojmout do emulátoru i počítač Ondra, který byl hardwarově velmi zdařilým dílem a jeho většímu rozšíření zabránila pouze pro praktické používání nevhodná, příliš ořezaná klávesnice.

Domníval jsem se, že maje naemulovaný Intel8080A, nezabere mi doplnit instrukce Z80 než jeden, nejvýš dva dny. Jenže celý jeden den a spoustu nervů mi zabralo hledání chyby, kterou jsem nemusel udělat, kdybych nebyl myslel – v krabici.

Posuďte sami. Pro emulátory používám instruction exerciser (více o něm zde), který jsem si rovněž přepsal do Javy, abych mohl rychleji najít chyby implementace jednotlivých instrukcí. Pro 8080 žádný problém, ale u Z80 jsem narazil na chybu, kterou jsem nemohl a nemohl najít. Až poté, co jsem si zprovoznil emulátor CP/M, v něm druhdy slavný debugger DDT, a propadaje střídavě amoku a stavům chorobné skleslosti, jsem na to, co je problémem, nakonec přišel. A protože je to problém věru bizarní, dělím se o něj se svými milými čtenáři i zde.

Když si prohlédneme zdrojový soubor Franka D. Cringla z r. 1994, vidíme, že jádrem exerciseru jsou test cases, jejichž dlouhá řada jest popsána v makrech na ř. 194–728. Povšimněme si parametrů těchto maker: vyjma triviálních hodnot 0 a –1 jsou všechny konstanty (literály) zapsány hexadecimálně.

Až na dvě výjimky, na ř. 277 a 285, kde se stkví neobvyklý zápis 010. Když jsem ho přepisoval do Javy, automaticky jsem napsal 0x08, domnívaje se, že Frank Cringle udělal chybu a mínil zapsat 0x10 a protože si neuvědomil, že assembler takto zapsanou konstantu vyhodnotí oktalově, vyšlo mu něco, co nechtěl, ale co je s ohledem na neměnnou hodnotu CRC nutno respektovat. Pro tuto hypothesu hovořilo i to, že je v závorce za voláním makra uvedeno (1024 cycles), což odpovídá počtu jedniček v řádku – tedy deseti.

Dlouhé hodiny jsem se pak vrtal ve svém kodu a pátral, co mám špatně, protože CRC ne a ne vyjít, jak mělo. Řešení bylo arci zcela triviální, ale tak outside the box, že mě stálo dobrých deset hodin času: Protože Cringle programoval v r. 1994 a assembloval v CP/M, předvěšená nula pro assembler neznamenala, že má konstantu interpretovat jako oktalovou: tehdejší softwarové nástroje to ještě nedělaly. Assembler proto vyhodnotil jeho zápis 010 jako 10 (dekadických); vedlejším důsledkem bylo, že ve skutečnosti se neprovádí 1024, nýbrž 2048 cyklů.

Jak se to celé stalo, bych mohli zjistit asi jen od Cringla, kdybychom mu napsali a pokud si to ještě pamatuje. Moje (upgradovaná) hypothesa zní, že původně měl 0x10, ale protože si uvědomil (nebo laděním zjistil), že by instrukce CPI/CPIR vyšla (o jeden byte) mimo rozsah testovacího pole, opravil hodnotu na deset, ale zapomněl smazat nulu a nenaznal, že se mu tím změnil i počet cyklů.

Já vím, chybami se člověk učí, jen by jich, pokud bych směl prosit, mohlo být o něco méně.

55 komentářů :

  1. Každý koutek programátorského světa má své zvyklosti. Assembleristi přemýšlejí jinak, než céčkaři a ti zase jinak než ...

    Assembler člověka naučí přidávat nadbytečné nuly před čísla, protože číslo nesmí začínat písmenem. Což je dobré pravidlo, kdyby do písmen nepatřily i hexadecimální číslice ABCDEF. Takže časem člověk rezignuje a píše nulu, pak číslo co chtěl napsat a na konec H jako hexadecimální číslo.

    C-like syntaxe je zase plná artefaktů jako je nula na začátku čísla je oktalová hodnota. Nebo záporné kódy znaků v horní polovině ASCII. C je vysloveně šit na míru prvním unixům.

    Miloslav Ponkrác



    OdpovědětVymazat
    Odpovědi
    1. Dnes nicméně vývoj dokonvergoval k oktalové interpretaci nuly všude, jen z toho, co aktivně používám, v C, v Javě, v Pythonu i v assembleru (používám GNU AS). Což je docela komické, protože s oktalovou notací se desítky let téměř nepracuje, takže čím méně je rozšířená, tím více je podporovaná.

      Vymazat
    2. Právě že nedokonvergoval. Vše co vyjmenováváte to převzalo z C i s chlupama.

      C oktalovou soustavu implementovalo, protože unixová práva na soubory a adresáře se zapisují v oktalové soustavě, tedy k tomuto se dodnes používá. A tak můžete třeba při vytváření souboru do práva napsat v oktalové soustavě jaká práva chcete pro vlastníka, jaká pro ... Kromě toho mám pocit, ale nevím přesně, že původní PDP-7 byla 18bitový počítač, takže oktalová soustava tam byla docela užitečná.

      Mně připadá spíše směšné, že v jazyku C byla oktalová soustava, ale nebyla binární.

      Pokud se vzdálíte ze světa inspirovaného Céčkem, které samo o sobě je neuvěřitelně zflikovaným jazykem, pak nuly na počátku jako oktalová soustava se nepoužívají. Považuji nuly jako indikátor oktalové soustavy za zvěrstvo.

      Jako asm používám nasm (http://nasm.us), který je možné použít s každým myslitelným kompilátorem co znám, a tam nuly na počátku čísel jsou bezvýznamné. Stejně tak MASM, tedy asm od Microsoftu žádnou nulu na počátku nepřiřazuje jako oktalový indikátor. Jinak řečeno, ve všech assemblerech nula neznamená oktalovou soustavu s výjimkou Céčkoidního gasu.

      GAS je céčkoidní asm vytvořený týmem gcc, a obsahuje částečně i Céčkové konstrukce. Java vysloveně převzala C syntaxi, a Python v některých výrazech také. Ostatně Python byl před lety představován jako glue language pro C.

      Nula jako oktalová soustava je unixoidní nápad - a šíří se spíše stylem "co unix/linux dělá je nejlepší a pokud to neplatí platí pravidlo číslo jedna". Ačkoli mám unix rád, ale tato neschopnost unixu vylepšovat nedobře navrhnuté věci způsobuje (kromě toho, že dnes už většina unixů včetně linuxu neodpovídá unixové filozofii velmi malé jádro a zbytek user mode) že už se na unix neorientuji jako jedinou věc jako jsem dělal v minulosti.

      Stejně tak SQL jazyk a databáze - ani v MySQL, ani v Oracle není 0 jako octal. Kdyby tomu tak bylo, vznikala by taková kvanta chyb, až by to hezké nebylo.

      Novější jazyky zaplaťpámbu od nuly jako indikátoru oktalu ustupují. Například Lua ho nepoužívá, jazyk Swift od Apple také ne.

      Miloslav Ponkrác

      Vymazat
    3. To máte pravdu, je to tedy do značné míry náhoda, že jsem na nulu tak zvyklý. GNU AS používám, protože umí nativně téměř všechno (kromě původní 8080, kde jsem použil ASL, např. v hadovi pro PMI-80) a na rozdíl od starých assemblerů vytváří relokovatelný výstup, takže např. i moje programy pro Atmely AVR jsou modulární. Jinak bych se patrně zbláznil, pro AVR jsem psal třeba i DES a AES a bez modularity si neumím ten kod představit.

      Vymazat
    4. Původní cesta překladu Céčka byla dost dlouhá. Zdroják v C nejdříve přechroustal preprocesor a vytvořil soubor .i, pak přišel kompilátor, který to přeložil do assembleru a vytvořil soubor .s. Pak přišel kompilátor asm, který vytvořil objektovou binárku. A nakonec se pustil linker a slinkovalo s knihovnami a vznikl spustitelný program.

      GAS je pozůstatek z tohoto procesu a sloužil právě pro překlad C. Nebyl určený pro lidi ani pro to, aby v něm někdo programoval. Proto třeba jeho makrovací schopnosti jsou velmi ubohé, prakticky žádné. Plus třeba pro x86 procesor si dokonce vytvořili nesmyslnou vlastní sysntaxi instrukcí. Na druhé straně je GAS dělaný pořádně, staré assemblery skutečně byly pro bastlení, ne pro programování.

      Sám jsem v GAS psal pro ARM. Spolu se skriptem pro linker se z toho daly udělat neuvěřitelné věci a vytvořit v podstatě jakoukoli strukturu výsledného binárního výsledku. Pokud člověk opravdu chce dělat nezvyklé věci, tak věci kolem GCC jsou docela dobré.

      Jen mám dost trauma z GPL a GNU programů, které tkví v neuvěřitelné složitosti a špatné dokumentaci open source programů kolem těchto licencí a hnutí. Když je chci využít, obvykle musím luštit jejich zdrojové kódy, abych pochopil, co vlastně v určitých případech dělají, jako třeba u toho linkového skriptu. A když pak čtu zdrojáky těch gnu a gcc, tak mám smíšené pocity. Například linkový skript intepretuje příkazy tak, že je zpracovává pomocí strlen/strcmp, takže co bych v jazyce podporující slušně řetězce napsal na jediný řádek, je v C zdrojáku na jednu až dvě obrazovky. A ve výsledku to limituje možnosti samotného skriptování linkeru, protože víc už programátor neměl sílu naprogramovat.

      Jinak klobouk dolů za DES a AES v assembleru.

      Miloslav Ponkrác

      Vymazat
    5. Preprocesor je dobrý nápad, např. v Javě mi velice chybí. Výsledkem je, že některé části javového zdrojáku emulující Z80 si generuji pythonem. Otřesné, jak jistě uznáte. Experimentováním jsem zjistil, že java generuje nejefektivnější kod, pokud je zdroják právě takto zdánlivě nelogicky strukturován.

      Hnutí GNU je založeno na principu, že nejlepší (a obvykle jediná) dokumentace je zdroják, to si časem zvyknete ;-)

      Vymazat
    6. Naopak, jste velice moderní javista. V zásadě každé Java IDE generuje části javovských zdrojáků, jinak by se programátor upsal k smrti.

      Preprocesor v Javě používat můžete, dělal jsem to tak občas. Nic vám nebrání přechroustat javovský zdroják C preprocesorem a výsledek předhodit javovskému kompilátoru.

      GNU hnutí nemohu upřít, že se mu podařilo srazit ceny sw na rozumnou mez a mnohé zdarma. Na druhé straně mám s GNU a GPL programy poněkud spíše traumatické zkušenosti. Je mi poměrně divné, proč třeba s programy pod BSD, MIT a jinými licencemi mám podstatně příznivější zkušenosti. Asi náhoda.

      Miloslav Ponkrác

      Vymazat
    7. Kdykoli potřebujete maximální efektivitu kodu, bez maker se neobejdete. Externí preprocesor, CPP nebo třeba M4, je slabá náhražka, protože není do Javy integrován a např. nevíte, na kterém řádku došlo k chybě: to musíte pracně zjišťovat z meziproduktu. Mimochodem, ty kryptografické algorithmy pro AVR jsou prakticky jen voláním maker, jinak by nemohly emulovat software v bezkontaktní kartě s potřebnou rychlostí. V Javě bych nikdy nic obdobně rychlého nemohl napsat, není to jazyk pro efektivní výpočty.

      Vymazat
    8. Makra jsou v assembleru základ. Bez toho se v assembleru programovat dobře ani efektivně nedá.

      Moje zkušenost je, že kromě assembleru a LISPu programovací jazyky nezvládají nějakou slušnou integraci maker. Není proto vcelku divu, že jazyky spíše preprocesor a makra vyhazují pryč. Je obtížné to vymyslet tak, aby to nebyla prasečina. Pokud by někdo vymyslel slušnou integraci maker do vyšších jazyků, nejspíše by se to rozšířilo. Hlavním problémem je, že z maker kompilátor nic nevyčte.

      Moje nepodložená představa je, že makra ve vyšších jazycích pro efektivitu nejsou nutně třeba. Že je zastoupí klícové slovo inline, metaprogramování a optimalizátor kompilátoru plus dobře navržená syntaxe jazyka dávající dostatek informací optimalizátoru. Nicméně nikdy jsem neprogramoval AES a DES, takže asi bych změnil názor.

      Metaprogramování je to co se v C++ nazývá šablony (template). Myslím, že je to hlavně pokus o rozumnější makrování. U dynamicky typovaných jazyků je to ještě jednodušší.

      Java není na rychlost a nikdy nebyla.

      Miloslav Ponkrác

      Vymazat
    9. To je koncepce chytrý kompilátor a hloupý programátor. V tu jsem nikdy nevěřil. V případě DESu (část zde) makra podle tabulek sestavují sekvence instrukcí (DES byl navržen pro hardwarovou implementaci a proto je tak složitý). V Javě neexistuje prostředek, jak vygenerovat volání method s proměnnými parametry podle konstantního pole, ale muselo by se v každém kroku sáhnout do pole, nabrat z něj parametry a provést úkon, tedy 90 % času by se ztratilo zbytečnou činností. V céčku, pomocí preprocesoru, by to šlo. V tom je ten zásadní rozdíl.

      Vymazat
    10. Koncepci hloupého programátora vytvářejí firmy a je zde velká ekonomická poptávka po hloupých programátorech, neboť se jim platí nižší mzdy. Typickým produktem vývoje, kdy mají programovat hloupí programátoři je Java, C# a vůbec celé objektové programování. V koncept hloupého programátora jsem nikdy nevěřil, tato idea je idea manažerská a programovací jazyky této idey jsou také stvořeny pro potřeby manažerů, nikoli programátorů. Java je typickým příkladem takového jazyka.

      Java je záměrně osekána v možnostech na často obtížně použitelné minimum, aby hloupí programátoři měli jedinou cestu, jak něco udělat. Třeba se upsat k smrti, což je cesta, kterou vás v případě implementace DESu nabízí Java - rozepsat pěkně makra na velmi dlouhou sekvenci základních příkazů.

      Mám na mysli dnešní většinové programovací jazyky, kde ani chytrý programátor nic moc nepořídí, protože programovací jazyk je hloupý a nedomyšlený. Makrování je obecný koncept, který je ale nepřehledný, proto se nahrazuje jinými koncepty. Stejně jako goto jako obecný koncept se nahrazuje podmínenými příkazy a příkazy cyklů, případně výjimkami.

      Já osobně makrování ve vyšších programovacích jazycích vidět nechci. Chci v nich ale vidět koncept, který umožňuje efektivné kód pomocí vlastní optimalizace a pomocí metaprogramování. A to bohatě jako náhrada maker stačí a IMHO to udělá stejnou práci. IMHO. Makrování nerespektuje nic, je to prostá textová operace. Ani prostory jmen identifikátorů, ani obory viditelnosti identifikátorů ani nic jiného.

      Problém je, že pokud se bavíme o C nebo Javě - bavíme se o hloupých jazycích plných kompromisů, které nejsou dobře navrženy. Pak je třeba dělat kompromisy. V C makrování neruší, C je v podstatě druh assembleru. C nemá ani skutečná pole, nemá prostory jmen, je tam silná tendenci všechny identifikátory být globálními.

      Miloslav Ponkrác

      Vymazat
    11. Céčku křivdíte, jsem naopak názoru, že cokoli bylo vytvořeno po něm, bylo pouze rozmělňováním geniálních myšlenek Kernighana a Ritchieho, a zejména OOP je antithesí dobrého programování. Jejich kniha ostatně patří spolu s Biblí, Lordem Jimem a Krystlíkovými Zamlčenými dějinami mezi tři nejdůležitější texty, které jsem v životě četl :-)

      Vymazat
    12. Můj pohled na C je podstatně kritičtější. On to v zásadě není jazyk, je to lépe zapsaný assembler. Kdybych měl tu moc zasáhnout do Céčka, udělal bych alespoň to, že by existovaly nějaké integery pevně dané délky a zrušil bych operátor ->. Nicméně beru to tak, že pro střední a větší projekty se C nehodí v žádném případě, i když se v něm dělají.

      OOP zcela bezpečně vznikl před jazykem C. Na počátku to nebyl zcela špatný koncept, dokud někdo z OOP neudělal zlaté tele k uctívání. A pak bylo OOP zpraseno a pokřiveno několika věcmi, aby to asi lépe připomínalo náboženství. Zejména byla na dědičnost navešeno moc funkci: 1) znovupoužitelnost kódu, 2) typová kompatibilita a přetypovávání, 3) definice interface. To nemohlo dopadnout dobře, protože docpat do dědičnosti 3 odlišné funkce nejde zvládnout jinak, než že OOP vykastrujete k nepoužití. A to se také stalo s dnešním OOP, ale tak to vždy nebylo.

      Původní OOP znamenalo objekty, které si předávají zprávy. Nic jiného. Takový byl třeba Smalltalk. Později se to nějak ohnulo v to, že OOP se stalo syntaktickým cukrem volání funkce, kde prvním parametrem byl odkaz na data objektu. A pak do toho někdo hloupě nacpal třífunkční dědičnost a od té doby je to hnus.

      Ohledně knih nechci dávat seznamy. Mám dojem, že knihy, které jsem četl kromě názvu musely také přijít v pravou chvíli, kdy jsem ve svém životě zrovna daný přelom potřeboval. Za nejdůležitější svou první knihu o programování považuji Niklaus Wirth "Algoritmy a datové struktury".

      Miloslav Ponkrác

      Vymazat
    13. On to v zásadě není jazyk, je to lépe zapsaný assembler.

      Ale přesně to od programovacího jazyka chci! Abych se mohl vyjadřovat ve výrazech a přitom přesně nebo skoro přesně věděl, jak je kompilátor přeloží. U Javy to nevím, a nejsem si jist, zda se to kdy dozvím (tj. zda je problémem moje imanentní hloupost nebo jen javová nevzdělanost).

      Wirtha jsem četl krátce před K&R, kteří mi, dá se říct, všechno převrátili na hlavu. Důležitá kniha byl samozřejmě Knuth's The Art of Computer Programming, ale to je asi u všech programátorů stejné.

      Vymazat
    14. Pak ale nechcete programovací jazyk, pak chcete assembler. Já nepotřebuji vědět, jak kompilátor něco přeloží, pokud to udělá dobře a efektivně a výborně optimalizuje. Problémem je, že Java je v podstatě také assembler, ale pro JVM. Původně to měl být jazyk pro pračky a elektroniku. C a Java vznikly jako low level assemblery, jen každý na to šel jinak. Ani jeden z této dvojice nepovažuji za programovací jazyk, jen za druh asm.

      Vymazat
    15. Pak ale nechcete programovací jazyk, pak chcete assembler.

      Nikoli, u assembleru vím, jak bude zdroják přeložen, vždy a z definice. U vyššího programovacího jazyka to jen zhruba tuším, ale mohu ty kdykoli snadno ověřit, a také ovlivnit např. klíčovým slovem register. U Javy to ani nevím, ani to nemohu snadno zjistit (jen na úrovni byte codu), a prakticky nijak to nemohu ovlivnit. Je-li vaším přáním mít nad počítačem méně kontroly, budiž; já mám požadavky opačné.

      Vymazat
    16. Opravdu nepotřebuji přesně vědět, jak bude zdroják přeložen. Stačí mi vědět, že výsledek bude odpovídat tomu, co je ve zdrojovém kódu a výsledný kód bude natolik efektivní, že bude velký problém pro člověka napsat lepší a efektivnější kód v asm/strojáku. To neznamená ani o píď menší kontrolu nad počítačem.

      Java, stejně jako Python není kompilátor, ale intepretr. Obojí se překládá do byte kódu a následně intepretuje nějakým virtuálním strojem. To, že JVM často používá JIT je už jiná věc.

      Vymazat
    17. To je ale čirá theorie. Člověk napíše lepší kód než kompilátor s nevelkým úsilím prakticky vždy, jen to v běžných situacích nedělá, protože se mu to nevyplatí, stejně jako se mu nevyplatí, řekněme, škrabat brambory ručně, když to za něj udělá robot: s většími "ztrátami materiálu", ale rychle a bezpracně.

      Java sice generuje slušně rychlý kod, ale zároveň mi bere možnost dosáhnout jakékoli optimalisace, i tam, kde ji potřebuji, takže příkladmo DES bych napsal v C a do Javy ho integroval jako hotovou funkci. To není čisté řešení a nelíbí se mi, Java mi bohužel jinou možnost nedává.

      Vymazat
    18. Člověk lepší kód hned tak nenapíše. Dnešní optimalizátory kompilátorů jsou ďábelsky dobré. A pokud napíše, pak už musí něco znát a rozhodně to nebude malé úsilí.

      Dobré programovací jazyky jsou v optimalizaci dostatečně dobré, že se nevyplací trávit čas ani v asm, ani kontrlou každé instrukce. Proto dodnes matematici a fyzici rádi Fortran, a C se mu rychlostí ne a ne rovnat třeba. Proto NASA píše v Adě, a to i na kdejaký mikrokontroler, protože kromě bezpečnosti je to i velice efektivní kód ve výsledku.

      Vymazat
    19. Dokud nebude umělá inteligence, napíše programátor od určité prahové úrovně netriviality vždy lepší kod než kompilátor. Programátor si může rozvrhnout, které registry k čemu použije, jaké operace s nimi bude provádět (kompilátory využívají jen malou část instrukční sady procesoru), a může kód zjednodušovat nejrůznějšími dalšími způsoby. To je soutěž pro stroj předem prohraná.

      Vymazat
    20. Abychom nehovořili theoreticky: vezměte ten program na DES, a pro začátek jediné místo z něj, makro mperm. To podle daného "rozpisu" bere bity z jedné skupiny registrů a ukládá je do druhé. Kompilátoru C ale takovou věc vůbec nemohu v bitové notaci napsat, protože bitové operace nemá. Takže bych musel ten výsledný byte, nebo skupinu bytů, vytvořit jako serii logických operací a shiftů, a žádný kompilátor na světě by nepřišel na to, že místo shiftování prostě může vzít bit po bitu a přestrkat je z jednoho místa na druhé.

      Zde se ukázaly dva problémy zároveň: 1. nedostatečná semantika vyššího programovacího jazyka; a 2. nedostatečné používání instrukční sady kompilátorem.

      Vymazat
    21. Já ale doufám zcela konzistentně od začátku tvrdím, že C není dobře koncipovaný jazyk. Na dobrý assembler mu řada operací chybí, na vyšší jazyk je příliš low level. Jazyk C nedělá efektivní kód, jeho typical use case je přenositelný assembler pro operační systémy unixového typu.

      Dokonce je Céčko tak špatný jazyk, že zpočátku jeho efektivita byla prachbídná. Museli mu pomoci sami výrobci procesorů a přidat strojové instrukce pro jeho podporu. To, že dnes má C slušnou efektivitu je tím, že procesory přidaly strojové instrukce - zejména různé inkrementace pointerů a indexové operace, které dříve byly vzácné a ani nebyly moc třeba. Cokoli, co vzešlo od unixu se těšilo podpoře IT průmyslu včetně výrobců čipů.

      A obecně, je to naopak. Programátor je schopen jen výjimečně napsat něco lépe než kompilátor, pokud se nejedná o miniaturní projekt. Možná napíšete lépe jednu dvě vysoce optimalizované rutiny, jednu z deseti tisíc, zbytek prohrajete. Jen velmi výjimečně najdete praktický algoritmus, který je lépe napsat v asm.

      Vymazat
    22. Na dobrý assembler mu řada operací chybí, na vyšší jazyk je příliš low level.

      C není přece žádný assembler, je na procesoru nezávislé. Je to low-level programovací jazyk, navržený tak, aby se v něm psaly snadno přenositelné a paměťově i časově velmi efektivní programy.

      Naposledy jsem psal v C větší program asi před dvěma lety, šlo o solver pro hru Freecell, takže prohledávání stavových prostorů, párování, heapsorty apod. V Javě by to bylo o dost pomalejší.

      Dále byste měl rozlišovat, pro který procesor se píše. Pro x86_64 s obrovskými registry a poměrně bohatou instrukční sadou je použití assembleru spíš raritou, naopak třeba pro Atmely AVR, které mají uzoučké registry a chudé možnosti adresace, není vyšší programovací jazyk přínosem. Mimochodem, dodnes jsem pro osmibity napsal jeden jediný program v C, a to jen na zkoušku, abych ověřil, že jsem si správně upravil Small-C (je součástí emulátoru). Tak jednoduché procesory raději programuji v assembleru, je to zábavnější a daleko lépe se využijí jejich možnosti.

      Vymazat
    23. C že je na procesoru nezávislé? Je už v C je typ int nezávislý na tom, kolika bitový procesor je target? Máte už v C nějak nezávisle zaručeno, jaké tam budou int typy a jakou budou mít délku? Je nějak nezávisle zaručeno, jaká bude délka typů float, double a long double? Mají knihovní funkce v C typy předem daných délek, nebo jsou tam stále procesorově závislé typy int, long a podobně? Je docela frustrující, když zavoláte fseek() nebo seek() a on je offset typu long a vlastně netušíte, jestli přes to proženete více, jak 4 GB soubor. Proč na jednom procesoru je konstanta 0xffffffff kladné číslo a na jiném záporné?

      Vymazat
    24. Já s vámi souhlasím v principu ohledně optimalizace. Pro vyší programovací jazyk není snadné vytvořit optimální program, který je malý a rychlý, pokud je procesorová architektura málo výkonná či má omezenou sadu instrukcí či registrů. V každém případě je tam zbytečný overhead, minimálně v délce, a často i v rychlosti.

      Jazyk C lze udělat optimální jen s určitou sadou instrukcí. Jak jsem psal, musely se procesory přizpůsobit C, nikoli naopak.

      Nicméně dobře navržené programovací jazyky jsou schopny dosti efektivního kódu a není ho vždy snadné přebít ručně. Ostatně považuji programování optimalizátoru u kompilátorů za větší machrovinu, než mnoho jiného. Nikdy mě nelákalo programovat třeba linux kernel, protože je to v zásadě nuda. Ale přál jsem si někdy nachomýtnout se k optimalizaci kompilátorů, to považuji za výzvu a machrovinu.

      Vymazat
    25. Každý standard C definuje pro šířku celočíselných typů hranice, a je celkem logické, že je respektována architektura procesorů. Příkladmo v tom Small-C je int šestnáctibitový (což, mimochodem, je méně, než požaduje norma), což odpovídá architektuře, pro kterou je generován kod. To z céčka žádný assembler nedělá.

      Procesory se přizpůsobují potřebám dominantního použití, co je na tom divného? Kdyby se většina softwaru psala v Adě, byly by přizpůsobeny Adě.

      Souhlasím, že optimisery jsou složité a zajímavé algorithmy, je to, jak jsem psal, fakticky AI.

      Vymazat
    26. Norma pro C vyžaduje, aby int byl min. 16 bitů, tedy je to v normě. Jen jsem chtěl napsat, že C je závislé na procesoru až hrůza, a programátor od toho příliš odstíněn není. Já jsem v C/C++ programoval velmi mnoho, a řešil jsem to alespoň napsáním vlastních knihoven, které měly pevně dané délky. Například sint<4>, nebo unit<8>, float<8>, apod.

      Ad 2) Většina jazyků toto přizpůsobení pro efektivitu nepožaduje, zrovna tak Ada. C ale ano, jinak je neefektivní. C je postaveno jako "emulate all by pointers" a bez strojových instrukcí pro bohaté indexování při dané bázové adrese je hodně neefektivní. Neuvádím to jako nevýhodu C, ale jako fakt, že ne každý procesor umožňuje efektivně hodit C.

      Ad 3) Není to AI. Je to o tom, že programovací jazyk musí mít strukturu a syntaxi, která umožňuje kompilátoru získat maximální informace pro optimalizaci (C je z tohoto důvodu dost špatné). A následně deterministickými postupy překopat syntaktické stromy a tedy výsledný kód do podoby co nejlepšího kódu. Ty postupy jsou vcelku známé. Problém je, že napsat neoptimalizovaný kompilátor je 10000 x menší práce, než optimalizovaný, proto se optimalizace píši jen pro platformy, které jsou frekventovanější.

      Vymazat
    27. Norma pro C vyžaduje, aby int byl min. 16 bitů, tedy je to v normě.

      Tak to jste mě dostal, roky žiji přesvědčen, že 32 :-) Naštěstí se jen málokdy pracuje se "syrovými" typy, téměř vždy se v headrech definuje přesná šířka, např. UINT32.

      Vymazat
    28. https://www.youtube.com/watch?v=wqxqu4r74MM

      Vymazat
  2. Co se týká Ondry, měl jsem tu čest ho ve své době vidět přímo u výrobce. Principem mi připadal jako ZX80, kdy procesor většinu času zobrazoval, a jen minimálně se věnoval programům. Už v té době bylo jasné, že toto se neujme.

    Zapojení je zcela jistě geniální, a se snahou udělat počítač co nejlevnější. Nicméně věcí, co tam dřelo bylo jistě více, než klávesnice. Procesor s taktem 2 MHz, který pracoval pro program jen 25 % výkonu a zbytek šlo na DMA. Génius autora byl brzděn omezenou nabídkou součástek a možností té doby a režimu.

    Nutno ale říci, že chovám podobnou úctu k autorovi i dílu samotnému, protože ono zapojení a řešení je v zásadě umělecké dílo. A také trochu opak dnešní doby, kde se věci, i počítače, i elektronika, skládají z modulů, kde je využito s bídou 1 % možností součástek.

    Miloslav Ponkrác

    OdpovědětVymazat
    Odpovědi
    1. Smutný umožnil (aspoň jak to tvrdil v novinovém rozhovoru, ještě nejsem tak daleko, abych to mohl ověřit v emulátoru) tuto kvotu snížit, takže se zobrazovala pouze část videa, ale využitelný výkon procesoru přiměřeně narostl. Asi je ale fakt, že ve videohře by to mohlo poněkud snižovat hráčský zážitek :-)

      Vymazat
    2. Sir Clive Sinclair také upustil od konceptu procesoru většinově zabývajícího se zobrazováním v ZX80 a ZX81, když tvořil Spectrum. Koncept ZX80 byl startovací, ale nijak neohromující lid a zákazníky. Tudíž bylo vcelku jasné, že opakovat jej nějakých 5 let po ZX81 nepovede k rozšíření. Tento koncept se prodával proto, že cena byla neuvěřitelně levná, pod 100 dolarů. Navíc Ondra udělal tu chybu, že neměl ani Basic uvnitř, takže jakmile jsme ho poprvé viděl, bylo mi jasné, že o něj nikdo moc stát nebude.

      Eduard Smutný si podle svých rozhovorů představoval, že uvedou na trh sérii několika počítačů, z toho Ondra bude ten nejslabší a nejlevnější.

      Mně přijde, že Ondra je sice geniální po hw stránce, ale že po stránce upotřebitelnosti uživatelem nešťastný. Už tehdy z něj čišelo "no co, uživatel se prostě omezí". Klávesnice, nevestavěný basic, výkon kvůli sdílení se zobrazováním velmi mizerný, přestřelená cena, žádné barvy (20 000 Kč v roce 1987! V té době stálo výrazně lepší ZX Spectrum kolem 6 000 Kč). Zkrátka Smutný a Ondra udělali všechno proto, aby počítač skončil debaklem.

      Miloslav Ponkrác

      Vymazat
    3. Nemyslím, že by do těchto věcí Smutného nechali moc mluvit, a také hrálo roli, že Ondra byl za české koruny, kdežto Spectrum za valuty. V té době ovšem začala rozhodovat kompatibilita, takže Didaktiků Gama se prodala spousta, Ondrů nějaké dva tisíce.

      Vymazat
    4. Ve skutečnosti to bylo jinak. Prakticky všechny počítače Smutného začaly jako kopie zahraničních. Ondra měl být kopií ZX81. Ondra ale byl ubastlen, nikoli zkonstruován. Spěchali s ním, aby ho předvedli na výstavě, a podle rozhovoru v AR s autorem je nikdo do výstavy netlačil, bylo to jejich rozhodnutí, a tak nebyl ani zkušební model - rovnou dělali z nuly ostrý stroj, konečný tišťák a bedny. Prvotní bylo stihnout termín a předvést něco fungujícího na výstavě. Na té výstavě jsem mimochodem byl osobně.

      Takže IMHO nebyl čas ho dodělat a když něco nešlo, tak to holt muselo ven. Nápad udělat Ondru se prý zrodil v září 1985 a v listopadu 1985 byla výstava, na které bylo předvedeno hotových prvních 5 kusů Ondry. Osobně jsem je na vlastní oči viděl.

      Ondra trpí nedodělaností, a to mu podle mého srazilo vaz. A zcela zaslouženě. Kdyby tomu věnovali delší čas a udělali ho pořádně, mohl to být velmi dobrý počítač. Takže všechny součástky měly prioritu v tom, co šlo rychle sehnat před čímkoli jiným.

      Sám si na ten moment, když jsem poprvé uviděl Ondru na výstavě pamatuji, vrylo se mi to do paměti. Jednak mě překvapilo, že jsem o něm předtím neslyšel, protože o všech novinkách jsem věděl chvíli dopředu. Druhak mě překvapilo, jak nepraktický a k ničemu počítač to je.

      Vymazat
    5. Podle mě byla rozhodující klávesnice, která se pro toto použití prostě nehodila. Vždyť to mělo čtyři shift-klávesy, a stav se zjišťoval podle toho, zda svítila žlutá LED, zelená LED, případně obě nebo žádná. Ani deset let vývoje by nepomohlo, z takové klávesnice slušný počítač nepostavíte.

      Vymazat
    6. Taková klávesnice byla nejspíše použita, protože jediná rychle a levně k dispozici. Kdyby na tom pracovali trochu déle, zřejmě by to mělo i lepší klávesnici. Pravděpodobně by to mělo i basic, a řadu dalších parametrů podstatně lepších.

      Sinclair ZX80 byla vyvíjena od května 1979 a prodávala se v únoru 1980. A to Sinclair i Westwood byli zcela nepochybně o třídu výš, než Smutný a kolektiv.

      Vymazat
    7. Klávesnice byla z Tesly Jihlava, a bohužel, Smutný a Mercl trochu neodhadli, jaký bude výsledek: příliš se soustředili na ideu hardwarově minimalistického počítače. To se občas stane.

      Vymazat
    8. Ještě jednu věc. Podle legendárního rozhovoru s autorem Ondry (myslím, že je to i někde na webu) jsem získal dojem, že v hlavě měli spíše počítač, který sestrojí po Ondrovi s názvem Honza. Bude to profi se CP/M se Z80 a později z toho udělat PC XT a honit DOS.

      V té době ale začala být důležitá jiná věc, kterou bych já tehdy neodhadl také. A to standardy. V době kolem revoluce se začalo lámat to, že se prosazovaly standardy a ne každý pes jiná ves. Tedy určitá abstrakce služeb. Myslím, že to postupně zabilo i ZX Spectrum a mnoho dalších 8bitových počítačů.

      Mám dojem, že Československo zanedbalo vytvoření cenově dostupného domácího 8biťáku a snažili se to rychle zaplácnout kolem roku 1985 = Ondra, Maťo a další. Maťo byl myslím lepší pokus. Oba vznikly rychle, ale Maťo stavěl na PMD-85.cNakonec nejúspěšnější byla zkopírovat zahraniční i s chlupama = Didaktik apod.

      A už nic z té doby nevím. Vyčerpal jsem se a nemám k tomuto tématu už co říci. Jen jsem chtěl podpořil názor, že Ondra přišel pozdě, v době, kdy už končily CP/M a začalo dominovat PC XT. A že Ondra byl hlavně nestandardní, stejně jako to ZX Spektrum.

      Vymazat
    9. Působilo tam několik faktorů v synergii: jednak začal být adresový prostor osmibitů programům těsný (stránkování je pro vývoj SW nesmírná zátěž), jednak pro ně, až do (pozdního) příchodu MSX, neexistovaly rozumné standardy. To byl ale problém i na Západě.

      CP/M je textově orientovaný operační systém, takový hodně (ale opravdu hodně) ořezaný Unix. Teď jsem v něm trochu pracovat při ladění Z80 a překvapilo mě, jak nesmírně primitivní je to systém; pamatoval jsem si ho složitější :-)

      Pokud se bavíme o standardech, šlo hlavně o grafiku, a dá se říct, že standardem bylo cokoliv, čeho výrobce dokázal prodat nadkritické množství, tedy Spectrum, Commodore, Atari, Apple atd. IBM PC přišlo v pravou chvíli, protože jednak bylo hardwarově kvalitní (hlavně klávesnice), bylo šestnáctibitové a přineslo koncepci grafiky mimo základní desku, na rozšiřující kartě. To byl podle mě ten rozhodující geniální nápad, který zajistil PC "nesmrtelnost".

      Vymazat
    10. Ten nápad byl tedy modularita a modularita si vyžadovala standardy komunikace mezi moduly.

      Tím se ze scénáře "jedna firma se pokouší dělat reklamu a prodat počítač" stane scénář "tisíce firem dělá reklamu a podporuje jeden počítač" - což je mnohem účinnější.

      Základní scénář, jak něco rozšířit do světa je nech vydělat mnoha lidem, když to rozšíří. Tento koncept rozšířil PC, tento koncept rozšířil Windows, tento koncept rozšířil třeba SAP, rozšířil třeba ARM, a rozšiřuje koncepty i mimo IT sféru včetně politických převratů v zemích.

      Vymazat
    11. Tento nápad byl realisován už u počítače Altair a jeho sběrnice S-100, ale ekonomický tlak donutil výrobce osmibitů pro domácí použití od této koncepce upustit a vše, nebo téměř vše, integrovat na jednu desku. IBM PC mělo výhodu v tom, že si na domácí počítač nikdy nehrálo, na to bylo příliš drahé, ale tím, že jeho HW nebyl patentově chráněn, se začalo vyrábět v takových kvantech, že jeho cena za pár let byla tam, co v polovině 80. let osmibity.

      Vymazat
    12. Ještě informace k ceně: podle tohoto videa Smutný předpokládal prodejní cenu 3 200 Kč.

      Vymazat
    13. V to době to bylo jednoduché. Byl profesionální počítač a počítač na hry. Problémem osmibitů bylo, že byly na hry. Problém i velmi vyspělých počítačů, jako je Amiga bylo stigma "herní počítač". IBM PC prostě bylo na hry fakticky nepoužitelné v první verzi, a proto se rozvinulo a ujalo. Herní počítače neumíraly, ale doslova vychcípaly.

      Kolik stál Ondra nikdo pořádně ani neví. Ono se ho vyrobilo asi jen 1000 kusů, a několik let po revoluci bylo nalezeno obrovské množství neprodaných Ondrů v jednom skladě, takže se prodalo minimum.

      Dnes je zcela stejné stigma. Podívejte se, jak chcípají herní věci. Jak se propadá prodej extenrích grafických karet. Jak klesají zisky z her. Jak ubožejší a rychleji zastarávající jsou herní konzole. Do jisté míry se dnes opakuje to samé = herní ptákovinky vypadávají, zůstává praktičnost.

      Problémem je, že profíci v IT trendy nevidí. Eduard Smutný neviděl trend, že v době vydání Ondry už jsou požadavky lidí řádově jinde, a Spectrum je tak tak splňovalo na dolní hranici. Už chtěli disky, barvy, klávesnici, programy. Stejně tak dnes na hw webech se diskutuje stejně. Nevidí trend, že herní zaměření umírá. Ale stále se diskutuje o tom, jaké herní věci vybrat. Výrobci nevyrábějí dobrou klávesnici, ale bazilióny herních. Lidé chtějí maličké počítače PC typu MacMini, nechtějí velké herní krávy factory vzhledu. Atd.

      Historie se dnes opakuje. Výrobci si totiž myslí, stejně jako tehdy, že herní je hlavní tahoun. Ale lidi chtějí ty počítače spíše na internet, psaní, účetnictví, programování, atd. Ale výrobci jen - herní, herní, herní, totéž IT weby.

      Miloslav Ponkrác






      Vymazat
    14. "Herní" je buzzword, asi jako před 15–20 lety multimediální.

      Já bych Smutnému rozuměl, že chtěl, aby se děti učili spíš programovat, než aby pařily Manic Minera. Ale v populaci je těch, kteří se dívají na počítač jako na fascinující technologickou hračku, stěží procento (ne-li promile), pro zbytek je Facebook a Farm Ville a Angry Birds a podobné nesmysly. To je realita, s níž se lidé jako Smutný museli smířit.

      Vymazat
    15. Pak se nabízí otázka, proč Smutný nedal do počítače ani Basic?

      Realita je taková, že lidé rádi budou používat počítač k užitečným věcem. Ne nutně programovat. Jenže pokud se počítač určitého typu hodí jen na hry, pak budou hrát hry.

      Například já jsem měl asi loni ideu, že budu profesionálně sázet. Tudíž jsem si objednal z USA knihu od Knutha a začal jsem. Úspěšně jsem si napsal asi 400 KB maker, takže v plain TeXu udělám to samé co v LaTeXu a lezou z toho krásné dokumenty. A pak jsem s tím sekl. Došlo mi, že těch pár algoritmů, co má TeX lze zcela určitě přenést do lepšího jazyka, než je makrovací jazyk TeXu. Tedy jazyk, který rezervuje jednotlivé znaky jako klíčová slova pro různé kategorie, nemá lokální proměnné, vyhodnocování výrazů stojí za starou bačkoru. Asi nejvíce humorné je, že jazyk na práci s textem nemá ani funkci na zjištění délky řetězce. A když jsem si pak přečetl dokument od CSTUGu, jak se pokoušeli vybudovat makro na porovnávání dvou řetězců a selhali, pochopil jsem, že nejsem škarohlíd a můj názor na TeX makrování je správný (XeTeX makro strcmp má).

      V podobném stavu je i dnešek. Lidem je nabízen low level jazyk C nebo Java. A to si zkuste v těchto klasických jazycích udělat třeba graf! To je teprve masochismus. (Dříve to s Borlandem a BGI šlo poměrně snadno.) V dávném basicu to šlo několik příkazy plot a line přímo v jazyce raz dva.

      Linuxová komunita ještě nedávno lákala lidi na linux stylem "každý se přeci může naučit bash, awk, C, flex, bison, ...". Zcela po zásluze tento zábavný přístup způsobil, že lidi se Window či OS X drží zuby nehty a nepouštějí se.

      Já se ani nedivím, že k těmto věcem lidé nechtějí. Viděl jsem laiky s radostí programovat - v grafickém prostředí Smalltlaku nebo v HTML/CSS. A v několika dalších prostředích. A nebo v hloupém Excelu. Ostatně mnoho lidí, když se dostane k Pythonu se první učitelů zeptá, proč mu Python neukázali hned a otravovali ho nějakým C či Javou. A mají pravdu.

      Já dodnes nechápu, proč programovací jazyky nemají základní abstraktní datové struktury jako součást jazyka. Tak jako Python. C nemá ani pole, ani řetězec, práci s řetězcem emuluje přes str*. Java už pole a řetězec má, ale tím končí, vše ostatní je už přes knihovny. Jakpak mají pak laici programovat?

      Vymazat
    16. Pak se nabízí otázka, proč Smutný nedal do počítače ani Basic?

      Protože na něj neměl místo. Shodou okolností právě rozebírám to jeho zapojení a analysuji, co který IO dělá a co na kterém pinu kdy je, takže mám trochu přehled, jak je to udělané.

      Slušný BASIC by zabral 10–12 KB místa (původní PMDčkový má 10 KB, tedy řekněme deset), a protože tehdy v ČSSR nebylo nic nad 2708/2716, tzn. 1/2 KB, musel by tam nastrkat, kromě monitoru, spoustu dalších velkých integrovaných obvodů, včetně patic, které zabírají víc prostoru než samotný chip. Takže Ondra s BASICem by byl pomalu dvakrát tak velký než bez něj.

      Došlo mi, že těch pár algoritmů, co má TeX lze zcela určitě přenést do lepšího jazyka, než je makrovací jazyk TeXu

      Zkuste tedy Luatex. Já stejný problém řeším, resp. v krátké době řešit budu, tak, že dokument bude napsaný v XML, ze kterého si přes XLST vygeneruji texový zdroják, protože, marná sláva, nic jiného tak dobře sázet neumí. Všechny dokumenty, které vystavuji na druhém blogu, jsou mimochodem generovány (plain) TeXem.

      A nebo v hloupém Excelu. Ostatně mnoho lidí, když se dostane k Pythonu se první učitelů zeptá, proč mu Python neukázali hned a otravovali ho nějakým C či Javou. A mají pravdu.

      Programátoři jsou elitáři, a víceméně právem, na rozdíl od jiných profesních skupin, které elitami nejsou ani náhodou, ač se tak tváří (právníci, lékaři apod.). Proč by se programátor měl snažit, aby laika naučil programovat, když mu může prodat svou práci?

      Vymazat
    17. Tentokrát jste lepší. :-) S tím Basicem máte nejspíše pravdu. Ano, plně uznávám.

      K TeXu bych napsal rozsáhlejší komentář, ale nechci to tu zahltit. Všiml jsem si, že sázíte XeTeXem jako já. Nápad jsem měl podobný jako vy, použít rozumný skriptovací jazyk a vygenerovat soubor obsahující jen primitivní makra TeXu a nepoužívat makrovací jazyk.

      Myslím, že v každém oboru je mnoho vyvolených a málo povolaných. Na vašem argumentu něco je. Je pravdou, že programátoři učit nikoho nebudou. Nicméně očekával jsem, že firmy živící se vývojovými prostředími tak budou k potěše své peněženky činiti, a vydají takové nástroje, aby slušné programy v nich vytvořila i lázeňská veverka na stromě. Nicméně neděje se tak.

      Vymazat
    18. Mimochodem, ironií osudu právě v PC začíná mizet ta oddělená grafika a vrací se jako pevná součást procesoru - tedy postupně se jde směrem k tomu, co bylo u 8biťáků.

      Procesor už má standardně v sobě řadič paměti, různé věci, co dřív byly součástí můstků na základní desce, a čím dál více se integruje právě grafická karta. Nakonec se to postupně vrátí tam, co 8bity, tedy all in one, vcelku téměř nerozšířitelné.

      Vymazat
  3. Trochu změním téma. Začínám trochu zkoumat svět mikrovln a tam z myšlení inside box už začínám propadat trudnomyslnosti. Momentálně se pokouším o měřič síly pole na 2,4 Ghz s trochu větší citlivostí. Zatím si můžu vybrat, do jakého tvaru si otluču hlavu o zeď.

    Miloslav Ponkrác

    OdpovědětVymazat
    Odpovědi
    1. Moje zásada: vše nad gigahertz je od ďábla :-)

      Vymazat
    2. Trefně řečeno.

      Vymazat
  4. > Experimentováním jsem zjistil, že java generuje nejefektivnější kod, pokud je zdroják právě takto zdánlivě nelogicky strukturován.

    Vy jste jako vazne napsal benchmark ze kteryho vylezlo ze tech 256 instrukci s prefixem 0xCB je nejrychlejsich kdyz se to roztahne na 60kB zdrojaku? Moc se mi to nezda, i kdyz je jasny ze tim odpada potreba rozebirat bajt opcodu na kousky.

    > Vždyť to mělo čtyři shift-klávesy, a stav se zjišťoval podle toho, zda svítila žlutá LED, zelená LED, případně obě nebo žádná.

    Ctyri ruzny shifty? Jako fanda Emacsu zacinam litovat ze jsem se s tim neseznamil dukladneji.

    > Linuxová komunita ještě nedávno lákala lidi na linux stylem "každý se přeci může naučit bash, awk, C, flex, bison, ...".

    Opravdu? Tehle vsech 5 veci jsem sice uz pouzil, ale nenadchla me ani jedna z nich a krome bashe jsem nic z toho uz mozna roky nevidel. A to sedim na Linuxu denne a (kdyz nejsu v IDE) delam skoro vsechno pres prikazovou radku.

    > Zcela po zásluze tento zábavný přístup způsobil, že lidi se Window či OS X drží zuby nehty a nepouštějí se.

    No ja o tomhle zabavnym pristupu jeste neslysel. BFU nepozna Linux od Pindowsu kdyz mu tam date spravny ikonky.

    OdpovědětVymazat
    Odpovědi
    1. Vy jste jako vazne napsal benchmark ze kteryho vylezlo ze tech 256 instrukci s prefixem 0xCB je nejrychlejsich kdyz se to roztahne na 60kB zdrojaku? Moc se mi to nezda, i kdyz je jasny ze tim odpada potreba rozebirat bajt opcodu na kousky.

      Experimentoval jsem s tím poměrně dost, a zjistil jsem, že Java nesnáší dlouhé switche, které chápe jako jeden kod a neumí je proto optimalisovat. Proto se musí kod rozsekat. Zda ho rozdělit na jednotlivé opcody nebo na jejich skupiny podle masky, je už celkem jedno, moje řešení je nicméně programátorsky čisté. Další optimalisace by šla sloučením manipulace s flagy do výrazů, ale vzhledem k tomu, jak nepatrnou zátěž emulace ALU představuje, se to prostě nevyplatí a postačí mi vědomí, že jsem dal kompilátoru možnost inlinovat prakticky všechny methody volané z instrukcí, např. incPC, CLEARNF, HL() apod., a není moje vina, pokud to případně nedělá (ale spíš dělá, celý exerciser pro Z80 mu trvá 2,5 sekundy).

      Ctyri ruzny shifty? Jako fanda Emacsu zacinam litovat ze jsem se s tim neseznamil dukladneji.

      Jako fanda Emacsu fanovi Emacsu vám říkám, nelitujte. Po napsání čtyřřádkového programu v Basicu jsem hluboce oddechoval a měl nutkání změřit si tep.

      Vymazat
  5. Nejsem laik, a podobnými lacinými zlehčováními si moc nepomůžete.

    Tento zábavný přístup propagoval Linux minimálně 10 let v kuse. Což je přesně důvod, proč LInux má na desktopu 1 %. Posledních několik málo jednotlivých let už tomu tak není, ale důvodem je spíše prořídnutí staré linuxové garnitury a nahrazení další generací, než jiný důvod.

    A to mluvím už o zralejším LInuxu. Co se dělo třeba v letech řekněme kolem roku 2000, raději nepíši. Ani o historkách k popukání v letech před a krátce po tomto roku. Například masový prodej počeštěného RedHat Linuxu CZ 6.2 (číslo verze si přesně nepamatuji),. který se prodával v každé trafice a kvůli chybě v instalátoru nešel vůbec nainstalovat. To bylo první setkání obecného českého lidu s Linuxem vůbec. Samozřejmě s komentáři "konečně můžete všicni opustit to chybové Windows a přejít na bezchybný Linux" ze všech stran linuxové komunity a webů.

    V dobách Windows 98 pak Linux byl ve tvaru, že bez čtení mnoha megabajtů plain text anglické dokumentace, nastudování kódu modemu, detailů protokolu - jste se k internetu nepřipojil vůbec. Mně to trvalo 14 dní celodenní práce v tehdejším Debain Linuxu. A to jsem pěkně prosím znal unix jako svoje vlastní boty.

    Dnes už je Linux poměrně mnohem vychytanější, a excesy jsou minimální. Nicméně představa linuxové komunity směrem k laikům byla poměrně dosti - mírně řečeno sadistická. A to ani nezmiňuji, s jakou vřelostí (ironii cítíte zcela správně) se laik či zkušený uživatel jiného operačního systému setkával na diskusních skupinách.

    Dnešní Linux je zcela něco jiného a linuxová komunita změnila taktiku. Dnešní Linux je prímový, a mám ho rád. Ovšem linuxová komunita nyní připomíná svědky jehovovy, šíří desatera a víra směrem od "politbyra", což je můj slangový název pro centrální dodávání názorů do linuxové komunity. Když se chci zasmát, přečtu si nějaké články o linuxu, zejména články, které mají v názvu "vyvracení mýtů o ..." jsou téměř vždy velice lživé a plné vtipů.

    Miloslav Ponkrác

    OdpovědětVymazat

Kursiva: <i>text</i>
Tučně (když už to musí být…): <b>text</b>
Odkaz: <a href = "http://adresa">název odkazu</a>, tedy <a href = ""></a>

Poznámka: Komentáře mohou přidávat pouze členové tohoto blogu.