Fórumok
A napokban egy olyan érdekes C fordító forrása került fel a GitHub-ra, ami egy szokatlan sajátosságával emelkedik ki a szóban forgó nyelvhez készült kompilerek végtelen sorából. A SectorC különlegességét ugyanis nem az adja, hogy minden másik társánál gyorsabb kódot generál vagy hogy a legújabb nyelvi sajátosságokat is támogatja, hanem az, hogy simán elfér egy rendszerbetöltő szektorban is - ugyanis 512 bájtban is elfér.
https://xorvoid.com/sectorc.html
https://github.com/xorvoid/sectorc
Forrás:
https://prog.hu/hirek/6475/sectorc-boot-sector-c-fordito-compiler-512-bajt-kicsi
Hozzászólások
Mondjuk a 4Kn diszkek korában akár 8x akkora is lehetne már ;)
Minek, ha 512 byte is elfér, hibaellenőrzés nélkül?
A 256 byte-os x86 demókat juttatja eszembe, majd megjelent mellette egy 4k demó irány is. Pedig akkor már 640k RAM felett jártak a PC-k. :)
Egyébként szép bravúr ennyibe belepaszírozni. Bár egyéb értelme nincs.
Ehhez hasonló kis méretű fordítót egyébként még az alábbira tudok elképzelni:
- LUA - veremgép módon implementálva pici méretben lehet megvalósítani
- FORTH - lásd: https://amforth.sourceforge.net/ - 8 bites MCU-ra is készen van
Kérdés hogy hajbazer ebben fog-e találni bloatware-t.
Nem is az a kérdés hogy fog-e hanem hogy mennyit? :)
Semennyit.
A koncepció csillagos ötös és példaértékű. A honlap letisztult, nincs betöltve egyetlen JavaScript library sem, CSS-ből egy darab jól szervezett stylesheet. Mind minify-idealizmus vagy obfuszkálás nélkül. Cookie-kat sem állít be. Ahogy minden szöveges tartalmat szolgáltató honlapnak ki kéne néznie.
Sokkal jobb kérdés az, hogy fősodratúék miért húnynak szemet a nyilvánvalóan túltervezett koncepciók, a nyilvánvalóan bloated megoldások és a fél világ JS-szemétdombját behúzó bemutatóhonlapok felett. Szóval legközelebb inkább ezt a kérdést kéne feltenned, n4n3x kollégáddal együtt.
Ami nincs minify-olva, az miert nem bloat? Ugyanazt tudja, mint ami kisebb, csak plusz felesleges overheaddel.
Persze ha vissza akarod fejteni, akkor nehezebb dolgod van, de alapvetoen a bongeszonek szol.
A strange game. The only winning move is not to play. How about a nice game of chess?
Amit minify-olni kell a hatékonyság™ érdekében, az önmagában bloat, különben nem kéne minify-olni.
Másfelől, nehezíti a debugolást, a hibabejelentést, a testreszabhatóságot, azaz gyakorlatilag mindent, ami hozzáadott értéke lehet egy ember által olvasható script-nyelvnek. Plusz, maga az elv is bloat, hogy egy ember által olvasható scriptnyelvből csinálunk egy ember által olvashatatlan katyvaszt, de azért az interpreternek és a gépikód-generálónak ugyanúgy le kell futnia a pluszköltségével.
Akkor küldjék le binárisan bytecode-ban.
A minify-olt JS jellemzőit tekintve bytecode, mert ember által olvashatatlan, de a gyakorlatban mégis script, annak járulékos költségeivel együtt. Ha valami, na akkor ez az az overhead, ami miatt a legnagyobb bloat.
Nem kell minify-olni, viszont kevesebb savszelesseg, memoria, http request (ha tobb js-t osszecsomagolsz), ugy, hogy minden egyeb szempontbol ugyanaz a kod. Minify elott lehet olvashato, nem erzekeny arra, hogy hany file-bol milyen beszedes nevekkel meg kommentekkel latod el.
Debugolni az eredetit celszeru (ha nem a forditot debugolod), szoval ez nem igazan erv.
A js egy kozos low-level valami, amit fordithatsz masik nyelvbol is akar. De ha binarisra vagysz, ott a webassembly, mas technika, de elerheto. Alapbol a bongeszoktol fugg a belso abrazolas, ugyhogy nem lenne jo leforditott js kodot atkuldeni (es amugy is gepi kodra fordul a V8 ota, ami architekturafuggo).
A strange game. The only winning move is not to play. How about a nice game of chess?
Megoldja a content-encoding gzip vagy a brotli.
Ne röhögtess. Nem a parse-olással megy el a memória nagy része. Hanem a fos minőségű trágyahalom kód lefuttatásával.
Nem kell minify ahhoz, hogy összecsomagold. Tehát lejön 1 JS-ben, amit fog használni az oldal, minify nélkül, content-encoding tömörítés pedig elintézi, hogy ne fogyasszon sok sávszélességet, ha a request-eken akarsz spórolni. Könyörgöm, mutass már mainstream oldalakat, ahol egy JS jön le és abba bele van minify-olva az egész funkcionalitás. Mert szerintem nem a valóságban élsz, hanem a tankönyvi idealizmusokban. Általában a fél világ JS-ei lejönnek, minify-olva. Például, ha felmész az index.hu-ra, akkor 58 különböző JS fájl jön le, amiből 9-et kidob a uBlock, tehát 49.
De igen, érv, mert nekem az eredeti nincs meg és ha szeretnék bejelenteni egy hibát úgy, hogy foglalkozzanak is vele, akkor nem árt, hogy ha nem a "something went wrong" áll a leírásban. Emellett, előfordul, hogy nem akarnak vele foglalkozni, mert nem™ éri™ meg™ nekik, ekkor adja magát, hogy megpróbáljam én kijavítani a hibát egy custom user JS-szel vagy CSS-szel. Amit szintén ellehetetlenít a minify.
Nem, nem az. A JavaScript egy high-level valami, aminek a funkcionalitását a babzsákfejlesztők ahelyett, hogy részletesen, kívülről-betéve, full-stack módon kitanulnák és kihasználnák, inkább divatnyelveken írt bloat szarkupacokat "fordítanak" le rá, temérdek overhead-del és bloat-tal.
Attól, hogy babzsákfejlesztőéknek nem elég kényelmes tiszta JavaScript-ben programozni, nem low-level nyelv. A bloat-ot író webökör állít ki magáról szegénységi bizonyítványt, meg lesz low-level (tudását tekintve).
Nem vágyom binárisra. Erőforráshatékony webes megoldásokra vágyom, amit a ma webfejlesztésnek csúfolt szakma szabványokkal való megreformálásával és kikényszerítésével lehetne elérni, akár JS alapokon is. Csak akkor követni is kéne a szabványokat és nem megerőszakolni.
Bytecode-ról beszéltem. Amit mondjuk egy JVM-nek is adsz, hogy a szöveges interpretációt megúszd. De mondom, nem ez a lényeg, hanem az, hogy egy-egy weblap funkcionalitását tizedannyi JS-ből meg lehetne valósítani, bloated keretrendszerek nélkül. Ami általában nem történik meg, de a xorvoid esetében megtörtént. Ez volt az eredeti téma.
Kicsit hatrebb lepve nekem ugy tunik, hogy az igazi baj, hogy nagyon hirtelen lett nagyon nepszeru a nyelv/platform. A dev-ek kozott meg nincs meg az igeny a hatekony, tiszta kodra. Most epp az a fazis van, amikor a dev-ek tobbsege rajon, hogy milyen megoldasok mukodnek, milyen best practices-el, es hogy nem lehet meguszni, hogy tiszta es karbantarthato kodot produkaljon, mert a munka 80% +- ban maintenance, nem uj development.
Nem a hirtelen jott nepszeruseg a baj.
Alapvetoen a web egy rosszul eltalalt valami. Erre jott ez a nyelv, amit 2 het alatt dobtak ossze, es ezt a fost takoljak azota is. Egyreszt vannak fejlesztok, akik mindenfele libekkel probaljak elerni, hogy nagyon szarul mukodo dolgok kicsit hasznalhatobba valjanak, masreszt ott vannak a bongeszo es szabvanyfejlesztok, akik a masik oldalt probaljak szilardabb alapokra helyezni (pl. ES6-ig beepult a jquery a szabvanyba es az azt implementalo bongeszokbe). Aztan ott vannak, akik ezt pluginekkel (java applet, flash, meg az a .net-es klonja), uj, js-re fordulo nyelvekkel (pl. typescript), css-re fordulo preprocessorral (pl. scss) probaljak ezt az alapjaiban elbaltazott rendszert vagy levaltani, vagy legalabb valahogy hasznalhatova tenni, ha mar valami miatt arra lett igeny, hogy minden a weben keresztul menjen. Backend oldalrol meg valamennyire szabad vagy, html kodot kb. akarmi ki tud printelni, de a bongeszoben ezekre tudsz epitkezni.
A strange game. The only winning move is not to play. How about a nice game of chess?
Az Angular (2-es verziotol, most 14 korul tartanak) pl. ugy mukodik, hogy megirod typescriptben a kodot, es leforditja (transpile) 1 db. js file-ra a veget. Persze 3rd party dolgokat bekothetsz, de alapvetoen ennyi. CSS-el ugyanez (hasznalhatsz scss-t, ugyanabba belefordul). Debughoz keszit hozza egy map file-t is, amibol kiderul mi melyik file-bol jott. Defaulban a dist/esbuild konyvtar main.js, main.css, main.js.map file-jai. Ezeket sima statikus file-kent ki tudod szolgalni, minden mast megold single page application-kent. Az indexhez ilyesmi nem kell.
A http az OSI modell szerint az egesz teteje. Webes fejlesztesben meg az alja, arra epitesz fel mindent. A C amikor megjelent, egy magas szintu nyelv volt, most meg "hordozhato assembly". A JS magas szintu, de egy rakas masik nyelv epit arra, hogy JS kodot allit elo magabol, epitve a JS meglevo (nem)tudasara (transpile korabbi JS szabvany miatt vagy mert neha jol jon a tipushelyesseg, de mar 15 eve is volt java->js fordito).
Lehetne bytecode, csak a bongeszok azt nem tamogatjak, a JS-t meg igen. Ahhoz kellene egy masik szabvany. Leginkabb ki kellene dobni az egesz webet, es leulni 0-rol megtervezni. Viszont az a jelenlegi szabvanyok es mar meglevo kod miatt nem olyan egyszeru. Ja, es az lenne az igazan bloat, ha a jelenlegi szart meg az ujat egyszerre kellene tamogatni.
Az eredeti temahoz meg: ott a .kkrieger, nagyon kiraly, hogy beletettek cipokanallal az egesz jatekot ilyen minimalis helyre. Viszont az eredmeny sokkal eroforraspazarlobb, mint egy hasonlo tudasu jatek, egyszeruen azert, mert a tarhelyre optimalizaltak, es nem a futasidore (amire egyebkent szoktak). RAM-ba kicsomagol mindent, es nem torodik az eroforrasok hatekony kihasznalasaval.
Egy C forditot is meg lehet irni hasonlora, csak epp a hattertar ezen a szinten kb. mindegy, az eloallitott kod futasi sebessege, a forditas sebessege, a kod atlathatosaga (fejlesztes, debug miatt), a funkcionalitas, tamogatott platformok/architekturak meg hasonlo aprosagok sokkal tobbet szamitanak.
A strange game. The only winning move is not to play. How about a nice game of chess?
Nem említetted a brózereket, napjaink táltos paripáit, amelyek egyre gyorsabb motorral rendelkeznek! :-D
A kígyó a fejétől a farkáig... A mérés nem mai: Egérkattintás -> szerver = 0,1s. Vezérlés -> sql = 0,1s. Xml -> kliens = 0,1s.
Összesen: >4s
És ekkor jön a C(++) kliens, ugyanarra a motorra. (Jójótudom: ajax és tsai. A gépem megbillen a firefoxtól, mert modern.)
Miert, miert, hat a profit miatt. Van ami fontosabb a penznel? :-)
A binaris meretet nem tudom, de Fabrice Bellard (qemu, ffmpeg) irt anno az IOCCC-re nagyon rovid forraskodu C forditot. Kesobb abbol lett a TCC.
A strange game. The only winning move is not to play. How about a nice game of chess?
Ez lehet az? https://github.com/ioccc-src/temp-test-ioccc/tree/master/2001/bellard
Van ebben a repóban bőven csemege szivatós C ZH-hoz. :)
A kod tippre ez, csak amikor neztem, meg nem volt github. Az egesz verseny a szivatos C zh-rol szol amugy.
A strange game. The only winning move is not to play. How about a nice game of chess?
Akkor most a szamitogepek almukbol velebredve is fognak tudni C programot forditani.
Malware-keszitok sajat fejlesztese gondolom: ok jarnak vele a legjobban. :)
Es nagyon nem varom a latszatintezkedeseket, amiket ezutan miattuk bevezetnek.
Gyakorlati értelme nem sok van ezen a szinten, de tetszenek az ilyen pihent agyú, minimalista projektek. A gyakorlatban egy Tiny C Compiler-nek több értelme van, de jó gyakorlat ez a minimalizmus. Van gyakorlati haszna egy szintig, de nem közvetlenül. A felhasználók-fejlesztők hozzáállásán javít, elkerüli a kódok bloatosodását.
Magam is ennek a híve vagyok. Sokan nem értik, hogy a mai erős hardverek korában minek a minimalizmus. Azért, mert a kód fenntarthatósága is fontos. Nem csak a hardver oldaláról, bár a kis hardverigény kifizetődik ott is, nem kell x évente hardvert cserélni, meg upgrade-elni, hanem ha maga a kódméret is csekély, azt könnyebb debugolni, fejleszteni, csomagolni, terjeszteni, forkolni, átportolni, a kisebb kódban kevesebb bug, sechole tud megbújni, stb.. Jelenleg az a divat terjed, hogy írják a monstrum, sok millió kódsoros kódokat, ami már normál, közönséges fejlesztőknek átláthatatlan, senki nem érti mit csinál, már csak a nagyvállalati tőkével tudják tákolni, meg AI kell hozzá, lassú, drága a fejlesztése, a felhasználó meg ki van szolgáltatva ezeknek a kódoknak, rakat sechole benne. Ezért jó a suckless, OpenBSD, stb. által népszerűsített minimalizmus, az Arch, Alpine, stb. által hirdetett KISS elv. Az embernek jó, hogy látja, érti, hogy mi mit csinál a rendszeren, ha valami eltörik, könnyű megjavítani. Sokan ezért is retróznak (8-bites mikrók, Basic/ASM, DOS, CP/M, korai Unix, stb.), mert azokat a megoldásokat át lehetett látni, nem voltak nagyobbak néhány száz, néhány ezer kódsornál, pont az a méret, amit még egy kezdőbb, hobbista fejlesztő is át tud látni, meg tud érteni.
Sajnos ez igaz a gcc-re, meg az llvm-alapú megoldásokra is (közöttük a Clang-ra). Aki már fordította le ezeket forráskódból, az tudja, hogy milyen óriási kódméret, és milyen sokára fordul le. Így abszolúte van értelme az ilyen kisebb projekteknek. Több fejlesztőnek kéne ilyesmivel foglalkoznia. Jó, az 512 bájtba beleférés kicsit túlzás, de a kódméretet előnyös a minimum közelében tartani, minden csak annyira legyen komplex, amennyire feltétlen szükséges.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Egy single board computer memóriájának is a kb. csak a 20%-át eszi meg a GCC fordításkor, ellenben sacc/kb. dupla olyan gyors kódot fordít, mint ezek a kis C fordítók.
RAM-ot 100 MB-tal növelni lehet, CPU számítási tempót duplázni sokkal nehezebb.
Attól is függ mit fordítasz, azért ha egy Gentoo install alatt forgatsz nagyobb csomagokat, 10 giga felett eszik simán. A lényeg itt elvi, ahogy már írtam, nem csak a hardverigény, hanem az emberi átláthatóság, ha valamit meg lehet valósítani x kódsorból, meg y memóriafoglalásból, akkor ne írjanak annál komplexebb kódot a feladatra, vagy ha komplexebb is, bontsák szét modulokra vagy pluginekre, amik önmagukban szintén ilyenek.
Ez a lényege a Unix-filozófiának is. Minden alapfeladatot egy egyszerű, 2-3 betűs parancs, CLI program valósít meg, ami hibátlan futás esetén sokszor a tömörség miatt (teletype-on spórolni kellett a papírral, tintával) még kimenetet sem ad, a visszatérési értékben tudod detektálni a hibás, hibátlan futást. Ezek az alapelemek meg pipe-okon, meg scriptekbe ágyazva hívogatható, és összelegózható belőlük komplett alkalmazás. Nálam pl. elég sok ilyen script van, jelszókezelő (plain text file vim-ben, ami opengpg-vel van ki/bekódolva), szótár (stardict-cli + less), onlline rádióhallgatás (plain text adatbázis + mpv), dokumentum-megnyitós (fzf + vim), felcsatolós (fzf + mount/jmtpfs), erőforrásfigyelő, SSD-statisztika, stb.. Kernighan is ezt mutatja be egy 40 éves videón, hogyan használtak helyesírás-ellenőrzést, és ez a mai napig használt technika (csak tipikusan hunspell-be pipe-olnak, nem kell sort, unique, stb.). Másik példa, illetve egy extrémebb (igazi retró terminálban vim + laptopképernyőn OpenSCAD). Hasonlók a library-k is egy kicsit: readline, (n)curses, stb., amit megint csak sok program tud újrahasznosítani.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Olyan nagy elemi C fájlokból áll? Hiszen a C még mindig fájlonként fordít és a végén a .o-kat linkeli. A linker mondjuk többet eszik, ha nagy binárist kell hogy a sok .o-ból összerakjon.
Természetesen így kell használni a unixot, hiszen erre készült.
Viszont a +100MB, a háromszor gyorsabb kód és amin kicsit feljebb okoskondnak, az index.hu+js = szép gondolatokhoz képest :-D vissza lehetne kanyarodni a topichoz is! :-DD (Megjegyzem, eléggé pirultam volna, ha az én kódom a C fordító miatt gyorsult volna háromszoros sebességre. ;))
Mire jó ez a kis C fordító? Hát pontosan semmire. Csak 8086 kódot állít elő, azt is csak eléggé subset szinten. Valójában csak igen egyszerű, világosan megfogalmazott kódot képes értelmezni.
Viszont nagyon jó minta és gondolatébresztő!
Képzelj el egy 8 bites risc mcu-t. Minden "driver" és "lib" ott csücsül a flash-ben, és ezek ugrótábla vagy egyéb entry point segítségével elérhetők. Azaz létezik egy-egy utility és driver készleted, akár egy kernelben. A C meg struktúrált assembler, ezért a már meglévő készségeket - az általában egyszerű - főprogrammal összekötözgeted és már el is készült a szerkezet. A fordítót ki kell egészíteni a flash-be írás/törlés képességével, és dokumentálni kell a kész modulok hívását. A kódot forrásként soros porton injektálhatod.
Az sem baj, ha a fordító és kód töltő rész 3x512 bájt lesz, inkább a ram a szűk keresztmetszet. Ilyenkor mindig PIC18-ra gondolok, ahol 2k, egyes példányoknál 4k vagy 8k ram is van. Ennek ellenére az ötlet adott, a kód hordozható lesz különböző utasításkészletű processzorok között is.
Hm... ez vajon menmyire lehet "portolhato" kicsit naprakeszebb beagyazott architekturakra...? ARMv6/7-M, AVR, RV32I, ... az nem baj feltetlen ha RISC-en 1.5x akkora lesz a kod :)