Linguaggi a confronto.

[Z80Fan]

• 

Molti sono ossessionati dal performance a tutti i costi, di conseguenza programmano con lo stesso linguaggio del sistema operativo.
In un sistema operativo se non vuoi overhead nelle chiamate di sistema devi scrivere le applicazioni nello stesso linguaggio.

Non si può creare un compilatore (linker) Pascal che genera il codice con la calling convention e i formati del C?
Perchè dici che l'integer del Pascal è diverso dall'int del C? Per via delle diverse lunghezze del campo? Perchè in C un intero potrebbe contenere un puntatore?
Perchè mettere i parametri da destra a sinistra è più lento che metterli da sinistra a destra?

Per TheKaneB:
http://brinch-hansen.net/memoirs/photos ... c4000.html
Lui impiegò quasi due anni per assemblarselo, pensi di competere con un nerd del genere?

Ci posso provare io; avendo tutti i pezzi posso fare anche in meno tempo. :ugeek:

Un esempio che mi viene in mente è quella porcata di GTK: un framework a oggetti realizzato in C. Un autentico abominio, insomma, e si vede a colpo d'occhio:

Ovviamente colui che ha deciso di usare un linguaggio non ad oggetti per creare interfacce grafiche è un demente che dovrebbe essere rinchiuso a vita.

Onestamente l'ho detto giusto per dare una motivazione a Z80Fan e non sembrare il solito estremista, diciamo che è un luogo comune che il C vada bene per i sistemi operativi e per il low-level, distruggere i luoghi comuni è difficile, per questo motivo l'ho detto.

Invece voglio proprio che tu li distrugga, ti chiedo di spiegarmi come stanno le cose, non farmi contento perchè sennò mi metto a piangere!

Non ho da commentare gli altri post.

Allora non vedo alcun vantaggio a usare il C, se non per la sintassi concisa (ma ben poco leggibile).

Infatti è proprio quello che mi son messo a indagare. :think:

[Z80Fan]

• 

Usare gli interi come stringa, una figata eh?

Uhm, no, è una cosa stupida perchè non guadagni nulla in spazio e complichi il codice. Mi dispiace.

La vera differenza tra strong e weak typing è questa. Di conseguenza in Pascal un intero ha un significato nettamente diverso dal C. Magari con una funzione che ritorna un intero io in realtà sto ritornando una stringa, un carattere o qualsiasi altra cosa sia e in Pascal non ho alcun modo per leggerla.

