Programozási versenyfelhívás

Megadott feltételek mellett.

Akkor csak elkerulte talan a figyelmemet, de igy nem vilagos, mit jelent a "vagy a C nyerne".

A videómemória közvetlen írását hová sorolod? Az egy eléggé hardverközeli dolog.

Továbbra sem akarod megérteni, hogy a Rust a helyességi ellenőrzéseivel pont hogy nem az ilyen feladatok miatt lett bevezetve. Az ilyen dolgokra maradnak az eddigi módszerek, pl. a C, vagy Rust unsafe.

Ugye, ugye...akkor mitol lenne a C a legjobb nyelv? Attol, hogy megtalaljuk azt a teruletet, amiben a legjobb, masra meg nem azt hasznaljuk ha nem az a legjobb.

A Te feladatod "versenyeztetni" a C-t egy olyan esetben, amire de tenyleg a C a legjobb. 

Azt nem ertem, hogy mit akarsz elerni vele? Kinek akarod bizonyitani, de meg inkabb hogy mit is? :D

Érdekes, nálam out of bound addressing errort ír rá.

De miert lesz neki jobb, ha igazol neked barmit is?

>megkaptad a lehetőséget, hogy gyakorlatban is igazold, nemcsak a szád jár.

Konkrétan mit is? Ha visszaolvasnád a hozzászólásokat, a tényszerű tévedést javítottam csak, miszerint a C-re továbbra sem lehetséges maradéktalanul memória túlcímzést ellenőrizni. Ennyi volt az állításom, ezt nem tudod cáfolni, mert így van. Rust evangelista nem vagyok, mert még alig ismerem. Szerintem érdekes téma, de eddig nem volt időm rá: érdekes és pénz hozó projekteken dolgozom, úgyhogy nem panaszkodok, de hiába érdekel, nem Rustoztam eddig egy tutoriálon túl.

Talán a Java a kedvenc programozási nyelvem a libekkel és eszközökkel együtt. De sosem állítottam, hogy rendszerprogramozásra alkalmas volna.

Azt nem veszed észre, hogy az alap állításoddal nem is álltam szembe, szeretem is a C-t, dolgozok is vele. Csak annyira fel vagy fuvalkodva, hogy mindenre vagdalkozol ahelyett, hogy gondolkodnál inkább.

Az szerintem nyilvánvaló, hogy bármilyen menedzselt nyelvhez szükséges az unsafe opciók használata ahhoz, hogy interfészeljünk a hardver környezettel. A kiírást nem gondoltam végig, de sejtem, hogy itt ugyanez van, nem tudsz C-be belehívni unsafe nélkül, mert C-t hívni eleve unsafe a Rust nyelven belül. (Tippre, nem néztem utána és talán nem is fogok.)

A környezethez drótozó kódokon kívül a többi viszont már lehet safe, az a logika, hogy egy timer szerint, vagy a buffer swap interruptból triggerelve beírunk két bájtot az már gyerekjáték. A nehézséget a C API elérése és a timer felrpogramozása jelenti. Mivel C API-t adtál, ezért ez pont olyan mint a Róka és a Daru vendégsége. Én meg kiírok egy versenyt, adok egy Java API-t, és az nyer aki a legegyszerűbben használja a Java API-t. Írhatsz JNI-t rá, de bukod mert túl bonyolult lesz.

A Rustnak nem engedni az unsafe-t, az itt nem fair, mert az olyan mintha én azt mondanám, hogy te meg futtas rendszerbetöltőt Valgrinddel, de úgy, hogy ne mondd meg neki, hogy a rendszer regisztereihez hozzá szabad férni direkt címzéssel. Úgy kivág mint macskát szarni. Ha meg megmondod, hogy ezeket neked szabad, az pont olyan mint Rustban az unsafe.

Ennek a versenynek hogy lehetne már ugyanaz a célja, mint egy cég részlegének? Sehogysem.

No igen, nehez meroszamot rendelni ahhoz, amikor rendben van a doksi, a CI, a re/un/... deploy; van failover, backup es monitoring, vannak processzek, megismetelheto, atveheto a fejleszes es uzemeltetes, van 24/7 pager duty, van biztonsagi audit, es meg sorolhatnam.

