Názory k článku Vývoj pro ZX Spectrum: mikroprocesor Zilog Z80 a smyčky v assembleru

Dekuji! Jako obvvykle skvely clanek!

org 0x8000

ld HL,0x5800

ld (hl), l
inc l
jr nz,$-2

start EQU 8000
ORG 8000
8000:210058 LD HL, 5800
8003:75 LD (HL), L
8004:2C INC L
8005:20FC JR NZ, 8003


o 2 bajty kratsi a 256+4 taktu rychlejsi varianta.

PS: Sorry jeste jsem clanek nedocetl.

neni JR pomalejsi nez JP? Dokonce o dost, jestli si dobre pamatuju, protoze se musi spocitat 16bitovy cil pres osmibitovou ALU?

Záleží. JP cc trvá vždy 10 cyklů. JR cc trvá 12 cyklů, pokud se skáče a 7 cyklů, pokud se neskočí.
Dá se s tím vyhrát, pokud člověk zná pravděpodobnost skoku.
Ještě větší legrace je RET cc, což je nejlevnější test na Z80 (5 cyklů pokud podmínka není splněna, 11 pokud je splněna).

jj, ale tady skace (tedy podminka plati) 255x a jen 1x neskace, takze to je 12x255+7 versus 10x256 ne?

Jenze tady porovnavam

JR nz,... ; 2:7/12

s

DJNZ ... ;2/8/13

Takze nemusim resit ze to jednou neskonci, vsechny varianty jsou o takt rychlejsi.

A ano, JP by byl rychlejsi o 3*256-2 taktu, ale delsi o bajt a kdyz dokazi napsat neco kratsiho a stale jeste rychlejsiho nez original tak dam prednost delce.

Dokonce mam pravidlo kde porovnavam jablka s hruskama.

1 bajt = 4 takty

Kde beru do uvahy zda je to ve smycce, to pak s timto pravidlem vyhrava vzdy delsi kod. Asi jsem to nerekl dost jasne, ale neva.

Diky za doplneni. Priste zkusim block fill a block move, tak si nachystejte ruzne triky (s PUSH atd.), protoze tam je dost moznosti.

Tohle pasmo nezvladne

sbc A
sbc B

ale jen

sbc A,A ; A = A-A-carry
sbc A,B ; A = A-B-carry

Protoze sbc (odcitani s carry ) muze byt i pro HL

Nektere jine prekladace zase vyzaduji cilovy registr tam, kde pasmo ma implicitni A. Myslim ze to bylo u "sub B", ale nejsem si jisty.

PS: Sorry jeste jsem to stale nedocetl.

Tak jeste optimalizace pro posledni 16 bitovou smycku.

org 0x8000

start:
ld hl, 0x59FF ; adresa pro zápis
ld a, 0x57 ; stop pro horni bajt adresy

loop:
ld (HL),L ; zápis hodnoty na adresu (HL)
dec HL ; snížní adresy i zapisované hodnoty
cp H ; počitadlo vnější smyčky
jp nz, $-3 ; skok pokud nejsme pod atributovou pamětí
ret

ORG 8000
8000: label start
8000:21FF59 LD HL, 59FF
8003:3E57 LD A, 57
8005: label loop
8005:75 LD (HL), L
8006:2B DEC HL
8007:BC CP H
8008:C20580 JP NZ, 8005
800B:C9 RET

To by melo byt o 4 bajty kratsi, ale skoro o 512 taktu pomalejsi (jsem linej to pocitat). Dalo by se to zkratit o další bajt a zpomalit o dalsich 1024 taktu prostym nahrazenim instrukce skoku za relativni skok.

Djnz je sice efektivni, ale ne vzdy.

Ah s tim CP H je to brutalni reseni!

Nasel jsem o bajt kratsi reseni a jeste k tomu rychlejsi.
Neni to ale 16 bitova smycka, ale 8 bitova, jen staci zvednou a snizit H.

