PDA

Visualizza versione completa : Compilazione...


wilhelm
02-04-2003, 13.40.41
ça mia è una curiosità: qualcuno riesce a spiegarmi come passa un compilatore da codice sorgente a impulsi elettrici?

P8257 WebMaster
02-04-2003, 15.56.59
La risposta è molto lunga e complessa e la strada che conduce da codice sorgente a materiale eseguibile lo è altrettanto.

Innanzitutto bisogna dire che il risultato non sono impulsi elettrici ma codice specifico per la piattaforma e l'architettura del supporto in cui viene eseguito. Sequenze di valori binari che vengono caricati in blocchi di memoria e processati poco alla volta, a seconda delle condizioni che si verificano nella logica di flusso.

La compilazione è solo uno dei passi di questo processo, in realtà molto altri elementi entrano in gioco. Ciò che sto illustrando è a grandi linee l'architettura dei compilatori più semplici che generano codice nativo, cioè codice che la piattaforma può eseguire direttamente, senza bisogno di ulteriori appoggi d'architettura come Frameworks e Virtual Machines.

Il compilatore è un programma che, dapprima legge il codice sorgente, ne controlla la sintassi, ne verifica eventuali incongruenze e le segnala, controllando anche che non ci siano riferimenti esterni e, nei casi di compilazione di progetti strutturati, procede all'esame di tutte le dipendenze "digeredo" il codice e restituendo un betacodice, se così si può dire .. chiamato oggetto. L'oggetto non è eseguibile, è appunto il codice "digerito" dallo stesso compilatore a seconda del sorgente e a seconda di certe opzioni che l'utente gli avrà espressamente indicato, come l'architettura su cui il programma dovrà girare, o lo spazio dello stack da allocare, la segmentazione ecc.

(sto sempre procedendo a grandi linee)

Il passo successivo è il linker il linker è un componente che interviene in modo del tutto trasparente all'utente che non fa altro che prendere l'oggetto prodotto dal compilatore, esaminarlo e procedere alla stesura del codice eseguibile. Come prima cosa scriverà un prologo nel file, indicando la natura del file stesso (sia eseguibile, libreria dinamica ecc.) poi altri passi obbligati come la definizione dello stack e di gestione della memoria. Successivamente vengono controllati i vari riferimenti che sono contenuti nell'oggetto. I riferimenti inseriti dal compilatore sono richiami a specifiche porzioni di libreria già precompilate dal produttore del linguaggio, da terze parti o dallo stesso utente che vengono quindi importate nel file finale stesso. Il tutto deve essere completo e coerente dato che ogni riferimento o chiamata a metodi deve avere l'implementazione nel file stesso o in risorse raggiungibili all'esterno (come i vecchi programmi che si appoggiavano a runtime).

Questo è un concetto di compilazione a grandi linee di livello piuttosto ortodosso, in realtà andava benissimo se applicato a sistemi più semplici come il DOS o le precedenti versioni di Windows, ora il discorso cambia perché windows dispone di architettura differente e molte cose sono gestite interamente dal sistema, come l'allocazione della memoria, lo stack ecc. tutto questo è volto a diminuire la dimensione del codice eseguibile all'interno di uno stesso file e rendere riutilizzabili librerie che contengono codice muti funzionale.

La nuova architettura dei linguaggi platform-indipendent inoltre, conferisce una definizione di compilatore che risulta snaturata da questo concetto appena espresso, poiché si tratta di un'analisi, di una compilazione che in realtà è più una codifica, dato che il risultato non è strettamente simile all'oggetto di cui si parlava prima ma è in realtà un bytecode, un linguaggio intermedio eseguibile SOLO dal motore che muove la piattaforma. Tale motore si preoccuperà di fornire in tempo reale tutte le risorse di cui il programma ha bisogno, il tutto sarà indipendente dall'architettura e dalla piattaforma e virtualmente compilato in tempo reale dallo stesso framework, pena: una maggiore lentezza di esecuzione. Non bisogna confondere quest'ultimo esempio con i linguaggi interpretati.

Ripeto che è una visione a grandi linee, ma spero sia utile.

Bye :cool:

The_Prof
02-04-2003, 16.18.39
Posso integrare il post precedente quanto mai esaustivo per piattaforme Win, con le spiegazioni complesse di quanto avviene nei calcolatori di grandi dimensioni.

