Paralelne bych si dovolil otevrit dalsi thread: proveditelnost z hlediska rychlosti MZ-800 ============================== Mame k dispozici Z80 na (zhruba) 3.5 MHz. S tim asi nic neudelame, budeme nuceni s tim vystacit. Vzhledem k tomu, ze na stejnem procesoru jedou podobne OS, tak neni duvod se domnivat, ze by se to nemelo povest, ale k tomu se jeste jiste vratime pozdeji. Dle meho skromneho nazoru bude nejuzsi misto v rychlosti odswapovavani RAM na periferni zarizeni. Dovolil bych si tedy trochu zanalyzovat, jak na tom jsme: RD: zde je potreba orientacne spocitat, jakou rychlosti jsme schopni prenaset data z/do RD: Rychlost RD asi bude limitovana rychlosti CPU pri nacitani dat. Standardni Sharp RD - telo cyklu, neoptimalizovane: pred cyklem: hl - cilova adresa RAM, bl - pocet bytu ke cteni loop: in a, (0eah) ; nacteni dalsiho byte z RD: 11T ld (hl),a ; ulozeni do RAM: 7 T inc hl ; dalsi adresa v RAM: 4T dec bc ; dekrementuj pocet bytu k preneseni 6T ld a,b 4T or c ; konec prenosu? 4T jr nz, loop 12 T ------------------------- to dela 48T /byte pri 3.5 MHz taktu to je rychlost prenosu zhruba 71 kB/s. Po jemne optimalizaci (cteni po 16 bytech naraz v loopu) jsem to napocital na 144 kB/s. Jiste by se dalo optimalizovat dale, ale pocitejme s touhle hodnotou. Takze napr. naswapovani 32kB bloku bysme meli zhruba za 0.23 s. Jestli se nemylim, tak zapis do RD je uplne to samy. Co vy na to - je to dobry odhad? Nebo je to uplne jinak? Udelal jsem nekde chybu? Jak je to s ostatnimi typy RD (SRAM, Pezik), je to stejne? HD: Zde bych se obratil na vas, strujce IDE8/IDE16 rozhrani: jak to u nich vypada s rychlosti? Muj laicky odhad je, ze slabe misto je zde asi procesor, nikoliv rozhrani nebo HD - takze rychlost teoreticky stejna jako RD? Nebo to bude znatelne pomalejsi - je treba kvuli slozitejsim rutinam pro cteni dat z IDE? ===== Pozadavky na rychlost by jiste snizila Romanem zminovana implementace pridavne strankovatelne RAM, ale 1) ta zatim neni a pokud vim, nikdo na tom nedela, a 2) vynucovali bysme si dalsi pridavny HW, coz je proti zadani projektu: pridavneho HW co nejmene. Ale jestli tahle RAM bude k dispozici, jiste ji radi vyuzijeme (optional). Na druhe strane bych rozhodne nechtel, aby tu RAM nekdo delal JEN pro projekt MZIX; kdovi, jestli ho vubec nekam dotahneme, ze... Otazku rychlosti celkove a jejiho dopadu na proveditelnost projektu bych v tuhle chvili nechal otevrenou, zalezi jak se vykrystalizuji pozadavky na rychlost z ostatnich aspektu projektu. Jestli nekoho napada cokoliv co se tyka rychlosti&MZIX, tak prispevky jsou vitany. Fuzzy
Celé vlákno · 2 zprávy
Re: MZIX-proveditelnost-rychlost MZ-800
Fuzzy SHARP MZ-800
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 schopni provest za 0.5s pri 32kB procesech. Hm, to tedy vskutku neni zadne 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 napocitali my. Zmena kontextu se deje typicky za 1s (slovy jednu sekundu). To znamena ze proces 0.5 sekundy bezi a dalsi 0.5 sekundy swapuje na jiny. Nic moc, podle me. UZIX: zde autor jiz pocitali s lepsim HW (MSX2), maji tam minimalne 128 kB strankovatelne pameti (ale i vic jako option). Takze si mouhou dovolit neswapovat, ale strankovat. Tim padem je pro ne zmena kontextu mnohem rychlejsi zalezitost a muzou mit rychlejsi prepinani. No, a kdyz mame posoudit, jestli nam rychlost MZ-800 staci, musime ted 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 teoreticky fungovalo, ale jiste se to nikomu nebude libit. Jina moznost je memory/process management trochu prekopat a jit jinou cestou nez UZI/UZIX. Dle me by to slo udelat tak, ze by se nenechavalo kazdemu procesu celych 32 kB, ale jen to, co zabere staticky. Plus dale za behu samozrejme procesem dynamicky alokovana pamet. Volnou pamet by bylo mozno priradit dalsim procesum. Tim by samozrejme prepnuti kontextu mezi procesy v pameti byla rychla zalezitost. Na periferni zarizeni by se odswapovalo, az by dosla RAM pro procesy. Z tohoto navrhu vyplyva: - binarky pro MZIX by musely byt relokovatelne na libovolne misto RAM (coz by se dalo zaridit) - upravit process/memory management z UZI/UZIX a vyresit problemy, ktere z tohoto reseni vyplynou Jsem si vedom toho, ze 32 kB mista na procesy je dost malo, ale na vybranou moc nemame. Muzeme udelat nejake moznosti pri kompilaci jadra - napr. zkompilovat pro uzpusobenou ROM Sharpa (kterou preprogramujeme) - pak by pameti mohlo byt vice, popr. moznost vyuziti pridavne straknovatelne RAM (ktera ovsem zatim neni). Co vy ostatni, nejake dalsi napady? Fuzzy.