HOVD 2023 - Kedvenc fordított programozási nyelv

HUP

  Itt a HUP Olvasók Választása Díj 2023 szavazás. Az idei HOVD immár a tizennyolcadik a sorban.

  A HOVD 2023-on minden HUP olvasó szavazhat. A HOVD 2023 választás ideje - két hónap - alatt a 20 kategóriában állított jelöltekre lehet majd szavazni.

  Szavazz az alábbi kategóriákban! Kedvenc ...

assembly (bármely architektúra, bármely dialektus)
4% (22 szavazat)
c
19% (103 szavazat)
c#
12% (64 szavazat)
c++
15% (84 szavazat)
go
11% (59 szavazat)
haskell, ocaml, f#, scala (statikusan tipusos funkcionalis nyelvek)
2% (9 szavazat)
java
13% (69 szavazat)
kotlin
4% (20 szavazat)
pascal
10% (53 szavazat)
rust
10% (52 szavazat)
swift
1% (7 szavazat)
Összes szavazat: 542

( joco01 v | 2023. 07. 03., h – 10:31 )

Kíváncsi lennék rá, ki miért nyom Javát Kotlin helyett :)

A Java és Kotlin interoperábilis, tehát bármilyen projektben könnyű bevezetni, akár fájlonként is lehet migrálni. A többi felsorolt nyelvben nem jellemző, hogy ilyen szabadon lehetne váltogatni a nyelvet egy binárison belül. A Kotlin sok szempontból jobb, modernebb, kifejezetten aszinkron kódolás esetén. Ritka az, hogy valaki mind a kettőt kipróbálja, és mégis a Javánál maradna szívesebben.

addig oke, de ez miert is jo? miert celszeru keverni 2 kulonbozo nyelvet egy projektben, foleg ha nem jar sebessegbeli elonnyel? mivel mind2 ugyanazzal a jvm-el fut, nem hiszem hogy annyira nagyon lenne feature-beli kulonbseg is koztuk, max kenyelmesebb a kotlin szintaxisa, de csak ezert megeri belekeverni?

en pl. felvaltva kodolok c es py nyelveken de meg igy is mindig keverem a szintaxist, if cond: vs. if(cond) es tarsai amikro valtogatok a nyelvek kozott...

Sok előny, kevés hátrány. Mert a Kotlin jobb, keveset kell hozzá újratanulni, és a projekt architektúráján semmit nem kell változtatni, ugyanazokat a libraryket tudod továbbra is használni, ugyanazt az IDE-t, stb.

> miert pont a kotlint valasztana a sok egyeb nyelv kozul?

Én annyit állítok, hogy Java és Kotlin közül utóbbi jobb, ha már amúgy is JVM-re akarsz dolgozni. Ez így egy értelmes választás, nem úgy, mint pl. Go vs. Kotlin, amik fényévekre vannak egymástól minden szempontból.

En nagyon keveset dolgoztam JVM-okoszisztemaban, azt is ugy, hogy 99%-a Scala volt. Nincs egy tl;dr osszefoglalo, hogy mi az, hogy "jobb" a Kotlin? A marketinganyagokat lattam, nagyon jo peldaul, hogy egyszerubb az aszinkron kodolas szintaxisa, csak altalaban eddig sem a szintaxis volt a nehez, hanem az, hogy rendesen kitalald, mit hogyan lehet aszinkron futtatni. 

Abban segit mondjuk a Kotlin, hogy ne legyen race condition, ne legyenek deadlockok, stb.?

Itt már írtam róla: https://hup.hu/node/179033

De akár a ChatGPT-t is megkérdezheted :)

> egyszerubb az aszinkron kodolas szintaxisa, csak altalaban eddig sem a szintaxis volt a nehez, hanem az, hogy rendesen kitalald, mit hogyan lehet aszinkron futtatni. 

Javában kurva szar aszinkron kódot írni, Kotlinban pedig kurva jó. Én microservice-es területen dolgozom, tehát rengeteg az RPC (sok másik backendhez beszélünk, adatbázishoz is), és alapvetően azokat kell aszinkronná tenni. De ugyanúgy fontos ez Android fejlesztés közben is, hogy ne blokkoljuk a UI szálat. Más területen meg gondolom nem számít annyit.

>Mert a Kotlin jobb
Nem is ertem miert nem dobta meg mindenki a Javat (including Oracle), mert innentol kezdve ugye egyertelmu melyik a "jobb". :)