Puvodni (12 bajtu a cca 27 taktu na bajt, oproti 16 bajtu a cca 26 taktu na bajt z clanku):

    org 0x8000

    ; t= 10+7+10+512*(7+6+4+10)=27+512*27=13851
start:
    ld   HL, 0x59FF         ; 3:10  adresa pro zápis
    ld    A, 0x57           ; 2:7   stop pro horni bajt adresy

loop:
    ld  (HL),L              ; 1:7   zápis hodnoty na adresu (HL)
    dec  HL                 ; 1:6   snížní adresy i zapisované hodnoty
    cp    H                 ; 1:4   počitadlo vnější smyčky
    jp   nz, loop           ; 3:10  skok pokud nejsme pod atributovou pamětí
    ret                     ; 1:10

Nove (11 bajtu a cca 38/2=19 taktu na bajt):

    org 0x8000

    ; t= 10+256*(4+7+4+7+4+12)-5+10=15+256*38=9743
start:
    ld   HL, 0x5800         ; 3:10  adresa pro zápis

loop:
    inc   H                 ; 1:4
    ld  (HL),L              ; 1:7   zápis hodnoty na adresu (HL)
    dec   H                 ; 1:4
    ld  (HL),L              ; 1:7   zápis hodnoty na adresu (HL)
    inc   L                 ; 1:4   zvýšení adresy i zapisované hodnoty
    jr   nz, loop           ; 2:7/12
    ret                     ; 1:10

Tohle reseni by slo prepsat na o neco pomalejsi variantu, ale ktera je schopna zvladnout vice 256 bajtovych bloku.
Univerzalnejsi (11 taktu a cca 41/2=20.5 taktu na bajt):

    org 0x8000

    ; t= 7+256*(7+7+4+7+4+12)-5+10=12+256*41=10508
start:
    ld    L, 0x00           ; 2:7   lo(adresa) pro zápis
loop:
    ld    H, 0x58           ; 2:7   hi(adresa) pro zápis
    ld  (HL),L              ; 1:7   zápis hodnoty na adresu (HL)
    inc   H                 ; 1:4
    ld  (HL),L              ; 1:7   zápis hodnoty na adresu (HL)
    inc   L                 ; 1:4   zvýšení adresy i zapisované hodnoty
    jr   nz, loop           ; 2:7/12
    ret                     ; 1:10

PS: Jeste by slo pouzit smycku kde counter by byl carry!
Protoze se ma zopakovat jen jednou (kod probehne 2x) a nikde carry nemenime.
Ale u takhle kratkeho kodu se to vyplati spis zduplikovat.

or A
loop:
...
ccf
jr c,loop

Nejkratsi varianta pro 16 bitovou smycku by byla s instrukci testu bitu.

0x59 = 0101 1001
0x58 = 0101 1000
0x57 = 0101 0111

0x57 se lisi u trech bitu.

Smycka je pomalejsi uz o 7 taktu na pruchod.

Puvodni - 13 (djnz) + 8 (bit) + 12 (jr)

org 0x8000

ld hl, 0x59FF ; adresa pro zápis
ld (HL),L ; zápis hodnoty na adresu (HL)
dec HL ; snížní adresy i zapisované hodnoty
bit 3,H ; test bitu 3
jr nz, $-4 ; skok pokud nejsme pod atributovou pamětí
ret

ORG 8000
8000:21FF59 LD HL, 59FF
8003:75 LD (HL), L
8004:2B DEC HL
8005:CB5C BIT 3, H
8007:20FA JR NZ, 8003
8009:C9 RET


PS: Jak se tu vlastne spravne vklada kod, aby zachoval odsazeni a neskoncil pri prvnim zalomeni?

Nebyl by varianta s JP NZ rychlejší, když už počítáš ty takty?

Myslim ze spravna odpoved je ti rici ze absolutni skok je rychlejsi ale o bajt delsi, protoze musi uchovavat celou adresu cile, tedy 2 bajty.

