| MZIX-proveditelnost-pamet: | |
V diskusi o tom, zda bude MZ-800 stacit rychlostne, se dle meho nazoru
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
naopak
odnekud se natahne jiny proces. Zachovame-li tuto filozofii, tak dle HW
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
(tim nechci
rict, ze by to bylo na 100% prakticky nepouzitelne - ale prinejmensim
nepohodlne).
2. Vyuzit nektere dalsi pametove zdroje MZ-800
-------------------------------------------------------------
Jestlize se spokojime s monochromatickym textovym rezimem 80x25, mame k
dispozici
rozsirenou VRAM (16 kB). Tu muzeme vyuzit, zvladneme-li nejak rozume jeji
strankovani
v ramci MZIX. Budeme-li pocitat temito kupeckymi pocty (i kdyz v praxi to
samozrejme tak
byt nemusi, problemy se strankovanim mohou byt pro nas neprekonatelne), tak na
beh
procesu muzeme mit dokonce 48 kB - jako UZIX 2.0. Muze se vsak ukazat, ze pro
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
znakoveho
generatoru). Velky problem u teto varianty je ztrata kompatibility s vetsinou
aplikaci pro Sharp. Dalsi problem
by bylo zkoordinovat relativne slozite strankovani ruznych casti ROM.
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.
Samozrejme by byla
jak jina option moznost behu MZIX s puvodni ROM Sharpa. Vyuziti tohoto vidim
napr. v
experimentech s emulatorem. Prepinani kontextu: zde by byla stejna situace jako
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
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
(napr.
ze by se mohla strankovat cast jadra - a pak by zbylo vic pameti pro procesy,
jadro by mohlo
obsahnout vice mista->vice funkcnosti v jadre). Pripadne by byla mozna kombinace
s bodem (2.).
Dobra by byla moznost strankovat jak spodnich 32 kB adresovaho prostoru, tak i
hornich 32 kB,
pripadne dalsi varianty - napr. spodnich 32 kB + dalsich 16 kB nekde jinde...
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
mysli
_zmenit_ tu skutecnost, ze je pro proces pridely pevny kus (32kB) pameti, a s
tim
at si proces dela, co chce.
Asi by to slo udelat nejak tak, ze se procesu prideli takove mnozstvi pameti,
kolik
staticky zabere a dale pak napr. nejaka rezerva (4kB?) pro zasobnik/dynamickou
alokaci
pameti. Zde by byla nutna uprava knihovniho 'malloc' tak, aby se dle toho
choval.
Pri vetsim pozadavku na dynamickou pamet v dobe behu procesu by se musela
pridelena pamet
'nejak' zvetsit.
V tomto pripade by mohlo byt vice procesu v pametovem prostoru a odswapovaly by
se jen nektere-
na ktere uz pamet nezbyva.
Tohle reseni by implikovalo pozadavek za relokovatelny kod procesu, coz by ale
nemusel byt
neprekonatelny problem - viz linker ze 'z88dk', ktery je schopny takovy kod
produkovat.
Tohle reseni by bylo kombinovatelne s resenimi (1.), (2.) i (3); i kdyz
kombinace s (3) by asi moc
prinosem nebyla.
=================================================
Nemyslim si, ze by sme se museli rozhodnout _jen_ pro nejakou z vyse uvedenych
moznosti.
Jde o to tyhle myslenky nejak zkombinovat a navrhnout skupiny reseni - a tyto
varianty by
se mohli volit napr. parametry pri prekladu jadra.
Jestli vas napadaji jeste nejake dalsi moznosti memory managementu, tak se tesim
na vase prispevky.
Kazdopadne si myslim, ze jista uroven proveditelnosti tu _je_ i co se tyka
pameti (i kdyz treba jen
na experimentalni bazi) a tudiz je tu i proveditelnost na urovni rychlosti
MZ-800. Co vy na to?
No, snad jste to po me prelouskali az sem. Howgh.
Fuzzy