Ma se so che il ritorno è un intero (metti che c'è una stupida funzione che fa una somma), non posso usarlo in Pascal?

Per esempio getchar() torna un intero per carattere perché in C (vedi che furbi) usano il valore di ritorno anche per la gestione degli errori, non hai alcun modo di utilizzarlo in Pascal come carattere. Potresti forzare l'importazione cambiando il valore di ritorno con il char del Pascal, ma quando getchar() ti ritorna -1 perché l'EOF è stato raggiungo, il programma ti va in runtime error.

Non si può fare qualcosa del genere:

Codice: [Seleziona]

var = getcharC();
if var = -1 then
    gestisciGliErroriComeSiFaInPascal();
else
    return convertiInCarattere(var);
C'è questo piccolo codice da aggiungere ad una eventuale getchar() del Pascal, ma è lo stesso codice che si dovrebbe implementare in C (vedi che furbi! ).
Poi si parlava dell'usare un altro linguaggio in UNIX, le sue syscall trattano principalmente con numeri interi (che sia un id di un oggetto, una dimensione o un offset).

Diciamo che quello descritto sopra era il calling convention di default prima che il C fosse così diffuso.

Quindi non è più così? Infatti mi sembrava strano, perchè mi permette di ritornare strutture. :think:

i puntatori non sono il massimo dell'efficienza

Questa non la ho proprio capita: alla fine, linguaggio di alto livello o non, a tutto si accede attraverso puntatori; dove sarebbe la penalizzazione nell'usarli? :think:

Come mai a te piace il C/C++?

Io ho scelto il C per programmare il mio OS perchè è semplice, non ha bisogno di una VM o di runtime support, e mi permette di gestire la memoria come voglio io (cosa importante, visto che se programmi un kernel la memoria devi gestirla a mano, byte per byte ). Non ho scelto il C++ perchè quest'ultimo ha bisogno di un leggero strato di runtime support, ma vedendo i vantaggi rispetto al C (ad esempio, i template), penso che lo riscriverò in questo linguaggio (non che sia un gran lavoro).
Per un gioco che sto sviluppando (un clone potenziato di Minecraft), invece, ho scelto di usare il C++, perchè mi permetteva di ottenere buone prestazioni (Java, con cui è scritto attualmente Minecraft, si può dire quel che si vuole, ma è un mattone anche sul mio PC che non è proprio un bidone; immagina sul mio netbook). Gestire la memoria a mano non mi preoccupa minimamente, perchè gestendo tutto con opportune classi, creo la memoria nel costruttore e la distruggo nel distruttore; non ho bisogno di portarmi puntatori in giro per il programma e dimenticare di eliminarli.
La sintassi di entrambi i programmi non la trovo un problema, non è un problema per me se devo scrivere == e non =, e la capisco meglio di tanti altri linguaggi (sarà perchè lo conosco molto bene, ma lo trovo talvolta più semplice di molti altri linguaggi).

[cdimauro]

• 

Un paio di note.

@Z80Fan: proprio per il fatto che il C può usare gli interi come gli pare, esporre un'interfaccia per altri linguaggi è molto problematico, come ha spiegato correttamente dsar.

Immagina il lavoro che deve fare il generatore di uno stub / interface per un determinato linguaggio, partendo dall'header scritto in C: non sapendo quale tipo utilizzare effettivamente per quel linguaggio, dovrà optare per qualcosa di simile all'int, lasciando poi al programmatore a sbrogliare la matassa.

@dsar: i confronti (load / store in generale) fatti "per word" non necessariamente producono segfault se i dati non sono allineati alla word. Dipende tutto dall'architettura.

[TheKaneB]

• 

ci sono alcune architetture (tipo ARM fino alla revisione v5) dove proprio fisicamente non puoi nemmeno specificarlo un indirizzo che non sia word-aligned (2 o 4 byte, in base all'ISA utilizzata, cioè Thumb o ARM). Fisicamente le linee di indirizzi sono 31, e la trentaduesima è hardwired a 0.   :shifty:
Il bit meno significativo del Program Counter viene infatti usato per stabilire se la prossima istruzione è in modalità Thumb oppure ARM.

Quindi un branch all'indirizzo 0x400 mette la cpu in modo ARM, mentre se faccio branch a 0x401 comunque eseguirà l'istruzione alla locazione 0x400 ma interpretandola con l'ISA Thumb. Il cambio di ISA si può fare, potenzialmente, ad ogni branch. Questo consente di generare codice misto che può privilegiare lo spazio occupato o le prestazioni (a discrezione del compilatore).

Tuttavia questo vale solo per le istruzioni, perchè i dati saranno sempre allineati alla word (specialmente l'accesso allo stack), con i due bit meno significativi dell'address bus hardwired a 0.

Da ARMv6 in poi le cose sono diventate più flessibili, ed è possibile accedere a dati non allineati. Tuttavia il memory controller dovrà fare due fetch distinti e riproporre il dato allineato alla CPU. Questo comporta penalità nelle prestazioni ma previene errori di programmazioni che possono causare letture / scritture erratiche.

[TheKaneB]

• 

Quando lavoravo su PS3 (IBM Cell, una specie di PowerPC), capitava spessissimo un errore che il compilatore avrebbe potuto evitare in automatico, mentre toccava a noi programmatori aggiustare manualmente.

L'OS integrato nella PS3 gestisce thread e sincronizzazione, esponendo le apposite primitive nell'SDK.
Dal momento che quella CPU integra delle operazioni di test-and-set atomiche, queste vengono usate dall'SDK per implementare i semafori in modo "safe" (diciamo). Il problema è che se includi un semaforo dentro una classe, questo semaforo subisce l'allineamento della classe e non sempre era word-aligned (perchè!?) quindi dovevamo specificare a mano l'attributo __attribute__(aligned((128)) su ogni classe e struttura che contenesse un semaforo, altrimenti il lock non avveniva correttamente, senza tuttavia causare errori in runtime. Ovviamente il problema sorgeva solo in caso di race condition, e soltanto compilando in release!

[TheKaneB]

• 

...chiaro che fosse un problema di GCC, infatti su XBox360 (sempre IBM PowerPC), con compilatore microsoft, non vi era alcun problema di allineamento. Usando il compilatore SNC (una roba di Sony) il problema non sussisteva, probabilmente perchè allineava in automatico in modo intelligente (il codice era anche mediamente più prestante e compilava 4 volte più velocemente).

[Z80Fan]

• 

Fare la comparazione di una stringa byte per byte è più lento di farlo word per word. Word per word ne compari 4 al volo in una piattaforma 32 bit. Ovviamente non sempre si può fare e qui il compilatore può venirti in aiuto. Se la stringa è di 7 byte non puoi fare la comparazione word per word, se lo lasci fare al compilatore lui in realtà alloca 8 byte (lo filla di byte dummy) e poi fa la comparazione word per word. Non ricordo come si chiama, per-word allocation boundary o aligned word allocation.

Si può anche comparare a word la parte iniziale della stringa, e completare a byte. Ho fatto una cosa simile per una memcpy per l'OS, visto che devo gestire le bitmap sullo schermo via cpu, ho fatto in modo di usare la più grande word che la cpu può caricare per la parte centrale del blocco, e poi copiare singoli byte per allineare all'inizio e completare alla fine (la cosa ideale sarebbe usare dell'assembly e caricare i dati con le istruzioni vettoriali da 128 bit).

In assembly x86 se il compilatore ti aiuta può usare rep cmpsw (compsw = comparison word).

Queste vecchie istruzioni sono emulate attraverso microcodice, non so se gli ultimi modelli la possono eseguire direttamente in hardware.

Diciamo di sì, ma questo devi considerarlo un caso semplice e soprattutto c'è il fatto che nessuno andrebbe a cambiare la funzione getchar() del C, ma tu non puoi affidarti alla buona fede dei programmatori.
Prendiamo altri casi molto realistici, in cui un software viene esteso sempre. Il fatto che un intero venga usato per la gestione degli errori, tu domani non sai se ci sarà da gestire anche un -2 e il tuo programma andrà in runtime error perché chr() si ritrova a converire il valore -2 che è fuori range [0 .. 255].

Dovresti fare un design migliore e wrappare la funzione in modo più sicuro (e che in futuro tu possa estendere), immagina un modulo separato che riceve caratteri dal getchar, tipo così:

Codice: [Seleziona]

type GetResult = (char, eof, unexpected);
[...]
intres : integer;   (* getchar's integer result value *)
realch : char;      (* pascal character *)
mean   : GetResult; (* result's meaning *)

intres := getcharC();
if intres = -1 then
  [...]
  mean := GetResult.eof
elsif intres in [0 .. 255] then (* oppure ch >= 0 and ch <= 255, ma usare l'in è più veloce in Pascal *)
  realch := chr(intres);
  mean := GetResult.char
else
  mean := GetResult.unexpected;
  [...]
  furthercondition(intres)
end


Ecco, proprio così. Aggiunge così tanto overhead e complessità che uno fa prima ad usare il C piuttosto che convertire Pascal?

Infatti Modula-3 (che è molto UNIX-centric, cioè è stato sviluppato per essere programmato su questa piattaforma) usa un layer di interfaccia per le chiamate.

Ed è molto pesante?

Comunque ricordavo male, il C può tornare valori strutturati per le strutture ma non per gli array (che concettualmente è anche structured).

Si perchè gli array sono semplicemente puntatori al primo elemento. Per poter tornare un "vero" array per valore, bisogna creare una struttura al cui interno c'è il vettore. Ovviamente, se il vettore è un po' più lungo di qualche decina di byte, questa soluzione è assolutamente lenta per via della copia dei dati al ritorno della funzione.

Infatti l'ottimizzazione consiste nell'evitare di deferenziare continuamente la memoria quando leggi o scrivi molto in una struttura dati.

Però, fai conto, se ho un algoritmo che lavora su un vettore, e ha bisogno della cella corrente, e della successiva, e fa diversi calcoli su questi due dati. Anche se scrivo a e a[i+1] ovunque, il compilatore cmq riconosce che "i" non cambia e salva i dati nei registri, senza troppo bisogno di specificarlo. Poi ovvio, se uno usa il compilatore degli anni '60, è inutile anche parlare.

Dovrebbe invece. I memory leak avvengono sempre, basta guardare il changelog di qualsiasi progetto opensource, i distruttori vanno bene per robette semplici e risorse limitate. In strutture (o classi) davvero complesse i casini si combinano ugualmente. Se fosse tutto così semplice, non esisterebbero i GC ;-)
Il GC non è il male, soprattutto quando i vantaggi superano i suoi svantaggi. (Uno di questi è la deframmentazione con il copying collector)

Io non ho detto che il GC è brutto e cattivo; io ho detto che non ho problemi a gestire la memoria manualmente, e mi dispiace per quei programmatori opensource.
Io so che, nella mia esperienza, se ogni classe si gestisce la sua memoria, non c'è nessun problema; ad esempio, in una lista di nodi, se ogni nodo è una classe, e ogni nodo ha un puntatore al suo successivo, il distruttore si riduce a un "delete successivo" e, automaticamente e ricorsivamente, tutta la lista viene eliminata e la memoria liberata. I problemi vengono quando si vuole avere una classe principale che fa da lista e tante altre classi secondarie che fanno da nodo, e alla classe principale si da il compito di gestire la memoria delle classi nodo, che diventano praticamente delle semplici strutture. Se proprio di vuole andare sicuri, si crea una stupida classe "safe pointer" che si preoccupa di eliminare l'elemento a cui punta quando viene distrutta, ma, ripeto, IO non ne ho mai avuto bisogno.

Tempo fa quando i developer di FreeBSD decisero di adottare lo static analyzer di Coverity, scoprirono circa un centinaio di bug nelle expression dovuti a mistyping di == con = nelle expression, e stiamo parlando di developer con anni di coding alle spalle. Inoltre il codice viene sempre revisionato da una o più persone e sono sfuggiti ai loro occhi. Magicamente sparirono bug che da anni si presentavano raramente.
I bug trovati da Coverity erano bug del tutto leciti nel C code, se non ricordo male i bug fixati furono sul migliaio in totale.

Non ho negato che può essere un problema, tu mi hai chiesto perchè usassi il C/C++ e ti ho dato delle motivazioni, che sono assolutamente dal MIO punto di vista. Non sto dicendo che i programmatori FreeBSD sono delle pippe o che è impossibile scambiare == con =; solo che a me non ha mai causato problemi.

Brainfuck (esiste davvero)

Si, lo conosco; quello lo uso per il software applicativo.

gli OS sono tutti in C :-) dal mio punto di vista perdono di tantissimo l'interesse da parte di curiosi.

Secondo me un OS "interessante" lo è se implementa qualche algoritmo o qualche soluzione interessante; neanche Modula-3 può rendere interessante un comune kernel monolitico.

Perché non provi Go? Scopiazzato interamente da Oberon-2, però ha la sintassi del C (se adotti una sintassi diversa, non ha diffusione).
Ha tutto ciò che serve per il system programming.

Perchè lo hai detto tu stesso, è uno scopiazzo!
Abbiamo già millemila linguaggi, preferisco molto più impararmi Oberon-2 piuttosto che un linguaggio che è la solita minestra riscaldata, e che magari sparirà con l'arrivo della nuova moda.

Immagina il lavoro che deve fare il generatore di uno stub / interface per un determinato linguaggio, partendo dall'header scritto in C: non sapendo quale tipo utilizzare effettivamente per quel linguaggio, dovrà optare per qualcosa di simile all'int, lasciando poi al programmatore a sbrogliare la matassa.

Ovviamente se lo fai fare a un sistema automatico, non puoi aspettarti del buon codice; un'interfaccia tra i due linguaggi va fatta da un programmatore umano che conosce i due linguaggi e sa, oltre al tipo di dati richiesti, il contenuto di quei dati. Solo in questo modo puoi sperare di avere un'interfaccia corretta.

Usando il compilatore SNC (una roba di Sony) il problema non sussisteva, probabilmente perchè allineava in automatico in modo intelligente (il codice era anche mediamente più prestante e compilava 4 volte più velocemente).

Perchè usevate GCC allora?

[cdimauro]

• 

Non serve un programmatore per fare la conversione. Serve un linguaggio dichiarativo che permetta di stabilire in maniera precisa la natura di ogni dato (e il modo in cui dev'essere passato).

Riguardo al GCC e i problemi di allineamento, è un problema ricorrente di cui ho parlato anche nell'articolo che ho scritto sul GCC (verso la fine).

[Allanon]

• 

E' veramente affascinante leggere tutto ciò  
Continuate pure, io vi ascolto (=leggo) in silenzio religioso

[ncc-1700]

• 

E' veramente affascinante leggere tutto ciò  
Continuate pure, io vi ascolto (=leggo) in silenzio religioso

Affascinante, ecco il concetto che ho provato nel leggere tutto ciò, mi metto anche io in mistico silenzio.

Ciao,
ncc-1700

[AmigaCori]

• 

Non capisco anche io perche' hanno usato il GCC (non e' in tono provocatorio ), credevo che fosse usato perche' copre molte architetture e quindi venisse usato per un fattore di comodita', pero' dai casi sopra ho letto di Xbox, PS3, quindi architetture specifiche con i compilatori della "casa" quindi mi chiedevo il motivo per cui avessero usato il GCC

[TheKaneB]

• 

SN Systems sforna compilatori per Sony già dagli inizi della PS2.

Il motivo è molto più prosaico... il kit incluso nel prezzo è basato su GCC e pensavano fosse sufficiente, poi gli ingegneri dell'engine si sono rotti il .... e hanno alzato la voce "compratelo sto ..... di SNC". E così fu luce, e vidi che ciò era buono.

[AmigaCori]

• 

SN Systems sforna compilatori per Sony già dagli inizi della PS2.

Il motivo è molto più prosaico... il kit incluso nel prezzo è basato su GCC e pensavano fosse sufficiente, poi gli ingegneri dell'engine si sono :obscene-birdiered:  .... e hanno :angry-screaming:  "compratelo sto  :music-tool:  di SNC". E così fu luce, e vidi che ciò era  :obscene-sexualdoggy: .

 :mrgreen: