Historické kompilátory jazyka C na vlastní kůži (2)

1.7.2018 00:56 | Přečteno: 5336× | | poslední úprava: 1.7.2018 00:56

V minulém zápisku jsme se podívali na nejstarší dostupnou verzi překladače jazyka C z roku 1972. Tentokrát se zaměříme na překladač o poznání mladší, vytvořený dlouhých šest let po vydání knihy The C Programming Language, která definovala K&R verzi jazyka C. Ale i tak se nebude jednat o nudný kus kódu. Je jím totiž HiSoft C - překladač pro osmibitové ZX Spectrum z roku 1984.

Nejpoužívanějším jazykem na osmibitových domácích počítačích se stal bezesporu BASIC, který byl ve většině případů přímo součástí ROM. Pokud vám jeho interpret výkonnostně či funkčně nedostačoval, nejpřirozenější alternativou byl assembler, pro který bylo i v té době k dispozici mnoho kvalitních informačních zdrojů. Ostatní jazyky byly spíše okrajovou záležitostí, i když i tak bylo z čeho vybírat. K dispozici byl například Lisp, Prolog či Pascal (sám si matně vybavuji, jak jsem zkoušel nějakou verzi Pascalu, která se ale ukázala jako zoufale nepraktická). Můžeme se jen domýšlet, jak by dnešní svět IT vypadal, kdyby výrobci dávali do ROM místo BASICu Forth jako v případě Jupiter Ace (simulátor, komentovaný výpis ROM, dokumentace, článek Pavla Tišnovského).

O svoje místo na výsluní zájmu programátorů vlastnících osmibitové počítače se zkoušel poprat i jazyk C. Neměl na růžích ustláno, protože parametry těch strojů mu zrovna dvakrát nepřály. Vždyť například ZX Spectrum mělo pro uživatele k dispozici jen cca 40 kB RAM. Minule popsaný prastarý kompilátor jednodušší verze Céčka se sice dokázal vměstnat do 4,5 kB, ale to byl pouze samotný překladač, který ještě funkčně závisí na kompilátoru assemberu a linkeru. Tady bylo nutné zajistit překlad přímo do strojového kódu a do paměti se musel ještě vejít použitelný editor, kód, který jste chtěli přeložit, standardní knihovna, prostor pro pomocná data při překladu a výsledek. Navíc jste neměli možnost si nic odkládat na pevný disk. Jazyk C je založen na proudovém zpracování, se kterým se používaná paměťová média moc neztotožňovala. Pro představu, 48 kB, což je velikost celé RAM Spectra, odpovídá současné velikosti souboru kernel/cpu.c o asi dvou tisících řádcích.

Nejlepší překladač jazyka C pro platformu ZX Spectrum bylo HiSoft C. To se umělo i s editorem nacpat do 25 kB. Ptáte se, jak to dokázalo? Dalo by se říct, že s rezervou, protože jeho kód není přeložený ručně psaný assembler, ale bylo napsáno v C a pouze některé jeho části se pak dočkaly ruční optimalizace. Distribuovaná binární verze programu dokonce obsahuje hodně smetí - nepoužívaná místa naplněná náhodnými obsahy bufferů počítače, který prováděl překlad. Při psaní tohoto překladače převládal čirý pragmatismus.

Nahrání vývojového prostředí z kazety o standardním datovém toku trvalo 4 minuty. Pokud se program osekal o úvodní obrazovku a podobný balast, pak se dalo dostat pod 2 minuty padesát. Člověka musí napadnout, proč ke kompilátoru přidávali úvodní obrazovku zbytečně prodlužující načítání. Odpověď je prostá. Předpokládalo se, že uživatel bude používat jako paměťové médium ZX Microdrive, kde byl nahrávací čas velice krátký. Obraz se nahrál přímo do video-RAM, nezabíral tak žádné užitečné místo a uživatel měl alespoň pocit, že za svých 25 liber dostal kvalitní produkt.

Po nahrání jste se ocitli v jednoduchém editačního režimu kompilátoru, kde jste mohli napsat krátký prográmek prakticky bez možnosti zpětné editace. Pak klávesovou zkratkou SS+I ukončit zadání, čímž se zkompiloval a hned spustil. Většina práce se ale prováděla v editoru, do nějž se dostanete klávesovou zkratkou CS+1 následovanou Enterem.

Editor je to velice spartánský a trochu připomíná ed. Například napíšete i10,10 a už můžete zadávat řádek 10, přičemž po stisknutí enteru začnete vložit další řádky, jejich číslo se bude vždy o desítku zvětšovat. Číslování řádků zde slouží pouze pro potřeby navigace v editoru, není to žádné předělávání Céčka na BASIC. Ven z editace ze dostanete opět pomocí CS+1,Enter. Důležitá je možnost úpravy již zadaných řádků, ta se dělá příkazem e následovaným číslem řádku, který chcete upravit. V editačním módu řádku máte k dispozici další sadu příkazů, jako je i pro vložení nových znaků, k pro smazání aktuálního atd.

Editor určitě není nejsilnější stránkou tohoto programu. Pro nás jsou důležité příkazy p (put) a g (get), které ukládají a nahrávají editované soubory. Právě ve způsobu ukládání a nahrávání tkví jeden z klíčů stojících za tím, že na Spectru může C vůbec fungovat. Ukládají se totiž na pásku po samostatných blocích o velikosti 512 bytů. To znamená, že si můžete uložit několik zdrojových souborů, ze kterých se skládá váš program, rozmařile je doplňovat o komentáře, ale když jejich velikost udržíte v rozumných mezích (uvědomte si, že na veškerou práci nám po nahrání kompilátoru v paměti zbylo jen 15 kB), v okamžiku, kdy se soubor uloží na pásku, bude při kompilaci postupně nahráván a překládán po blocích a jeho celková velikost už nebude příliš důležitá.

Používat interní editor HiSoft C je velice nepohodlné, takže pro hraní člověk ocení utilitku c2tap, která převede běžné C soubory do obrazu pásky používaného v emulátorech. Ty se dají případně snadno spojovat do větších obrazů. Perličkou je, že jsem hanebně podcenil googlení a utilitku se stejnou funkcí si nejdříve napsal sám na základě rozborů uložených souborů. Člověk pak třeba zjistil, že při ukládání těch 512 bytových bloků se HiSoft C neobtěžuje předmazat buffer, takže kromě kódu, který chcete, na pásku uložíte i kusy staršího. Tento náhodný, ale smysluplně vypadající balast pak vstupuje do výpočtu kontrolních součtů a stoprocentně zamotá hlavu každému bláznovi, který se v těch datech bude chtít hrabat.

Pokud si chcete HiSoft C vyzkoušet na v emulátoru, potřebujete nejdříve zvolit vhodný prostředek. Ve většině běžných případů využívám JavaScriptový Qaop. Ten se bohužel v tomto případě moc nehodí, protože potřebujete často pracovat s obrazy pásek. Osobně používám ZEsarUX a pokud jej neznáte, určitě jej neváhejte zkusit. Tomu se předhodí parametry --tape helloc.tap --snap cc.zx, kde helloc.tap je kazeta s páskou vygenerovanou programem c2tap a cc.zx snaphsot čerstvě nahraného HiSoft C. V něm zadáte

#include hello.c

ukončíte soubor stiskem SS+I a program se provede. Samostatné #include vloží data z editoru (do něj je lze nahrát data pomocí příkazu g,,hello.c),

Pokud chcete uložit přeložený program v binární podobě na pásku, musíte ještě před provedením #include zadat direktivu #translate se jménem, pod níž se program uloží (např. hello).

#translate hello
#include hello.c

Výsledek na pásce bude binární blok. Pro nahrání a spuštění v čistém systému tedy musíte provést

LOAD “hello” CODE 25200
RANDOMIZE USR 25200

Z výše uvedeného popisu je zřejmé, že celý překlad probíhá z technických důvodů jednoprůchodově a že tedy nelze plně použít preprocesor. Direktivu #define ještě trochu zvládá, ale podmíněný překlad už ne. Direktiva #include funguje trochu odlišně od standardu (#include ?filename?) a do jisté míry nahrazuje právě podmíněný překlad.

Krom preprocesoru má HiSoft C ještě jedno citelné omezení - přímo nepodporuje operace v plovoucí řadové čárce. Tento nedostatek však řeší jedna z dostupných knihoven použitím rutin z ROM.

Původní zdrojové kódy tohoto překladače bohužel k dispozici nejsou. V dekompilované a trochu pročištěné formě jej tvoří přibližně 12,5 tis. řádků v assembleru, což není mnoho. Z dnešního pohledu přímý praktický význam má jen minimální. I když se rozhodnete programovat pro Spectrum v Céčku, stále máte na výběr řadu jiných moderních variant. Ty ale samozřejmě nebudou fungovat přímo na cílovém systému.

HiSoft C svět nedobylo. Na vině je celá řada faktorů, od nepřívětivého editoru, přístupu mateřské firmy, která jej rozvíjela jen minimálně, přes obecné vlastnosti Spektra až po fakt, že ZX Microdrive se nakonec neprosadil a intenzivní využívání záznamových médií bylo pro přijatelně pohodlnou práci v tomto prostředí zásadní.

Ale už samotná existence tohoto překladače je inspirující. Vidět, jakým způsobem jeho autoři překonali zásadní technická omezení a dokázali přinést téměř plnohodnotné Céčko i do tak omezeného pracovního prostoru. To si zaslouží i po 34 letech malé připomenutí.

       

Obrázky

Komentáře

[ehm]

Fakt moc pěkné články. Díky.

[xsubway]

To je nostalgie Pokusy s C na ZX Spectrum+ 48k skončili právě proto, že jsem ve své době měl jen kazeťák. Když jsem si polepšil na disketovou jednotku, tak už to zase nebylo aktuální. Prostředí Prometheus, pro psaní v assembleru, zvítězilo

[MMMMMMMMM]

Prometheus byl super. :)

[Miloslav Ponkrác]

Programovací jazyk C totiž není univerzální. Aby procesor umožňoval dobrou a efektivní implementaci C, musí mít určité předpoklady ve strojové sadě instrukcí. Kdyby se C nepřisálo na unix, který vlastně požadavky na procesory zglajchšaltoval, tak by se C nejspíše neprosadilo vůbec a zaniklo by postupně jako slepá větev.

Céčko nelze efektivně implementovat tam, kde je málo registrů, není podpořena intenzivní práce se zásobníkem a rychlé ukládání/obnovování registrů. Plus další předpoklady.