>tudod továbbra is használni, ugyanazt az IDE-t, stb.
Itt megallnek egy pillanatra es megemlitenem, hogy ha jol remlik a Kotlinnak nincs language servere es (ha jol remlik) nem is terveznek, az IntelliJ IDEA tamogatasan kivul mas nem igazan erdekli a JetBrains-t.

En amugy ajanlom, hogy dolgozz mindkettovel komoly projekteken egy darabig, idovel lesz annyi tapasztalatod, hogy megsporolsz magadnak "x jobb mint y" kijelenteseket. ;)

https://develotters.com

"rengeteget": 2022-08-14 10:56 "Az utóbbi pár hétben beletanultam, és nagyon tetszik."
Egyreszt ez kis joindulattal is kb. egy ev, masreszt akkor nem irnal olyanokat, hogy X jobb mint Y, teljesen mindegy hogy mik azok. ;)
Kitarthatsz barmi mellett, ettol a tobbseg velemenye meg lehet mas (es vannak olyanok akiknek a "rengeteg" mondjuk 20+ ev egyik es ~10 masik).
 

https://develotters.com

( KoGa v | 2023. 07. 03., h – 11:42 )

Eltartott egy darabig, mire rájöttem, mit jelent hogy fordított programozási nyelv :D Mondom, hogy van megfordítva? :D

Pedig vagy 10 éve mindig így volt kiírva.

Amúgy hogy kéne mondani, ha arról van szó, hogy a fejlesztés során van egy definit lépés a forráskód előllítása után, amikor az adott nyelv fordítójával valami (esetleg köztes) nyelvre fordítod, és utána az így előállított "binárist" futtatod - egy esetleg virtuális - gépen. Ellentétben a fent tölétetesen jól (bár értelmetlenül) magyarított tolmácsolt (azaz interpretált) futtatással, amikor is a kód megírása után azonnal futtatás történik, amikor is a futtatókörnyezet eleve a nyers forráskódot kapja, és lépésról lépésre, sorról-sorra értelmezi a kódot és hajtja azt végre.

Persze lehet ezt a - nem szép - definíciót eléggé elbonyolítani / megkavarni, lásd a C nyelvi intepreterek (cint / cling)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Fordított nyelvnek itt van például a nagysikerű dc, amely minden Linux rendszer tartozéka. Egy igazi RPN logikás igásló.
És már mehet is internet és számítógép nélküli ZH kérdésnek a "mit ír ki".

$ dc -e '_640320[0ksslk3^16lkd12+sk*-lm*lhd1+sh3^/smlxlj*sxll545140134+dsllm*lxlnk/ls+dls!=P]sP3^sj7sn[6sk1ddshsxsm13591409dsllPx10005v426880*ls/K3-k1/pcln14+snlMx]dsMx' | head

( Hevi v | 2023. 07. 03., h – 11:48 )

Kedvenc fordított programozási nyelvem: avaJ

Amúgy miért nincs Swift opció?

Azért a D és a Nim is megért volna egy misét, vagy legalábbis egy jelölő karikát. Értem én, hogy egyik sem terjedt el széles körben, de azért használják profi célra is mindkettőt, meg azért sok embernek hobbi nyelve is. Főleg a Nim, egyszerű, Python-szerű szintaxisa miatt. Ugyanakkor mindkettő eléggé powerful, olyan feature-kal, amelyek más nyelvekben nincsenek.

Ugyanakkor mindkettő eléggé powerful, olyan feature-kal, amelyek más nyelvekben nincsenek.

De ilyenkor miert nem irjatok oda, hogy "..., peldaul ..."? :)

Szerintem tok erdekes lenne, mert egy embernek biztos nem lesz ideje az osszes programnyelvvel megismerkedni, ebbol viszont lehetne tanulni valami ujat. 

Itt van fölötted a példa, hogy valaki valamit sikerrel kért. El tudom képzelni, hogy ha szólsz, akkor trey beteszi. Meg persze azt is, hogy nem, mert akkor (pl.) már túl sok macera lenne feldolgozni. És ha valakinek tényleg a - mondjuk - Nim a kedvence, akkor törli a korábbi szavazatát, és rá szavaz. No de ha nem is kéri senki ....

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( Raynes v | 2023. 07. 03., h – 18:23 )