Sokan, akik nem dolgoztak meg kozepes/nagy cegeknel, nem is tudnak ezekrol. Nagy cegeknel a jo kod max. a fele a requirement-eknek. Siman van atlagosan minden koder melle egy SRE/Security/PO/IA/BA/PM fo. Egy 3-5 fos team melle siman egy 3-5 fos support garda tartozik, akik a (developer szemszogbol) "kulimunkat" vegzik.

Kis cegnel ezeket altalaban elsumakoljak, vagy annyira egyszeru a landscape, hogy egyvalaki megcsinalja kaveszunetben. De nagy ceg ezt nem engedheti meg maganak; egy esetleges sulyos leallasbol, security breach-bol, adatvesztesbol akkora veszteseget tud 'kitermelni', amibol kijon a teljes IT eves fizuja... Mas a nagysagrend.

Én beágyazott programozó is vagyok, C-ben kiismerem magam, a Rust érdekelne, és kifejezetten jó mókának tűnne ilyesmit írni AMD64-re. De az agresszív kismalacos hozzáállás miatt úgy érzem akármit is hoznék össze, arról kiderülne, hogy eggyel több unsafe kulcsszó van benne, vagy kellett hozzá egy ASM betét, vagy ilyesmi, és ezért érvénytelen az egész.

Nem értem bzt miért idegenít el magától mindenkit, mert kifejezetten érdekesek lehetnének ezek a témák ha nem vagdalkozna hozzá. Olyan mint egy Apple fanboi, aki a C-ért rajong az Apple helyett :-)

Nem tudom x86-on hogy van, de például ARM-eken vagy AVR-eken is kell néhány "compiler intrinsic" vagy assembler betét ahhoz, hogy a rendszer alapjait le tudjuk tenni, amire már lehet szabványos vagy MISRA C-t írni. Ezért a Rust-tal szemben is az volna az ésszerű, hogy a rendszer "szélén", azaz ahol a számára külvilággal interfészel, ott engedjük meg az unsafe használatát. Hívj meg egy ABI-t, ami nyilván eltér a Rust hívási konvenciójától, de ne használj unsafe-t! Teljesen korrekt versenykiírás. Pedig amúgy érdekes lehetne.

Mi a baj a char *-gal? Nehéz megemészteni, hogy a printf("Hello world!\n"); esetében maga a szöveg valahova teljesen máshova tárolódik, s a printf() ott csak egy pointert kap meg, ami a 'H' betűre mutat?

Rendben, de akkor C-ben se lehessen pointert használni, csak az interfész függvényekre.

Az unsafe nem az jelenti, hogy az adott programrész feltétlenül bajt csinál, hanem azt, hogy arra a részre nem tud a compiler garanciát adni. Mert garanciát akkor tud adni, ha a matematikai konstrukció amire a biztonság bizonyítása épül mindenütt be van tartva. Az unsafe-re a programozónak kell garanciát adnia, nagyjából ott van ahol C-ben lenne: vannak eszközei amikkel lehet hibás és hibátlan programot is írni.

Általában két céllal hozzák létre az unsafe dolgokat:

Egyik a teljesítmény növelése, amire nagyon ritkán, de szükség lehet. Azért mondom, hogy ritkán, mert a teljesítmény növelésére persze mindig szükség van, de többnyire nem ez a szűk keresztmetszet. Ritka az olyan program ami már annyira optimális, hogy már csak unsafe-fel lehet javítani rajta. De van ilyen és szükség van rá, akkor lehet.

A másik pedig a virtuális gép szabályainak nem megfelelő dolgok használata, ami lehet például egy másik nyelvbe belehívás, vagy perifériák memóriájának közvetlen írása. Ez az amire vélhetően a "versenyben" szükség volna.

Összefoglalva az unsafe azt jelenti, hogy a biztonságosságot a compiler és a runtime nem tudja garantálni, mert a bizonyítás logikájába bele nem férő módon történik a működés. De ettől még az a kód lehet biztonságos, csak azt a programozó egyéb módszerekkel kell hogy garantálja.