Na Z80 není možné Céčko dobře implementovat. Stejně jako na řadě 8bitech i profesionálnějších procesorech. Mnohem lépe dopadl Pascal na ZX Spectru, kterému jsem před C dával zde přednost.

Na Atari bylo C ještě horší, chvíli jsem v něm zkoušel programovat, ale nestandardností bylo příliš mnoho.

Zkrátka C je svázáno s moderními procesory a jejich sadou instrukcí. Když C nepomůže procesor, tak to moc dobře nedopadá. Je to vlastně unikát: Programovací jazyk, který potřebuje podporu přímo od výrobců procesorů, jinak ho nelze slušně, natož efektivně implementovat.

Najdete stovky pokusů, včetně některých velice raritních a zvláštních, jak implementovat C na platformy, kde je C nevhodné. Často to ústí ve snahu vytvořit dialekt C nebo nový C jazyk s C-like syntaxí.

[berk]

Zdá se, že nesmířlivý boj mezi pascalisty a c-čkaři stále žije Bude to chtít nějaký článek i o Pascalu, aby druhá strana tolik nežárlila na "slepou větev přisátou na UNIX"

[Ovoce]

No ale není Unix (nebo vlastně celý IT) o tom, že vždycky vyhraje horší řešení? Naposled třeba Android.

[Käyttäjä 11133]

A co je to lepší(tm) řešení oproti Androidu?

[Ovoce]

No i kdyby nebylo nic lepšího, tak Android je tak hroznej kus softwaru že by se mu stejně mělo říkat horší systém. I kdyby to bylo ve srovnání s úplně neexistující platformou :) Ale to je offtopic, já bych tu diskusi nezasíral příliš moc, to téma blogu je o dost zajímavější.

[_]

V cem je hroznej? Jako spokojeneho dlouholeteho uzivatele byt me to docela zajimalo...

[Jendа]

Předpřipravená odpověď:

Problém s Androidem je, že to sice běží na linuxovém kernelu, ale userspace je vyrobený kompletně od nuly. Tím se zahodila veškerá přizpůsobitelnost a konfigurovatelnost ekosystému desktopového unixu, kterou budovaly miliony lidí a unixových bohů posledních 30 let a kterou jsem si budoval na svém desktopu posledních 12 let. A chroot s Debianem to neřeší, protože ten Debian nemůže plně přistupovat k hardwaru.

GUI nejsou Xka, takže tam nefungujou normální aplikace (leda si spustit appku emulující X server nebo VNC) a není tam nic jako xlevels (nastavení "Levels" obrazovky, znáte z GIMPu).

Lock screen není PAM, ale nějaká custom věc, a není tam nic jako pam_jenda (něco co po 3. špatném zadání hesla udělá zvolenou akci) a nejde tam triviálně dodělat, protože to nemá nic jako pam_exec.

Šifrování karty není LUKS, ale custom věc nad dm-cryptem, která má za posledních 5 let už třetí nekompatibilní API, a když se změní heslo přes špatnou verzi API, tak to neřekne žádnou chybu, ale tiše to ztratí data (a existující nástroje na opravu LUKSu nejde použít, protože to není normální LUKS). A z GUI nelze nastavit jiné heslo k disku a jiné k lockscreen.

Kamera není V4L2, ale používá se přes custom knihovnu, ve které jsem během pěti minut narazil na bug v procházení VFS. Výsledek je že nejde fotit do ramdisku, což chci kvůli tomu, že fotky nechci ukládat na storage, ale okamžitě je asymetricky zašifrovat GPGčkem a až potom uložit.

Zvuk není tak úplně ALSA, nefunguje třeba alsácké přepínání výstupů a na obou zařízení s Androidem co jsem měl způsobilo vytažení jedné šavle v alsamixeru tvrdý reset O_o (výsledek: nejde generovat zvuk triviálně jako "program|aplay -" a nejede mplayer (ten taky nejde kvůli Xkům/opengl/framebufferu). To je problém, protože androidí VLC, MPV i BsPlayer nemají funkční změnu rychlosti videa - místo prostého resamplování dělají nějaký debilní pitch shift. Takže na tom nejde rozumně koukat na přednášky.)

Od mobilu bych třeba ocenil, aby tam šlo naprogramovat „pokud jsi doma a je tma, tak zvoň pouze u hovorů z whitelistovaných čísel“. Na normálním Linuxu je to na tři příkazy (iwlist na zjištění SSID, stáhnutí frame z V4L2 na detekci tmy a pactl na vypnutí/zapnutí vyzvánění).

Uspávání a wake locky fungují z pohledu chrootnutého systému prostě divně, takže když si třeba spustím arecord, tak to dropuje samply jakmile to hodím na pozadí nebo zhasne displej.

Network manager mají nějaký vlastní, takže zase zábava

a ten kernel je vlastně taky divnej, třeba to používá všechny dostupné loopbacky (tj. nepřipojíte si vlastní), náhodně tam chybí různé featury (třeba se mi tam nepovedlo rozjet síť s glibc ze Stretche) a tak

Celkově mám pocit, že jsem si nekoupil smartphone, ale špatně fungující tamagoči. Strávil jsem nekonečně času hackováním věcí, které na Linuxu normálně fungují. Ale jak mi jiní lidé řekli, asi mám nestandardní požadavky na funcionalitu operačního systému (e.g. https://forum.root.cz/index.php?topic=16414.msg228284#msg228284).

[Käyttäjä 11133]

Problém s Androidem je, že to sice běží na linuxovém kernelu, ale userspace je vyrobený kompletně od nuly. Tím se zahodila veškerá přizpůsobitelnost a konfigurovatelnost ekosystému desktopového unixu, kterou budovaly miliony lidí a unixových bohů posledních 30 let a kterou jsem si budoval na svém desktopu posledních 12 let.

Však on mobil taky není desktop, tak k čemu by mi tam byl desktopový userspace?

GUI nejsou Xka

Díky Google!

není tam nic jako xlevels (nastavení "Levels" obrazovky, znáte z GIMPu)

Pro nás co spokojeně používáme Lightroom, a s Gimpem už roky nepracujeme to je?

Ale jak mi jiní lidé řekli, asi mám nestandardní požadavky na funcionalitu operačního systému (e.g. https://forum.root.cz/index.php?topic=16414.msg228284#msg228284).

Zbytek tvého komentáře bych uzavřel ve stejném duchu Jen bych doplnil "na funkcionalitu operačního systému pro mobilní telefony".

[pc2005]

Však on mobil taky není desktop, tak k čemu by mi tam byl desktopový userspace?

Proč by nemohl. Já ho používám například jako JTAG programátor.

GUI nejsou Xka

Díky Google!

Tak si dej: s/Xka/Wayland/, s/Xka/GTK/ nebo s/Xka/QT/ . U toho GTK si jsem jistý, že existuje i backend na framebuffer.

[Jendа]

Však on mobil taky není desktop, tak k čemu by mi tam byl desktopový userspace?

K tomu, abych si mohl jednoduše přizpůsobit cokoli co mě napadne.

Pro nás co spokojeně používáme Lightroom, a s Gimpem už roky nepracujeme to je?

"Curves" (ty v LR jsou), ale jenom lineární. Používá se to třeba k tomu, když máš blbě oskenovaný dokument nebo moderní webovou stránku, které je tmavě šedá na světle šedé, a chceš z toho udělat černou na bílé, aby se to dalo číst.

[pc2005]

Kamera není V4L2

Jo to je peklo, ještě s GSM to výrazně komplikuje možnosti používání GNU/Linuxu na mobilech.

[Ovoce]

Tak že to není desktop/normální linux, ale hromada NIH, to jsem ani neměl na mysli.

Je to hlavně strašlivej bastl v tom způsobu, jak se tam chovají aplikace, jak to všechno kyne a jak je to děsivě pomalý a nestabilní. No a pak ten průser s tím, že jsou aktualizace vázané na konrkétní zařízení a výrobce (a tím de facto do jednoho -dvou let vždycky skončí). Otřesný pro někoho, kdo si zvykl na PC. Ať už s Linuxem, nebo s Windowsama.

Tak jako Android mě už nesral dlouho žádnej systém, snad ani Windows 98. Je mi jasný, že na nějakých výkonnějších zařízeních s lepším vyladěním a s trochou štěstí to určitě musí jet o dost líp, než co s tím zakouším já (dva telefony, televize), ale správně by to mělo i na těch míň šťastnejch chodit aspoň trochu uspokojujícně.

[Michal Kubeček]

Celá historie (nejen) IT je o tom, že vždycky vyhraje řešení, o kterém pak někdo tvrdí, že bylo horší. Podezřele často jsou to autoři a fandové těch řešení, která prohrála. :-)

[_]

cela historie IT je prolozena kubeckovymi plky... nemel by se uz odebrat do duchodu?

[Miloslav Ponkrác]

"Zdá se, že nesmířlivý boj mezi pascalisty a c-čkaři stále žije Bude to chtít nějaký článek i o Pascalu, aby druhá strana tolik nežárlila na "slepou větev přisátou na UNIX""

Vy jste jak malej Jarda.

Celý život si vydělávám C/C++ - tedy už celá desetiletí. Kdybyste četl mé starší články a příspěvky, tak byste věděl, že jsem prakticky nekritický až fanatický zastánce C++. Obviňovat mě z toho, že používám Pascal raději než C/C++ je to samé, jako obviňovat Linuse Torvaldse, že používá raději Microsoft Windows než Linux.

Napadlo vás také někdy, že život není jen fotbalový mač Baník se Spartou, ale také občas o tom, že něco má vhodnější vlastnosti a něco méně? Zřejmě se celý život řídíte jen emocemi, o existenci racionality a racionálního uvažování jste nejspíše nebyl dosud informován.

Programovací jazyky C/C++ sktriktně vyžadují určitou architekturu procesoru - jinak nic moc. C/C++ nejsou žádné univerzální jazyky. Když půjdete třeba do exotičtějších architektur jednočipů, pak je C/C++ dost ke vzteku.

Stejně tak 8bitové mikropočítače nebyly ideální pro jazyk C. A také to podle toho dopadlo, tedy dost na nic. Zrovna na tom ZX Spectru se Pascal povedl 1000 x lépe než C. Na Atari se zase povedl jazyk Action! lépe než C, což je zajímavé i proto, že je to pointerově zaměřený jazyk.

Prostě každý programovací jazyk má své plusy a mínusy. Na 8bitových mikropočítačích je reálnější implementovat dobrý Pascal než dobré C. Na sálových mašinách před 8bity bylo zase reálně dobře implementovat Fortran než Pascal nebo C.

Stejně tak C není rozumně implementovatelné na exotické procesorové architektury, nebo na masivně paralelní operace, nebo na systémy reálného řízení, nebo tam, kde jde o bezpečnost a chyba by stála moc peněz.

[berk]

Já vám tu vaší pravdu brát nechci. Jen mi ty vaše příspěvky připadají trochu jako od žárlivé manželky

[Miloslav Ponkrác]

A mám si urvat límec nebo co, když jste prostě jednodušší jedinec, co ve všem vidí jen dvě nesmiřitelné strany?

[Busy]

"Na 8bitových mikropočítačích je reálnější implementovat dobrý Pascal než dobré C"

Mohli by ste prosim konkretne dolozit nejake technicke detaily, ktore by toto preukazovali ? Pretoze podla mna oba tieto jazyky su principialne podobne a implementacia kompilatora kladie na system, vratane nasich oblubenych 8 bitovych systemov, podobne naroky.

[Jendа]

Na Překladačích blahé paměti říkali, že C má pasti jako a * b, kde člověk musí znát už v okamžiku parsování co je sakra a a b, aby věděl, jestli je to násobení nebo deklarace „b je proměnná typu pointr na a“, zatímco v Pascalu se tohle neděje, a proto jsme psali překladač Pascalu a ne Cčka. Ale třeba existuje nějaký trik, jak to snadno vyřešit a neřešit. A taky jak moc je to relevantní na počítači, kde není runtime pro používání věcí jako GNU Bison (Ponkrác nepíše, jestli chce ten překladač na tom 8bit počítači i provozovat, nebo je to jenom target a překládat se bude na něčem výkonnějším).

[pc2005]

Já bych si tipl, že chce na tom 8bitu i provozovat, aspoň ten céčkovej v blogu je i na provozování ne?

ad přetěžování operátorů: to by šlo vlastně vyřešit tím C-like jazykem (kterej by prostě použil jinej symbol). Ale i tak, trackování toho, co je vlastně a a b mě nepřijde zas až tak komplikovaný.

[pc2005]

BTW neměl pascal maximální délku stringu tak 256? Mám dojem, že si strlen hodnotu někam poznamenával.

[Michal Kubeček]

Takhle to fungovalo u původní implementace datového typu string v Turbo/Borland Pascalu. První byte obsahoval délku (0-255), pak následoval vlastní text. Ale to bylo AFAIK jen jejich rozšíření, původní Pascal podle normy IIRC nic takového neměl.

[Radovan]

Možná to neměl podle normy, ale říká se tomu Pascalské řetězce, zatímco těm ukončeným nulou Céčkové.

A ty, které mají poslední nebo první znak označený jedničkou v nejvyšším bitu by se mohlo říkat Basicové, protože v M$ na tomhle způsobu vytrvale ujížděli

[Michal Kubeček]

Asi není potřeba pořádat nějaký průzkum, abychom se shodli, že lidí, kteří si pod označením "Pascal" představí právě ten dialekt používaný v TP / BP / Delphi, bude nejspíš řádově víc než těch, kteří někdy viděli nějakou oficiální specifikaci jazyka.

[Gilhad]

Asi ne, i kdyz se priznam, ze ja programoval v minimalne ve 3 dalsich ruznych Pascalech krome tech vyse zminenych :)

