Trends - Amiga Magazine Online

caso si precisi l'opzione ADDSYM. Nel nostro esempio, non
Il progranima sariì una variante del classico "Hello n~orld": abbiamo usato né l'una né l'altra cosa, dovremmo dunque
sentirci al siciiro. Non è così. Perché oltre agli hunk-del->ug,
main (int argc, char *argv [ I )
possono comparire nel codice oggetto e nell'eseguihile
t
degli hunk-symbol, che contengono i nomi dei simboli
if (argc==2) printf ("Hello World %s\nT', argv [l] ) ;
definiti esternamente: questo accade anche se non è stata
Delay (50) ; usata né l'opzione -d del compilatore. né l'opzione
return 5; ADDSYM del linker.
Qciesto risibile programiua compilato con il Lattice 5.04
senza alcuna opzione particolare per LC. occupa la bellezza
di 6516 hyte. Troppi. veramente troppi: se andiamo a
vedere la mappa generata dal linker troveremo una
quarantina eli funzioni inserite automaticamente dal
compilatore, clie non appaiono affatto nel sorgente: non
sarà possibile. per caso, eliminarne qualcuna?
In verità si possono elirilinare tutte e si può addirittura
arrivare, con qualche sacrificio, a scrivere un progra~n~iia
che faccia esattamente la stessa cosa in poco piìi di 350 byte
(se non si richiede la compatibilità Workt->ench). Sarebbe
quasi come un programiila scritto in Asseriibly e tutto
questo con poche modifiche e con qualche opzione ben
scelta.
Ci sono dunque almeno 6K di overhead nel nostro esempio:
questi 6K SLI un programma, mettiamo, di 100K. a motivo
dei vantaggi che assicurano. possono sicuramente essere
tollerati, ma su un programmino di 10 o 20K si fanno sentire
inolto e iiioltiplicati per 20-30, il numero approssimativo eli
~itility da directory C: che normalmente possono trovarsi su
un sisterna neanche poi tanto esteso. fanno 120-150K, che
non sono certo pochi per un floppy. Ma c'è anche cla notare
un'altra cosa: una paste dell'overliead. come vedremo,
cresce in proporzione al programma. e quindi piii questo è
lungo, n~aggiore è l'overhead: i 6K sono solo teorici, spesso
sono ben di piìi.
I'rirna di iniziare la nostra "cura dimagrante", vorrei però che
si capisse perché e stato scelto questo prograniriia ese~iipio:
esso comprende diie f~inzionalità clie sono fra le ~iiaggiori
responsabili dell'increiiieilto della lunghezza dei
progratnmi: le funzioni di I/O e la gestione clei parametri
della linea di comando. Mediante una serie di rinunce e di
compromessi a questi livelli si può arrivare a ridurre
clrasticamente il programma. I1 programma comprende,
inoltre, la chiamata diretta a una funzione eli libreria Amiga
(Delay) e non corilprende invece 1'~iso di f~inzioni
maten~atiche. che escl~idiamo dalla presente trattazione.
Le informazioni di debug
IJna delle prime cose da verificare è la presenza delle
inforri~azioni per il debugger. Se si coriipila con il Lattice
cisando le opzioni di debugging (-dx), nel codice oggetto
verranno inseriti degli hunk-debug che, a loro volta,
saranno poi aggiunti da Blink all'eseguibile, ma solo nel
L'unica n~aniera per escludere questi hunk dal codice
destinato al rilascio è usare l'opzione NODEBIIG (ND) con
Blink: è la sola clie assicura l'assoluta mancanza di
informazioni di dehiig. Nel nostro esempio appare un solo
hunk-synlbol, che contiene il simbolo esterno -Delay,
essendo Ilelay praticarilente l'unica f~inzione esterna
cliiamata dal nostro modulo. Ovviamente, in Lin sorgente
con un iiiaggior numero di chiamate esterne la quantità
delle inforriiazioni siii simboli esterni crescerà di
conseguenza.
Se effettiiiatiio il linking con l'opzione NODEBUG otteniaiiio
un eseguibile di 6492 by~e. con un guadagno di 24 byte:
pocliini, direte voi; tila il sinibolo era uno solo: provate ad
iminaginare cosa succederebbe con 70 o 100 chiamate
esterne a f~inzioni dal nome magari un po' piìi lungo, del
tipo BltBitMapKastPort ...
Il numero di hunk
Anche il nuriiero di Iiunk influisce sulle dimensioni
dell'esegiiibile. Da una paste ogni Iiunk implica un certo
overhead contenente le inforiliazioni relative all'hunk
stesso. Ma dall'altra, e in maniera piìi incisiva. la divisione
del codice in pii1 hunk induce necessariamente il linker a
gener:ire altri hiink contenenti le informazioni di
rilocazione: gli liunk-reloc32.
Questi inciclono in maniera &iriabile sulle diriiensioni del
coclice. ma c'è da notare che l'aumento degli hunk di codice
e di dati accompagnato all'aumento della lunghezza del
sorgente implica un aurilento esponenziale delle
informazioni di rilocazione, che possono tranquillamente
raggiungere I'orcline delle centinaia (e delle migliaia nei
programmi rilolto lunghi e fraiilmentati). 11 nostro
microscopico sorgente contiene I~en 3 hunk code e 1 liunk
data assielile a 4 Iiunk reloc32 per un totale di 16 rilocazioni
(ognuna delle quali occupa alnieno 4 byte).
Ora. Iiiink e rilocazioni sono poche in qiiesto caso. perché
fra le opzioni di default del coriipilatore vi è l'opzione -bl
che indica di usare. per i riferimenti esterni, degli
scostamenti relativi ai registri indirizzi e non dei valori
Lissoluti a 32 bit: se proviamo a coiiipilare il programma con
l'opzione -120 (con riferimenti esterni a 32 hit) otterreriiino
questi risultati: Iiinghezza ciell'eseguibile 7200 byte, 5 hunk
code o dat:i, 4 hunk-reloc32 con iin totale eli 145 (!)
rilocazioni. Quindi se vogliamo ridurre le dimensioni del
sorgente sari Ixne evitare accurata~iiente l'uso di -h0 e