Nem hinném, hogy valódi probléma volna, hogy a kezdők értelmetlenül használnák az unsafe konstrukciót. Nem lesz attól egyszerűbb semmi, egyáltalán nem erről szól ez a kulcsszó. És ha mondjuk egy kernelt fejleszt valaki Rustban, akkor abban lesz fix számú unsafe, és azt ki lehet listázni a kódból és hozzá lehet mindegyikhez rendelni egy magyarázatot, hogy miért szükséges használni, és mi garantálja, hogy megfelelően működik. És az unsafe nem azt jelenti, hogy az egész programban deaktiválva vannak a védelmek, hanem csak pont abban a kis részben.

Az pedig továbbra is áll, hogy nyilván nem lesz egy kezdő szarja jó attól, hogy Rustban van, arra viszont mégis garanciát ad a nyelv, hogy a memória a virtuális gép szabályainak megfelelően fog működni. Tehát ha nem kap referenciát a kezdő programozó függvénye a b változóra, akkor annak az értékét nem tudja átírni semmilyen módon.

Egy c programban, ha 1 függvényt használsz, ami nem tuti, akkor megtörténhet, hogy felülírja az isLaunchingNuclearRocketImminent változó értékét igazra. Akkor is, ha a függvény feladata csak vonalkód nyomtatás lett volna valójában, de mondjuk valaki számok helyett betűket is írt a mezőbe, ami az átalakítás során overflowolt, és épp ez a változó csücsült ott. Ilyen Rustban nincsen, nem lehetséges. Ezt a hibaosztályt megszünteti a biztonságos memória menedzsment. De nem csak a Rustra igaz ez, számtalan nyelv régóta tudja, a Java és a .NET is ilyen volt már a kezdetektől (90-es évek), Quora szerint a BCPL volt az első nyelv, amiben biztonságos pointerek voltak.

>Azt gondolom, ez a kizárás oka, csak nincs minden egyes feltétel hosszas körmondatokkal megmagyarázva.

Ennek semmi értelme nem lenne, mert a funkcionalitás maga, például JavaScriptben megírva kb egysoros volna. Semmi értelme nincsen a probléma logikáján belül unsafe-t használni valakinek, aki tudja hogyan kell Rustot programozni. A tiltás értelme pontosan az, hogy a Rust unsafe nélkül csak Rustot tud hívni, hiszen ami kívül esik az ő VM-jén az számára nem safe. Tehát fából vaskarika unsafe nélkül a kírás. Olyan mint az, hogy "Vágjátok ki az erdő legnagyobb fáját! Ezzel a heringgel!" És ezt vagy tudja bzt és akkor nem fair a kiírás, vagy nem tudja, és akkor meg olyat kritizál amit nem ismer. Vagy lehet az is, hogy a C-be híváshoz nem kell az unsafe kulcsszó, de attól még az ugyanaz. Például Java-ban a native kulcsszó jelöli a JVM-ből kilépő hívást, amivel például C libraryt lehet hívni. Tehát nem unsafe a neve, de attól még az persze unsafe, mert a JVM nem tudja ellenőrizni, hogy odakinn ki mit hogyan fog felülírni.

En mar reg nem programozok "nagyban", mostansag 95% bash, mert rendszergarazda vagyok, konkretan evek ota nincs semmilyen IDE a gepemen.

De egyebkent a memoriakezeles es a leakeles elkerulese mar 25 eve is tema volt. 2000 -ben keszullt vizsga munkam egy olyan C++ osztaly volt, ami a himem.sys -re tamaszkodva egyfajta virtualis memoriat biztositott az ot felhasznalo kod szamara. Lokalis valtozokent kellett peldanyositani, de a sok (lokalis) peldany egy static valtozon keresztul tartotta egymassal a kapcsolatot. Az adott peldanyt hasznalva lehett rajta keresztul rohadt nagy meretu tombot, listat, fifot, lifot foglalni, es hasznalni. DOS alatt lehetett igy akar tobb MB-os adatszerkezeteket egyben kezelni. A josag az volt benne, hogy ha kileptel a lokalis valtozod ervenyessegi tartomanyabol, akkor a destruktor felszabaditott mindent, amit eddig foglaltal, ergo esely sem volt leakelni, ha rendesen hasznaltad.

Persze ez csak egy technikai bemutato volt, hiszen addigra mar volt vedett mod, es mindenki Windows 98 -at hasznalt, igy a DOS szukebb keretei a kutyat sem erdekeltek, de azert jo mulatsag volt megirni.