[pc2005]

Tak já jsem dělal i v delphi a 1 (slovy jednou) _zkusil_ udělat program ve freepascalu. Ale přišlo mě blbý tahat objektové rozšíření jazyka původně z borland pascalu pro Windows do diskuze pod blogem, kde je úspěch načtení kompilátoru céčka pod 2 minuty z kazetové jednotky . Navíc v těch dalších jsem se se stringama ani moc nesetkal.

[Radovan]

Ano, dneska určitě. V minulosti to mohlo být úplně jinak: http://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html

[pc2005]

Aha tak to pak jo, já právě pracoval jen s turbo/borland pascalem.

[Grunt]

Zkrátka C je svázáno s moderními procesory a jejich sadou instrukcí. Když C nepomůže procesor, tak to moc dobře nedopadá. Je to vlastně unikát: Programovací jazyk, který potřebuje podporu přímo od výrobců procesorů, jinak ho nelze slušně, natož efektivně implementovat.

Nechci do toho kecat soudruhu, ale tak jako upozorňoval někdo u předchozí instance, upozorním i já: Největší úspěchem PDP bylo že neběžel na vakuové elektronce, ale na trandíkách naskládaných na vyjímatelných kartách (žádná integrovaná polovodičová součástka; Unit se jmenuje CPU protože to bylo implementované v celé té skříni s kolečkama zespodu aby se to dalo za použití tlačné síly dvou obvyklých soudruhů přesouvat po místnosti) a feritové paměti. Přesto na to někdo napsal nejen překladač, ale i operační systém který v podstatě používáme dodnes. Takže asi tak.

[Miloslav Ponkrác]

Nechci ti do toho kecat soudruhu, ale nemluvíš tak trochu z cesty?

Představ si, soudruhu, že překladače i operační systémy někdo napsal dokonce i na daleko starší a horší obludy než na PDP-11. A třeba takový FORTRAN se používá dodnes.

Čekám, kdy ti soudruhu hrábne docela, a budeš mi tu vyjmenovávat třeba průměry ložisek v kolečkách PDP a konkrétní typy použítých tranzistorů - nicméně je to hodně off topic, soudruhu.

[Grunt]

No nějak mi nesedí ten výrok:

Zkrátka C je svázáno s moderními procesory a jejich sadou instrukcí. Když C nepomůže procesor, tak to moc dobře nedopadá.

to je prostě směšné. Vždyť to bylo psané na něco co ani za procesor tak jako ho známe dnes považovat nemůžeme.

A třeba takový FORTRAN se používá dodnes.

No to i BASIC pokud je člověk odkázán na produkty Microsoftu. Dokazuje to něco konkrétního?

Nechci ti do toho kecat soudruhu, ale nemluvíš tak trochu z cesty?

Já, sure.

[Miloslav Ponkrác]

"Dokazuje to něco konkrétního?"

Že šňupete kvalitní matroš. Protože není jasné, proč jste na můj příspěvek reagoval ani na co jste chtěl (bohužel zapomněl) v mém příspěvku na něco konkrétního reagovat.

Ale klidně si tripujte dál podobnými výlevy. Já tedy nebudu rušit vaše kruhy.

[Grunt]

Že by zase můj milý anonymní osobní trol? Jaká nádhera jednoho mít.

[Miloslav Ponkrác]

Podívejte se na inkonzistenci toho co jste vyplodil jako reakci na mě. Začal jste trolovat, nazývat soudruhy, a vlastně ani netušíte co píšete. Až zítra vystřízlivíte, budete se nejspíše divit. A tím reakce na vás, soudruhu, končí.

[Grunt]

Takže jako odhaduju dobře že můj osobní trol který mě má celou dobu tak strašně rád je vlastně nepřihlášený Ponkrác? ehm?

[Radovan]

Tady je řeč o PDP-11, a ten už trandíky neznal. Frčel na TTL: http://retrotechnology.com/pdp11/exhibit/DR11C.jpg

[Grunt]

Ok, v tom případě omluva. I tak je do diskrétní elektronická součástka.

[Miloslav Ponkrác]

Takže jsem to pochopil správně, že by to Grunt neměl pít už ani ředěné.

[Grunt]

Ne, správně by si to měl pochopit tak že by ses měl jít konečně vycpat trole.

[Miloslav Ponkrác]

Jsem rád, že jsem pochopil, že poučuješ lidi o tom, o čem víš kulové. Ale soudruhování ti šlo.

[Grunt]

Jsem rád, že jsem pochopil, že poučuješ lidi o tom, o čem víš kulové.

Ok, očividně máme něco společného

Ale soudruhování ti šlo.

A v čempak je problém?

[Grunt]

Tak ještě oprava: PDP-11 neběžel na žádné TTL flip chipu, ale MCP-1600. Takže vlastně jo, moderní mikroprocesor akorát v několika součástkách.

[Miloslav Ponkrác]

Nezapomeň ovšem poučovat lidi, že jsi chytřejší, a zvát je u toho soudruhy:

"... upozorním i já: Největší úspěchem PDP bylo že neběžel na vakuové elektronce, ale na trandíkách naskládaných na vyjímatelných kartách (žádná integrovaná polovodičová součástka; Unit se jmenuje CPU protože to bylo implementované v celé té skříni s kolečkama zespodu aby se to dalo za použití tlačné síly dvou obvyklých"

[Grunt]

V klidu, nezapomenu.

[Radovan]

Vývoj šel strašně rychle, ještě později to narvali celé do jednoho čipu LSI-11, na ten koupili licenci Rusové a dávali to i do kalkulaček: Elektronika MK-85

[pc2005]

Kdyby se C nepřisálo na unix, který vlastně požadavky na procesory zglajchšaltoval, tak by se C nejspíše neprosadilo vůbec a zaniklo by postupně jako slepá větev. ... Céčko nelze efektivně implementovat tam, kde je málo registrů, není podpořena intenzivní práce se zásobníkem a rychlé ukládání/obnovování registrů.

No hele, nevím nevím jak bych pařil minecraft na lispovém stroji nebo ve forthu.

[Gilhad]

Asi uplne stejne, pokud by bylo stejne GUI. A pokud by ten stroj v HW podporoval lisp, nebo forth (coz neni zas takovy problem), tak by to mohlo behat i stejne rychle

[pc2005]

Ale zase pokud bude muset lisp nebo forth implementovat vektorové jednotky, aby utáhl výpočty ve 3D celulárním stroji, tak jsme zase u mnoharegistrové C-friendly architektury.

[Gilhad]

Tim si zase nejsem tak zcela jist. Vektorove jednotky muzou byt IMHO resene i mapovanou pameti a specializovanym koprocesorem (ci jinym zpusobem), ktery nemusi na nich umoznovat vse, co by C chtelo od registru.

C se dost vyvyjelo podle stavajiho HW a naopak vyvoj HW sel docela Ccku na ruku. Pokud by se prosadil jiny jazyk a jina paradigmata, mohl by byt vysledny procesor staven zcela jinak a nikoli nutne zpusobem pro C vyhodnym (respektive vyhodnejsim pro C nez pro onen jiny jazyk).

[pc2005]

Může být, určitě bych ale takovou architekturu chtěl vidět .

[Jendа]

Tak třeba architektury s mesh/grid pamětí jako Parallela. Ale možná že i na využití dnešních GPU by se hodil nějaký jazyk s vestavěným něčím jako mapreduce kde se může ještě víc ovlivňovat tok dat - zejména protože přesvědčit dneska program a programátory aby to na ten akcelerátor offloadovali je „něco extra“ co se dělá jenom když je to fakt nutně potřeba. Kdyby byl SW napsán víc v takovýchto jazycích, tak by to možná šlo dělat automaticky (jenom teoretizuju). Related: Von Neumann bottleneck.