Hobbistaként C-t és C++-t egyformán szeretem, de ha csak lehet, a minimalizmus miatt a C-t részesítem előnyben, főleg, ha tényleg egyszerű kódot kell írni (pl. egy pár paramétert lekezelő CLI tool), amihez a shell script esetleg nem elég már, vagy kényelmetlen (pl. matekozásra, amiben a shell script béna), nem elég gyors a kód, de a C++ meg overkill lehet. Pedig semmi extrát nem tud a C sem, ami miatt hű de szeretni lehetne. Régi, egyszerű, megy, van hozzá fordító minden platformra, még a retrókra is, lényegében amúgy is csak egy kispécizett macro assembly. Univerzális közös nevező, elég jó a mai napig. Ja, nem memory meg thread safe, de az nem minden projektben fontos.

Meglep, hogy a Javát és a Pascalt ennyien szeretik. Elhiszem, ha tud keresni vele, na de hogy szeretni? Pascalnál talán még megértem, nekem is nosztalgikus, 20+ éve sokat programoztam benne, de ma már nem látom a létjogosultságát kb. semmihez. Az a kevés ember is, aki még ezen a vonalon mozog, max. csak azért van rajta, mert keresni tud vele, de akkor is inkább Delphit használnak.

A funkcionális nyelvek tetszenének, főleg a Lisp (ez most ebben a szavazásban nem játszott, mert interpretált) és a Haskell, elismerem, hogy elegánsak, de egyszerűen nem tud ráállni az agyam a funkcionális paradigmára. Annyira szokatlan és nyakatekert, annyi mindent máshogy kell csinálni és végig gondolni, átfogalmazni benne, így akárhányszor nekifutok, mindig lepattanok róla.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Én azt szeretem a Javában, hogy olyan matematika-szerű: ha leírok valamit, akkor az egy egészen pontos definíciója annak, hogy mit kell csinálni. Ez a tulajdonsága sokkal szimpatikusabb, mint a C, ami tele van undefined behaviour-rel.

Tudom, hogy nem a Java az egyetlen ilyen nyelv, de ezen kívül azt is szeretem benne, hogy évek óta használom és kiismertem mindenét. Mint egy házasság, olyan már.

Például a Python az ami nagyon divatos mostanában, azt nagyon nem szeretem, mert szerintem minden gagyi, ami nem erősen típusos. Tehát a compiler a kód egy adott pontján pontosan tudja, hogy az adott ojjektum milyen típusú lehet, és mit lehet csinálni ezzel a típussal. Ebben sem egyedi a Java, de egy rakás alternatívánál emiatt szeretem jobban. Hasonlóan a JS alapú dolgokat sem szeretem. Tudom, hogy ott a TypeScript, azt emiatt akár szerethetném is, de ahhoz képest meg az a jó a Javában, hogy a runtime legalább 10x hatékonyabb.

A Kotlin, amit valaki fentebb említett lehet, hogy jobb lenne mint a Java, de még sosem próbáltam. Nem érzem szükségét, mert nem a nyelv a szűk keresztmetszet a fejlesztési időben az esetek 99%-ában. De talán jó lenne, csak hát el kellene kezdeni ahhoz...

( arpi_esp v | 2023. 07. 03., h – 20:23 )

Szerkesztve: 2023. 07. 03., h – 20:23

C, ez nem kerdes:

 

    unsigned char address4[4]={0,0,0,0};
    int len=0;
    const char* p=buffer;
    while(1){
        int c=*p++;
        if(!c && len==3) return locdb_lookup4(address4); // end of strings and we have 3 dots in it
        if(c=='.'){ if(++len>=4) break; } // max 3 dots! :)
        else if('0'<=c && c<='9'){ int x=(int)(address4[len])*10 + (c-'0'); if(x>255) break; address4[len]=x; }
        else break; // only dot & numbers are allowed here
    }

( bzt | 2023. 07. 03., h – 20:52 )

Ennek így ebben a formában semmi értelme. Fordított nyelvek?

Most vagy vegyük le a listáról a C#-ot, Java-t, Kotlin-t, vagy pedig adjuk hozzá a listához a LISP-et, JavaScript-et, PHP-t, Lua-t, Python-t, BASIC-et, mert ezek is mind ugyanúgy bytecode-ra fordulnak, mint azok.

> Pedig semmi extrát nem tud a C

Szerintem de. Tipp: mutass egyetlen másik nyelvet, ahol egy 30 éve írt forrás lefordul a legfrissebb fordítóval! Rust-nak, Go-nak már az is gondot okoz, hogy egy fél éve nem karbantartott repót lefordítsanak, mi lesz itt hosszú távon?

