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>Re: MZIX-proveditelnost-rychlost MZ-800:</B></td><td align=right valign="middle"></td></tr></table><BR><pre>Zdar,

Vyjadrujte se please dal k tem rychlostem, ja zatim budu premyslet dal:

Predpokladejme tedy, ze zmenu kontextu dle toho, jak to dela UZI/UZIX, jsme
<img src="BODY_IMAGES_WRAP_GIF"> schopni provest za 0.5s pri 32kB procesech. Hm, to tedy vskutku neni zadne
<img src="BODY_IMAGES_WRAP_GIF">terno.
Zde bych se zastavil u toho, jak to vlastne UZI/UZIX delaji:
UZI: dle me UZI nepocita s tim, ze by to swapovani bylo rychlejsi, nez jsme
<img src="BODY_IMAGES_WRAP_GIF">napocitali my. Zmena kontextu se deje typicky za 1s (slovy jednu sekundu). To
<img src="BODY_IMAGES_WRAP_GIF">znamena ze proces 0.5 sekundy bezi a dalsi 0.5 sekundy swapuje na jiny. Nic moc,
<img src="BODY_IMAGES_WRAP_GIF">podle me.
UZIX: zde autor jiz pocitali s lepsim HW (MSX2), maji tam minimalne 128 kB
<img src="BODY_IMAGES_WRAP_GIF">strankovatelne pameti (ale i vic jako option). Takze si mouhou dovolit
<img src="BODY_IMAGES_WRAP_GIF">neswapovat, ale strankovat. Tim padem je pro ne zmena kontextu mnohem rychlejsi 
<img src="BODY_IMAGES_WRAP_GIF">zalezitost a muzou mit rychlejsi prepinani.

No, a kdyz mame posoudit, jestli nam rychlost MZ-800 staci, musime ted
<img src="BODY_IMAGES_WRAP_GIF">zateoretizovat, jak ten process/memory management vlastne muzeme udelat.
Prvni moznost je zustat u toho, jak to dela UZI - zmena kontextu za 1s. Coz by
<img src="BODY_IMAGES_WRAP_GIF">teoreticky fungovalo, ale jiste se to nikomu nebude libit.
Jina moznost je memory/process management trochu prekopat a jit jinou cestou nez
<img src="BODY_IMAGES_WRAP_GIF">UZI/UZIX. Dle me by to slo udelat tak, ze by se nenechavalo kazdemu procesu
<img src="BODY_IMAGES_WRAP_GIF">celych 32 kB, ale jen to, co zabere staticky. Plus dale za behu samozrejme
<img src="BODY_IMAGES_WRAP_GIF">procesem dynamicky alokovana pamet. Volnou pamet by bylo mozno priradit dalsim
<img src="BODY_IMAGES_WRAP_GIF">procesum. Tim by samozrejme prepnuti kontextu mezi procesy v pameti byla rychla 
<img src="BODY_IMAGES_WRAP_GIF">zalezitost. Na periferni zarizeni by se odswapovalo, az by dosla RAM pro
<img src="BODY_IMAGES_WRAP_GIF">procesy.

Z tohoto navrhu vyplyva:
- binarky pro MZIX by musely byt relokovatelne na libovolne misto RAM (coz by se
<img src="BODY_IMAGES_WRAP_GIF">dalo zaridit)
- upravit process/memory management z UZI/UZIX a vyresit problemy, ktere z
<img src="BODY_IMAGES_WRAP_GIF">tohoto reseni vyplynou

Jsem si vedom toho, ze 32 kB mista na procesy je dost malo, ale na vybranou moc 
<img src="BODY_IMAGES_WRAP_GIF">nemame. Muzeme
udelat nejake moznosti pri kompilaci jadra - napr. zkompilovat pro uzpusobenou
<img src="BODY_IMAGES_WRAP_GIF">ROM Sharpa (kterou preprogramujeme)
- pak by pameti mohlo byt vice, popr. moznost vyuziti pridavne straknovatelne
<img src="BODY_IMAGES_WRAP_GIF">RAM (ktera ovsem zatim neni).

Co vy ostatni, nejake dalsi napady?

Fuzzy.
</pre>