[pc2005]

Tak třeba architektury s mesh/grid pamětí jako Parallela.

V každém tom uzlu je ale registrová architektura epiphany. To jsou pořád C-friendly procesory.

BTW podpora mesh/grid interconnectu je poměrně stará, zajímavá ilustrace je v transputerech. Ten používal jazyk occam, ale to ho taky prý zabilo (špatná podpora C).

[Jendа]

(se podívej i na ty 20 let staré SIMDy - překladač musí furt řešit jestli to může autovektorizovat, protože pointry defaultně aliasují, a programátor musí explicitně říct, že garantuje, že nebudou, a krkolomně vysvětlovat počáteční podmínky a invarianty - nešlo by tohle řešit nějak lépe?)

[Gilhad]

Jeden takovy si stavim doma, ale to je projekt na dlouhe zimni vecery, spoustu veceru a spoustu zim :)

Jinak takove FPGA ( viz treba https://fpga.cz/ ) kam si muzes naprogramovat a prelozit procesor optimalizovany na konkretni ulohu neni zrovna apriori platforma, pro kterou by Ccko bylo byl optimalni jazyk. Spis se tam pouziva jazyk VHDL ( https://vhdl.cz/ ), ktery se od Ccka znacne lisi.

Ale da se na tom (jako specialni pripad) naprogramovat i ten Z80, nebo 6502 nebo i neco silnejsiho ...

A to je technologie, ktera se dnes bezne pouziva, ale nikoli jako hlavni CPU pro domaci pocitace.

IMHO se kdysi delaly procesory specialne pro FORTH a specialne pro LISP, jen nedosly velkeho rozsireni - ale udelat procesor (a architekturu), ktery registry nema vubec, RAM jen pro program a dva zasobniky (pro data a stack) neni zase takovy problem (ALU=vypocty jedou nad vrcholkem datoveho zasobniku). FORTH ti na vesele tom pobezi. Ccko to asi moc neoceni.

[pc2005]

Jinak takove FPGA ( viz treba https://fpga.cz/ ) kam si muzes naprogramovat a prelozit procesor optimalizovany na konkretni ulohu neni zrovna apriori platforma, pro kterou by Ccko bylo byl optimalni jazyk.

To mě přijde už moc mimo definici turingovsky univerzálního stroje. Každopádně vivado HLS umí syntetizovat hardware i z C zdrojáku a intel/altera nějak vyvíjeli opencl (což je vlastně taky +- C-like jazyk) překladač.

Ccko to asi moc neoceni.

Jo pointery budou mít na zásobníkovém procesoru problém. BTW jak bys v té své architektuře naprogramoval Game of life?

[Gilhad]

No, pokud se na tom da turingovsky stroj naprogramovat (napr existujici implementace Z80 + urcite se da pridat podpora pro externi RAM a ctecku pasky) tak bych to za turingovsky stroj byl ochoten povazovat. V ciste teoretickem slova smyslu.

Na te moji architekture je hlavni RAM 64kB, a zakladni instrukce, vcetne volani podprogramu, takze by to slo - s omezenou herni plochou ofc. Dokonce bych mohl celou herni plochu drzet v registrech

Nemluve o tom, ze premyslim o rade dalsich podporovanych periferii, kdyz to nepujde jednoduse z integracu, nemam moralni zabrany si neco naemulovat prez Arduina a prilehle site. (teda hlavne I/O na dotykovou obrazovku a klavesnici, I2C, Serial a podobne periferie, ktere nemusi byt soucasti vlastniho "procesoru" ale jen trapne povesene na sbernici, nebo mapovane nekam do pameti, pripadne do "alternativni pameti pro mapovana zarizeni", kam by psala jina (lec obdobna) sada instrukci, nez pro zapis do pameti - takze na sbenici by byla RAM+jeji radic, ROM+jeji radic a MapovanaZarizeni+jejich radic, ovladalo by se to vsechno v podstate stejne

LDA 13, 23 ; nacte registr[13] z RAM[33] LDO 13, 23 ; nacte registr[13] z ROM[33] LDX 13, 23 ; nacte registr[13] z eXternalDevice[33]

na ridici sbernici probehnou stejne signaly, jen jednou bude enable pro RAM, podruhe pro ROM a potreti pro radic mapovanych zarizeni

---

Na ciste FORTH-like CPU bych asi spis dal ty datove zasobniky dva, na vedlesi bych vyskladal celou matici po radcich, na hlavnim pracoval a prubezne si prelejval v vedlejsiho casti matice do hlavniho a zase zpet. Napriklad.

---

[snajpa]

Mam jinak v Bejse nejakych 20ks AT16V8B v PDIPu a 20ks v SOICu, klidne ti je na to rad prenecham. K puvodnimu use-case se to nakonec nehodilo, tak zustaly lezet. Akorat teda ta "toolchaina" je Windowsova hnusna binarka, ale tusim, ze to chodilo i pod Wine. Je to v Brne ready k vyzvednuti za odvoz.

[pc2005]

GAL/PAL se dá programovat ručně přímo v JEDEC (hexdump) souboru. A jestli má ten atmel kompatibilní rozložení fuses, tak jde použít nejspíš libovolnej abel syntetizátor pro 16V8 typy (anebo ručně přes K-mapy :-P).

Doufám, že tohle od atmelu, nemá hnusný programovací algoritmy, kde je potřeba pulzovat 20V apod. jako u mého klasického GALu od lattice. Nejlepší programátor, co si pamatuju byl galblaster, co to programoval přes LPT. Akorát měl nevýhodu, že byl pro win3.11 a v emulátoru měl moc velkej jitter a obvod to občas nenaprogramovalo správně.

[snajpa]

Programator bych k tomu mel, neco cinskyho do USBcka - ale toho by mi bylo lito, jelikoz umi i PICy, AVRka a EEPROMky, tak ten kdyztak jenom zapujcim na par mesicu, kdyby me chtel nekdo tech GALu zbavit na neco edukativne uzitecnyho. S kazdym dalsim tydnem u mne strasne klesa pravdepodobnost, ze na ne nekdy jeste sahnu, 5V IO uz v podstate v nicem, co mne zajima, davno neni - a uz je to poslabsi i s tim aspon 5V “tolerant”; ted spis potkavam uz ten samy problem s 3v3. Ale ten programator se jeste jednou za sto let hodi (i kdyz spis ze zvedavosti, nez produkcne).

[pc2005]

Jo já si právě sehnal CPLD XC9574, na rozdíl od GALu to má normálně JTAG a bylo to podporovaný i poměrně novejma verzema Xilinx ISE. Ale i tak to už v té době bylo dost starý. Low voltage verze tuším 3.3V umí a hlavně je to nejspíš poslední CPLD, co se dělala do PLCC, takže přes vhodnej socket se dá napájet do 2.54mm rastrového prototypového PCB.

[Gilhad]

Docela by me to vyhledove zajimalo, je spousta obvodu, ktere by se takhle daly sikovne postavit :) Jen nevim, kdy se k tomu dostanu.

Pisu ti mail.

[pc2005]

No, pokud se na tom da turingovsky stroj naprogramovat (napr existujici implementace Z80 + urcite se da pridat podpora pro externi RAM a ctecku pasky) tak bych to za turingovsky stroj byl ochoten povazovat.

Na takovou architekturu už zase Céčko půjde, jen by musel někdo pracně napsat backend pro GCC/LLVM nebo vymyslet toolchain, co bude ty backendy automaticky generovat z VHDL popisu.

[Gilhad]

A nebo mit to Ccko "interpretovane" - ze by na FPGA bezel "C interpret", ktery by realizoval registrovaty, pointrovaty pocitac a Ccko prelozene do bytekodu by to proste bralo jako data a interpretovalo/emulovalo ten vypocet. Cili backend by byl spis jeden (nebo par) ve smyslu JVM pardon CVM (C Virtual Machine) a ten by zpracoval predprelozene soubory *.car (C archive) :)

[Radovan]

Aneb "Všechno je BASIC!" :-P

[pc2005]

Na ciste FORTH-like CPU bych asi spis dal ty datove zasobniky dva, na vedlesi bych vyskladal celou matici po radcich, na hlavnim pracoval a prubezne si prelejval v vedlejsiho casti matice do hlavniho a zase zpet. Napriklad.

Nebylo by to strašně pomalý? Že bys musel načítat i buňky, který se měnit nebudou (i v dalekém okolí není aktivní buňka).

[Gilhad]

Tak zalezelo by, jake instrukce bych mel k dispozici (treba nahlizeni do nizsich casti zasobniku a tak) a taky by sel urcite nejak vylepsit ten algoritmus (co ja vim, mit to jako ridkou matici a ukladat jen aktivni bunky treba).

Nicmene jako proof of concept, ze to vubec resit jde mi to staci. Jak to resit optimalne je neco zcela jineho a zda resit GoL na FORTHu je dalsi otazka, FORTH je vyhodnejsi pro jine typy uloh.

A pokud bych stavel nejake komplexni zarizeni (lunochod, hvezdu smrti ...) tak bych urcite pouzil vic ruznych architektur, ruznych pro ruzne moduly a ucely. Ono i pro robotka, co chci postavit, aby jen tak jezdil a nenarazel a ruzne reagoval, tak uvazuju o vnitrni strukture na bazi site, kde bude hlavni mozek, zvlast budou senzory, zvlast reflexy (ochrana pred nadproudem, zablokovanim pohonu, prehrivanim, podpetim ..), zvlast komunikace (dalkove rizeni prez kabel, infra (TV ovladac), mozna wifi) ... a tyhle moduly budou komunikovat uvnitr po siti. Vetsinou bude srdcem nejake to Arduino (protoze je to nejjednodusi, i kdyz casto overkill), ale klidne casem pribude nejake RPi jako frontalni mozek pro strategicke mysleni, reseni bludist a tak na jedne strane a na strane druhe tam bude spousta drobne elektroniky, kde par integracu nebo tranzistoru bleskove a nepodminene zabrani nejhorsimu, nebo prevedou nejake spatne pochopitelna data na neco citelnejsiho (proud na I2C packety a tak)

Takze mozna se tam casem taky objevi i jine architektury modulu (uz takhle jsem vyjmenoval aspon 3 ruzne, tak FORTH jako 4 uz neni tak velky rozdil)

[Radovan]

Nic z toho Hlenka nemá, přesto si pamatuje, vnímá čas, umí komunikovat v hejnu, a bludiště řeší úspěšněji než většina lidí!

[pc2005]

Tak zalezelo by, jake instrukce bych mel k dispozici (treba nahlizeni do nizsich casti zasobniku a tak)

To by už se nebezpečně blížilo pointerům .

taky by sel urcite nejak vylepsit ten algoritmus (co ja vim, mit to jako ridkou matici a ukladat jen aktivni bunky treba).

Vida to je dobrej nápad. I když teda pro 3D celulární automat bych to implementovat nechtěl .

Jak to resit optimalne je neco zcela jineho a zda resit GoL na FORTHu je dalsi otazka, FORTH je vyhodnejsi pro jine typy uloh.

Njn, jenže na začátku vlákna šlo o to, že by nevznikl unix a architektury jdoucí tomu unixu na ruku.

[Tom.š Ze.le.in]

Co bunka automatu, to jednoduchy Forth CPU, ktere vidi sousedy. Zrovna tady mi to prijde jako prirozene reseni. Otazka je pak vizualizace, ale pokud jsme v alternativnim vesmiru, tak to CPU je v monitoru a ovlada svuj pixel.

[pc2005]

Jo to by šlo, ale to by těch nodů muselo bejt teda pěkně hodně .

[Tom.š Ze.le.in]

F21 (ktera neni nejmensi} - transistor count 15000, vcetne nejakych periferii. Soucasne Intely od oka 1e9, z toho se par nodu postavit da. A asi by vznikly nejake triky aby jedna bunka toho pocitala vic.

[Gilhad]

Pokud by slo jen o Game of Life, tak klidne ten node muze obsahovat plno bunek, vzdy dost vzdalenych, aby se navzajem neovlivnovaly v jednom kroku a postupne je projit (a jejich sousedy), takze pro vypocet by stacilo nejakych 9 nodu s HW sbernicema mezi sebou a zasobnikem na prislusny pocet pixelu a odkazu s tim, ze kazdy nod by dokazal menit "frame" na zasobniku podle potreby (podle toho, ktery pixel zrovna pocita) a protoze vypoctova narocnost je dana (a celkem mala), tak by se spousta toho dalo optimalizovat uz primo v HW :)