Pokud to vis, tak bych mel otazku zase ja, proc bys pouzival JP kdyz muzes pouzit kod stejne delky s tou variantou co jsem psal nad timhle kde je konec testovan pres

CP H
JR nz,$-$

co trva 4+12 = 16 taktu oproti

BIT 3,H
JP $-4

ktery trva 8+10 = 18 taktu? A kod je stejne dlouhy? Duvod by totiz stale nejaky byt asi mohl protoze je to Z80... .)

Snad všechny varianty z80 umí pracovat i s polovinami indexových registrů - LX,HX,LY,HY. A jde s nimi dělat totéž co s registry L, H (víceméně).
Díky prefixu opkódu jsou sice pomalejší než operace s L, H, ale i tak se hodí mít další 8 bitové registry.

A jinak bych nenazýval tu smyčku s šestnáctibitovým counterem jako naivní variantu, je to prostě nejčitelnější a správné řešení.
Tady ty hacky v diskuzi kolikrát nepřežijí přesun pracovního prostoru na jinou adresu.
Ta varianta s pseudo 16-bitovym registrem AB je validní, ale na zásobník se mnohem lépe ukládá BC než AB.

Myslim ze treba ten hack s testovanim bitu prezije cokoliv. Ze u tri po sobe jdoucich adresach se vzdy najde 1 bit u ktereho se bude kazdy lisit od zbyvajichich dvou. Mozna ani nemusi byt po sobe jdouci.

A u toho prikladu kde vyplnujes adresu 0x58.. a 0x59.. jdou udelat obe varianty s jak sestupnym tak vzestupnym posunem indexu.

Pravdu mas s tim ze pri jinych prikladech, kdy nelezi zacatky a konce (vyjma) na nulovych bajtech nizsi adresy muze byt kod s djnz efektivnejsi. Ale to je proste psani asembleru pro Z80. Efektivni kod se bude lisit podle konstant.

Dokonce nekdy muzes vzit nejlepsi kod a napsat o bajt kratsi jen tim ze ho ulozis na jedinou spravnou konkretni adresu do pameti.

Zajimave cviceni je napsat kod typu

cp DEHL, 32bitova konstanta

To je fakt temny les kolik optimalizaci tady muze vzniknout a co vsechno se da vyuzit. Jen to tomhle by se dal napsat fakt dlouhy clanek.

Promin nemuzu editovat ani reagovat sam na sebe (po/do)kud nebudu schvalen, tak forknu trosku vlakno.

S tim "cp" jsem mel na mysli slovo EQ nebo NE.

LE,LT,GE,GT jsou pro cisla se znamenkem taky temny les, ale ne az tak temny jako EQ.

Taky XL, XH, YL, YH nebo IXL, IXH, IYL, IYH ;)

Jop. Z80 měla hromadu nedokumentovaných instrukcí, narazil jsem na to, když jsem v mládí programoval emulátor, že jsem u některých pokročilejších programech, které jsem pak něm spouštěl, narážel na neznámé instrukční sekvence ... a netušil jsem, co mají ty sekvence dělat, protože neoficiální dokumentace těch instrukcí se v té době - internet neměl kde kdo - blbě sháněla

Diky, je to nostalgie. Kde jsou ty casy se ZX a pozdeji SAM coupe, kdy jsem si hral s asemblerem Z80 a hral hry od FUXOFT. Kdyz se divam na ten kod porad si to vybavuju, LD, JP NZ, ... Pak jsem chtel prejit s PC na intelovy asm ale nikdy k tomu nedoslo, proste ta slozitost narostla, jine zkratky (MOV, ...). Je to davno.

Přesně. Jakmile měl procesor extra instrukci i pro násobení, tak už to nebylo nic pro mě.

ASM Z80 jsem použil tak před 30 lety. Možná ještě dříve.
Dokonce pana Fuku jsem osobně několikrát viděl na stanici mladých techniků v Praze v Dejvicích. Nevím jak dopadl.

