Žirafoviny.cz

Sašo, u ankety ti chybí další možnost - MIKROPROCESORY NEPROGRAMUJU.

Tentokrát nechybí, protože mě zajímalo v čem se programuje, pokud už se programuje. Někdy minule se řešilo, jestli se programuje a ne v čem. Takže tentokrát předpokládám odpovědi pouze od těch, kdož opravdu programují

Tak to bys nejdřív měla definovat jestli myslíš opravdu procesor (CPU) nebo mikrořadič (MCU), případně jaký procesor či jaký mikrořadič, a potom se možná někdy dozvíš to, co tě skutečně zajímá.

Myslím procesory obecně, takže jak ty maličké, tak malé, větší až ty největší. Každý z nich se dá programovat přímo ve strojovém kódu i všemi dalšími způsoby.

Skutečně? Takže třeba nějaký ten i5 má interpreter jazyka přímo v procesoru (volba z ankety), který můžeš použít? To mi teda předvěď, rád si počkám.

Pokud ho někdo vytvoří (nadšenec, komunita, firma...), tak proč by nemohl být interpreter i pro i5? Jsou různé interpretery pro různé procesory. Viděla jsem Basic, Javu, Python, PHP, C... něco je pro AVRka, něco pro PICky, něco pro 8051 či jiné rodiny, druhy a další příbuzenstvo.

„proč by nemohl být interpreter i pro i5”

Protože nerozlišuješ mezi mikrořadičem, samotným procesorem a celým počítačem, což je chyba, stejně tak jako nerozlišuješ programování pro procesor vs. programování pro operační systém, což je další chyba. Je v tom podstatný rozdíl, ale dnešním dvaadvacetiletým lemplům pracujícím jako aplikační programátoři v C# se tohle nedá rozumně vysvětlit.

Mluvil jsem o interpreteru pouze pro samotný i5 (aby to bylo analogické těm Picaxe z příkladu), ne pro celé PC a v nějakém operačním systému, a to záměrně, aby se dal snadno pochopit rozdíl - a stejně jsi ho nepochopila.

Ano, správně, v této anketě nerozlišuji mezi programováním mikrořadičů, samotných procesorů ani celých počítačů. Programovat se dá jedno, druhé i třetí a všechny možnosti tu jsou. Možná jsou i další, které mě nenapadli.

Já také nikde nemluvím o tom, že interpreter pro i5 musí být jen v nějakém operačním systému. Někdo ho může udělat i přímo pro procesor bez operačního systému, ačkoli ten vlastní interpreter vlastně bude tím operačním systémem, stejně jako Picaxe. Nicméně mám pocit, že nějakého interpreteru přímo pro i5 se asi nedočkáme

A také máš pravdu v tom, že tentokrát tvým připomínkám prostě nerozumím, asi si sedím na vedení.

No, asi jo, protože „jádro pudla” je právě v tom, že pro samotné i5 interpreter přímo „na železo” dnes už nikdo jednoduše napsat nemůže, protože i kdybychom tedy „milostivě svolili” s tou RAMkou k CPU, tak by ten někdo stejně nejdřív musel naprogramovat celý operační systém, a k tomu je potřeba mnoho mnoho znalostí (a i tak by to ten člověk možná sám nezvládl).

Jinými slovy, tvoje představy o programování pro moderní procesory (tedy jako systémový programátor, nikoliv aplikační) jsou naprosto liché, dnes vše běží v protected mode (včetně UEFI), doby kdy procesor běžel v reálném módu skončily s MS-DOSem a přímo k železu se prostě nedostaneš ať děláš co děláš - tam se dostane jenom jádro systému (tedy když víš, o co a jak ho poprosit). Tedy procesory i dnes umí běžet v real mode, ale technologicky to zůstalo právě v té MS-DOS době („superrychlá 486”), protože to prostě nikdo nepoužívá a na nic nepotřebuje. Už ani ten BIOS ne.

Že se něco nepoužívá, nebo je to zbytečné, ještě neznamená, že to nejde.

Navíc jsem nikde nepsala o tom, o jaký procesor se má jednat, byla to všeobecná otázka. Když ale tak koukám na tuto debatu, tak asi nevhodně zvolená. No jo, stává se.

Já píšu tatarsky, nebo jak??

Právěže to znamená že to nejde, protože z protected mode není cesty ven jinak než resetem, a když ti to do protected režimu po resetu přepne hned UEFI, tak se prostě NEMÁŠ JAK dostat do real mode.

Takže pro novější x86 procesory už dneska nikdo neprogramuje, protože prostě NEMŮŽE. Můžeš pustit staré kódy nebo kódy napsané čistě v ASM, ale poběží vždy v emulaci, tj. pod nějakým OS - takže dnes už prostě nelze říci "programuju pro x86 procesor", protože jde programovat už jen pro OS (tzn. úplně jiným stylem).