[pc2005]

Kruci předběhl jsi mě o 1 minutu :-P

[pc2005]

Jj já o CPU per pixel taky uvažoval, když jsem studoval, jak fungoval CM-1.

Ono by asi stačilo vzít 3x3 blok a postupně do něj cpát stavový prostor automatu. Ale to by už vlastně bylo nezávislý na té samotné architektuře CPU, v uzlu by stačilo mít nějakou hloupou jednotku, co resolvuje ten GoL stav.

[Gilhad]

Jo, vzniklo by asi neco jineho. Ale IMHO by od urcite urovne abstrakce to mohlo byt docela srovnatelne (jako webove prohlizece uz moc s HW/C nesouvisi a dokonce i spousta commandline veci neni zase tak brutalne svazana, ze by na jine architekture nevzniklo neco radove podobneho (pravda mista bashe by byl lisp, nebo forth ale myslenka razeni programu za sebe do skupin (pipy, filtry...) by tu byla porad, jen s trochu jinou syntaxi)

[Tom.š Ze.le.in]

K vidění je třeba Connection Machine pro Lisp, známá z Feynmanových memoárů, nebo GreenArrays pro Forth, originál od Chucka Moora. Spadá to do toho?

[pc2005]

Rozhodně to spadá do té definice od Ponkráce. Ale nedokážu si představit, jak by v tom byl ten minecraft implementovanej, aby neběžel 1 frame za "hodně dlouho".

[Pavel Křivánek]

Uvádět Forth jako extrémní příklad není zrovna šťastné. Forth náhodný přístup do RAM používá, ty procesory "pouze" optimalizovaly intenzivní použití zásobníků. Ostatně Minecraft je v Javě, což je také virtuální stroj postavený na práci se zásobníkem.

[pc2005]

Hmm špatnej příklad teda :-/.

[Martin Mareš]

To je s prominutím naprostá hloupost. Především není v podstatě žádný rozdíl, jestli překládáte Pascal nebo Céčko. Více registrů by se jistě hodilo, ale ona taková 8086 na tom také není nijak skvěle a v Céčku se na běžně programovalo. Z dalších vlastností procesorů je zajímavé mít adresní mód s relativní adresací (bázový registr + offset), ovšem ten na Z80 najdete.

[pc2005]

Jo mě taky přišlo, že má Z80 registrů kotel (dokonce ty "alternate"). Nevím jaký je pro Ponkráce kritický limit.

[Gilhad]

No, Premyslim o stavbe vlastniho procesoru a vychazi mi, ze tam asi budu mit (podle verze a architektury) 8/16/32 tisic registru a minimalne dva nezavisle HW zasobniky ... s tim, ze se to da postavit doma "na kolene". Z80 se temto limitum ani radove neblizi :)

[snajpa]

Jakoze spis nez nacpat tranzistory do kesi, radsi vic registru? Ten vysoky pocet je ve stinovych registrech pro multitasking, nebo mas nejak vyresenej kontext switch pro tisice pracovnich registru? Zajimava myslenka, rozved to prosim

[Gilhad]

Stavim to z integracu a protoze puvodne objednana pamet nejak bloudila a nebylo jasne, zda vubec dojde, nasel jsem jinde a levneji pamet jinou, ale ta byla v paru. No nakonec dosly obe zasilky.

Mit jenom jeden registr (+jeden implicitni) mi prislo malo, dratovat tam prepinani nekolika takovych pro pristup k ALU je spousta prace navic (a zisk nic moc), takze proste misto svaba s pameti 8bit tam dam svaba s pameti 32KB a svaba, co si zapamatuje adresu.

Casem mozna i nejakou jednoduchou logiku pro kratsi instrukce pro pristup k mensi oblasti a pocatek te oblasti bude dan registrem pro offset registru, takze by to mohlo fungovat jako zasobnik pri volani funkci -

Parametry dostanu v prvnich X registrech dalsich Y pouziju pro lokalni promenne a pri volani dalsi funkce dam jeji parametry do registru (X+Y)+1..(X+Y)+X2 ... a bude CALL addr, Roffset kde Roffset bude (X+Y) - odswapuju svoje registry a dalsi funkce ma parametry v registrech v prvnich X2 registrech, vysledek vraci v prvnich nekolika registrech (podle delky) RETURN proste vyzvedne navratovou adresu a Roffset o ktery snizi pointer na registry a volajici funkce ma vysledek v registrech (X+Y)+1 ...

Zasobnik asi taky bude realizovany zvlastni pameti a jeste planuju datovy zasobnik pro FORTH-like jazyky, kde si funkce budou moct ukladat/predavat parametry bez ohledu na hranice, proste PUSHD a POPD, takze treba funkce sezere z datoveho zasobniku ctyri hodnoty, prida dve a vrati se, volajici funkce prida jeden a zavola jinou funkci, co vyzvedne pet a prida dve a tak dal ..

Jasne ze na PC to jde realizovat jako nekolik datovych oblasti a v kazde mit zasobnikove struktury, ale tady pujde o ruzne typy pameti a proste se navzajem neprepisou a pujde HW kontrolovat preteceni (out of memory type XXX)

[Gilhad]

(Proto taky o kus vys mluvim o jinych typech procesoru, co muzou sice umoznovat Ccko, ale byt treba pro FORTH vyrazne lepsi. Nebo pro jine jazyky. Konec koncu jsou esotericke jazyky, co si vystaci s jedinou instrukci a lze postavit procesor jim primo na miru a preklad Cckoveho programu pro takovyto procesor asi bude hodne neefektivni v porovnani s programem psanem primo v jazyce procesoru. Ale v kazdem turingovsky kompletnim jazyce asi jde napsat emulator stroje, na kterem Ccko (nejak) pobezi.)

A proc to delam? Hmm ... protoze muzu a chci? Me to jako argument staci.

Jinak podle soucastek (vetsina na 20MHz) to vypada, ze takt by mohl byt teoreticky tak v radu jednotek MHz a asi 2-7 taktu na instrukci podle typu. Realny takt (kde to pobezi stabilne) asi bude kvuli dratovani jeste o rad ci dva nizsi. Ale zato tam bude spousta LED a LCD panelu ukazujicich hodnoty na vyznamnych mistech (PC, bus, nektere registry ...)

[pc2005]

Ale v kazdem turingovsky kompletnim jazyce asi jde napsat emulator stroje, na kterem Ccko (nejak) pobezi.

mírně OT?: Jj to bude jádro pudla diskuze, ten ZX spectrum má tak malou RAM, že naráží na limity turingovsky univerzálního stroje mnohem víc než něco, co má aspoň 640kB RAM (až nekonečno).

[Gilhad]

no to spis byla odbocka k tomu podvlaknu vys, jak by slo hrat mincraft na lispovem/forthovem HW stroji - stejne, GUI by se nelisilo - ale to by ten stroj musel mit spoustu registru a tedy byt vhodny pro C - navrat do tohoto vlakna : nemusel, muze mit HW podporujici jen jednu instrukci, nebo muze byt ryze FORTH optimalizovany a pro prime C nevhodny (ALE protoze turingovsky uplny, tak v nem lze namodelovat cosi, na cem by C bezelo (za cenu emulace), ovsem tim padem mnohem pomaleji, nez nativni kod, takze Minecraft by se na tom hral lip v nativni implementaci, nez v Ccku s vektorovymi jednotkami v emulaci)

Tedy samozrejme by slo naemulovat i treba Core2, nejen Z80, jen je otazka rychlosti takove emulace (kde by bezel minecraft v C) oproti nativni implementaci (kde by bezel mincraft v cemsi obskurnim, pro dane HW nativnim).

[pc2005]

Já ten minecraft použil jako hyperbolu. Protože mě přijde, že řada úloh je na zásobníkové architektuře (non C-friendly architektury jak psal Ponkrác) strašně neefektivní (oproti něčemu, co umí random access, třeba přes pointery) a že nepůjde udělat jiné ekvivalentně rychlé řešení v paradigmatu té architektury.

[Gilhad]

Tak jasne. Zase je spousta veci, na ktere C neefektivni a nativni reseni je vykonove zcela jinde.

Ostatne to puvodni C taky nejak moc nepocitalo s mnoha procesorovymi pocitaci, kde na kazdem procesoru jede spousta vlaken "paralelne" a spousta veci se muze dit "nejak na pozadi" at uz jsou to ruzne vektorove instrukce, DMA, vetci zapojeni GPU a tak ...