Nakonec jsem se k tomu dokopal a napsal i něco v moderních assemblerech x86 a x64. Zjistil jsem, že mnoho instrukcí x86 procesoru prostě "nechutná" a jediná instrukce trvá déle, než třeba 3 instrukce jiné. Ono je to třeba 10x pomalejší. Je tam spousta "plonkových" instrukcí, které se nepoužívají. Abych byl konkrétní tak <b>XCHG [paměť],registr</b>
U Z80 bylo časování deterministické, nové superskalární procesory zvládnou 3 instrukce v jednom taktu. A když se nezadaří tak to trvá výrazně déle.

https://cs.m.wikipedia.org/wiki/Franti%C5%A1ek_Fuka

Možná je dobré s trochou nadsázky dodat, že cokoli vytvoříte pro ZX Spectrum, tak bude spustitelný přes emulátor (i webovej) na prakticky jakékoli platformě. DOS, Windows, Linux, Mac, Android, iPhone, webové emulátory, asi to půjde emulovat i na emulátoru Amigy :-). To je docela unikátní platforma :-)

To je jak webassembly. By ještě chtělo propojit s web rozhraním, třeba přes in/out rozhraní.

jak se tahala webova stranka s "zx assembly" tak by to delalo ty "kazetakove" pruhy.

To normálně klíčovalo videosignál. Jen program ZX nevěděl, kde se právě paprsek generovaný ULA nachází. ULA buď generovala border, nebo obsah videoram. Dokonce se ty pruhy daly udělat v BASICu smyčkou:

1: LET i = 0
10: BORDER i
20: ... nejaké zpoždění
30: LET i = i+1
40: GOTO 10

ale opravdu bez záruky. Už si to detailně nepamatuji.

Da se to pouzit i jako "osciloskop" pro zjisteni, jak dlouho nejaka akce trva.

Jen to všechno muselo být na jednom řádku, příkazy oddělené dvojtečkou. PAUSE 1. Pak to dělalo divy. :)

Aaa, to je nostalgie. I když po těch 30+ letech jsem si vzpomněl maximálně, že RET je C9. A to se na Sharpu psávalo rovnou v hexa (M:Monitor po startu) :)
Děkuji za článek.

Co se týče počítání cyklů - viz https://www.overtakenbyevents.com/tstates/

Není to perfektní. Myslím, že tam je chyba u jedné instrukce a autor nekomunikuje, ale i tak je to nástroj, který hodně pomáhá a šetří práci. Alespoň pro základní orientaci s následnou kontrolou.

Pěkné, díky za link!

A pokud to chcete offline, tak doporučuji (myslím, že už po několikáté :)) výbornou knížku L. Zajíčka Bity do bytu. Jednak se opravdu hezky četla a hlavně měla tabulky s počty taktů pro instrukce Z80 jako přílohu.

Super kniha, svého času jedna z nejlepších, co se u nás dala k tématu sehnat.

Když už jsme u literatury - dobré jsou i Universumovy "Assembler a ZX Spectrum" - díky Softhousovi ke stažení zde https://softhouse.speccy.cz/dokumenty.htm společně s komentovaným výpisem ZX ROM od D. Jenneho... (se všemi pozdějšími korekcemi).

Zvláště první Assembler a ZX Spectrum je unikátní nejenom zajímavým obsahem, ale i tím, že to je kniha vysázená v programu Desktop na ZX Spectru (pravděpodobně nejrozsáhlejší dílo, co v Desktopu vzniklo). Přičemž Desktop je asi jediný opravdu plně WYSIWYG editor pro ZX Spectrum.

Pravděpodobně i Daniel Jenne psal své knihy na ZX Spectru, některé jsou sazbou shodné D-Textem, který D. Jenne počeštil původně ze Spectral Writeru.

jj ta kniha je skutečně dobrá (snažím se z ní neopisovat :)

Ano, znam ji. Taky jsem pouzival manual Mikroprocesorove systemy Z80 a I8085, vydala Tesla Eltos, (c) Vladimir Dvorak, 1986