Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: noname 30. 07. 2014, 00:37:15
-
Rozmyslal som nad tym, ze ked mam nejake zdrojaky napr. v C, tak aby som vedel spustit ten program, tak ich musim skompilovat prekladacom (napr. gcc). Lenze ten samotny gcc kompilator (spustitelny subor) je tiez skompilovany kompilatorom, ktory musel niekto skompilovat a tak dalej.
Ako ale potom vznikol uplny prvy kompilator?
Dalej, ked si napr. zoberiem prekladac ako je LLVM, tak to bolo skompilovane s gcc? A mozu potom uz kompilovat LLVM s LLVM resp. s clangom?
Asi blbe otazky ale toto by som rad vedel :)
-
To, na co se ptáš, je defakto první prověrka každého kompilátoru. Zda dokáže přeložit sám sebe.
Historicky:
Úplně první programy se cvakali ručně, pomocí kolíčků, přepínačů, atd. To znamená, že jsi si to napsal na papír, a musels mít dobře.
Pak se vytvořili Asemblery, které jen převáděli MOV na její hexa reprezentaci. Tento první asembler byl napsaný ručně, na papír, pomocí přepínačů, kolíčků napchán do stroje.
Pak se vytvořili lepší Asemblery, které toho uměli více, a které byly napsané v předchozí verzi Asembleru.
Pak se vytvořili Lispy, které byly napsány v Asembleru.
Pak se vytvořil jazyk C, který byl napsán v Asembleru.
Pak se vytvořil jazyk Haskell, který byl napsán v C.
Pak se vytvořil jazyk Java, který byl napsán v C.
(Nezajímavé jazyky přeskakuju.)
Schematicky:
Vždycky se překládá nová verze jazyka pomocí předchozí verze, nebo jiného již existujícího jazyka.
Zajímavé by pro tebe mohl být Turingův stroj a princip turingovsky kompetního stroje/jazyka.
-
Takze ked si zoberiem tu Javu, tak v C bol napisany java kompilator (javac) prelozeny s gcc. V C je napisany ten virtualny stroj (prelozeny s gcc), ktory konzumuje bajtkod, ktory je vytvoreny tym java kompilatorom v C?
-
První kompilátor vzniknul jako program v ASM.
První program se realizoval takhle:
1) Kritická část po resetu se vyšila jehlou a drátem do určené oblasti feritové paměti.
2) Zbytek se nacvakal ručně speciálním HW přípravkem, mělo to displej na jeden byte, potřebný počet vypínačů jeden pro každý bit, enter, krok vpřed, vzad.
3) Až se takhle podařilo do feritové paměti dostat loader na pásku, tak další program se ručně vyděroval na papírové pásce a tu už počítač schroupal.
4) Po čase se takhle napsal program co uměl i vyděrovat pásku a to už je skoro jako dnes :-)
Zde je příklad jak se dělalo to ruční cvakání:
http://www.iva-w.org/ZXS/Prom2.gif
http://www.iva-w.org/ZXS/sinclair_zx_spectrum.htm
-
JVM musí být povinně v jazyku produkujícím binárky, je použito C nebo C++.
javac bylo ze začátku v C, nyní je údajně v Javě, ale může být v čemkoliv.
-
uplne prvni kompilator se proste narodil. pak vymyslel papyrus. elektronku. derny stitek. ram. a pak uz konecne i jiny druh kompilatoru.
-
Kompilátor jazyka je program jako každý jiný. Tudíž je možné ho napsat v assembleru nebo přímo ve strojovém kódu. Samozřejmě, ve vyšším jazyce se takový program píše lépe, nepotřebuješ k tomu ale nějaký rozsáhlý jazyk a knihovny, protože problém, který řešíš, je poměrně omezený. Tudíž, kdybych měl dělat kompilátor "od nuly", udělal bych si napřed v nižším jazyce nějaký jednodušší jazyk - třeba nějakou variantu LISPu a z něj bych se teprve pouštěl do něčeho většího.
-
JVM musí být povinně v jazyku produkujícím binárky, je použito C nebo C++.
Ve skutečnosti existují třeba implementace JVM v JavaScriptu (http://wiki.apidesign.org/wiki/Bck2Brwsr), v Javě (http://jikesrvm.org/) nebo přímo v hardwaru (http://www.jopdesign.com/).
-
Ve skutečnosti existují třeba implementace JVM v JavaScriptu (http://wiki.apidesign.org/wiki/Bck2Brwsr), v Javě (http://jikesrvm.org/) nebo přímo v hardwaru (http://www.jopdesign.com/).
No dobře, můžete transformovat JVM do jiného VM nebo interpretu, ale na konci takového řetězce bude nepochybně vždy binárka, procesor nic jiného neumí.
Komerční HW JVM neexistuje, v opačném případě prosím odkaz na eshop.
-
...nepotřebuješ k tomu ale nějaký rozsáhlý jazyk a knihovny, protože problém, který řešíš, je poměrně omezený....
Tak ty asi vela toho o programovani nevies a ani netusis co taky kompilator v dnesnej dobe robi.
-
Tak ty asi vela toho o programovani nevies a ani netusis co taky kompilator v dnesnej dobe robi.
Kompilátor funguje odjakživa pořád stejně a to tak, že strojově přepisuje vyšší jazyk do assembleru (popř. do jiného jazyka). Pokročilé optimalizace tuto základní funkčnost nemění.
-
ale na konci takového řetězce bude nepochybně vždy binárka,
nevidim do toho az tak, ale bolo viacero pokusov o procesor, ktory vedel vykonavat jvm instrukcie, alebo aspon pre to bola vylepsena podpora
napr. jazelle http://www.arm.com/products/processors/technologies/jazelle.php
-
bolo viacero pokusov o procesor, ktory vedel vykonavat jvm instrukcie
A takhle dopadli (http://youtu.be/qch5IaUrt_M?t=1m09s) jejich autoři... ;D :D
-
Neviem ako vznikol prvy kompilator ale ak mam verit tomu co je napisane na Youtube tak ho napisala Admiralka Grace Hopper pre Mark1. Admiral Grace Hopper was one of the first programmers of the Harvard Mark I computer. She developed the first compiler for a computer programming language.
Zda sa ze to bola celkom mudra pani https://www.youtube.com/watch?v=9eyFDBPk4Yw
-
Nejdřív nebylo nic. Pak řekl Bůh "Budiž kompilátor".
-
napr. jazelle
Jazelle není HW JVM, to je obecně oblíbený omyl. Některé věci, které autoři nebyli schopni realizovat v mikrokódu, jsou jako standardní program ve strojovém kódu.
-
...nepotřebuješ k tomu ale nějaký rozsáhlý jazyk a knihovny, protože problém, který řešíš, je poměrně omezený....
Tak ty asi vela toho o programovani nevies a ani netusis co taky kompilator v dnesnej dobe robi.
Co ti brání tvůj sofistikovaný a vysoce optimalizující kompilátor zkompilovat v jednoduchém neefektivním kompilátoru a pak ho znova zkompilovat v tom svém novém právě zkompilovaném kompilátoru?
-
bolo viacero pokusov o procesor, ktory vedel vykonavat jvm instrukcie
A takhle dopadli (http://youtu.be/qch5IaUrt_M?t=1m09s) jejich autoři... ;D :D
;D ;D ;D
wölø
-
Svatá prostoto! Podobné otázky se za mých mladých osmdesátých let řešily v knížkách pro děti od Albatrosu. Výhodou bylo, že v tom nebyly gramatické chyby a že to řešil člověk, který o tom aspoň něco věděl.
(1) Kritická část po resetu se vyšila jehlou a drátem do určené oblasti feritové paměti. -- Cože??? ;D Mohl bys to rozvést trochu podrobněji? ;D)
-
Cože??? ;D Mohl bys to rozvést trochu podrobněji? ;D)
Není co rozvádět, polovodičová ROM ještě nebyla, tak se bity doslova zadrátovaly na potřebnou hodnotu. Navlékaly se kroužky na drátky jako když se vyšívá obraz do koberce.)
V počátcích IT se dělaly různé podobné kousky, namátkou tohle:
http://cs.wikipedia.org/wiki/Pam%C4%9B%C5%A5_se_zpo%C5%BE%C4%8Fovac%C3%AD_linkou
-
Tady je trochu chyba v úhlu pohledu. Na kompilaci jazyka C (zřejmě platí pro většinu jazyků) do strojového kódu není potřeba kompilátor. Ten překlad se dá udělat s tužkou, papírem, referenční příručkou procesoru a trochou času a zkušeností.
Pro jazyk C se to běžně učilo na VŠ a dodnes se to i dělá v oboru "embedded zařízení". Vezme se program v C a některé jeho funkce se ručně "zkompilují" do assembleru. Takže i dnes může vzniknout "první kompilátor" tím, že ho někdo napíše v assembleru a ten pak ručně převede do strojového kódu. V rámci studia se to dodnes dělá, akorát už ne na PC, ale na něčem jiném. Strojový kód 8086 ještě šel, ale pro nové procesory už je to šílenost. Proto se to učí třebas na mikrořadičích, případně na emulátorech starých procesorů/počítačů (ZX Spectrum, MC68000, PC AT epod.) Starý vtip: opravdový programátor používá "copy con myapp.com".
Další krok je pak "evoluce". V assembleru udělám jen nezbytně nutnou funkcionalitu. Překladač, který vezme zdroják v C a vygeneruje fungující program. Bez optimalizací, bez linkování knihoven atd. V té chvíli mám překladač jazyka C a můžu začít programovat překladač jazyka C, tentokrát nikoliv v assembleru, ale v C. Tím, že to je v C, je snažší do toho implementovat všelijaké optimalizace, linkování atd. Ve chvíli, kdy tenhle nový překladač bude fungovat uspokojivě, můžu začít svůj překladač překládat v tom novém překladači a začít využívat všelijaké optimalizace, dynamické linkování atd. To mi dá ještě větší volnost a možnosti a kolo se roztáčí. Poslední verze překladače pak už nejde přeložit tím "prvním překladačem", protože ten takhle složitý dialekt C nezvládal.
-
Cože??? ;D Mohl bys to rozvést trochu podrobněji? ;D)
Není co rozvádět, polovodičová ROM ještě nebyla, tak se bity doslova zadrátovaly na potřebnou hodnotu. Navlékaly se kroužky na drátky jako když se vyšívá obraz do koberce.)
V počátcích IT se dělaly různé podobné kousky, namátkou tohle:
http://cs.wikipedia.org/wiki/Pam%C4%9B%C5%A5_se_zpo%C5%BE%C4%8Fovac%C3%AD_linkou
Ale blbost, nic se nevyšívalo. Kdes na to pro boha přišel? ROM samozřejmě byla, na ROMce není nic technologicky náročného - matice tavných pojistek, v polovodičovém provedení matice diod, které buď programováním odprásknu nebo je nechám být - nic jednoduššího už snad ani není. Problém byl s dostatečně rychlou RAM - a k tomu právě sloužila feritová paměť, jež byla rychlá a spolehlivá, i když přísně vzato to nebyla RAM, ale spíš EEPROM. Nic se do ní nevyšívalo, jednalo se o bloky matic feritových kroužků navlečených na dvojici kolmých adresových vodičů a protažených jedním společným datovým vodičem pro daný blok. Programovala, vyčítala a mazala se elektricky.
Chápu, že to je historie, ale ani dnes není problém během pár vteřin si najít, co to bylo, k čemu se to používalo a jak to fungovalo, místo psaní nesmyslů o nějakém vyšívání.
-
Ale blbost, nic se nevyšívalo.
Chápu, že to je historie, ale ani dnes není problém během pár vteřin si najít, co to bylo, k čemu se to používalo a jak to fungovalo, místo psaní nesmyslů o nějakém vyšívání.
http://authors.library.caltech.edu/5456/1/hrst.mit.edu/hrs/apollo/public/visual3.htm
dnes není problém během pár vteřin si najít, co to bylo, k čemu se to používalo a jak to fungovalo, místo psaní nesmyslů
souhlas
-
http://authors.library.caltech.edu/5456/1/hrst.mit.edu/hrs/apollo/public/visual3.htm
Jenže tohle není to, čemu se říká feritová paměť. Ve feritové paměti slouží kroužky feritu jako nosič informace, v tomto případě jde pouze o transformátory. Navíc je to velmi speciální aplikace - naváděcí počítač rakety, který musel být radiačně a ESD odolný, proto bylo použití polovodičů dosti riskantní. Rozhodně to ale není něco, co by se běžně ve výpočetní technice používalo.
-
Ale blbost, nic se nevyšívalo. Kdes na to pro boha přišel? ROM samozřejmě byla, na ROMce není nic technologicky náročného - matice tavných pojistek, v polovodičovém provedení matice diod, které buď programováním odprásknu nebo je nechám být - nic jednoduššího už snad ani není. Problém byl s dostatečně rychlou RAM - a k tomu právě sloužila feritová paměť, jež byla rychlá a spolehlivá, i když přísně vzato to nebyla RAM, ale spíš EEPROM. Nic se do ní nevyšívalo, jednalo se o bloky matic feritových kroužků navlečených na dvojici kolmých adresových vodičů a protažených jedním společným datovým vodičem pro daný blok. Programovala, vyčítala a mazala se elektricky.
Nemáš ani tušení jak funguje polovodičová ROM. Ta se navíc rozšířila až v 60. letech.
Již jsem zmínil, že se takhle dělaly pouze nejnutnější úseky, ne celé programy jako tady http://en.wikipedia.org/wiki/Core_rope_memory
Jenže tohle není to, čemu se říká feritová paměť. Ve feritové paměti slouží kroužky feritu jako nosič informace, v tomto případě jde pouze o transformátory. Navíc je to velmi speciální aplikace - naváděcí počítač rakety, který musel být radiačně a ESD odolný, proto bylo použití polovodičů dosti riskantní. Rozhodně to ale není něco, co by se běžně ve výpočetní technice používalo.
Z toho stejného kroužku se udělá transformátor, nepřekvapivě.
-
Na to jsi přišel jak, machýrku? Abys mohl **z ničeho** vydupat super kompilátor, to chce nějaký čas. Asi těžko si v assembleru uděláš z ničeho LLVM a CLang. Nehledě na to, že autor původního dotazu se na nic tak sofistikovaného neptal.
...nepotřebuješ k tomu ale nějaký rozsáhlý jazyk a knihovny, protože problém, který řešíš, je poměrně omezený....
Tak ty asi vela toho o programovani nevies a ani netusis co taky kompilator v dnesnej dobe robi.
-
Není co rozvádět, polovodičová ROM ještě nebyla, tak se bity doslova zadrátovaly na potřebnou hodnotu. Navlékaly se kroužky na drátky jako když se vyšívá obraz do koberce.)
Je ti jasné, že feritová paměť („kroužky na drátech“) je volatilní? Když chceš zadrátovat hodnotu, připojíš to na nulu nebo jedničku, žádný kroužek není potřeba.
-
Když chceš zadrátovat hodnotu, připojíš to na nulu nebo jedničku, žádný kroužek není potřeba.
a adresovat to bude jak?
http://authors.library.caltech.edu/5456/1/hrst.mit.edu/hrs/apollo/public/visual3.htm
http://en.wikipedia.org/wiki/Core_rope_memory
-
Nemáš ani tušení jak funguje polovodičová ROM. Ta se navíc rozšířila až v 60. letech.
Jo, zdá se mi, že popsal PROM. Polovodičová ROM má ty bity normálně vymaskované přímo na čipu hliníkem, ne? (někde jsem měl hezkou fotku z mikroskopu, teď ji nemůžu najít)
Již jsem zmínil, že se takhle dělaly pouze nejnutnější úseky, ne celé programy jako tady http://en.wikipedia.org/wiki/Core_rope_memory
Aha, to jsem nevěděl. Jaký byl důvod patlat se s šitím transformátorů místo toho to prostě naswitchovat v matici natvrdo.
-
a adresovat to bude jak?
Jo to je pravda, stejně tam potřebuju spínací prvek.
-
Nejdřív nebylo nic. Pak řekl Bůh "Budiž kompilátor".
nejdriv byl kvantovy stack overflow. pak vnikl kompilator buh.
-
Nejdřív nebylo nic. Pak řekl Bůh "Budiž kompilátor".
nejdriv byl kvantovy stack overflow. pak vnikl kompilator buh.
Na hranici s tebou, kacíři!
-
Dnešní programátoři jsou trpaslíci, kteří stojí na ramenou obrů.
-
toto je pekny clanok o vzniku c od dennisa ritchieho
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
v skratke: ako bol jazyk bcpl obsekany do jazyka b, z ktoreho potom velmi rychlo vyplaval c
+ zmienky o kompilatoroch
-
Na to jsi přišel jak, machýrku? Abys mohl **z ničeho** vydupat super kompilátor, to chce nějaký čas. Asi těžko si v assembleru uděláš z ničeho LLVM a CLang.
Nevím, jestli tě chápu správně, ale možná na něj útočiš dost zbytečně.
I dnes vznikají ÚPLNĚ nové HW architektury, pro které je potřeba napsat kompilátor úplně od píky a to i pro poměrně komplexní jazyky. Nemluvím tím o převedení GCC na jinou HW architekturu, ale o architekturách, které jsou zcela mimo obvyklý rámec ARM/x86.
Sám jsem podobný projekt viděl v akci a žádné MOV, CMP, JZ nebo AAD instrukce neměl, prostě vycházel z řady malých jednotek, kdy každá mohla pracovat pouze s množinovými operacemi, takže instrukce ToRightUP 10 otestovala okolní jednotky na pravé straně a pokud některá z nich měla větší hodnotu než ona samotná, zvýšila její hodnotu o 10. Jednotky mohly pracovat pouze v párech, přesněji řečeno se to asi kapku podobalo programování HW neuronové sítě.
Velmi zajímavé a velmi výkonné.
Takže neříkej, že bez ničeho ten vyšší překladač prostě stvořit nejde, protože naopak je potřeba právě pro nové architektury nový překladač z ničeho stvořit. Samozřejmě, první překladač obvykle běží na nějaké stávající architektuře nebo na papíře.
-
Na to jsi přišel jak, machýrku? Abys mohl **z ničeho** vydupat super kompilátor, to chce nějaký čas. Asi těžko si v assembleru uděláš z ničeho LLVM a CLang.
Já útočím? Četl jsi, co psal on?
Takže neříkej, že bez ničeho ten vyšší překladač prostě stvořit nejde, protože naopak je potřeba právě pro nové architektury nový překladač z ničeho stvořit. Samozřejmě, první překladač obvykle běží na nějaké stávající architektuře nebo na papíře.
Dvě poznámky:
1. Nikde jsem nepsal, že to NEJDE. Je to velice obtížné, ale technicky a teoreticky lze od píky napsat cokoliv. Ještě jsem každopádně neslyšel o tom, že by někdo na první dobrou napsal (dostatečně složitý) kompilátor, který by nepotřeboval v dalších verzích zoptimalizovat. Natož aby ho implementoval v ASM nebo strojáku.
2. Vycházel jsem z předpokladu, že autora dotazu zajímá vývoj kompilátoru v situaci, že žádný vyšší jazyk k dispozici nemá a to ani na jiné architektuře. Situace, kdy je možné napsat v prvním kroku nějaký cross compiler, je sice také zajímavá, ale je to přece jenom něco jiného. A když odpovím podle nejlepšího svědomí a podle mě vůbec ne mimo, přijde nějaký borec a začne mi vysvětlovat, že kompilátory, které jsou na světě X let a mají Y. verzi, dokážou víc, než můj usmolený kompilátor verze 0.2, který jsem v imaginárním potu tváře vyplodil v minilispu.
-
Mně někde kdysi někdo povídal, že jazyk C vznikl z jazyka B a ten z jazyka BCPL (ať už to znamená cokoliv). Kamarád vykutal nějakou knihu z počítačové mladší doby kamenné, tam se psalo, že programátoři nebudou psát rovnou strojní kód, ale problém zakódují do nějakého mezistavu kterého se chopí kompilátoři (lidi!) a ti z toho teprve vytvoří chodivý stroják.
-
A nástupce jazyka C se měl jmenovat P
-
Tak se hned nečerti, tvoje čichová integrita nám je svatá.
Jde jen o to, že v určitých případech opravdu mohou vznikat i zajímavé překladače prakticky z nuly.
-
Neviem ako vznikol prvy kompilator ale ak mam verit tomu co je napisane na Youtube tak ho napisala Admiralka Grace Hopper pre Mark1. Admiral Grace Hopper was one of the first programmers of the Harvard Mark I computer. She developed the first compiler for a computer programming language.
Zda sa ze to bola celkom mudra pani https://www.youtube.com/watch?v=9eyFDBPk4Yw
Skutecne byla: http://www.root.cz/clanky/ibm-a-sedm-trpasliku-treti-cast/#k05
Nakonec z jeji snahy vysel COBOL, ktery ma porad jeste par peknych vlastnosti.
-
První kompilátor vzniknul jako program v ASM.
První program se realizoval takhle:
1) Kritická část po resetu se vyšila jehlou a drátem do určené oblasti feritové paměti.
Podle me dost blbost, feritove pameti byly mega drahe, takze se pouzivaly bubnove pameti (napriklad http://www.root.cz/clanky/historie-pocitacu-vyrabenych-v-nbsp-sssr/ ctvrta kapitola). Az kdyz uz bubnove pameti rychlostne nestacily, muselo se se skripajicimi zuby prejit na feritove pameti.
-
Dnešní programátoři jsou trpaslíci, kteří stojí na ramenou obrů.
Tesat do kamene :-)
-
a ti trpaslici sa budu zdat byt o 20 rokov obrami
-
udelas si ten zaklad v tom, co je k dispozici (napr. asm) a pak uz ten kompilator vyvijis v tom jazyce, pro ktery vyvijis ten kompilator :D
-
uz se perou?