Nicmene v alternatyivnim vesmiru, kde by se prosadil FORTH jako hlavni a urcujici programovaci jazyk a smer by asi taky prosly jak procesory, tak jazyk radou vyvojovych etap, kde by se vylepsovaly a pridavaly veci pro zpracovani obtiznych, lec potrebnych, uloh (jak nove prvky jazyka, tak nove HW "koprocesory" a jine mechanizmy).

---

Pokud bych chtel takovehle veci resit nejak jednoduse, klidne muzu udelat I/O instrukci, ktera bude pristupovat k "disku" po sektorech (ci blocich souboru) a mit nektere disky/soubory namapovane v pameti (ci na SSD pripojenem primo ke sbernici nebo cokoli jineho). Pripadne muzu mit i "DMA" instrukce pro vypocty nad takovymito "soubory" / pametovymi bloky (obdoba vektorovych instrukci v soucasnych procesorech, nebo offloadu vypoctu matic na GPU).

[snajpa]

Tak na otazku, proc to delas, odpoved, ze te to bavi, je ta nejlepsi mozna, rekl bych Ale to jsem se ani nemusel ptat, protoze to je videt. Na cem/jak to dratujes? Univerzalni plosnaky a hromada dratu? Nebo mas kde leptat/frezovat? (Nad implementaci napr. na ice40+IceStorm jsi premejslel?)

[snajpa]

Ale jinak teda, ne ze bych ti chtel kazit radost, to si nenech - ale musim rict, ze navrhy vlastni architektury, ktery se opiraj o D/SRAMku, ktera je nekolikrat rychlejsi, nez zbytek dratovanyho obvodu, mi neprijdou moc legit - je to dobry asi na trochu lepsi pochopeni, jak procesor funguje v porovnani se ziranim do schematu neceho uz hotovyho, na druhou stranu, co pise pc2005 - gate propagation delay a naskladani pipeline za sebou je prave to umeni, v cem tkvi navrh CPU - tam nemas sanci se oprit centralne o jednu pamet, ktera ti vzdycky stiha a je ji dost.

[Gilhad]

Puvodni inspiraci mi bylo tohle a to si asi postavim jako verzi 1, ciste proto, ze to jde, a jako podklad pro experimenty pro dalsi kroky

https://www.youtube.com/channel/UCS0N5baNlQWJCUrhCEo8WlA

(Problem je, ze tam pouzita RAM 16x8bit je uz prakticky nesehnatelna a draha, takze tam dam neco modernejsiho a v prvni fazi z toho pouziju prvnich 16 bytu. V dalsi fazi bud proste zdvojim sbernici na 16 bit a pouziju 1024 bytu, nebo pouziju 1,2 a vice bytove instrukce ( instrukce, data) (coz by slo i tady, jen by to chtelo vic kroku na instrukci)) a nebo oboji )

Dalsi krok je (az tohle bude chodit) prejit na univerzalni desky a ovijene/letovane spoje, kde ta kabelova smrst bude kratsi a ucesanejsi a nebude tolik zatizena kapacitou, indukcnosti a prechodovymi odpory breadboardu.

Tam uz by to byla rozhodne 16 bit architektura a patrne optimalizovana ridici sbernice (takze by nemel kazdy modul jeden drat, ale soucasti ridiciho slova by bylo urceni zdroje a cile adresou modulu jako binarnim cislem a moduly by ty adresy dekodovaly (napr 3 bity = 8 moznych modulu) a na jedne desce by tech modulu bylo vic, takze demodulace by se provadela pro celou desku jednim integracem, odkud uz by sly jednotlive draty primo k modulum.

Spojene stosovatelnymi konektory s 40pinovou sbernici (16b data+22b ridici+PWR+GND). A celni deska by mela I/O modul patrne osazeny prave nejakym(i) arduinem(i), nebo STM a monitorek a klavesnici a konektory a tak ... I2C + Serial urcite, ale klidne i USB a dalsi ..

A pro nektere veci si pripadne navrhnu plosnak a vyleptam. Par uspesnych pokusu s SMD Atmega328 uz mi chodi, takze si celkem verim. Jen to holt bude trvat dlouho, pokud mi vydrzi zajem.

[pc2005]

Hlavně to nedělej z tranzistorů, jinak si budeš muset alokovat celou skříň jen pro registrovou banku (megaprocessor).

RAM 16x8bit je uz prakticky nesehnatelna a draha

Nestačí 16x octal D flipflop? Ten si můžeš navíc zapojit jak se ti zlíbí. A nebo použít výstupní makrocell jako jednobitovou RAM z nějakého CPLD (řada XC95144 by mohla možná dát těch 128bitů a zbytek použít jako dekodér).

[Gilhad]

No, tech 16x8 je v originalu, kdyz je to nesehnatelne a drahe, tak musim resit nejakou nahradu a protoze tam uz stejne byl ten skok (hradla - RAM), tak jsem nechtel moc chipu navic a radsi se kouknul po jinych RAM a shledal, ze jsou levne, jednoduche a velke.

A ze stejne 16B je malo a mam spoustu napadu na rozsireni, tak proc nezacit vymenou modulu RAM za jiny, se stejnym rozhranim, kam bude stacit pridat zdvojeni pro praci se sbernici, abych ziskal mnohem vetsi RAM v dalsi verzi - stejne jsem uz byl rozhodnuty jit vyhledove do 16B sbernice a viceslovnych instrukci. A HW datoveho zasobniku a tak, kdyz uz budu delat pokrocilejsi verzi.

Navic jak jsem tam cetl ty diskuze, tak par problemu v tom navrhu bylo stejne (pouzival konkretni radu integracu, kde to zrovna prochazelo, ale ta uz mi prisla jako zastarala a spatne dostupna - a nebyl jsem sam - a s novejsima radama nektere ty triky neprochazely (jako pichnout LED bez odporu do vystupu proti zemi a ocekavat, ze protoze to vystup neutahne, tak LED neshori a nasledujici vstup naopak furt bude schopny vzit 1 kdyz mu to LED stahne na svoje napeti - v nove verzi neplatil ani jeden z techto predpokladu) (nebo dat na hodiny u RAM jednoduse RC clen ktery ji udela potrebny pulz - v nove rade to rozhodilo hodiny celemu stroji) (nebo dat vystup z nekolika EEPROM primo na sbernice - v nove rade bylo trochu jine casovani a EEPROM mohly projit nekolika stavy mezi pocatecni a cilovou hodnotou a moduly na to stihaly zareagovat, takze na vystupu obcas byly nesmysly) (nebo nepripojeny vstup je log. 1 - taky uz neplati) ... a ten vyklad tam tohle nezminoval, protoze autorovi to proste chodilo, stejne jako kdyz autor mluvil o hodinach, tak to znelo, jako by tam byly jen jedny s nabeznou hranou, ale ve skutecnosti tam byly aspon 3 faze (nabezna hrana, sestupna hrana a pak samostatna faze po jedne z tech hran, kdy se kaskada s EEPROM stihla preklopit a tak doslo k hrane na ridicich linkach mimo hrany hodin

Takze jsem se rozhodl pouzit snadno a levne sehnatelnou radu 74HCxxx a tyhle veci si zdokumentovat, poresit ciste (EEPROMky oddelit od ridici sbernice jako kazdy jiny jiny modul od datove a poslat tam az ustalenou hodnotu, LEDky pouzit zapojene s tranzistorem kvuli odberu a kvalite nabeznych hran, RAM resit zcela jinak a pripadne pulzy resit minimalne oddelenim od prislusne linky prez tranzistor/hradlo/jiny clen, napajeci napeti rozvest tlustymi draty vedle a pripojit kazdy breadboard extra a na kazdem z nich mit fitrovaci kondiky (v dalsi verzi na kazdem integraci) a tak dal a tak dal - proste nespolehat na to, ze s originalni soucastkami od originalniho vyrobce v originalnim zapojeni a radou dalsich nevyslovenych podminek to pobezi a radsi si to postavit tak, ze to pobezi prakticky s cimkoli, co cinan smetl na dvore po odjezdu nakladaku a nevypadalo to moc rozbite. S tim, ze hodnoty odporu a kondiku jsou "asi tak radove spravne" a vic od nich cekat nelze. Ze breadboardy jsou lacine kopie a maji vsemozne nesvary. Ze to nebudu provozovat mezi 0.01 a 2 Hz, ale budu chtit jit vyrazne vys i za cenu, ze blikani LED nebudu stihat cist. atd atd atd ...

No a to v podstate znamenalo to nejen okopcit, ale hlavne pochopit a doladit do podoby, kdy to nebude chodit protoze se hodnoty "zrovna nahodou sesly, neb to tak vyrobce zamyslel", ale protoze "tohle musi byt driv, tohle potom a mezi tim musi byt dost casu, aby se to spolehlive preklopilo, napeti nestaci okolo meznich hodnot stability, ale radsi ode zdi ke zdi cim bliz k 0V a 5V, tim lip, zdroj predimenzovany na nasobek maximalniho odberu a naopak ztraty mezi integraci pokud mozno minimalni". Takze pouziti velke RAM misto flipflopu mi neprijde jako hereze, ale spis jako priprava na dalsi krok :)

[Radovan]

A tohle jsi viděl? A CPU made of EPROMs

Na tomhle dokonce běží jeho vlastní web!

[pc2005]

Heh flash čip jsem použil, když jsem potřeboval udělat mooreovskej stavovej automat. Část slova byl stav a část slova byly výstupy. Stav se přes D flipflopy vracel na nekteré adresní bity (a zbytek byly vstupy). Hodiny pro flipflopy byly 555 . Jako víceméně to fungovalo, ale bylo peklo vygenerovat image toho flash čipu. Pamatuju si, že nakonec jsem to generoval nějak divně přes regexpy v bashi (Quine–McCluskey v pascalu bych asi nedal a céčko jsem ještě dostatečně neuměl).

[pc2005]

Nebo gigatron je taky dobrej.

[Radovan]

Moc hi-tech, zkus Minivac 601

[pc2005]

To jsou relátka?

[Radovan]

Ano. A krásně cvakají

[pc2005]

Aha, to už ale radši kolečka .

[Radovan]

Tak Babbage je samozřejmě základ, ale já bych do desítkové soustav radši nešel, ta dvojková je tak akorát, možná trojková by se ještě dala...

[Pavel Křivánek]

Potěšilo mě, že ke Gigatronu nedávno zveřejnili schéma, které původně veřejně dostupné nebylo, a existuje i hezký JavaScriptový emulátor

[pc2005]

Nebylo schéma? Proboha proč, to se za něj styděli ne? Jinej důvod mě nenapadá. Zrovna u takovéhle stavebnice je trasování spojů na PCB téměr nutnost.

[Pavel Křivánek]

Ono bylo v manuálu, který k tomu člověk dostane, ale volně na webu ho neměli.

[Grunt]

Taky jsem se po tom díval jako po zábavě pro dlouhé zimní večery a popravdě mi moc dobrý nepřišel. Projekt na skládání sám o sobě perfektní, ale ten výsledek nic moc.

[pc2005]

Jo to jo i PIC v DIL pouzdře bude tak o dva řády rychlejší (však to může být až 32bit MIPS). Ale zase co bys chtěl od TTL logiky, co se musí vecpat i s video výstupem na tak malou plochu.

[Grunt]

Ta rychlost mi až tak nevadí. Ale to že se využívá procesor pro vlastní kreslení grafických dat a téměř žádná podpora z pohledu SW.

[pc2005]

Si koupíš dva, jeden bude GPU a druhej CPU . Ale ty opravdu hloupý 8-bity z historie, dělaly podobné prasárny s procesorem (DRAM refresh třeba).

[Gilhad]

Hezky :) Ja mam EEPROM jen jako dekoder mikroinstrukci (a pro OUT jako prevodnik z binaru na hexakod pro 7segmentovky)

[pc2005]

Jinak podle soucastek (vetsina na 20MHz) to vypada, ze takt by mohl byt teoreticky tak v radu jednotek MHz

Tady bych spíš počítal s Tpd (propagation delay) než s Fmax. Musíš čekat s hodinovým signálem, než se přes všechny hradla dostane i ten nejpomalejší signál na výstup.

[Gilhad]

Prave proto rikam, ze takt by mohl byt teoreticky v radu MHz - protoze propagation delay jde vetsinou tak prez 3-4 hradla s temi 20MHz (pocitano z delay) ZA SEBOU, takze se tam scitaji ty delay na radove tak 3-5 nasobek delaye jednoho chipu, cili nez to spolehlive protece a ustali se na vystupu, tak jsem na 3-5x nizsi frekvenci, cili tak 7-4 MHz, coz jsou radove jednotky MHz pro pouzitelny takt. Jen jsem to rekl prilis strucne, protoze to byl jen orientacni odhad TEORETICKE horni hranice taktu.

Ale protoze konstrukce neni na vicevrstvem plosnaku s optimalizovanymi drahami a stinenim a kvalitnimi soucastkami renomovanych vyrobcu (vcetne odporu a kondendatoru), ale spousta dratu nacpanych do pochybnych breadboardu (tedy hafo parazitnich odporu, kapacit a indukcnosti) a tazenych vedle sebe tam a zpet (dalsi indukcnosti a preslechy) a soucastky jsou ty nejlevnejsi z ciny (ackoli jsem kazdy integrac aspon zakladne otestoval na funkcnost a prosly vsechny) a odpory jsou taky z ciny s toleranci udajne 2% a kondiky jsou s toleranci 0.5-2.3 nominalni hodnoty a nejasnymi vnitrnostmi a zapojeni nema vsechny doporucene filtry a kondenzatory "co neblize napajecim pinum" a kaskady kondenzatoru u napajeni kazde rady integracu atd atd atd

Tak teoreticke maximum povazuji apriori za nedosazitelne a muj odhad jak vysoko s taktem muzu jit je tak asi 1/10 az 1/100 toho, co by ty integrace v danem zapojeni mohly podle datasheetu zvladnout.

"Presnou realnou" hodnotu zjistim tak, ze to stejne budu ozivovat krokovanim stiskem tlacitka (samozrejme bezzakmitove, debouncing ~ 0.1 sec) a sledovanim LEDek (tedy prakticky tak jeden kompletni tik hodin za 2-10 sec) a az vychytam vsechny spatne zapojene draty a jine zjevne nesmysly, tak teprve prejdu na automaticke hodiny s taktem kolem 1 sec a vizualni kontrolou prubehu a pokud toto pobezi spravne na ruznych testovacich programech, tak teprve zacnu zvysovat takt na 0.1s a kdyz to pujde stale dobre, tak to budu mit za stabilni a "taktovatelne" a pak zacnu zvysovat kmitocet prez desitky, stovky Hz a pokud to bude furt stabilni, tak postavim lepsi modul hodin a pujdu na 1 kHz, 10 kHz, 100 kHz a tak, dokud to bude davat spravne vysledky (pricemz uz se prubeh sledovat neda, jen zobrazovane vysledky) tak i vys ... az do stavu, kdy to prestane spravne vysledky davat, kvuli vnitrnimu (i vnejsimu) ruseni. Nacez jako "doporuceny provozni kmitocet" dam nejaky rozumny zlomek te hodnoty, pri ktere uz to prestalo byt stabilne spravne (coz bude celkem jist mnohem min, nez soucet propagation delays prez nejpomalejsi cesty).

No a pak se podivam osciloskopem na nektera zajimavejsi mista a uvidim, jak tam ten signal vypada, jestli jsou jen hrany sikme a kulate (cili uz to moc nevylepsim), nebo zda tam jsou nejake zakmity (a tudiz najit, kudy tam lezou a zda se daji odstranit). A nevylucuju ze dojde i na nejaky debouncing/kondiky (ktery jeste snizi teoreticke maximum, ale zajisti vetsi stabilitu a mozna zvedne tu maximalni realnou hodnotu)

(A samozrejme pokud tam budou obvody/moduly s vyrazne delsimi nominalnimi propagation delay, tak v mikrokodu bude pri jejich pouziti prislusny pocet kroku navic pro ustaleni hodnot, nebo, pokud bude detekce dokonceni instrukce, tak cekani na signal dokonceni (zejmena u modulu pro praci s externimi zarizenimi))

Ale prakticky pouzitelny kmitocet bude rozhodne mensi, nez to, co vyjde z datasheetu a budu ho muset urcit empiricky, nikoli vypoctem.

[pc2005]

Jj to já jen pro úplnost. Protože kdybys to chtěl dělat v asynchronní logice (nebo hodně jemnou pipeline), tak tam těch 20MHz možná i protlačíš, ale reakční čas to bude mít n*Tpd.

Docela by mě zajímalo jakej takt vytáhneš nakonec . Jinak jsou i superspeed diskrétní hradla, který mají Tpd pod 10ns, ale ne v DILu samozřejmě.

[Gilhad]

Tak SMD mi problem necini a pokud bych sel po vypocetnim vykonu, tak spis cestou Atmega/STM32 - RPi - klasicky pocitac - cluster

Tohle je skutecne spis hricka a "cesta sama je cil" - inspirace bezi na necem kolem 1Hz, to si jsem schopny naprogramovat v rychlejsi v Pythonu, ale nebude to tolik blikat :)

[Michal Kubeček]

To nezní, jako by byla šance, že to bude efektivnější než emulátor téhož na nějakém "normálním" procesoru. Ale jako zábava, proč ne…

[Gilhad]

Jasne, jde jen o zabavu :)

