1 - Amiga Magazine Online

swap d4
moveq #0,d5
m0ve.w OnScreenDim,d5
divu.1 d5,d4 ; d4=Step
moveq #O,dl ; dl=v
m0ve.w #320,d3 ;d3=Dimensioni riga schermo
m0ve.w yO,d5
mu1u.w d3,d5
move.1 ScreenBase,a2
adda.w xO,a2
adda.1 d5,a2 ;a2=ptr allo schermo
m0ve.w OnScreenDim,d7 ;d7=y
subq.w #l,d7
loopy :
moveq #O,dO ; dO=u
move.1 dl,d5
swap d5
mu1u.w TextureDim,d5
move.1 TextureBase,aO
adda.1 d5,aO
move.1 a2,al
m0ve.w OnScreenDim,d6 ;d6=x
subq.w #l,d6
loopx :
swap do
m0ve.b (aO,dO.w),(al)+ ;Scrive il pixel
swap do
add.1 d4,dO ; u+=Step
dbra d6,loopx
;Passa alla prossima riga di schermo
adda.w d3,a2
add.1 d4,dl ;v+=Step
dbra d7,loopy
Lasciamo le altre ottimizzazioni, per esempio quelle rela-
tive alle moltiplicazioni e agli accessi assoluti alla memo-
ria, come esercizio.
Si osservi ora il ciclo identificato dalla label loopx, la cui
ottimizzazione è di vitale importanza. Infatti è in questo
piccolo ciclo che il processore impiega la maggior parte
del proprio tempo, e le tecniche per ottimizzarlo sono al-
meno due, entrambe molto efficaci.
Iniziamo con la tecnica più importante e meno conosciuta,
quella che ritroveremo in tutti i cicli di texture
mapping ben ottimizzati. Come avrete notato, la prima
istruzione di swap serve per mettere nella word bassa di
do la parte intera di u, in modo da poterla utilizzare nell'indirizzamento
indiretto indicizzato, necessario per leggere
il pixel dalla texture. Subito dopo, una seconda
istruzione di swap riporta do nel formato originario, necessario
alla istruzione di somma. È possibile eliminare
dal ciclo le due istruzioni di swap? Ebbene, la risposta è
sì.
Normalmente, la parte intera di un numero in virgola
fissa è contenuta nella parte alta di un registro, mentre
la parte frazionaria è contenuta nella parte bassa, ma
nulla ci vieta di invertire tale ordine, in modo che la
parte intera sia già dove ci interessa e che le due istru-
zioni di swap non siano più necessarie. Owiamente en-
trambi gli addendi devono essere rappresentati nello
stesso formato. Nascono però due problemi. Nella som-
ma di due long, il riporto si propaga, come è logico che
sia, dalla word bassa a quella alta, cosa che nel nostro
caso non deve assolutamente accadere. Sarebbe infatti
totalmente sbagliato che un eventuale overflow della
parte intera andasse a intaccare la parte frazionaria (pri-
mo problema). Al contrario, il riporto deve propagarsi
dalla word alta a quella bassa (secondo problema).
Il primo problema, nel nostro caso, è inconsistente, in
quanto la parte intera dei due valori da sommare può as-
sumere il valore massimo di TextureDim (128), per cui in
nessun caso pratico è possibile che si verifichi un over-
flow della word bassa.
La soluzione del secondo problema è un po' più com-
plessa. A prima vista, per fare in modo che il riporto di
una somma si propaghi dalla word alta a quella bassa,
bisognerebbe utilizzare due istruzioni di somma:
L'istruzione addx di somma estesa (con d2=0) serve
esclusivamente a sommare alla parte bassa di do il ri-
porto della somma precedente. In questo modo, però,
sono necessarie due istruzioni di somma e un registro
(d2) in più che, tra l'altro, potrebbe non essere libero.
Possiamo allora pensare di utilizzare la sola istruzione di
somma estesa, avendo l'accortezza di evitare altre istru-
zioni che modificano il flag di X:
loopx:
m0ve.b (aO,dO.w),(al)+ ;Scrive il pixel
addx.1 d4,dO ; u+=Step
dbra d6,loopx
Il ciclo appena descritto funziona abbastanza bene, ma
non è perfetto, in quanto il riporto (costituito come
sappiamo dal flag X) viene sommato alla word bassa di
do con un ciclo di ritardo, generando delle lievi impre-
cisioni. Tali imprecisioni sono del tutto impercettibili,
ma se è possibile eliminarle facilmente, perché non far-
lo? A tale scopo è infatti sufficiente, subito prima del ci-
clo loopx, sommare a u la sola parte frazionaria di Step
move.1 d4,d2 ;Copia Step in un registro
c1r.w d2 ;Elimina la parte intera
add.1 d2,dO ;Somma a u la parte frazionaria