Přejít na obsah
ARCHIVEKArchiv e-mailových konferencí o 8bitových počítačích Archiv Pandory 1999 až 2013

Zpět na zprávu

Celé vlákno · 2 zprávy

MZIX-proveditelnost-rychlost MZ-800

Fuzzy SHARP MZ-800

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

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.