Fura, hogy evtizedekkel kesobb is ugyanazok a problemak koszonnek vissza, amelyek csak reszben vannak jol megoldva. A Java GC jo elgondolas, de a finomhangolas azert be tud kavarni. Irtad, hogy Ada-ban irtal kodot, nos, egy volt munkahelyemen olyan "biztonsagos" Ada kodot kellett kezelnem, ahol nagyjabol minden valtozohoz kulon tipust hoztak letre, hogy biztosan ne lehessen kisebbet-nagyobatt beletolteni mint amire a kolto gondolt. Ez elmeletileg jo, csak gyakorlatilag a fene se tudta fejben tartani, hogy a tobb tucat integer valtozobol melyik milyen range ertekekkel rendelkezik. Agyf4szt is kaptam tole rendszeresen. Nem sokkal kesobb meg a dolog masik oldala jott szembe ugyanannal a cegnel, amikor C# programozoi sapkaban allandoan olyanokat kellet irnom, hogy if (alma != null) alma.valami(); mert a hatam borzongott, hogy mi az isten ez a kupleraj, hogy kerulhet ide egy null ertek, es ha null, akkor miert nyeljuk le csendben a nem teljesen jo mukodest, ahelyett, hogy megallitjuk a szemet be, szemet ki folyamatot?

Szoval nem csak nyelvek, de a programozasi szokasok, modszertanok is tudnak annyira masok lenni, hogy ihaj. 

Onellentmondasba utkoztel, de gondolom valami kis szemelyeskedessel es onmagad piedesztalra emelesevel majd kimagyarazod magad: :D

"Elegem lett a sok nagyszájúból, ezért úgy döntöttem, lehetőséget adok nektek a gyakorlatban is bizonyítani,  hogy valójában a gyakorlatban egyik csodanyelv sem képes leváltani a C-t"

:D

Igen, kotozkodok, ugyanakkorb felreerted. Pontosan tudom, hogy csak C-ben irt palyamu fog nyerni, a masodik helyezes erdkel jobban, Az kevesbbe, hogy sokx modatban dicsered magad.

Egy jotanacs: fogalmazz tomoren, lenyegretoroen. 

A "többi szájkaratés", aki nem tud ilyen alacsony szinten programozni, az éppen azért szájkaratézott érvelt, hogy az ilyen megoldásokat is el kelljen fogadni.

Úgy látszik, hogy mégsem "szájkaraté" volt, hanem megalapozott érvelés, amit bzt, a fenti hozzászólása alapján, el is fogadott.

Így: https://github.com/chainq/langcontest-pas

Ja a bináris (ELF) amúgy 664 byte. Ebből 256 byte csak a 4db ELF section header, amik nélkül 408 byte-ról beszélünk. Ami kisebb mint a kézzel írt assembly 425 byte-ja... :) Tudom, sántít az összehasonlítás, de azért vicces. Még van egy hónapom, talán majd kiszopom hogy hogy lehet olyan ELF-et gyártatni, amiben nincsenek sectionök.

De az a baj, hogy egy x86_64 rendszerprogramozás az bármiben gusztustalan, még C-ben is. Ez kb. olyan mintha azzal tesztelnénk melyik (emberi) nyelv mennyire szép, és milyen "kifejező ereje" van, hogy milyen jól lehet benne kínrímeket írni. "Mint Zuzuval beszélgetni. Enyhén szórakoztató, de leginkább fájdalmas." Ebből a szempontból a C az különösen olyan, hogy meg lehet írni benne egy csomó mindent amit másban nem, nyolc rétegű makróhalommal meg pragma-túltengéssel, csak minek. 2 sor inline assembly többet ér, még akkor is ha az már "nem a nyelv része". (És most itt nem akarok Pascal vs. C-be kezdeni, mert azt tényleg minek, az a vonat min. 35 éve elment.)

Mindegy. A szentimentumot értem a newschool nyelvek ellen, de attól még továbbra is úgy gondolom, hogy ez nem egy jó teszt. Pluszban, a Rust-nak mintha lett volna egy embedded working groupja, amiben különösen erre mentek rá, hogy hardware közeli dolgokra, igaz főleg mikrokontrollerek és társaik programozására jó legyen. Szóval az ilyen tesztekkel az a baj, hogy ahogy az idő halad, egyre extrémebb és extrémebb dolgokkal kell majd "tesztelni", hogy mennyire nem jó semmire. És őszintén, már egy x86_64 low-level interruptkezelés is elég extrémen ronda...

