EMB_81

COMPILER | SOFTWARE 63 EMBEDDED SETTEMBRE eseguita solo raramente. Quindi come si può ottimiz- zare al meglio? La soluzione ottimale in questo caso è À - zioni di ottimizzazione vengono scelte in base ai risul- À , À - dell’applicazione reale. % Á - gono eseguite, la frequenza delle chiamate e quanto tempo viene dedicato a ciascuna funzione. Ciò consen- te di riconoscere le aree del programma che richiedo- no molto tempo di elaborazione dove l’ottimizzazione della velocità è quindi particolarmente vantaggiosa e le aree che richiedono invece appena un tempo conte- nuto di elaborazione dove può quindi essere più utile ottimizzare le dimensioni del codice, perché è lì che un possibile compromesso sulla velocità risulta trascura- % À < la maggior parte del tempo della CPU è allocato solo a due funzioni (minSpanningTreePrims e minSpan- ningTreeKruskals). Queste ultime possono quindi essere oggetto di un’ottimizzazione spinta per la velo- cità di elaborazione, anche se di conseguenza le loro dimensioni cresceranno notevolmente. Tutte le altre funzioni potrebbero probabilmente essere ottimizzate per dimensioni. Le funzioni chiamate molto di frequente, anche se non richiedono molto tempo di elaborazione, sarebbero pro- % À ) À À - ter scegliere di conseguenza le opzioni di ottimizzazione À Ottimizzazione del linker Gli sviluppatori sanno che anche il linker può effettua- re ottimizzazioni. Perché dovreste abilitarle? Ebbene, il linker deve comunque processare tutti i moduli ed è l’ultimo componente nel processo di compilazione a ve- dere quali funzioni e quali dati vengono effettivamente À ) le funzioni e i dati inutilizzati durante l’operazione di linking. Ovviamente, è necessario fare attenzione quando si utilizzano puntatori di funzione impostati in fase di esecuzione, ma è anche possibile fornire al linker in- formazioni su ciò che non deve essere assolutamente rimosso. Inoltre, il linker è in grado di capire se nell’in- tero programma determinate sequenze di istruzioni vengano eseguite in punti diversi e se tali sequenze possano essere sostituite da una subroutine. Questo ap- proccio è chiamato “outlining” (l’opposto dell’inlining). Le insidie tipiche Per assicurarsi che il compilatore possa compiere un buon lavoro nell’ottimizzare il codice, occorre evitare comportamenti potenzialmente dannosi. Alcuni svilup- patori pensano di “poter far meglio del compilatore”, oppure vogliono semplicemente realizzare in modo ef- À - mente in linguaggio assembly, senza passare attraver- so un linguaggio ad alto livello. E sì, a volte il codice assembly scritto a mano può essere migliore di quello generato da un compilatore a partire da istruzioni in un linguaggio ad alto livello come il C o il C ++. Tuttavia, la situazione diventa critica quando lo sviluppatore lo fa utilizzando l’assembly inline, ovve- ro inserisce le singole istruzioni a mano nel bel mezzo del codice C. Queste istruzioni assembly inline vengono automaticamente considerate come una barriera all’ot- timizzazione del compilatore. E poi tutti i trucchi sopra menzionati come CSE, BCM, DCE, ecc. non devono es- sere applicati all’istruzione assembly inserita. Ulteriori problemi possono sorgere anche da un pre- supposto sbagliato sul modo in cui un compilatore memorizza i dati in memoria e su come sia possibile ottimizzare l’accesso ai dati stessi. I compilatori e i lin- ker possono riorganizzare a piacimento le variabili in memoria, purché non siano dichiarati come elementi di una struttura o attributi di una classe. Il compilatore può inserire le variabili locali nello stack o nei registri e, nel migliore dei casi, l’accesso alle varia- bili potrebbe essere completamente ottimizzato (si veda la tecnica DCE sopra descritta). Se si vuole impedire la rimozione di una determinata variabile, è consigliato À " / $ - timo indica al compilatore che la variabile sottostante ) À - pilato. Come si può vedere, sono disponibili diverse ottimizza- zioni che hanno obiettivi eterogenei e operano sul codi- ce sorgente o su sequenze di istruzioni estremamente differenti. Ci si possono aspettare quindi risultati molto diversi dalle ottimizzazioni, a seconda del codice sor- gente e dell’architettura hardware sottostante.