Celé vlákno · 4 zprávy

Mozna se Vam bude hodit povidani, ktere v sekci Speccy na Pandore pridal Pavel Cimbal. Tyka se lockovani Z-80 a s MZIXem tedy uzce souvisi:

Pavel Cimbal (Zilog) piše:

podotykam ze locky treba kodovat _atomicky_.
kod typu:

otestuj lock
pokud nastaven odskoc nekam
nastav lock
.....
zrus lock

neni spravny. mezi sejmutim stavu locku a jeho nastavenim nesmi mit
druhy subjekt (preruseni) moznost intervence. Jinak se stane, ze prvni
sejme odemceny stav, a jeste nez ho obsadi, sejme ho i druhy a take
obsadi -> kolize.

Test a nastaveni musi probehnout atomicky, tj. jednim vrzem tam nacpat
hodnotu LOCKED a zaroven nacist, co tam bylo. Typicky instrukce EX
(mem),reg, TSL atd. Ty bohuzel Z80 nema. Jedine EX (SP),HL, ktera je
ovsem zamyslena k necemu uuuplne jinemu. EI/DI je divne, muzeme prijit o
preruseni, ktere ani nema s lockem co do cineni. Nastesti mame
nepublikovane instrukce, konkretne rotace s kopii do registru:

SCF
RL (IX+N),A
JR NZ,...

Nastavim carry (chci zabrat lock), rotaci ho do bytu nasunu, a zaroven
podle nenulove hodnoty A zjistim, ze ho uz nekdo drzel, a nemam tedy
narok pokracovat v sekci. Ma nasunuta jednicka tak jen potvrzuje
okamzity stav a nijak nevadi. Pokud byl ale registr nulovy, nikdo lock
nedrzel, a ma jednicka okamzite vsem potencialnim dalsim tazatelum
zabrani vstoupit do teze sekce, jako jsem ja. Jednicku nikdy nevyroluji
ven, protoze tam pri dotazu cpou svou dalsi. Jedine az na konci sekde
dam LD (IX+N),0, sekci tim odblokuji.

Toto nemusi byt kopirovanio na kazdem pocatku kriticke sekce, obvykle to
vyusti v rutinu typu:

LD A,#lock_no
CALL SETLOCK
z=free, nz=engaged

LD A,#lock_no
CALL UNLOCK
-

rutina pak uz udela :


SETLOCK: push IX
ld IX,locktable
SCF
codeplace: RL (ix+A),A
pop IX
ret

UNLOCK: push IX
ld ix,locktable
ld (IX+A),0
pop ix
ret

Coz snadno vyresime (adresace (ix+A) nexistuje) treba pomoci ld xl,a a
zarovnanim tabulky na zacatek 256-stranky, nebo proste jen udanim
nizsiho byte (cela tedy v jedne strance - pro malou tabulku tedy zadne
riziko ani omezeni, konkretni offset jeji polohy ve strance muzeme dat
jako #DEFINE). Co vy na to?

Z.

Timto zdravim Prof. Doc. Pavla Tvrdika CSc., protoze nam velmi hezky a
vtipne objasnil filozoficke zalezitosti kolem semaforu, lockovani a
kodovani paralelnich systemu ;). Lockovani na Z-80 je pole neorane, a
zajimaji mne vase nazory na tuto problematiku, hlavne vyvojarsky
zainteresovanych lidi (baze, busy?).

--
PS: do konference Speccy je treba se prihlasit.

zelez

hmmmmm....

musim uznat, velmi dobre si vysvetlil podstatu. skutocne som si pochutnal,
s napatim som cital od zaciatku do konca.

samozrejme s poskytnutymi navrhmi suhlasim (zarovnanie tabulky lockov na
0x##00 je rozumné, len aby bolo co dat do medzier :-); sample un/lock
rutina).

este sa chcem opytat: cital som o pokusoch kompilovat jadro v C. nepozeral
som este na zdrojaky, ale verim, ze iste partie by sa mohli prepisat do
ASM, co by IMO (najma ak sa pouzivaju ako INLINE) mohlo mat usporny efekt
(kazdy bajtik opakovany X vela krat = vela X bajtikov).

Zdravim!

Feri

Hm, materialy o lockovani na Z80 jsou velmi zajimave.
UZIX resi svoje vnitrni kriticke sekce zakazanim/povolenim preruseni, cili na
 tom asi bude rozumne zapracovat.
Osetreni kritickych sekci neni ani ve funkcich volani jadra UZIXu 1.0.

Feri: Ano, tohle je otazka - jak velkou cast jadra ma smysl prepisovat do ASM.
Nutno rict, ze HTC komilator je pri pouziti optimizeru velmi efektivni.
Je treba si uvedomit, ze prepsanim do assembleru docela vyrazne snizime
udrzovatelnost projektu a zvysime jeho slozitost.
Asi neni pochyb o tom, ze veci blizke HW (napr. drivery FD, HD atd) je nutno
nakodovat v ASM (nakonec tak to v UZIXu vetsinou je), ale je otazkou, jak
postupovat ve zbytku jadra. Nechci tim rict, ze to nema smysl, ale rozhodne je
to nutne dobre uvazit.

Jinak dale pripravuji zdrojaky, ktere budou zakladem MZIXu; brzy se objevi na
SourceForge.

Fuzzy

jadro a ASM: samozrejme ze akykolvek ASM blok znizuje prenositelnost,
udrziavatelnost, zrozumitelnost. to co som mal ale na mysli su ale drobne
rutinky, ktore sa vyuzivaju casto, a ktore kompilator ani optimizer nemaju
sancu napisat tak dobre, ako by to spravil znaly a inteligentny autor. a
prave take rutinky sa pri vysokom pocte opakovani vdaka babickovskemu
"bajtik ku bajtiku" moze vyplatit prepisat...

inak na zdrojaky sa uz tesim, posli linku!

Feri