Én legalább bevallom hogy szubjektív okokból nem kedvelem a Rust-ot, pl. szerintem ritka gusztustalan a szintaxisa, de mivel mások meg a Pascalról gondolják ezt, ezért nem fogunk összeveszni, inkább tisztelem felebarátaim elmebaját és kész. Meg a szokásos overhype miatt, miszerint ez majd megoldja az afrikai éhinséget, a globális felmelegedést, feltalálja a mindenség elméletét, meg a toronyórát lánccal is, csak én már elég öreg vagyok hozzá, hogy emlékezzek legalább 3 ilyen ciklusra szakmánkból. Én még emlékszem, amikor a Java volt a jövő, abban írtak OS-t, meg a sok okos elhitte hogy "van garbage collector, ezért nem lehet memory leaket csinálni". Aztán egész jó pénzt kerestem abból úgy egy évtizedig, hogy az ilyen fejlesztők kódjait fixelgettem. :) Már kezdődik ez a trend a Rust-nál is, most pl. a Microsoft kiadta a Rust-ban Windows-ra írt sudo klónt, aminél feltüntették h. mekkora sekureti stonks, mert hogy Rust, na egy hozzább értő szét is kapta mint floki a lábtörlőt, mert "az ellen nem véd" ha valaki elbassza az ellenőrző logikát és emiatt az egész cucc a nagyon memory-safetyvel együtt simán bypassolható. Szóval ja. Nekem ez a fajta hívő-hozzáállas, és a kritikai gondolkodás hiánya, ami nem tetszik egy csomó newschool nyelvben, és a Rust ebból az elsőszámú példa. De majd kinövöm, gondolom. A Java-t meg a Pitont is utáltam eleinte, aztán mikor végül valamit dolgozni kellett benne, akkor csak ment... Mondjuk hobbiból továbbra sem megyek egyik közelébe sem...

Legalul a processzor úgyis csak a goto-t meg a pointereket ismeri. Hogy ki mivel akarja kábítani magát, hogy ez nincs így, majdnem mindegy. :) Köszönöm, hogy elmondhattam, leültem.

> JS-ben nem fogsz interruptokat kezelni

Ez viszont valóban, még elméletben sem lehetséges, mivel interpretált szkriptnyelv.

javascript mikrokontrollerre:

http://johnny-five.io/

Kifejezetten interruptra pelda:

https://gist.github.com/rwaldron/769068fbbc9b433768dd

Szerintem nem estünk át a ló túloldalára. Azok estek, akik a mai operációs rendszereket és programokat írják. Ez egy sarkos példa volt, amire nagyon ráfókuszáltál. Nem azt akartam vele érzékeltetni, hogy legyen sok egyfloppy-s rendszer. De állítsuk már meg ezt az végtelen pazarlást! És erre jó példa a mai operációs rendszerek és programok. Én az ellentétre akarom felhívni a figyelmet, mindegyik működő operációs rendszer, grafikus felülettel! Az egyik elfér egy floppy-n, a másiknak lassan több tíz GB nem elég. Nem beszélve arról, hogy tulajdonképpen nem tudod használni a számítógépedet, mert az operációs rendszer zabálja fel az összes erőforrást. Holott nem az lenne a feladata (szinte láthatatlanul), hogy kezelje és elérhetővé tegye az erőforrásokat?

Én csak egy autószerelő vagyok! Csak a 🍿-ért jöttem! Meg az elitet figyelni, aki szerint az a baj a HUP-pal, hogy nincs szakmai kontent és csak a flame megy! ^

https://gitlab.com/bztsrc/langcontest/-/tree/main/gelei

404 Page Not Found

El404-elt a powershell manual, amit par eve bookmarkolt, a tobbi nyelvet meg nem ismeri annyira. :)

Bocs, de amit a C fordító "nem nyúl a veremhez" eszmefuttatásról írsz, az egyáltalán nincs így és 100% fordító specifikus. És amint írtam, még optimalizációs beállítástól is függhet (pl. generál-e a fordító frame pointert az rbp-be, ezt eltárolja-e a verembe vagy sem). Erről vajmi keveset ír az ABI... Ez egy olyan dolog amire _semmi_ garancia nincs. Sem C-ben, sem semmiylen nyelven.

