[Generica] Compilatori

[M4rk191]

Per curiosità ho iniziato a studiare l'Assembly per Intel x86. Ho dato uno sguardo ai manuali Intel :eek:


Non mi ha stupito tanto il numero di pagine dei manuali (circa 800 l'uno) quanto il numero di istruzioni che sono integrate nei moderni processori. Capisco che per motivi di compatibilità, siano presenti anche istruzioni che nel tempo sono state rimpiazzate da altre, ma rimangono comunque un'enormità. L'assemblatore NASM le supporta credo tutte e in sostanza una assemblatore traduce il codice mnemonico in codice binario, inoltre calcola gli indirizzi di memoria. Finché si tratta di convertire codice assembly in codice macchina 1:1 nonostante la complessità, riesco a comprendere che sia una cosa possibile. Oggi, però l'assemblatore, spesso è invocato in seguito ad un'operazione di compilazione. Bene, quello che mi chiedo è se sia possibile che un compilatore traduca un codice scritto in un linguaggio di alto livello, in assembly utilizzando tutte le istruzioni disponibili. Quello che non riesco a capire, è come sia possibile identificare le istruzioni assembly adatte a tradurre un brano di codice in un linguaggio ad alto livello, soprattutto mi chiedo se sia un procedimento statico; mi spiego: le strutture di controllo, credo si possano tradurre in un solo modo che permetta di adattarsi ad ogni situazione (intendo che, magari, un ciclo for è tradotto con le stesse istruzioni Assembly), mentre il codice contenuto nelle strutture di controllo è arbitrario, per cui non può essere tradotto sempre allo stesso modo, e se così fosse, ci sarebbe quasi sicuramente una traduzione (possibile) migliore di quella eseguita.

Scusate il post chilometrico, spero di essere stato abbastanza chiaro.

[cionci]

Il compilatore ha certi pattern in linguaggio macchina per ogni istruzione di alto livello, si riempie le parti mancanti con i parametri e poi va a scrivere il linguaggio assembly.
Tutte le singole istruzioni del linguaggio di alto livello vengono tradotte sempre allo stesso modo.
Poi ci sono anche compilatori che eseguono un secondo passo di ottimizzazione. Si rileggono il codice generato e cercano un modo per ottimizzarlo: ad esempio se hai la traduzione di due particolari pattern una vicina all'altra è possibile che tu possa eliminare alcune istruzioni per ottimizzare il tutto.

[cionci]

Il compilatore si basa sulla costruzione di una struttura chiamata albero di derivazione. La struttura è il risultato dell'analisi sintattica del sorgente del linguaggio. Ogni nodo identifica univocamente un determinato pattern di traduzione.

Ad esempio:

a = b * c

L'albero sarà:

=
|-- a
|-- *
___|-- b
___|-- c

Il compilatore dovrà fare una visita posticipata dell'albero. Andrà a mettere in un registro disponibile c, poi andrà a mettere b in un altro registro disponibile.
A questo punto seguirà il pattern di traduzione dell'operatore * ed userà i due registri come parametri andando a mettere il risultato in un registro disponibile.

"a" il compilatore sa che non è un parametro normale (ci penserà la struttura dati ad interificarlo), ma è un L-value (cioè un parametro il cui valore verrà modificato dall'operatore).
Quindi ci sarà uno schema ben preciso per andarlo a tradurre (di solito si limita a tenersi pronto l'indirizzo in cui è memorizzato).
Ora esegue l'operatore =. Seguirà il pattern dell'operatore, che sarà una MOV da un registro verso un indirizzo nello heap o nello stack.

E' tutto così: per ogni istruzione o costrutto si ottiene l'albero di derivazione e si usa una traduzione nodo per nodo, tenendo conto dei parametri già calcolati precedentemente.

[cdimauro]

Per curiosità ho iniziato a studiare l'Assembly per Intel x86. Ho dato uno sguardo ai manuali Intel :eek:

Non mi ha stupito tanto il numero di pagine dei manuali (circa 800 l'uno) quanto il numero di istruzioni che sono integrate nei moderni processori. Capisco che per motivi di compatibilità, siano presenti anche istruzioni che nel tempo sono state rimpiazzate da altre, ma rimangono comunque un'enormità.
In parte è vero. (http://www.appuntidigitali.it/5393/la-guerra-dellisa-x86-limpatto-su-decoder-compilatori-e-implicazioni-varie/)
L'assemblatore NASM le supporta credo tutte e in sostanza una assemblatore traduce il codice mnemonico in codice binario, inoltre calcola gli indirizzi di memoria. Finché si tratta di convertire codice assembly in codice macchina 1:1 nonostante la complessità, riesco a comprendere che sia una cosa possibile. Oggi, però l'assemblatore, spesso è invocato in seguito ad un'operazione di compilazione. Bene, quello che mi chiedo è se sia possibile che un compilatore traduca un codice scritto in un linguaggio di alto livello, in assembly utilizzando tutte le istruzioni disponibili.
In teoria sì, in pratica è estremamente difficile a causa della presenza di istruzioni molto particolari.
Quello che non riesco a capire, è come sia possibile identificare le istruzioni assembly adatte a tradurre un brano di codice in un linguaggio ad alto livello, soprattutto mi chiedo se sia un procedimento statico; mi spiego: le strutture di controllo, credo si possano tradurre in un solo modo che permetta di adattarsi ad ogni situazione (intendo che, magari, un ciclo for è tradotto con le stesse istruzioni Assembly), mentre il codice contenuto nelle strutture di controllo è arbitrario, per cui non può essere tradotto sempre allo stesso modo, e se così fosse, ci sarebbe quasi sicuramente una traduzione (possibile) migliore di quella eseguita.

Scusate il post chilometrico, spero di essere stato abbastanza chiaro.
Oltre al metodo spiegato da cionci, si fa uso di peephole optimizer (http://en.wikipedia.org/wiki/Peephole_optimizer) per individuare pattern di istruzioni e sostituirli con altri patterni più efficienti (che potrebbero anche contenere istruzioni particolari / rari).

[M4rk191]

Grazie per avermi risposto.

@cionci: sei stato molto chiaro nella spiegazione, mi hai tolto i dubbi :D

@cdimauro: ho letto il tuo articolo, molto interessante, ora leggo anche il link su Wikipedia ;)