Vdaka za clanok, stoji za to.
Este poznamka: clanok sa venuje prekladacom a tam sa da s trochou snahy ziskat slaba istota. Plna istota je narocnejsia - ked mi nieco neuslo, tak najlepsie navrhovane postupy sa spoliehaju na zapis na pamatove medium ako je disketa. Ale ja nemam dost pevnu ruku na zapis magnetizovanou ihlou. Pouzitie nastrojov znamena, ze uz v nich moze byt trusting the trust utok.
Utok moze byt aj nizsie: co ak je trusting the trust utok vo firmwari niektorej komponenty, napriklad v mikrokode CPU? Alebo co ked je cely v HW tak, ze vyrobcovia cipov vyrabaju cipy s backdoorom aj ked o tom nevedia?
Je to tak. Já se zabýval hlavně bootstrapingem překladače, ale jde udělat i bootstraping OS (asi tedy ne namačkáním loaderu na předním panelu, jak to dělávali pionýři IT, spíš vypálením do PROM). To vše za předpokladu, že HW je verifikovaný (což není). IMHO s dnešní architekturou PC to nejde zaručit, muselo by se jednat o něco mnohem mnohem jednoduššího, pravděpodobně počítač s plně softwarovým řízením prakticky všeho (jak to měl Apple II - to ovšem nemá nic společného s dnešními apply, dokonce i logo je jiné :-)
Původně jsem měl jen podezření, které ale už přerostlo v jistotu. Osoba jménem Pavel Tišnovský nemůže existovat, protože žádný člověk nemůže mít takový přehled v tolika oblastech a psát takto poutavě, zajímavě a ještě i bez chyb. Je to určitě nějaké fake jméno, za kterým se ukrývá tým minimálně 20 lidí
Teď vážně - Pavle (ať už vás je kolik chce ), díky moc za články, jsou vždy špičkové.
No úplně nová věc by samozřejmě zabrala víc času než těch +-10 hodin, takže 10 hodin na známé téma, ovšem samozřejmě s dohledáním referencí a upřesnění. Zrovna u tohoto článku asi máme "my stařešinové" výhodu v tom, že jsme něco podobného dělali bootstrapu na osmibitových mašinách, takže to novinka není. Ten Thompsonův příklad je taky pár let starý, relativně nový je hlavně Wheelerův důkaz (2009).
ahoj diky!
myslis ze je to nejak takto? https://www.youtube.com/watch?v=C9d3GsaZqe0
Osobně si myslím, že jméno a příjmení autora je takovým krycím názvem pro Tima O'Reilly-ho. Již jednou jsem se vyjádřil, že Pavel musí psát asi 36 hodin denně. Nebo používat VoiceRecongition a mluvit ze spaní.
Články jsou fantastické a číší z nich autorova vskutku renesanční záliba snad ve všech oblastech IT.
Něco málo k O'Reiily:
https://en.wikipedia.org/wiki/O%27Reilly_Media#/media/File:ACM_OReilly-Rainbow-large-flash.jpg
No, ja nahodou vim, ze osoba jmenem Pavel Tisnovsky opravdu existuje - chodil jsem s nim 5 let do tridy na VUT Brno :-)
A proto i vim, ze mel Atari a rad programoval v assembleru.
Takze predpokladam, ze ten clovek co znal celou instrukcni sadu 6502 zpameti byl on sam. I kdyz ja jsem ji ze sveho Commodore +4 znal taky.
Ted je jeste otazka, kolik Indu na psani takovych clanku schovava ve sklepe .....
Zdarec...
Taková migrace kódu/metadat do binarek překladače... Ono to hodně souvisí s tím co Pavel píše. Pokud si jeden nedá pozor (a v rámci času a vývoje to je někdy dost těžké) na migraci kódu a metadat ze zdrojáku do binárky, tak se dostává do podobné situace. A při zjištění dané věci nezbývá, než opravit prapůvodní verzi (obvykle) a postupne překopilovat všechny verze zpětně. Někdy stačí přepsat pár drobností je to OK... Typickej příklad pro C, parsování zpětnýho lomítka:
switch (character)
case 'n':return(0x0d);
case 'r':return(0x0a);
....
Není moc co řešit. Jinak to ani nešlo, prvni verze neuměla "\n" :) Nicméně, postupem času se změní kód na:
switch (character)
case 'n':return('\n');
case 'r':return('\r');
....
Je to přece přehlednější. Pak se naskýtá otázka, kde vlastně je uloženo 0x0d a 0x0a ? Ve zdrojkáku už ne... Pokud pak někdo prohodí D/A protože to je blbě a má být A/D, tak rozdílné binárky ze stejného zdrojaku zprodukují rozdílnej výsledek. V tomto prípadě relativně bagatelní.
Kdysi v minulosti přemigrovaly ty konstanty do binárky a už se jen přelejvá pri kompilaci z jedné verze do druhé a její hodnota už není pod kontrolou zdrojového kódu. Je krásně zbinarizovaná. A neviditelná.
Tohle je samozrejmně jednoduchý příklad, nicméně, podobné věci se dějí nejen na takto krásné a kontrolovatelné úrovni. V dnešní době, plné "metadat" je to raz dva.... A když se jeden snaží, není takovéj problem zbinarizovat bůch ví co. Speciálně kód, co děla optimalizace má spousty možností (třeba příprava lookup tabulek, což je čiště vygenerovanej kód a pod)... A krásné na tom je nejvíce to, jak to není na první pohled vidět. Koho by napadlo, že ta věc nahože, druhá v pořadí, je vlastně "průser" ? Nejspíš jen toho, kdo se s tím někdy potkal. Jojo, slepice a vajíčko :)
R.
fakt super článok - vďaka
téma je aktuálna, treba dať pozor na veci, ktoré považujeme sa samozrejmé. Za samozrejmosť berieme, že prekladač je O.K. - čo tak vôbec nemusí byť.
problém softvéru sa dá riešiť, ale čo problémy na hardwarovej úrovni? také zabugované cpu intel, amd, arm - s nimi sa ako máme vysporiadať?
Potiz je spis v tom, ze v pocitaci mas tech CPu desitky, i kdyz se jim tak nerika. Programovatelnou jednotku s vi buh jakym kodem mas v kazdym disku, sitovce, zvukovce, radice vseho moznyho i nemoznyho ... a to vsechno ma prevazne primej pristup ke vsemoznym sbernicim, takze je ve finale uplne jedno jak moc bezpecnej je nebo neni tvuj kod. Je i uplne jedno jak moc bezpecnej je prave kompilator a stejne tak je jedno jak moc bezpecnej je system.
Kdyz na to prijde, muzes naprosto smesne jednoduse vsechny tyhle vrstvy trivialne obejit, protoze ses mnohem niz nez kam dohlednou. Kdyz ti dorazi update nejakyho toho firmware, analyzujes co ze to vlastne dela?
Oni rusove dobre vedi proc svy spiony vraceji ke psacim strojum. Protoze tam mas vsechna rizika viditelna, snadno zhodnotitelna a muzes s tim neco delat.
>> (i když osobně znám člověka, který si dokázal zapamatovat kódy všech strojových instrukcí i jejich variant)
Jojo, toho znam taky :-) Jmenuje se Ales.
Zapamatovat si (vetsinu) instrukci Z80 nebylo tak tezke, v tech dobach jsme psali programy primo v hex kodech. Assembler jsme totiz nemeli. Napsali jsme s timhle zpusobem dokonce i interpretr Forthu. (na TNS ze zemedelskeho druzstva Slusovice, kdo si na ne dnes jeste vzpomene...)
V tech dobach to byla normalka ... kdyz si chtel zjistit co neco dela, tak sis vypsa/vytisk obsah pameti/nejaky epromky/... a pak si to pekne rucne (protoze jinak nebylo prevazne jak) prevadel zpatky na asm, aby ses podival, co ze to tam vlastne ti zapadni soudruzi delaj ... ;D
Mno a kdyz si to delal dost dlouho, tak uz si ani nepotreboval dohledavat, protoze si ty hexa kody rovnou cet.
BTW: Znam cloveka kterej si takhle primo cet derny pasky.
Zapamatovat si (vetsinu) instrukci Z80
Zkusil jsem, kolik se mi toho vybavi po tech letech (desetiletich). Bez pomoci uz dam jenom ctyri instrukce: 3E, C3, CD, C9. (LD A, imm, JMP, CALL, RET).
Nejhorsi bylo, kdyz clovek zjistil, ze mu nekde nevychazi misto a musi kvuli tomu prepocitat polovinu adres.
takže vlastně znáš celou 1/4 instrukční sady! To si pamatuju z průmyslovky, kdy nás Aleš za hodinu naučil MOV a řekl "tak a znáte celou 1/4 assembleru, zbytek dobereme příště" :-) Ale tuším, že namísto nějaké MOV M,M je tam NOP nebo HLT nebo něco podobného, takže "jen" 63 instrukcí.
(učili jsme se BOBO, ne Z80)
[Josef Pavlik]
"na TNS ze zemedelskeho druzstva Slusovice, kdo si na ne dnes jeste vzpomene..."
Samozrejme, i kdyz jsem byl v te dobe maly capart. Vyrabeli pocitace rady TNS a bylo svyho casu tak zname, ze se o nem i zpivalo : https://www.youtube.com/watch?v=YoBUNZJdxzc&ab_channel=rudolfo6666 :-D
Ahoj Jožine,
ten Forth byl super a poznamenal mě na celý život, i když jsem v něm profesně nikdy nic nedělal. Jestli si dobře vzpomínám, tak jste to s Jirkou implementovali průběžně, jak vycházel ten seriál v AR, že? To byly časy... Tomáš
A děkuji panu Tišnovskému za další skvělý článek. Sice Pavla osobně vůbec neznám, ale věřím, že kdybych si s ním mohl u piva pokecat o IT, tak skončím jako alkoholik :)
Ahoj Pavle. Uzasny clanek diky za nej.
Tak me napada, i pres to, ze to zni jako akadamecke tema, zda se bootstraping pouziva realne v praxi, nebo se alespon testuje cistota prekladace. Napriklad tvurci mainstreamovych dister (napr. Red Hat, Cannonical, Debian...) overuji, ze jejich prekladace jsou ciste a produkuji cisty kod?
Ahoj Pavle. Popravdě jsem čekal, že zmíníš Smalltalk a jeho minimalistickou VM. To je skoro doslova pár instrukcí ne?
(mimochodem - trošku plánuju reiteraci TinyBasicu s poli nativně pro AArch64. Tím, že je ta VM maličkatá, by se mohl obejít problém s I-cache (celý VM by byl na pár cache line), takže uvidíme.
Tak minimalistická, abych si to dovolil, zase není ;-)
Spíš bych v tomto případě šel jinou cestou. Když se podíváš na Self, funguje flastně jako systém vzájemně provázaných Forthovských slovníků s pozdní vazbou, které mezi sebou delegují vyhledávání. Když by se ve Forthu udělal jednoduchý GC a některá slova se používala jako selektory pro sloty s kódovým slovem provádějícím delegaci, mohl by se Selfovský objektový systém velice elegantně bootstrapnout.
Jedná se spíše jen o úhel pohledu.
Když se vyhledává slovo ve Forthu, tak se začne postupně procházet spojový seznam slovníku slov a porovnává se hledaný řetězec se jménem slova, dokud se nenarazí na konec. Pro jednoduchost předpokládejme, že Forth má slovník jen jeden. Pokud se slovo kompiluje, pak se do programu zapíše příslušný code pointer (early binding).
Teď si představ, že budeš chtít Forth upravit tak, abys měl možnost mít libovolný počet slovníků a v každém z nich žádný, jeden nebo více odkazů na další slovníky. Jakmile se nenajde slovo v příslušném slovníku, deleguje se hledání slova na rodičovský slovník. Pokud chceš mít možnost odkazy na rodičovské slovníky dynamicky měnit, pak ti nezbyde nic jiného, než se rozloučit s early binding a použít pozdní vazbu (pomineme-li různé možnsti optimalizací). Když navíc takové slovníky uložíš do paměti s automatickou správou, získáš něco, co jako by z oka vypadlo objektovému modelu Selfu.
Když už objekty v Selfu fungují principiálně podobně jako Forthovské slovníky, pak se na Forth můžeš dívat jako na Self s jedním objektem. A obráceně. Dalo by se tedy možná začít s Forthem jako základem pro bootstrapping Selfu. V Selfu potřebuješ něco jako symboly nebo kanonické řetězce pro efektivní hledání slotu, abys nemusel porovnávat jména slotů jako řetězce, ale jen rychle porovnáním identity. Pak potřebuješ nějakou tabulku symbolů, ke které má přístup virtuální stroj, a nějakým způsobem ji spravovat. Nabízí se v tomto případě přímo použít slovník Forthu. Jméno Forthovského slova by obsahovalo text symbolu a code pointer by odkazova na rutinu, která by prováděla vyhledání slova a případnou delegaci na další slovníky. Přitom bys stále měl možnost používat běžná slova Forthu, která by ze Selfovského pohledu hrála něco jako roli primitiv.
Pokud by takto vytvořený rozšířený Forth skutečně fungoval, dal by se nad ním postavit jednoduchý parser, který by Forthovský kód posypal trochou syntaktického Selfovského cukru, ale měl bys systém, který je jasně bootstrapovatelný, docela rychlý, jednoduchý a mající stále možnost, kdykoliv je to nutné, používat Forthovskou základnu.
Neuvěřitelná tvárnost Forthu k takovým úvahám svádí. Ale pokud jde o mě, tak když jsem se s tím dostatečně vyřádil, začal jsem zase spíš couvat, omezovat i nadužívání DOES>, pole si definuji přes CREATE místo zavádění nějakých svých vlastních definujících slov, místo různých vlastních CASE použiju jednoduše tabulku xt-ček... Ten jazyk je prostě dokonalý tak, jak je, tak proč z něj dělat nějaký objektový nebo kdo ví jaký. Tu jeho flexibilitu je nejlepší využít jako nástroj k tvorbě konkrétního DSL a ne k vytvoření další abstraktní univerzální vrstvy. To je můj názor po mnoha letech programování ve Forthu (pro mikrořadiče).
Je to na dobré cestě: https://gigatron.io/?p=1198
Jenom se v tom bude asi trochu blbě psát kompilátor Céčka.
Nebyl by lepší Magic-1?
Já už TinyBasic pro Gigatron TTL zkoušel alespoň v emulátoru a fungovalo to hezky: https://github.com/PhilThomas/gigatron/pull/2
Ale psát kompilátor C jsem v tom nezkoušel ;-)
Možná by bylo lepší začít assemblerem, něco jako https://www.asm80.com/ :)