Most kipróbáltam, GCC 12.2.0, x86_64 Debian bookworm, természetesen -O3-mal egy üres függvény kizárólag egy "ret"-re fordul, míg -O0-val beletolja a frame pointert is a stackbe. Szóval ha erre akarod építeni az elméleted hogy a Rust miért nem "jövőbiztos" akkor ez masszívan mellément.

Erre elvileg nincs szükség, a betöltő pont azért van. 

Itt arra gondolok, hogyan tudom azt elérni, hogy a Rust által generált output az ne támaszkodjon arra, hogy van oprendszer, ill. van C runtime. Van ehhez opció, csak nyilvánvalóan ez az erősen haladó rész. Ahogy mondtam, ez az első Rust programom. Szóval ez inkább a saját szívásom volt :)

Tessék az AMD és Intel mérnököknél panaszkodni, ne nálam. Így működik a CPU, ezt nem tudod megkerülni. Még Assembly-ben is külön speciális utasítás van erre (aminek a neve történetesen "iretq").

Ezzel én teljes mértékben tisztában vagyok. És semmi hiba nincs a CPU utasításkészletében. Itt csakis abban van a hiba, hogy te hogyan tervezted meg, hogy a megoldás futása során majd meghívódjon az IRETQ utasítás. Arra gondolok, hogy ahelyett, hogy

Magas szintű nyelven írt handler kezdete:
  Implementációs lépések...
  Továbbhívás a bootloader iretq függvényébe
    Bootloader iretq függvény kezdete:
      Magic a stack pointerrel, mert nem tudod, hogy a hívó magas szintű implementáció mekkora stack frame-et csinált
      OUT instruction
      IRETQ instruction
    Bootloader iretq függvény vége
Handler vége

sokkal értelmesebb így csinálni:

Handler kezdete:
  Továbbhívás a magas szintű nyelvi implementációba
    Magas szintű nyelvi implementáció belépési pontja:
      ...
    Magas szintű nyelvi implementáció vége
  OUT instruction
  IRETQ instruction
Handler vége

nem igazán tudod megtippelni, hogy mekkora lesz a stack frame

Egy C program ezen a CPU specifikus működésen túl nem is nyúl a veremhez (amennyiben a függvény nem tartalmaz lokális változót).

Ez tippre nem így van, szerintem lehet olyan bonyolult kifejezéseket csinálni, ahol lokális változó nélkül is muszáj a stack-hez nyúlnia a compilernek. Másik szempont: ha csapatban dolgozol? És bárki hozzáad később egy lokális változót a függvényhez? Akkor mindenki vakarhatja a fejét, hogy mitől fagy le az egész, mert van valahol benne egy magic constant, aminek elmászott az értéke.

És ez teljesen igaz C-re és Rust-ra is. Ez a fajta megközelítés nyelvfüggetelenül szívás. Ahogy mások is írták, akár compiler optimalizációs szinttől is függ. Pl. a Microsoft compiler a CALL helyett JMP hívással megy tovább a bootloader-ed függvényébe, mivel látja, hogy ez a függvény utolsó sora. Úgy itt ezért kellett pl. negatív szám ahhoz, hogy mekkora a stack frame.

Azt akartam ezzel mondani, hogy ez egy értelmesebb méretű rendszernél átgondolandó. A jelen példaprogramnál persze tökmindegy, mondhatni a kihívás része :)

Engem meg regi masnyelves megoldas is erdekelne. Ha mar "boomerportal". :) Pascal mondjuk close enough, de egy fortran vagy egy lisp nagyot utne pl. :)

Zig még jöhet, abban biztosan meg lehet csinálni.

Azt ki sem lehet zárni unsafe miatt ;-), bár eléggé rámentek a biztonságosságra a nyelv készítők, csak kicsit másként, mint a Rust.

... ha ahhoz is ertene ... :)

Igen, vagy amikor assembly-ben írod meg a programot, mert abban lesz a leggyorsabb, aztán kiderül, hogy még a Java is megveri, illetve nem fér be az 5 leggyorsabb közé. ;-)