Podle tehle inspirace :)

[Grunt]

Stavim to z integracu

To jako fakt?

[pc2005]

Však si můžeš i dneska koupit stavebnici, ale předpokládam, že jeho bude komplexnější.

[Gilhad]

Jo :)

[pc2005]

Nevím jak Gilhadova, ale moje architektura by měla "registry" přímo jako slova v cache.

[Radovan]

Jo, tohle jsem chtěl napsat také.

A ještě by počet těch registrů mohl být volitelný.

[pc2005]

Jo hele to máš možná stejnou architekturu jakou chci i já . I když teda já žádné _registry_ nepotřebuju .

[Michal Kubeček]

Z dalších vlastností procesorů je zajímavé mít adresní mód s relativní adresací (bázový registr + offset), ovšem ten na Z80 najdete.

Zrovna Z80 IIRC při použití prefixu 0xdd/0xfd na instrukce pracující s [HL] místo [HL] jako argument používala [IX+d] a [IY+d]. Ale jen s osmibitovým signed d, takže praktická použitelnost pro vyšší jazyky byla dost omezená.

[pc2005]

Ona na nepoužitelnost je způsobená hlavně tím, že vyšší úlohy obvykle vyžadují minimálně u8 (například ASCII regexp), takže 8biťák nemá moc velkou rezervu (zvlášť když musí adresovat 16bit paměť). Ono kdyby většina úloh měla 4GB datový prostor, tak by stejně nestíhal ani 32bit procesor.

Z80 instrukce neznám, ale stačilo by udělat wrapper, který bude prostě přičítat n*256 ne?

[Martin Mareš]

Já vím, však proto jsem psal, že to na Z80 najdete :)

8-bitový offset na nejběžnější použití při indexování struktur naštěstí stačí.

[Michal Kubeček]

Já vím, však proto jsem psal, že to na Z80 najdete :)

Oops… opravdu tam to "ne" není. :-) Tak to se omlouvám.

8-bitový offset na nejběžnější použití při indexování struktur naštěstí stačí.

No, v kontextu doby asi ano. Dneska jsou sice větší struktury denní chleba, ale když měl celý adresní prostor 64 KB a prakticky použitelné paměti bylo tak 30-40 KB, byla měřítka trochu jiná.

[kvr]

Matně si vzpomínám, že C má snad složitější gramatiku oproti Pascal, ale už si nejem úplně jistý. Ta deklarace pointeru vs násobení se dá během parsování přeskočit a analyzovat až během sémantické analýzy.

Spíš bych viděl hlavní problém ve velikosti standardní knihovny C a Pascal - C má tunu funkcí na IO, paměť, strings, zatímco Pascal v základu kromě write a read neumí skoro nic Na embedded procesorech se proto používá běžně C, ale s jinýma (minimalistickýma) knihovnama. Předpokládám, že podobně to řešil HiSoft, bo většina funkcí z ANSI C by na tehdejších 8mi bitech postrádala smysl.

To samozřejmě není otázkou jazyka, výsledek překladu je prakticky stejný, podobně je pro oba užitečné relativní adresování, pokud oba podporují struktury (pole je ještě složitější případ, které snad x86 začala podporovat až od 80386).

[Gilhad]

Pascal je LL1 gramatika (az asi jednu vyjimku - k cemu se vaze 'else' za druhym vnorenym 'if' - vaze se k nejblizsimu aplikovatelnemu, coz se da obejit poradim vyhodnocovani) a na tu se prekladac pise celkem snadno a muze byt i jednopruchodovy,

C a zejmena C++ LL1 gramatika rozhodne neni a to ani kdyz se projede plnym preprocesorem, ktery zpracuje vsechny includy a makra a podobne.

Bez rozvinuti includu a maker to v podstate nema pouzitelnou gramatiku vubec, protoze v makru muze byt prakticky libovolny fragment kodu.

