Jak ulepszyź procedurė? (odc. 4.) --------------------------------- PAMIĖŹ Dzisiejszy odcinek bėdzie trywialny... Przynajmniej dla niektórych. Ci, którzy majā juū na koncie jakāō produkcjė, wīaōciwie nie muszā go czytaź i mogā spokojnie przejōź do lektury dziaīu "Amiga Play". Miklesz/Damage Dziō zajmiemy siė problemem pamiėci, a dokīadnie jej typów. Zapewne nie wszyscy wiedzā, ūe Amiga moūe adresowaź aū 6 typów pamiėci, (choź nie wszystkie sā typami fizycznymi). Wymieļmy je: Slow, Rom, Public, Chip, Fast, Local, 24-bit DMA. Z góry narzuźmy sobie pewne ograniczenie. Otóū nie ma sensu omawiaź tutaj pamiėci typu Local i 24-bit DMA, moūemy sobie równieū "darowaź" ROM, gdyū nic tam nie zapiszemy, oraz Slow, kiedy powiemy sobie, iū jest to po prostu Fast z prėdkoōciā Chipu (czyli po prostu, nie warto jej uūywaź, kiedy mamy wolny Chip lub Fast). Pozostaī nam wiėc juū tylko: Public, Chip i Fast, lecz zanim przejdė do szczegóīowego ich omawiania, krótka tabelka, wyjaōniajāca nam, gdzie moūemy zetknāź siė z danym typem pamiėci i jaki ma ona priorytet. RAM priority public Chip Fast local 24-bit A3000 coprocessor 40 x x x A3000 motherboard 30 x x x Zorro-III 20 x x Zorro-II 0 x x x Ranger -5 x x x x Chip -10 x x x x A teraz moūemy juū spokojnie przejōź do omówienia poszczególnych typów "pamiātki"... Chip Jest to pamiėź, do której dostėp majā wszystkie koōci pomocnicze Amisi, a co siė za tym kryje, chyba nie trzeba tīumaczyź. No dobrze, zapytacie, ale co tu trzymaź? Co trzymaź w Chip Memory? -- obszary, na których aktualnie operujemy blitterem; -- bufory, w których skīadowane sā dane z/do stacji dysków; -- aktualne dane sprajtów; -- odgrywane sample moduīów (same nuty nie muszā byź w Chipie!); -- uruchomione copperlisty; -- wyōwietlane bitplany; Czego nie trzymaź w Chip Memory? -- kodów aktualnie wykonywanych programów, gdyū dziaīajā wolniej; -- danych, na których w danej chwili przeprowadzamy operacje. Fast Dostėp do tej pamiėci ma jedynie procesor gīówny, który ogranicza jej zastosowania. Fast ma jednak jednā zasadniczā zaletė, która odróūnia jā od Chipu i która nawet przyczyniīa siė do powstania nazwy tej pamiėci. Chodzi mi oczywiōcie o szybkoōź wykonywanych w niej operacji, która na przykīad w wypadku A1200 ze standardowā kartā pamiėci jest ponad dwa razy wiėksza od szybkoōci wykonywania operacji w Chipie. Poniūsze zestawienie jest juū wīaōciwie tylko formalnoōciā... Co trzymaź w Fast Memory? -- kody aktualnie wykonywanych programów, gdyū dziaīajā szybciej; -- dane, na których w danej chwili przeprowadzamy operacje. Czego nie trzymaź w Fast Memory? -- obszarów, na których aktualnie operujemy blitterem; -- buforów, w których skīadowane sā dane z/do stacji dysków; -- aktualnych danych sprajtów; -- odgrywanych sampli moduīów; -- uruchomionych copperlist; -- wyōwietlanych bitplanów. Public Jest to pamiėź logiczna, która jednak ma swoje odwzorowanie w fizycznej pamiėci. Public Memory oznacza mniej wiėcej kaūdā wolnā pamiėź, z zastrzeūeniem, ūe wyūszy priorytet ma tu Fast niū Chip. Polecam wīaōnie w pamiėci typu Public przechowywaź kod i dane naszych programów, gdyū oznacza to, ūe: -- Jeūeli pisaliōmy kod, uūywajāc pamiėci Chip, mamy szansė na automatyczne przyōpieszenie naszego programu, kiedy uruchomimy go na sprzėcie lepiej wyposaūonym w pamiėź... -- Jeūeli pisaliōmy kod, uūywajāc pamiėci Fast, mamy pewnoōź, ūe na uboūszym sprzėcie caīoōź "pójdzie" jedynie trochė (?!) wolniej... Nie bėdė juū po raz kolejny wypisywaī "Co trzymaź...", bo posādzono by mnie, o zbyt czėste uūywanie opcji "Copy" i "Paste". Hunki Na koniec dzisiejszego odcinka pozostaī nam tylko jeden problem, sprawa hunków. Hunki, jak wiadomo lub nie, sā to (najproōciej mówiāc) "kawaīki" naszego programu, które przy īadowaniu sā rozrzucane po caīej pamiėci. Typów hunków jest aū 20: Break, BSS, Code, Cont, Data, DeBug, DReloc32, End, Ext, Header, Index, Lib, Name, OverLay, Reloc16, Reloc32, Reloc 32Short, Reloc8, ResLib, Symbol, Unit. Mógībym wypisywaź po kolei, po co jest kaūdy i jakā ma budowė, ale nie ma to sensu. Do tego sīuūā "mādre" ksiėgi, a jeūeli rzeczywiōcie bėdzie to Was interesowaīo, to popeīniė (poza cyklem), artykuī-kobyīė, z którego dowiecie siė wszystkiego. Na razie, do napisania interka, demka, czy teū jakiegoō utilka (rozbudowanego trochė mniej niū Page Stream 3.0), wystarczy znajomoōź jedynie hunków typu Code, Data i BSS. A teraz podstawowe rulez "w temacie" hunki: 1. Po kaūdym typie hunka podajemy: _C, _F, _P, co odpowiada za umieszczenie go w pamiėci: Chip, Fast, Public. Niepodanie niczego oznacza pamiėź Public. 2. Kod lub dane, nie opatrzone hunkiem, sā asemblowane jako CODE_P. 3. Hunk CODE sīuūy do przechowywania kodu, choź moūemy przechowywaź w nim dane. 4. Jednakūe do danych istnieje specjanie hunk DATA, przeznaczony wyīācznie do tego celu. 5. Hunk BSS nie powiėksza naszego programu, a sīuūy do przechowywania pustych (wypeīnionych zerami) tablic, generowanych podczas īadowania programu (lub jego asemblacji). Polecam umieszczanie w nim wszelkich tablic, które generuje nasz program. Tablice oznaczamy etykietā, ewentualnie poprzedzamy cnopem i definiujemy ich dīugoōź przez "dc.b/w/l dīugoōźtablicy". 6. Hunk "trwa" od momentu wystāpienia dyrektywy inicjujācej go: "Section nazwahunka,CODE/DATA/BSS(_C/_F/_P)", do wystāpienia nastėpnego hunka lub do koļca programu. 7. W zwiāzku z powyūszym taki krótki schemat programu, którego sam uūywam, kolejnoōź jak teū i nazwy hunków, jest wīaōciwie dowolna, a wynika jedynie z moich przyzwyczajeļ, które wcale nie muszā (i zapewne nie sā) najwīaōciwsze: ;Include'y, które majā wīasny zestaw hunków Section Code,Code ;Include'y inne, czyli w 99% symbole lub kod ;Kod mojego programu ;Dane, które mogā byź umieszczone ewentualnie w Fast Memory ;IncBiny, które mogā byź umieszczone ewentualnie w Fast Memory Section Data_C,Data_C ;IncBiny, które muszā byź umieszczone w Chip Memory ;Dane, które muszā byź umieszczone w Chip Memory Section BSS,BSS ;Dane i tablice, które wytwarzam sam i które mogā byź umieszczone ;ewentualnie w Fast Memory Section BSS_C,BSS_C ;Dane i tablice, które wytwarzam sam i które muszā byź umieszczone w ;Chip Memory Sādzė, ūe wystarczy tyle kazania na dzieļ dzisiejszy. Przepraszam, ūe tylko tyle, ale obiecujė, ūe za miesiāc, nie doōź, ūe odcinek bėdzie obszerniejszy, to sādzė, ūe zainteresuje szerokā rzeszė koderów. Zajmiemy siė bowiem metodā emulacji znanego z "blaszaków" trybu przechowywania danych graficznych, "chunky pixel". Metod emulacji jest kilka, ja zajmė siė tā najbardziej elastycznā, którā teū najbardziej lubiė (wystarczy spojrzeź na ostatnie produkcje Damage :-), polegajācā na wykorzystaniu Coppera.