Zab, nem azt mondom, hogy nincs olyan eset, amikor pont ez kell. Én is írtam (baromi rég) ilyen feltételekre programot. Assembly-t használtam.

De azt mondom, hogy ez egy speciális eset, ennek alapján nem lehet azt kijelenteni, hogy az assembly a legjobb. OK, erre a célra, ebben az esetben az volt a legjobb. Más esetben, más célra meg valami más lesz a legjobb.

Dehogy adok be megoldást! Kb. 20 éve nem nyúltam Python-hoz (se). A kiírásban szereplő hardver környezettel semmi tapasztalatom nincs, és számos jobb módon el tudom tölteni a szabadidőmet, mint olvasgatással, hogy megtanuljam, hogyan lehet kiírni valamit PC-n a képernyőre egy olyan módban, amit sohasem tervezek használni a jövőben.

Ügyes, hogy a kérdéseket / észrevételeket egyszerűen figyelmen kívül hagyod.

> hogy mekkora a lefordított program

A program méretét a hardver korlátozza, nem én. Tessék a BIOS fejlesztőinél reklamálni!

Elhiszem, hogy van olyan hardver környezet, amiben ezek a korlátok adottak. Még azt is elhiszem, így láttatlanban, hogy ebben a hardver környezetben, erre a feladatra a C a legjobb nyelv.

De ebből nem következik, hogy a C a legjobb nyelv mindenre. Helyből, nincs olyan, hogy mindenre legjobb nyelv.

Ahol a hosszútávú karbantarthatóság is szempont, ott 100%.

Nem ez a tapasztalatom.

A lefordított bináris mérete hol számít a hosszútávú karbantarthatóságban?

Egy másik érdekesség, a számláló kiírása.

Itt is két megoldást adtam:

1. Alacsony szintű, kézi megoldás

    if (counter == 100) {
        counter = 0;
        if (vga[6] != '9') vga[6] += 1 else {
            vga[6] = '0';
            if (vga[4] != '9') vga[4] += 1 else {
                vga[4] = '0';
                if (vga[2] != '9') vga[2] += 1 else {
                    vga[2] = '0';
                    if (vga[0] != '9') vga[0] += 1;
                }
            }
        }
    }

2. Kicsit magasabb szintű megoldás

    if (counter == 100) {
        counter = 0;
        for (0..4) |i| {
            if (vga[(3 - i) * 2] != '9') {
                vga[(3 - i) * 2] += 1;
                break;
            }
            vga[(3 - i) * 2] = '0';
        }
    }

Utóbbinak az az érdekessége, hogy ha méretre optimalizálva fordítjuk, akkor lényegesen kisebb lesz, mint a fenti. Emiatt is tudott a noptr-es megoldás 656 byte-on elférni.

Ha pedig teljesítményre optimalizálunk, akkor kvázi ugyanazt kapjuk, mint a fenti. ;-)

Az 1. és 2. az ténylegesen egy megoldás fizikailag is, de két formátumra (architektúrára) van lefordítva.

Itt még az is érdekesség, hogy tetszőleges architektúrán fordíthatunk teljesen más architektúrára. A fenti megoldást én Linuxon fordítottam a Linux-ost és a Windows-ost is, de lefordulna Windowson is a Linuxos. Illetve ez igaz a sok tucat többi architektúra és OS kombinációjára is.

>a továbbiakban hirdethetem, itt a hupon, a babzsákfotelben nevelkedett soydev fejlesztő barátaimmal egyetemben, hogy a Zig képes leváltani a C-t?

Már azt hittem senki se kérdezi meg! Köszönjük a szójalattés babzsákfejlesztők nevében! :-)

Igen, az vagyok :) A commitoknál egyébként látszik a teljes nevem is.

Ennyire mélyrehatóan nem ismerem sem a C-t, sem a Pascal-t. Nekem, mint koca "programozónak", a kódokat megnézve kb. egy polcon vannak. Nem tudom mi az amiben a C mondjuk többet ad, mint a Pascal? Vagy esetleg valamit egyszerűbb megcsinálni benne. A Pascal olyan szempontból szimpatikusabb, hogy jobban hajaz a funkcionális nyelvekre.

Eresszük rá az AI-t, és fordítsa le a Linux kernelt C-ről Pascal-ra. :-)