[Martin Mareš]

Především není zase tak těžké na Céčko napsat ad hoc parser, který se gramatikou neřídí.

Ale i pokud chcete stavět parser na gramatikách, není to problém, pokud zavedete typované tokeny (tokenizátor si u všech identifikátorů pamatuje, jestli to jsou jména typů nebo proměnných).

[Michal Kubeček]

pole je ještě složitější případ, které snad x86 začala podporovat až od 80386

Jestli myslíte možnost použít scaling při adresaci, tak to ale jen pro 1, 2, 4 nebo 8, tj. typicky jen pole základních typů, ne něčeho složitějšího. Nakonec to ale vždycky jde obejít tím, že si ten offset předpočítám, ale v případě, že procesor pomůže specializovanou instrukcí, je to efektivnější. Stejně jako se dá v nouzi vystačit s pár registry, ale když jich je víc, je život o hodně jednodušší.

[.]

To je zase kravina.

[Grunt]

Na HiSoft C jsem narazil nedávno, ale popravdě jsem neměl ani odvahu ho stáhnout, natožpak načíst. Ocenil bych akorát nějaký funkční kus kódu který bych si mohl přeložit. Trošičku mi uniká jak vlastně může být implementovaná standardní knihovna. Co volá třeba printf? To přímo kreslí na 16384 nebo volá nějakou rutinu z ROM?

Jinak ten editor to je katastrofa. To ani nemělo šanci. Škoda. Díky moc za c2tap a nějaké manuály. Bez toho bych ani nenašel odvahu to LOADovat.

[Miloslav Ponkrác]

ZX Spectrum má velice bohatou knihovnu podporogramů v ROM. Dokonce v ní je i koncept streamů (souborových proudů). Takže implementace printf je velice přímočará a krátká v asm.

[Pavel Křivánek]

Nějaké kusy kódu jsou v repozitáři. Malá část funkcí (jako printf, isalpha apod. je zabudovaná přímo a částečně využívá rutiny z ROM. Další funkce ze standardní knihovny se musí importovat. Některé (popsané v dokumentaci) se povalují na HISOFT_5.TAP, ale tento soubor je bohužel poškozený. Zkusím to vydolovat. Rusové k tomu prý udělali i hi-res editor.

[Grunt]

Přílohy:

• intro.png (4306 bytů)
• editor.png (2862 bytů)
• privet.txt.png (11004 bytů)

Rusové k tomu prý udělali i hi-res editor.

No, pěkný. Akorát by mě zajímalo jak se vlastně používá.

[Pavel Křivánek]

To je z obrazů těch Beta Disků? Jak se to dá dostat do nějakého emulátoru?

[Grunt]

Používám FUSE, ale jinak to samozřejmě otevře asi každý emulátor který je schopen emulovat Škorpiona ZS-256 a otevřít scl image. Ale hodně štěstí s Azbukou.

[Pavel Křivánek]

Díky za tip, už mi to běží. Pokusil jsem se dokumenty z toho disku vytáhnout (původní kódování IBM866). Z velké části se jedná o starší knihu o C. Podle toho, co jsem pochopil, o funkčně vylepšený editor se pravděpodobně nejedná, výsledek by měl být podobný tomu, jako když se použije Busyho ROM s menšími znaky.

[Grunt]

Odpověď je prostá.

Jinak na tohle je odpověď ještě prostší. Takhle se to tehdy prostě se softwarem dělalo. Někdy byl dokonce napsán v kódu vlastní loader, který se spustil a nestandardním způsobem kreslil nahrávací obrazovku a bůh ví co a teprve pak se načítal samotný kód která nebyl až tak velký když se přihlédne k tomu jak dlouho se načítá nějaká kravina na zavedení kódu. Ale že by někdo napsal LOAD "" CODE; RANDOMIZE USR, to by snad ani nikoho nenapadlo. To by nebyl produkt.

[Pavel Křivánek]

Mohli to alespoň zkrátit nahráním jen prostřední třetiny. U žádného assembleru jsem nahrávací úvodní obrazovku neviděl, ale je možné, že se ke mně dostaly až optimalizovné verze.

[Grunt]

Tou úvodní obrazovkou je myšleno co? To [y/n]?

[Pavel Křivánek]

Ano, je to standardně řešený obraz načítaný přímo do video-RAM

[Grunt]

Tak to se vynechat nedá.

[Busy]

U žádného assembleru jsem nahrávací úvodní obrazovku neviděl

Uvodny obrazok pri nahravani ma aj assembler MRS. Resp. ani nie obrazok, ale skor len take atributove logo. Urobil som to tak ze pri nahravani sa najprv nahralo do spodnej tretiny atributov logo a potom sa nahraval samotny kod programu. Logo zaberalo 256 bajtov, co v pomerne celkovej dlzke celeho MRS (cca 15kB) bolo zanedbatelne, takze celkovy cas nahravania to ani velmi nepredlzilo.

[xxxs]

mas to niekde ako tap, alebo z80 file? ja mam iba kazetu. niekde.

[Pavel Křivánek]

program, manuál

[Busy]

Vdaka za linky. Link na program je na verziu MRS08E, prave tato verzia mala pri nahravani z kazety to atributove logo. Link na manual odkazuje este na uplne povodny historicky manual pre ovela starsie verzie MRS 01-03 ktore boli releasnute v UAK Bratislava este v roku 1986.

Pokial by ste si MRS chceli vyskusat, skuste rovno poslednu verziu MRS09/2 ktoru aj s dokumentaciou najdete na tejto stranke.

[Pavel Křivánek]

Díky za odkaz. Celá ta stránka je takový malý poklad. MRS byl svého času můj nejoblíbenější assembler, především díky kvalitnímu editoru (ale Prometheus jsem tenkrát neměl příležitost zkusit). Ta ROM s 64 znaky na řádek je luxusní.

[Pavel Křivánek]

Příloha:

• hisoft-c-64.png (3813 bytů)

Dokonce i HiSoft C si s ní dobře rozumí. Viz příloha

[xxxs]

vdaka obom.

[Michal Kubeček]

Vlastní loader byl v podstatě nutností, protože na Spectru standardní příkaz LOAD nahrával program v BASICu a nespouštěl ho. Takže pokud bylo potřeba nahrát něco jiného, musel se udělat loader, který "hacknul" systém, aby se sám spustil ("autostart" - ten trik už si přesně napamatuju, ale IIRC se se loader nahrál tak, aby přepsal návratovou adresu a místo návratu z podprogramu pro podstatnou část implementace příkazu "LOAD" se spustil ten loader) a pak nahrál zbytek.

U her pak samozřejmě bylo zvykem, že loader i něco vykreslil, ale ani tam nebyl loader nějak přehnaně velký v poměru k vlastnímu programu. I kdyby nahrával celou obrazovku jako bitmapu, tak potřeboval nějakých 6 KB + 768 B, zatímco hra samotná typicky zabrala celou paměť.

[R]

LOAD nahra program v BASICu a hned ho aj spusti. Pre nahratie bez spustenia sluzi prikaz MERGE. Pre vacsinu programov a hier loader vyzeral takto:

10 LOAD "" SCREEN$
20 LOAD "" CODE
30 RANDOMIZE USR 24576

[ZX Cygnus]

Automaticky spustitelný BASIC uložíš SAVE "jméno" LINE řádek, kde řádek udává číslo od jakého řádku se program spustí.

Typicky nejjednodušší nahrávání strojáku vypadalo takto

10 CLEAR 24199: LOAD "" CODE: RANDOMIZE USR 24200

A to se dá uložit SAVE "jméno" LINE 10.

Komplikovanější basicový loader nastavoval i barvičky, příp. něco vypsal.

10 BORDER 0: PAPER 0: INK 7: CLEAR 24199: LOAD "" CODE: RANDOMIZE USR 24200

V případě potřeby ušetřit každý byte se čísla nahrazovala výrazem, který v paměti zabral o kousek míň.

Např.

10 BORDER NOT PI: PAPER NOT PI: INK VAL "7": CLEAR VAL "24199": LOAD "" CODE: RANDOMIZE USR VAL "24200"

Další komplikace nastávaly při použití různých diskových zařízení. Třeba u Betadisku bylo potřeba rezervovat víc místa pro jeho systémové proměnné a buffer na jeden 256 bytový sektor, takže se RAMTOP posouval z minimálního 24200 pro pásku na 24500 (nebo víc, byl-li zavaděč delší s více basicovými příkazy.)

Obrázek je prostě jen jeden z mnoha binárních bloků (od 16384, dlouhý 6912 bytů). Buď ho nahraješ rovnou do obrazovky, nebo někam do volné RAM, typicky ty komprimované samorozbalovací (Pressor např.).

atd... atd...

[Jindřich Makovička]

Systém se nehacknul, sejvnulo se to jednoduše pomocí SAVE "mujprogram" LINE číslo. Akorát bylo občas zvykem kód nějakým poukem lehce zprznit, aby se nedal načíst pomocí MERGE, které autostart ignorovalo.

[Michal Kubeček]

Jsem zvědav, kolik dalších lidí mi ještě napíše stejnou odpověď… Ano, spletl jsem si to s PMD-85, na kterém jsem přeci jen dělal delší dobu (a některými dalšími).

[Petr]

Na to jak často ze sebe děláte chytrého se pletete příliš často.

Grafománie nepodložená znalostmi je neštěstí. Bohužel především pro okolí.

[Michal Kubeček]

Aspoň se nestydím za své jméno, takže se každý může podívat, jak často to skutečně je.

[Vinicius]

Tak špatné to s tím C na 8bitových počítačích nebude.

S použitím překladačů jako z88dk (pro Z80) nebo CC65 (pro 6502) se dá dosáhnout dobrých výsledků. To jsou samozřejmě moderní překladače běžící na PC.

Dobové překladače tak efektivní nebyly. Bylo to doopravdy proto, že Z80 nebo 6502 jsou tak nepřátelské k C? Nebo tím, že do 64 KB RAM se pořádné vývojové prostředí založené na jazyce C a optimalizující překladač jednoduše nevejdou.

[Grunt]

No popravdě se kompiluje od pradávna. Já bych např. chtěl někdy vidět něco kompilovat třeba IBM 1401 či něco podobného, to by mohl být docela (hlasitý) zážitek.

[Radovan]

Asi takhle: Honeywell H316 FORTRAN IV impressions

[snajpa]

Jinak tohle by byla super prednaska na OpenAlt / Linux Days, zvazil bys to, prosim?

[lizbee]

thanks for sharing this news with us pittsburgh eyelash extensions

[lizbee]

cool post! lash extensions lexington ky