Immaginiamo che tu abbia scritto un programma in un determinato linguaggio ad esempio Cobol a Assembler.
Al momento della compilazione vengono controllate tutte le istruzioni per verificarne la correttezza.
Successivamente viene eseguito il passo di Linkage Editor che modifica l'output della compilazione e crea un file in formato eseguibile.
Questo file eseguibile e' una successione di 1 e 0 (sistema binario).
Esistendo una correllazione tra sistema binario ed esadecimale, ogni istruzione macchina occupa 2 o 3 Byte (8 bit) .

Con un particolare linguaggio detto JCL crei il job per eseguire ll programma.

A questo punto il controllo passa al sistema operativo che controlla il tutto e poi passa il controllo al tuo programma (utilizzando sempre un'area di memoria in cui sono contenuti gli indirizzi dei 16 registri).

Quando il tuo programma termina, con una particolare istruzione il controllo passa di nuovo al sistema operativo e cosi' di seguito.

Mi rendo conto che e' complicato capire il tutto, ma forse e' ancora piu' complicato spiegarlo :D

Ciao :)

LoryOne
02-04-2003, 17.34.47
Beh cosa aggiungere ancora ?
Tra WebMaster e The_Prof resta ben poco (sempre a grandi linee)

Se apri un file eseguibile (per esempio) con un editor di testo esadecimale, noterai che il contenuto del file è umanamente impossibile da comprendere perchè costituito in larga parte da caratteri strani e poco comprensibili da parte nostra.

Ogni carattere in realtà viene interpretato dal PC come una sequenza binaria di numeri 1 e 0.
La sequenza binaria varia a seconda dell'istruzione e del dato da elaborare da parte del processore ma la sequenza è sempre la stessa se resta la stessa l'istruzione.
Ogni bit viene poi tradotto in livelli di tensione differenti che poi vengono rielaborati e...troppo lungo e complesso da spiegare,dovrei essere un ingegnere elettronico e non lo sono.

Comunque, a parer mio, non è molto sbagliata la domanda che hai posto.
:)

P8257 WebMaster
02-04-2003, 18.41.22
Si, c'è inoltre da aggiungere che si possono ricavare alcune informazioni marginali sulla natura del programma stesso, guardandone l'eseguibile o identificandone le dll.

Questo ragionamento filava molto bene con applicativi a 16-bit, ora sotto Windows è tutto un po' più complesso ma non impossibile. Aprendo un file eseguibile ad esempio se ne distingue il prologo e l'epilogo, ogni file di codice ha solitamente un header (che sia eseguibile, libreria o altro) e un footer in cui vengono catchate le eccezioni di runtime più comuni e ingestibili o poco frequenti.

Le librerie linkate solitamente occupano la parte superiore del file, l'oggetto è nell'area inferiore con le stringhe di testo, da queste è possibile leggere le varie messaggistiche, se contenute nell'eseguibile o nella libreria e a volte avere traccia del linguaggio con cui esso è stato scritto, è il caso proprio dei linguaggi come C/C++ che portano nelle stringhe i popri specificatore di formato (come '%c', '%s', '%d', '%i' ecc.).

Alcuni compilatori a 16bit per DOS come il Borland o il Watcom (che magari generavano codice da accoppiare ai DOS Extender), lasciavano addirittura una signature all'interno del file con il nome del linguaggio e la ditta produttrice.

.. eh, quanti bei ricordi .. col pctools a modificare...

Bye :cool:

P8257 WebMaster
03-04-2003, 15.23.32
Dimostro,

Prendendo in esame un file di facile reperibilità, nella fattispecie la dll che gestisce le risorse linguistiche di Windows Messenger o MSN Messenger: MSGSLANG.DLL che potete reperire nel percorso di Messenger, è possibile notare nella prima immagine l'header della stessa, con la scritta: this program cannot be run in dos mode aggiunta dal linker e il prologo, nella seconda immagine, potete notare l'area di messaggistica con evidenziato lo specificatore di formato "%s" in questo caso che viene reso in chiaro in quanto contenuto nella stringa stessa e ci dà indicazione sul linguaggio utilizzato.

Bye :cool:

P8257 WebMaster
03-04-2003, 15.27.46
...Le immagini in realtà sono inverite, per incompetenza del sottoscritto ad allegare le immagini :D

wilhelm
05-04-2003, 13.11.33
Grazie per le esaurienti risposte. Adesso la cosa mi è un po' più chiara. E se cercassi un libro dove approfondire lo troverei o si tratta di più argomenti messi assieme?