Ha valami régi C kód nem fordulna, az mindig a libek hibája, és sosem a nyelvé. A C visszafele kompatíbilis, ráadásul minden C fordítóban van -std= kapcsoló, biztos, ami biztos.
Na ez rohadtul hiányzik az összes többi fordítóból, lesz majd itt még sírás-rívás 10 év múlva, amikor (akkor már) régi mondjuk Rust programot akar valaki lefordítani a majdani architektúrára a majdani oprendszeren a majdani fordítóval!

(Ráadásul a C-s platformfüggő libhívások egyszerű s///g-vel javíthatók, ahogy pl. ESR bácsi is tette a vms-empire-el, amikor VMS-es verzióról portolta ANSI C libc-re. Vagy ott a Doom, amit 1997-ben, majdnem 30 éve portolt Carmak Linuxra, és még mindig lefordul és működik a legújabb make+gcc-vel! https://github.com/id-Software/DOOM/tree/master/linuxdoom-1.10)

+sok.  most forditottam le egy 2010-ben irt C kodomat, hiba nelkul ment a legujabb gcc-vel.

> ezek is mind ugyanúgy bytecode-ra fordulnak

jo de mondjuk ezek belul "maguktol" fordulnak futaskor (mint egy JIT), nem pedig a user forditja le 2 lepesben, mint pl. java/c# eseten...

> Rust-nak, Go-nak már az is gondot okoz

remekul hangzik... :(

php is ilyen, a python nem ennyire de azert ott is hozza kell nyulni 1-2 evente a kodhoz hogy tovabb mukodjon...

remekul hangzik... :(

Es mennyire hihetetlen hogy ma mar ezt teljesen normalisnak veszik hogy "ja, igen, megirjuk, de majd par ev mulva ugyis hozza kell nyulni". 

De igen, a C-ben az a jo hogy a/ megirtad valamikor es meg mindig ugyanugy jol megy b/ megirod egy architekturara es minden mas architekturan ugyanugy jol megy. Ezutobbira jo pelda lehet amikor sajat AVR vagy RISC-V procikra irt C lib-eket hasznalunk 1:1-ben x86_64-es linuxok alatt is. 

Szerintem de. Tipp: mutass egyetlen másik nyelvet, ahol egy 30 éve írt forrás lefordul a legfrissebb fordítóval! Rust-nak, Go-nak már az is gondot okoz, hogy egy fél éve ...

Esetleg Fortran? 60 éves C kód vs. 60 éves Fortran kód? Na 60 éves C kód nem lesz.
Emlékszem a Fortran-t sok évtizede a BME-n a diákként temettük, viccelődtünk rajta. Ennek ellenére hazánkban is tudok helyekről, ahol a Fortran még igencsak élő nyelv.
Szabányát nézve a Fortran-2018 ISO/IEC szabvány után most fog jönni a Fortran-2023. Nem passzióból.
A témaidítóban a listán persze mi is jól eltemettük, legalábbis nem került bele.

És akkor a kontraszt kedvéért a fiatal versenyző, amely állítólag fél éves kódot sem tud lefordítani. A 6 éve írt kódjaimat is szépen lefordítja.
Ha magától nem, akkor kis rásegítéssel: mond meg, mely "szabvány" szerinti a kód? Olyan, mint a -std=... kapcsoló C és C++ esetén.
Itt a Cargo.toml fájlba írd be:

edition = "2015"   # vagy 2018 2021 2024 ...

Szóval Rust fordító esetén teljes visszafelé kompatibilitás biztosított a legelőször széleskörben publikált verzióig (Rust-1.0).

> Rust-nak, Go-nak már az is gondot okoz, hogy egy fél éve nem karbantartott repót lefordítsanak, mi lesz itt hosszú távon?

A Go-nal remelem reportoltad a bugot, merthogy hivatalosan a policy az az hogy regi kod is fordithato az uj forditoval (forras: https://go.dev/doc/go1compat )

 

It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. At some indefinite point, a Go 2 specification may arise, but until that time, Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.).

Compatibility is at the source level. Binary compatibility for compiled packages is not guaranteed between releases. After a point release, Go source will need to be recompiled to link against the new release.

The APIs may grow, acquiring new packages and features, but not in a way that breaks existing Go 1 code.

Kiemelem ezt a részt:

"Ha valami régi C kód nem fordulna, az mindig a libek hibája, és sosem a nyelvé. A C visszafele kompatíbilis, ráadásul minden C fordítóban van -std= kapcsoló, biztos, ami biztos."

 

Azért láttunk már olyat, amikor tört a visszafelé kompatibilitás. És a -std sem egyértelműen létező opció - a clang és a gcc (sőt a pcc is) támogatja, de most kapásból a Bellard-féle TCC-t találtam, amelyik nem ismeri. Persze valószínűleg sok elterjedt fordítónál van valami hasonló - tán még ennél is, csak én nem vettem észre.

Pár példa a visszafelé kompatibilitás törésre:

K&R C vs ANSI C:

j =- 1 vs j -= 1

main( argc, argv )

int argc;

char **argv;

vs

int main( int argc; char *argv[])

mintha lett volna gond a void * -gal, a hiányzó fv-szignatúrákkal; most mintha a register kulcsszó lenne zavaró (de lehet hogy keverem, és az C++-ban veszett el az idők és a szabványosítás során).

Azt amúgy elismerem, hogy sok esetben könnyű az ilyesmit s/// formában javítani, de nem mindent. És ekkor már ott tartunk, mint a modern nyelveknél, hogy kell némi kódigazítás.

 

 

 

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Bonyolítja a képet, hogy van a C kőbe vésett szabványa és vannak a jobb és hitványabb C fordító implementációk.
Na meg a #pragma cheet-ek, amik tényleg fordító függőek.

Bár tény, hogy elkényelmesedtünk. Leginkább GCC és CLANG ma a két versenyző. De menj le a hitványabb mikrovezérlők felé és csodálkozz rá az őskövület C fordítókra.
Egyszer belefutottam olyan 8 bites fordítóba, amelynek még az ANSI C néhány trükkje is túl bonyolult volt. Le kellett bontanom számára több apróbb részre a kifejezést, hogy le tudja fordítani.

> Rust-nak, Go-nak már az is gondot okoz, hogy egy fél éve nem karbantartott repót lefordítsanak

Rustnak edition-jei vannak, eddig 3.  A mai fordító is lefordítja a 2015-ös kódot, és az az alapértelmezés, hacsak nem paraméterezed 2018-ra vagy 2021-re.  Ez nem jelenti azt, hogy egy új edition könnyedén megborít bármit, emellett is kiemelt szempont a kompatibilitás.

( bzt | 2023. 07. 03., h – 21:43 )

> +sok. most forditottam le egy 2010-ben irt C kodomat, hiba nelkul ment a legujabb gcc-vel.

Wow! Nekem a rekordom egy 2003-as kód, bár kicsit bele kellett nyúlnom (az XFree86 videómódállítást ki kellett vennem, mivel az xorg alatt olyan már nincs). Minden más hiba nélkül fordul és megy, pedig 20 éve még nem voltam rutinos C programozó, szóval eléggé gáz a kód. :-)

> jo de mondjuk ezek belul "maguktol" fordulnak futaskor (mint egy JIT), nem pedig a user forditja le 2 lepesben, mint pl. java/c# eseten...

Ezt hogy érted? Tudtommal a Java és a C# is pont ugyanúgy JIT compileres, akárcsak a többi.
https://learn.microsoft.com/en-us/dotnet/standard/managed-execution-pro…
https://developers.redhat.com/articles/2021/06/23/how-jit-compiler-boos…

Ne érts félre, nem akarlak megcáfolni, csak tényleg nem értem, mitől lennének ezek a nyelvek bármiben mások, mint mondjuk a LISP (LLVMjit), JavaScript (wasm-jit), Lua (LuaJIT), PHP (PHP8 JIT) vagy Python (Numba, PyPy)? Én komolyan nem látok semmi különbséget köztük. De nem is vagyok Java vagy C# programozó, szóval simán lehet, hogy tévedek.

> remekul hangzik... :(

Hát sajnos ja. A mai suhancoknak lövésük sincs, milyen fontos is lenne ez. De majd pár év múlva úgyis rájönnek.

> Nekem a rekordom egy 2003-as kód

mondjuk a mailer3 meg 2000 elotti de abba idonkent belenyultam (uj featurek, 64 bit support etc) de az is fordul meg,m pedig '98 korul irix/aix-en fejlesztettem...

> Ezt hogy érted?

hogy az user kell eloszor egy kulon lepesben leforditsa a forraskodot binarisra (az hogy az egy bytecode lesz es nem nativ exe, ebbol a szempontbol lenyegtelen) es utana tudja azt futtatni.   pl. javac-vel fordul java-bol class-ra es azt tudja java programmal futattni. vagy dotnet eseten egy "exe" filet kapsz amit futtathasz de igazabol abban is bytecode van, nem nativ kod a loader utan.

mig pl. php, js, python eseten az user kozvetlen a php/py/js kodot futtatja, nem o fordit eloszor kezzel pyc-t vagy mast belole.

szoval technikailag valoban egy koztes bytecodera fordulnak ezek is futaskor, de errol az user nem tud semmit, mivel nem o forditja le egy kulon paranccsal/programmal/compilerrel, ugy mint java vagy dotnet eseten...

jo kerdes. megneztem a diff-et a 32 es 64 bites verzio kozott, ugy tunik elotte nem hasznaltam long-ot :)

 typedef struct rek_tip {
         int from;
         int to;
         int subject;
-        int date;
-        int pos;
+        unsigned int pos_hi; //date volt, de sose hasznaltuk
+        unsigned int pos;
         int size;
         int msize;
         int flags;
...

-  fseek(folder->file_folder,mail->pos,SEEK_SET);
+  fseeko(folder->file_folder,mail->pos+((long long)mail->pos_hi<<32),SEEK_SET);

Az int mérete az ősrégi K&R könyv szerint architektúra függő. A long volt amit fixként használtunk 32 bitre, a long long típust 64 bitre.
Azóta óvatosabb lettem, a C99-ben megjelent és évek alatt mindenhol elterjedt stdint.h szerinti int32_t, uint32_t és társait előszeretettel használom. Ezek tényleg fixek.

Rust esetén eleve tanultak ebből. Itt i8 .. i128 és unsignedként u8 .. u128 típusok vannak, na meg architektúra függő  isize és usize a memória indexeléshez.
Itt még annyi szigorítás történt, hogy közöttük az átjárás nem amolyan warning nélküli automatikus, hanem 'as' kulcsszóval neked meg kell mondanod, melyik konvertálódjon melyikké és csak az azonos típusokkal fog műveletet végrehajtani.

  let a: u32 = 4;
  let b: i32 = 6;
  let c = a as i32 + b;

> Az int mérete az ősrégi K&R könyv szerint architektúra függő.

Ez szerintem még mindig így van, az int mérete továbbra is architektúra függő (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf).

x86_64 alatt azért nem lett 64 bites, mert a természetes regiszterméret 32 bites (nem összetévesztendő a címbusz méretével). Külön opkód (egy bizonyos REX prefix) kell ugyanis a 64 bites regiszterek kódolásához.
AArch64-en is hasonló a helyzet, ott egy 0-ás bit jelenti az utasításban a 32 bites regisztereket (Wn, szóval vehetjük ezt a alapértelmezettnek), és 1-es bit a 64 biteseket (Xn). Legalábbis ha jól emlékszem, rég volt már, amikor ARM disasszemblert írtam.
RISC-V esetén nem tudom, mi a helyzet, de érdekelne. Ott mekkora az int? Az RV64I utasítások ugyanis alapból 64 bitesek, és a 32 bites variánsok a speciális esetek. (Gyanítom felrúgták a szabványt, és meghagyták az int-et 32 bitesnek a kompatíbilitás végett)

> szoval technikailag valoban egy koztes bytecodera fordulnak ezek is futaskor, de errol az user nem tud semmit, mivel nem o forditja le egy kulon paranccsal/programmal/compilerrel, ugy mint java vagy dotnet eseten...

Ja, így már értem. Valóban, de nem hiszem, hogy ez sokat számítana a _nyelv_ meghatározásánál. Az, hogy a fordítás után a JIT egyből meghívódik-e vagy külön parancs, inkább környezeti részletkérdésének tűnik, semmint a nyelv meghatározó elemének, szvsz. De így már világos, hogy egyesek miért dőlnek be ennek az "ez komoly nyelv" átverésnek.

> És mit szólt ahhoz az adatfolyamra cast-olt struktúrával működő feldolgozó, hogy a benne használt 4 byte-os long időközben 8 byte-osra változott?

Azt, hogy WIN32 alatt nem változott (mert lemaradtak az LP64-ről), és egyébként is, ha valaki adatfolyamra cast-ol struktúrát, akkor az úgyis stdint.h-t használ és sosem long-ot. Az stdint.h egy egyszerű, portolható és tökéletes megoldás, ráadásul a nyelv része (nem 3rd party, a C szabvány írja elő, hogy léteznie kell).

Ezt kifejezetten szeretem a C nyelvben: ha olyan struktúráról van szó, ami valamilyen bináris struktúrát ír le (EFI partíciós rekord, FAT BPB, mittomén PNG chunk fejléc), akkor arra ott az stdint.h. Ha meg ki akarod használni azt, hogy a jövőben egy erősebb architektúrán nagyobb kapacitású legyen a programod (annélkül, hogy módosítani kellene a forráson), akkor meg int/long. A döntés a programozó kezében van. Amikor kezdtem, akkor az int még 2 byteos volt például (TurboC).

Mondjuk ez miért ellentmondás a szabvánnyal? Az én emlékem ezzel kapcsolatban ez:

sizeof( short ) <= sizeof ( int ) <= sizeof( long )

A man-ban megtaláltam, hogy ekkor a long 2 byte-os. (Igaz azt nem, hogy a short is 1-byte-os lenne.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Azért nem konform, mert ugyan a fenti egyenlőtlenségek igazak mindig, de ez úgymond nem a specifikáció, hanem csak egy következmény.

A szabvány felsorolra a limits.h-ban definiált konstansokat, megad értékeket,  és előírja a konform implementációkban lévő értékekre ilyet: "Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.".

Lásd: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf, 26-27-ik oldal.

És itt:

minimum value for an object of type int INT_MIN -32767

maximum value for an object of type int INT_MAX +32767

Tehát egy int legnagyobb értéke legalább 32767, az ennél kisebb int az nem szabványos.

Ez még K&R idejében is így volt.

Persze a multiplex buszon jó kérdés. (8088)

POWER arch, ahol 30 éve 256 bit a memória szélesség és az MMU előtt egy switch kezelte a memóriakártyát, ott meg nem is érdekes. Ugyanis egy ciklus allatt több címről is képes olvasni.

64 bites procin, 64 bitre fordítva egy 64 bites load 1 órajel. 32 bitre fordítva már két utasítás, ahol az egyik 1 órajel, a másik meg 0 órajel. ;)

Tudom, az én hibám. :( Elfelejtettem odaírni, hogy a következő sorok is POWER-re (mint féleség) vonantkoznak.

Ha már 64 bit, akkor legalább POWER4-ről van szó. (wait cycling --> A POWER4 cpuclock/3 órajellel olvas, míg a POWER5 memoryclock sebességgel, ami kicsit gyorsabb. Az MMU 8 csatornán olvas és 4 csatornán ír.)  Szóval nem 8080-szerű, vagy IBM PC-szerű hardverről van szó. ;) Ennek az egész erőlködésnek az a lényege, hogy a 8 párhuzamos végrehajtóegység (amelyből rossz esetben is 6 működik) az 1 órajel alatt végrehajtott 8 utasítást ne csak a mesében tudja, hanem a valóságban is. ;)

A hivatkozott órajelszámot a C fordító assembly listájában megjelenő ún. straight-line execution time alapján írtam. És el is hiszem, mert mértem. :-D (Nem, nem a load idejét, hanem a memóriában csücsülő adatbázist lekérdező függvény 40Mx futásidejét.)

Igaz, a POWER4 már jó 20 éves technológia, de tanulmányozhatnád és utána újabb  rejtélyes szakkifejezésekkel tudnád a nálam naivabbakat riogatni. :-D

Itten fentebb leginkabb arra gondoltam gondolt a költő hogy legyen bármilyen szuper-fancy vagy akár egyszerű-de-nagyszerű is az architektúra, ha valamiféle külső dolog (egy vagy több másik CPU, cache, DMA, ...) már megjelenik a CPU mag mellett, akkor már ugrik ez az "x típusú utasítás y órajel alatt minden esetben végre is hajtódik" jellegű definit, jól időzíthető működés. Sőt, a gyakorlatban az AVR*-on kívül nem is ismerek más implementációt ahol pont ezen külső dolgok teljes hiánya miatt jól számítható az időzítés. Esetleg még az egyszerűbb PIC-ek lehetnek ilyenek.

Látom, 32 way SMP-re kihegyezett szerverprocesszor annyit jelent számodra, hogy biztosan AVR vagy PIC az összehasonlítási alap. ;) Pedig odaírtam, hogy tanulmányozhatnád a 20 éves technológiát, milyen buszok, hogyan kötve és mit csinálnak. Lényegében néhány könyvet érdemes lenne elolvasnod, és leesne, hogy nem csak ágyugolyóval lehet a Holdra utazni. Hogy ne ragadjunk le a PIC szintjénél (ami ugye NEM szerverbe való), itt egy részlet a POWER4 és IA64 szempontunkból lényeges eltérésének rövid elemzéséből (forrás):

Another  radical  difference  between  these  two  processors  concerns  the  scheduling,
dynamic on the POWER4 and EPIC-static scheduling for servers. In the presence of cache
misses,  the  POWER4  dynamically  remakes  the  instruction  schedule,  thereby  avoiding
pipeline stalls on cache misses. IA-64 machines, because of their in-order execution and
static instruction groupings, are less adaptive. If EPIC compilers for traditional code are a
challenge,  dynamic  just-in-time  compilers  (JIT’s)  for  Java  will  be  a  nightmare.  Java
performance  is  a  serious  issue  for  IBM,  which  has  the  second-largest  cadre  of  Java
programmers in the world, next to Sun (Sun probably agrees with IBM’s concerns about
EPIC, as  its new MACJ architecture has many features that are radically different from
IA-64 for just these reasons).

Tehát itt nem a bus wait, hanem a cache miss is már olyan súlyos esemény, hogy a CPU inkább átszervezi röptében a végrehajtást, mintsem egy órajelet is veszítsen. (az ugye 8 utasítás) Ehhez a pipeline címzése sokkal keskenyebb (mint pl. a korabeli AMD CPU-nál, pedig akkoriban az AMD és IBM együtt dolgozott), viszont sokkal bonyolultabb logika áll mögötte. Persze idióta programmal bármilyen lassulást elő lehet idézni. Mondjuk folyamatosan másolgatod a memóriát jobbra balra DMA segitségével, az biztosan befolyásol valamit. A memória-DMA-IO  nem valószínű, mert a memória sebessége nagységrenddekkel nagyobb. A POWER4 előtti 4x112,5 MHz PowerPc604 munkagépem (1995) 1,8 GB/s, dilettáns multiprogramozás mellett 0,8 GB/s memóriabusz-sebességgel működött. Ez a max. 8 CPU-hoz elegendő, tehát soha nem láttuk, mert nekünk csak 4 volt. ;)

Természetesen jöhetnek közbe nem várt események, pl. interrupt. Az említett mérés mmap-pelt memória adatbázison történt, amely már teljes terjedelmében be volt lapozva. A 40M lekérdezés alatt az egyéb eseményekből származó overhead elhanyagolható volt, ezért az elméleti straight-line execution time megegyezett a mért értékkel.

És különben is, ha az utasítás végrehajtására egy órát (nem órajelet) vár a CPU, majd végrehajtja a 64 bites load-ot, az biztosan 1 órajel lesz. A két 32 bites load végrehajtási ideje (1 és 0 órajel) szintén 1 órajel lesz, mert két LD egység működik parhuzamosan.

Sokszor nem a memoria, hanem a futasido a kerdes. Ha int-et valasztasz, az is jellemzoen legalabb 16 bit (ld. fenti kivetelt), de tudod rola, hogy amilyen architekturan fut, ott a proci kenyelmesen hasznalja. Szoval gyors lesz mondjuk x86-on, x64-en, es ARM-on is. Persze ettol meg megadhatod pontosan.

A strange game. The only winning move is not to play. How about a nice game of chess?

Igen, ez a resze egyertelmu. Ha nem fer el, akkor nem jo a meret.

A kerdeses inkabb az, hogy ha van egy - mondjuk 0-100 kozti egesz ertek, akkor arra mit valassz? 8 biten elfer (ha signed, ha unsigned). Ha egy tombben van 1000000 ilyen, akkor celszeru a legkisebbet valasztani. De ha nincs sok, es szamolsz vele, siman lehet, hogy jobban jarsz mondjuk 32 bitessel, ha a konkret architekturad mondjuk azt jobban tamogatja - gyorsabb kodot fordit. 32 bites ARM-on megerheti bealdozni 3 byte-ot, hogy egy ciklus kozepen nyerj jopar utasitast. De mi van, ha 64 bites az architektura? Mi van, ha 32 bites, de jol tamogatja a kisebb adatokat is (nem csak ugy, hogy 4 byte-ot kiolvas, aztan kimaszkolja/shifteli)?

A strange game. The only winning move is not to play. How about a nice game of chess?

( emberk | 2023. 07. 04., k – 09:52 )

Fortran :), sajnos mér nem hasznlom, de volt egy varázsa.