Proto jsem hned na začátku psal, že je chyba nerozlišovat CPU od MCU a případně jaký, atd. Vždy se musí první nejdříve říct, o jakém konkrétním se bavíme, a až pak se teprve můžeme dobře domluvit.

Tatarsky nepíšeš, ale já jsem asi poněkud natvrdlá.

Jen blbá otázka: pokud se o přepínání mezi protected a real mode stará UEFI, kdo jej tedy napsal a v čem? Podle Wikipedie je to mezičlánek mezi operačním systémem a firmwarem/hardwarem počítače. Takže je to je kus programu, který musel někdo vymyslet, napsat a pak začít používat.

A pokud se něco píše v libovolném programovacím jazyku, tak to stejně překladač musí nějak převést na strojový kód daného procesoru, nebo rodiny procesorů, takže z toho usuzuji, že pokud to umí překladač, měl by to umět udělat i člověk, byť je to velmi nepohodlné řešení. To ale bylo programování ve strojovém kódu vždy.

UEFI je dnes to, čemu se dřív říkalo BIOS, tj. kus programu v paměti na základní desce, který se stará o základní inicializaci HW a POST. Dnes už je to asi kryptované, kvůli Secure bootloaderu a dalším podobným zvěrstvům - detaily tohoto přesně neznám.

Nechápeš nic, nelze roubovat znalosti z jednočipů na velké procesory, není mezi nimi stejného už prakticky nic. Procesory se neuvěřitelně vyvinuly za ty léta - když bych ti tu napsal že procesory jsou dnes pokročilá RISC architektura, která s x86 nemá společného nic a zpracování běží tak, že se vnitřně provádí překlad a emulace x86 instrukcí, tak mi to neuvěříš stejně jako každý běžný (franta) uživatel - a přesto je to pravda už od Pentia Pro.

Za další - pokud argumentuješ překladačem, tak bys měla aspoň vědět, co je dneska vlastně překladač a jakým způsobem dnes pracuje, znalosti z dob DOSu, 386 a (ne tak úplně) dnešních mikrořadičů nelze na velká CPU takto aplikovat. Překlady dnes běží objektově, oddělené mnoha frameworky a různými HAL a API, když dnes překládáš tak vlastně jen stavíš ze stavebnice, sestavené a určené právě pro tyto frameworky a vrstvy - v případě Javy, dotnetu a mnohých dalších (jejichž množství se neustále zvětšuje) se dokonce už ani nepřekládá do strojového kódu procesoru, ale do bytecode (uměle vytvořený konstrukt, syntetický kód pro nějž zpravidla neexistuje žádný hardwarový procesor), který pak zpracovává právě framework. Dokonce tyto zvrhlosti zašly tak daleko, že se pro Java bytecode (což je první syntetický kód, který existoval dříve než procesor pro něj) někteří pokusili zpětně vytvořit hardware, na kterém by mohl běžet přímo - je to případ ARMu (konsorcia). Povedlo se jim to jenom částečně.

Citát:

To ti uvěřím velmi snadno, protože tomu tak skutečně je.

Ten zbytek je zcela určitě také pravda, ale pořád mi to připadá, že se bavíme o tom stejném, ale každý trochu jinak.

Přes to všechno co píšeš, přes ty všechny překladače, frameworky, vrstvy a dotnety se nakonec ten kód dostane až do registrů toho procesoru, do jeho klopných obvodů a dalších součástek. A ten strojový kód řekne procesoru, že má vzít data z registru X, sečíst je s daty v registru Y a to celé pak dát do registru Z. Předpokládám, že i dnešní složité procesory fungují tímto způsobem a ne tím, že procesor je živá bytost, která si ten kód přečte a pak, možná, provede.

A pokud je ALU i toho nejmodernějšího procesoru řízena nějakým kódem, který jí říká co má s čím sečíst, tak musí být možnost napsat pro takový procesor program přímo v tomto kódu. Byť je to práce pro šílence a jedná se o velmi obtížnou a nepraktickou činnost.

Řeknu to teda ještě jinak, i když trochu nepřesně: Z toho kódu, co se ve finále provádí v HW tak jak píšeš, je "ta tvá" asi tak každá desetimilióntá instrukce. To je to, co se tu celou dobu snažím vysvětlit - ten kód co se provádí jsi nenapsala ty, napsal ho někdo jiný, ty můžeš jen určit které kousky se kdy mají brát a provádět. Ani v assembleru není problém napsat např CALL Window.Create nebo něco podobného, ale nejsi to ty/tvůj kód, kdo vytvoří okno - ty jsi jen řekla, že se to má provést - použila jsi cizí kód, který ani nevíš jak uvnitř vypadá, a co je hlavní - ani nemáš jako programátor možnost to dělat nějak jinak, než takto pod OS. Tohle je to, co tu celou dobu řešíme.