Původní podoba příspěvku
Surová data tak, jak byla v roce 2013 stažena z Pandory (HTML zdroj bez úprav, osobní e-mailové adresy jsou maskované).
<!--------------------------------------------------------------> <table width="100%"><tr><td align="left" valign="middle"><B>MZIX-proveditelnost-pamet:</B></td><td align=right valign="middle"></td></tr></table><BR><pre>V diskusi o tom, zda bude MZ-800 stacit rychlostne, se dle meho nazoru <img src="BODY_IMAGES_WRAP_GIF"> ukazalo, ze to neni zrejme a bude zalezet, jak bude MZIX hospodarit s pameti. Z toho duvodu bych chtel otevrit dalsi thread, co se tyka proveditelnosti: PAMET ====== UZI i UZIX pouzivaji filozofii prideleni urciteho pametoveho prostoru jednomu procesu (UZI a UZIX 1.0 32 kB, UZIX 2.0 48 kB), a tam at si proces (s urcitymi omezenimi a s podporou knihovnich funkci) dela, co chce. Zmena kontextu se deje tak, ze tento pametovy prostor se 'uklidi' nekam pryc a <img src="BODY_IMAGES_WRAP_GIF">naopak odnekud se natahne jiny proces. Zachovame-li tuto filozofii, tak dle HW <img src="BODY_IMAGES_WRAP_GIF">konfigurace Sharpa mame nekolik moznosti pametoveho modelu: 1. Zachovat vse co se tyka pameti tak, jak je v UZI/UZIX 1.0. ------------------------------------------------------------------------------- To znamena 0100-7fff prostor pro proces, 8000-ffff prostor pro MZIX. Kam ale odkladat nebezici procesy? Pri nejrychlejsi variante RD by dle predbeznych vypoctu zmena kontextu mohla trvat cca 0.4 s. Pro experimantalni ucely by to stacilo, otazkou zustava prakticka pouzitelnost <img src="BODY_IMAGES_WRAP_GIF"> (tim nechci rict, ze by to bylo na 100% prakticky nepouzitelne - ale prinejmensim <img src="BODY_IMAGES_WRAP_GIF">nepohodlne). 2. Vyuzit nektere dalsi pametove zdroje MZ-800 ------------------------------------------------------------- Jestlize se spokojime s monochromatickym textovym rezimem 80x25, mame k <img src="BODY_IMAGES_WRAP_GIF">dispozici rozsirenou VRAM (16 kB). Tu muzeme vyuzit, zvladneme-li nejak rozume jeji <img src="BODY_IMAGES_WRAP_GIF">strankovani v ramci MZIX. Budeme-li pocitat temito kupeckymi pocty (i kdyz v praxi to <img src="BODY_IMAGES_WRAP_GIF">samozrejme tak byt nemusi, problemy se strankovanim mohou byt pro nas neprekonatelne), tak na <img src="BODY_IMAGES_WRAP_GIF">beh procesu muzeme mit dokonce 48 kB - jako UZIX 2.0. Muze se vsak ukazat, ze pro <img src="BODY_IMAGES_WRAP_GIF">beh jadra MZIX 32kB stacit nebude, a pak bysme tuto VRAM mohli pouzit pro ucely jadra. Dalsi zdroje mame v ROM Sharpa. Dle me muzeme pouzit az 14 kB z ROM (bez 2 kB <img src="BODY_IMAGES_WRAP_GIF">znakoveho generatoru). Velky problem u teto varianty je ztrata kompatibility s vetsinou <img src="BODY_IMAGES_WRAP_GIF">aplikaci pro Sharp. Dalsi problem by bylo zkoordinovat relativne slozite strankovani ruznych casti ROM. <img src="BODY_IMAGES_WRAP_GIF">Aplikujeme-li opet kupecke pocty na pamet, tak mame 62 kB pro proces (samozrejme ciste teoreticky). To vyuziti ROM myslim docela vazne, ale je jako "option" pri prekladu jadra. <img src="BODY_IMAGES_WRAP_GIF">Samozrejme by byla jak jina option moznost behu MZIX s puvodni ROM Sharpa. Vyuziti tohoto vidim <img src="BODY_IMAGES_WRAP_GIF">napr. v experimentech s emulatorem. Prepinani kontextu: zde by byla stejna situace jako <img src="BODY_IMAGES_WRAP_GIF">v (1.) s tim, ze prepnuti kontextu by se prodlouzilo adekvatne velikosti pameti pro proces. 3. Pouziti pridavne strankovatelne RAM --------------------------------------------------- Uplne jina situace by byla pri pritomnosti strankovatelne RAM 0000-7fff. To <img src="BODY_IMAGES_WRAP_GIF">bysme pak byli prakticky ve stejne HW konfiguraci jako MSX2 se svym memory mapperem a zmena kontextu by pak nevyzadovala prakticky zadne kopirovani dat. Navic by zde byla moznost jeste pro tohle strankovani nejak optimalizovat jadro <img src="BODY_IMAGES_WRAP_GIF">(napr. ze by se mohla strankovat cast jadra - a pak by zbylo vic pameti pro procesy, <img src="BODY_IMAGES_WRAP_GIF">jadro by mohlo obsahnout vice mista->vice funkcnosti v jadre). Pripadne by byla mozna kombinace <img src="BODY_IMAGES_WRAP_GIF">s bodem (2.). Dobra by byla moznost strankovat jak spodnich 32 kB adresovaho prostoru, tak i <img src="BODY_IMAGES_WRAP_GIF">hornich 32 kB, pripadne dalsi varianty - napr. spodnich 32 kB + dalsich 16 kB nekde jinde... <img src="BODY_IMAGES_WRAP_GIF">ale to si asi uz moc vymyslim. 4. Prepracovani process/memory managementu z UZI/UZIX ----------------------------------------------------------------------------- Dalsi moznost je, ze predelame process a memory management z UZI/UZIX. Mam na <img src="BODY_IMAGES_WRAP_GIF">mysli _zmenit_ tu skutecnost, ze je pro proces pridely pevny kus (32kB) pameti, a s <img src="BODY_IMAGES_WRAP_GIF">tim at si proces dela, co chce. Asi by to slo udelat nejak tak, ze se procesu prideli takove mnozstvi pameti, <img src="BODY_IMAGES_WRAP_GIF">kolik staticky zabere a dale pak napr. nejaka rezerva (4kB?) pro zasobnik/dynamickou <img src="BODY_IMAGES_WRAP_GIF">alokaci pameti. Zde by byla nutna uprava knihovniho 'malloc' tak, aby se dle toho <img src="BODY_IMAGES_WRAP_GIF">choval. Pri vetsim pozadavku na dynamickou pamet v dobe behu procesu by se musela <img src="BODY_IMAGES_WRAP_GIF">pridelena pamet 'nejak' zvetsit. V tomto pripade by mohlo byt vice procesu v pametovem prostoru a odswapovaly by <img src="BODY_IMAGES_WRAP_GIF">se jen nektere- na ktere uz pamet nezbyva. Tohle reseni by implikovalo pozadavek za relokovatelny kod procesu, coz by ale <img src="BODY_IMAGES_WRAP_GIF">nemusel byt neprekonatelny problem - viz linker ze 'z88dk', ktery je schopny takovy kod <img src="BODY_IMAGES_WRAP_GIF">produkovat. Tohle reseni by bylo kombinovatelne s resenimi (1.), (2.) i (3); i kdyz <img src="BODY_IMAGES_WRAP_GIF">kombinace s (3) by asi moc prinosem nebyla. ================================================= Nemyslim si, ze by sme se museli rozhodnout _jen_ pro nejakou z vyse uvedenych <img src="BODY_IMAGES_WRAP_GIF">moznosti. Jde o to tyhle myslenky nejak zkombinovat a navrhnout skupiny reseni - a tyto <img src="BODY_IMAGES_WRAP_GIF">varianty by se mohli volit napr. parametry pri prekladu jadra. Jestli vas napadaji jeste nejake dalsi moznosti memory managementu, tak se tesim <img src="BODY_IMAGES_WRAP_GIF">na vase prispevky. Kazdopadne si myslim, ze jista uroven proveditelnosti tu _je_ i co se tyka <img src="BODY_IMAGES_WRAP_GIF">pameti (i kdyz treba jen na experimentalni bazi) a tudiz je tu i proveditelnost na urovni rychlosti <img src="BODY_IMAGES_WRAP_GIF">MZ-800. Co vy na to? No, snad jste to po me prelouskali az sem. Howgh. Fuzzy</pre>