[ Pobierz całość w formacie PDF ]
b dzie si rzeczy mie adres nieparzysty; je li b dzie to s owo b d podwójne s owo, adres
taki nie b dzie optymalny. St d konieczno znajomo ci sposobów wymuszania odpowiedniego
wyrównania obiektów.
Niech w programie HLA okre lone zostan nast puj ce deklaracje statyczne:
static
dw: dword;
b: byte;
w: word;
dw2: dword;
w2: word;
b2: byte;
dw3: dword;
Pierwsza z deklaracji statycznych w programie (przy za o eniu, e program ten b dzie dzia a
pod kontrol systemu operacyjnego Windows, Mac OS X, FreeBSD, Linux lub innego systemu
32-bitowego) zostanie umieszczona pod adresem o parzystej warto ci b d cej przy tym wie-
lokrotno ci liczby 4096. St d pierwsza zmienna w sekcji deklaracji, niezale nie od jej typu,
zostanie optymalnie wyrównana. Kolejne zmienne s jednak umieszczane pod adresami liczo-
nymi jako suma adresu bazowego obszaru pami ci i rozmiarów wszystkich poprzednich zmien-
nych. Je li wi c za o y , e deklarowane powy ej zmienne zostan po kompilacji w obszarze
pami ci rozpoczynaj cym si od adresu 4096, to poszczególne zmienne otrzymaj nast puj ce
adresy:
// adres pocz tkowy rozmiar
dw: dword; // 4096 4
b: byte; // 4100 1
w: word; // 4101 2
dw2: dword; // 4103 4
w2: word; // 4107 2
154 Rozdzi a 3.
b2: byte; // 4109 1
dw3: dword; // 4110 4
Z wyj tkiem zmiennej pierwszej (wyrównanej do adresu 4096) oraz zmiennej bajtowej b2
(wyrównanie zmiennych bajtowych jest zawsze dobre) wszystkie zmienne s tu wyrównane
nieoptymalnie. Zmienne w, w2 oraz dw2 rozmieszczone zosta y pod nieparzystymi adresami;
zmienna dw3 zosta a wyrównana do adresu parzystego, ale nieb d cego, niestety, wielokrotno ci
czwórki.
Najprostszym sposobem zagwarantowania odpowiedniego wyrównania wszystkich zmien-
nych jest zadeklarowanie jako pierwszych wszystkich obiektów o rozmiarze podwójnego s owa,
a za nimi wszystkich obiektów o rozmiarze s owa; obiekty jednobajtowe powinny by deklaro-
wane na ko cu, jak poni ej:
static
dw: dword;
dw2: dword;
dw3: dword;
w: word;
w2: word;
b: byte;
b2: byte;
Takie u o enie deklaracji owocuje rozmieszczeniem zmiennych pod nast puj cymi adre-
sami (przyjmujemy, e adresem bazowym obszaru zmiennych statycznych jest 4096):
// adres pocz tkowy rozmiar
dw: dword; // 4096 4
dw2: dword; // 4100 4
dw3: dword; // 4104 4
w: word; // 4108 2
w2: word; // 4110 2
b: byte; // 4112 1
b2: byte; // 4113 1
Jak wida , wyrównanie poszczególnych zmiennych jest ju zgodne z regu ami sztuki.
Niestety, bardzo rzadko mo liwe jest takie u o enie zmiennych programu. Niemo no ka -
dorazowego optymalnego u o enia zmiennych wynika z szeregu przyczyn technicznych; w prak-
tyce wystarczaj c przyczyn jest brak logicznego powi zania deklaracji zmiennych, je li te s
uk adane wy cznie ze wzgl du na rozmiar obiektu; tymczasem dla przejrzysto ci kodu ród o-
wego niektóre zmienne nale y grupowa niezale nie od ich rozmiarów.
Rozwi zaniem tego konfliktu interesów jest dyrektywa align j zyka HLA. Sk adnia dyrek-
tywy prezentuje si nast puj co:
align( sta a-ca kowita );
Dost p do pami ci i jej organizacja 155
Sta a ca kowita okre lona w argumencie dyrektywy mo e by jedn z nast puj cych war-
to ci: 1, 2, 4, 8 lub 16. Je li w sekcji deklaracji za s owem static kompilator HLA napotka dyrek-
tyw align, nast pna deklarowana w sekcji zmienna zostanie wyrównana do adresu b d cego
ca kowit wielokrotno ci argumentu dyrektywy. Analizowany przez nas przyk ad mo na z wyko-
rzystaniem dyrektywy align przepisa nast puj co:
static
align( 4 );
dw: dword;
b: byte;
align( 2 );
w: word;
align( 4 );
dw2: dword;
w2: word;
b2: byte;
align( 4 );
dw3: dword;
Jak dzia a dyrektywa align? To ca kiem proste. Je li kompilator wykryje, e bie cy adres
(czyli bie ca warto licznika lokacji) nie jest ca kowit wielokrotno ci warto ci okre lonej
argumentem dyrektywy, wprowadza do obszaru pami ci szereg bajtów danych nieetykietowa-
nych (bajtów wyrównania), uzupe niaj c nimi poprzedni deklaracj , tak aby bie ca warto
licznika lokacji osi gn a po dan warto . Program staje si przez to nieco wi kszy (o dos ow-
nie kilka bajtów), ale w zamian dost p do danych programu jest nieco szybszy; je li faktycznie
zwi kszenie rozmiaru programu mia oby si ograniczy do kilku dodatkowych bajtów, wymiana
ta by aby bardzo atrakcyjna.
Warto przyj regu , e w celem maksymalizowania szybko ci odwo a do obiektów danych
nale y je wyrównywa do adresów b d cych ca kowitymi wielokrotno ciami ich rozmiaru.
S owa powinny wi c by wyrównywane do parzystych adresów pami ci (align(2);), podwójne
s owa do adresów podzielnych bez reszty przez cztery (align(4);), s owa poczwórne nale y
wyrównywa do adresów podzielnych przez osiem i tak dalej. Je li rozmiar obiektu nie jest
równy pot dze dwójki, nale y wyrówna go do adresów podzielnych przez pot g dwójki naj-
bli sz jego rozmiarowi, lecz od niego wi ksz . Wyj tkiem s obiekty typu real80 oraz tbyte,
które nale y wyrównywa do adresów podzielnych przez osiem.
Wyrównywanie danych nie zawsze jest konieczne. Architektura pami ci podr cznej wspó -
czesnych procesorów z rodziny 80x86 pozwala bowiem na efektywn (w wi kszo ci przypad-
ków) obs ug równie danych niewyrównanych. Dyrektywy wyrównania powinny wi c by
stosowane wy cznie wobec tych danych, w przypadku których szybko dost pu ma zasadnicze
znaczenie dla wydajno ci programu. W przypadku takich zmiennych ewentualny koszt optyma-
lizacji dost pu w postaci kilku dodatkowych bajtów programu b dzie z pewno ci do przyj cia.
156 Rozdzi a 3.
3.5. Wyra enia adresowe
Prezentowane w poprzednich podrozdzia ach tryby adresowania ilustrowane by y kilkoma
postaciami odwo a , w tym:
zmienna[ rejestr32 ];
zmienna[ rejestr32 + przesuni cie ];
zmienna[ rejestr32-nie-ESP * skala ];
zmienna[ rejestr32 + rejestr32-nie-ESP * skala ];
zmienna[ rejestr32-nie-ESP * skala + przesuni cie ];
zmienna[ rejestr32 + rejestr32-nie-ESP * skala + przesuni cie ];
Istnieje jeszcze jedna forma odwo ania, niewprowadzaj ca nowego trybu adresowania,
a b d ca jedynie rozszerzeniem trybu adresowania bezpo redniego:
zmienna[ przesuni cie ]
W tej ostatniej postaci odwo ania adres efektywny obliczany jest przez dodanie sta ego
przesuni cia okre lonego wewn trz nawiasów prostok tnych do adresu zmiennej. Na przyk ad
instrukcja mov(adres[3], al) powoduje za adowanie rejestru AL warto ci znajduj c si
w pami ci pod adresem odleg ym o trzy bajty od adresu zmiennej adres (patrz rysunek 3.8).
Rysunek 3.8. Wyra enie adresowe w odwo aniu do danej umieszczonej za zmienn
Warto przesuni cia musi by wyra ona jako sta a, czyli litera liczbowy. Je li, na przyk ad,
zmienna i jest zmienn typu int32, wtedy wyra enie zmienna[i] nie jest dozwolonym wyra-
eniem adresowym. Aby odwo ywa si do danych za po rednictwem indeksu dynamicznego
modyfikowanego w trakcie dzia ania programu, nale y skorzysta z trybu adresowania indek-
sowego, ewentualnie indeksowego skalowanego.
Dost p do pami ci i jej organizacja 157
Kolejnym wa nym spostrze eniem jest to, e przesuni cie w wyra eniu adres[przesuni cie]
jest adresem bajtowym. Mimo e sk adnia wyra enia adresowego przypomina t znan z j zy-
ków C, C++ i Pascal, to tutaj przesuni cie nie stanowi indeksu w sensie licznika elementów
tablicy chyba e adres jest tablic bajtów.
W niniejszej ksi ce wyra eniem adresowym b dzie dowolny z trybów adresowania pro-
cesora 80x86, który obejmuje przemieszczenie (na przyk ad zawiera nazw zmiennej) albo prze-
suni cie. Za poprawne wyra enia adresowe b d tak e uwa ane nast puj ce odwo ania:
[ rejestr32 + przesuni cie ]
[ rejestr32 + rejestr-nieESP32 * skala + przesuni cie ]
[ Pobierz całość w formacie PDF ]