Autor Wątek: Tricki na Amstradzie  (Przeczytany 34883 razy)

tooloud

  • *****
  • Wiadomości: 2974
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: Tricki na Amstradzie
« Odpowiedź #75 dnia: 2021.02.15, 21:46:42 »
Pytania nie zauważyłem, ale chyba ja nie rozumiem dlaczego taki nacisk na to kładziesz, bo jest to dosyć oczywiste:

http://z80-heaven.wikidot.com/instructions-set:jr

weźmy skok warunkowy JR NZ, NN

jeżeli jest spełniony warunek to zajmuje to prockowi 12 tstatów, jeżeli nie jest - tylko 7. Dlatego dwa wyliczenia dla pętli. Ale czy policzy ile razy zrobi pętlę i jaka jest suma tsatów na wyjściu z pętli? Raczej nie, ale jestem otwarty na zmianę myślenia o ZASM jeżeli jest inaczej.

I teraz jeszcze raz - o czym pisałem - DEBUGGER, nie assembler, pozwala na śledzenie kodu wraz z przyrostem tstatów/rejestrów etc. Assembler może Ci w raporcie wyliczyć tabelkowe dane jak te powyżej, ale w praktyce - chcesz się zmieścić z czymśtam w 250 tstatach - albo zobaczyć gdzie wypada ta ilość tstatów w Twoim kodzie - wtedy ma sens narzędzie o którym pisałem. Kompletnie dwa różne zastosowania i potrzeby.
dużo sprzętu mało czasu.

Klaud

  • *****
  • Wiadomości: 5648
  • Miejsce pobytu:
    trzecia planeta od Słońca
  • KL
Odp: Tricki na Amstradzie
« Odpowiedź #76 dnia: 2021.02.16, 07:02:14 »
Chyba qmam. Dla mnie programowanie jest poza moim poziomem abstrakcji, dlatego nie jestem informatykiem lub programistą. Dzięki.
KL
-----
R Tape loading error 0:1

matofesi

  • *****
  • Wiadomości: 1856
  • Miejsce pobytu:
    Toruń/Poland
Odp: Tricki na Amstradzie
« Odpowiedź #77 dnia: 2021.02.16, 08:58:48 »
Problem statycznego vs dynamicznego zliczania czasów wykonania to stosunkowo skomplikowana kwestia. Bo z jednej strony jest to, czego nie zrozumiał Klaud - czyli proste statyczne choćby z warunkowymi wynikami zliczanie można zrobić choćby podczas assemblacji ale nie da się tego zrobić sensownie bez pełnej symulacji/emulacji wykonania kodu. Debuggery o których wspomina tooloud też nie do końca będą potrafiły to zrobić dobrze jeśli nie mają np. mechanizmów "podkładania" danych zewnętrznych. Dla "prostego" kodu liczącego jakieś rzeczy, przerzucającego dane itp. można policzyć czasy wykonania stosunkowo prosto. Ale co z kodem, który robi jakieś I/O i chcielibyśmy wiedzieć jak się czasowo zachowa zależnie od danych, które dostanie z zewnątrz?... Profilowanie wykonania kodu to cała szeroka gałąź i to o czym dyskutujemy to oczywiście tylko malutki jej wycinek :)

Myślałem kiedyś, żeby sobie spróbować zrobić taki "profiler" (ale raczej właśnie do dynamicznego zliczania taktów niż do analizy które gałęzie kodu jak się wykonują), ale po przemyśleniu uznałem, że ilość pracy jaką trzeba by w to włożyć żeby było zrobione dobrze przekracza użyteczność otrzymywanych wyników w zastosowaniach, do których chciałbym takiego narzędzia używać ;) Zadziałała więc klasyczna zasada "jeśli chcesz coś zrobić, to usiądź i przemyśl... przejdzie ci" ;)

Gryzor

  • *****
  • Wiadomości: 1871
  • Miejsce pobytu:
    Warszawa
Odp: Tricki na Amstradzie
« Odpowiedź #78 dnia: 2021.02.16, 11:05:17 »
Profiler zatrzymal sie w 2016 roku  :D
https://www.speccy.pl/forum/index.php?topic=2346.0

Warunki i dane mozna symulowac w roznych przebiegach, ale dodajac przerwania wszystko sie znacznie komplikuje.
Moim zdaniem dobry statyczny profiler jest wystarczajacy - reszte mozna analizowac w emulatorze podczas normalnego wykonania programu. Tu bardziej przydaja sie narzedzia analizy/prezentacji niz same Tstates. Np. co mi z tego ze w funkcja f zajmuje lacznie 20% czasu wykonania, jak nie wiem skad i ile razy do niej wchodze. Tyle, ze na 8bitach procedury to nie jest normalnosc, bo na call/ret traci sie czas. I zostaje nam caly piekny kod z naduzywaniem GOTO...

matofesi

  • *****
  • Wiadomości: 1856
  • Miejsce pobytu:
    Toruń/Poland
Odp: Tricki na Amstradzie
« Odpowiedź #79 dnia: 2021.02.16, 11:08:56 »
Liczenie taktów ma w praktyce dwa zastosowania: porównywanie wydajności różnych algorytmów albo metod implementacji tego samego algorytmu oraz liczenie time-sensitive efektów graficznych. Do pierwszego przydać się może profiler albo debugger liczący dynamicznie, drugie zwykle trzeba jednak policzyć ręcznie ewentualnie posiłkując się maszynkami podobnymi do "kalkulatora" do którego link dał tooloud.

tooloud

  • *****
  • Wiadomości: 2974
  • Miejsce pobytu:
    Warszawa
  • mydłem go!
Odp: Tricki na Amstradzie
« Odpowiedź #80 dnia: 2021.02.16, 19:05:04 »
Tzn. ten kalkulator to takie bardzo proste narzędzie (użyłem tylko do sprawdzenia paru prostych kodów) - wg mnie debuggerem z licznikiem tstatów robi się to lepiej i bardziej uniwersalnie typu limit tstatów do zbadania na żywym kodzie etc. czyli z obiema rzeczami, które wymieniłeś używałbym debuggera, a nie tego kalkulatora (to taka bardziej ciekawostka - mam gdzieś na dysku wspomniany arkusz do Excela, który generalnie robi to samo, wklejasz kod, a on generuje kolumnę obok tstaty) - chociażby z racji tego, co próbowałem Klaudowi wytłumaczyć.
dużo sprzętu mało czasu.

matofesi

  • *****
  • Wiadomości: 1856
  • Miejsce pobytu:
    Toruń/Poland
Odp: Tricki na Amstradzie
« Odpowiedź #81 dnia: 2021.02.17, 08:17:45 »
Ja wiem, że proste, ale na co dzień jak potrzebuję policzyć takty to otwieram PDFa z manualem Z80 (albo po prostu przywołuję otwarte okno - gdzieś tam prawie zawsze wisi ;)) i liczę na piechotę przewijając PDFa w te i we wte ;)
Co do zasady uważam, że takie liczenie ma sens w kilku dość ograniczonych przypadkach - głównie akademickich dyskusji oraz efektów na borderze na Spectrum - i w praktyce dotychczas właściwie nie odczuwałem potrzeby używania bardziej zaawansowanych narzędzi tego typu.

McArti0

  • *
  • Wiadomości: 4
Odp: Tricki na Amstradzie
« Odpowiedź #82 dnia: 2021.02.17, 23:46:22 »
kopiowanie ekranu  &c000-&FFFF do banku 1 &4000-&7FFF

musimy mieć 3 linie rem wypełnione do końca

kopiowanie przez stos z prędkością 15,6 T/byte - szybszy od LDI ! ;-)

org #277
di

push AF
push hl ;11
push bc ;11
push de ;11
push iy ;15
push ix ;15
exx ;4
EX AF, AF' ;4
push AF
push hl ;11
push bc ;11
push de ;11

;-------------------

ld (#8002),SP
ld sp,#fff0      ;źródło

ld ix,#7fff       ;cel-1
inc ix
ld a,170          ;170*16*6+16*4=16384

petla:
EX AF, AF'  ;4

macro kopia            ;246T/16byte

pop af ;10
pop de ;10
pop bc ;10
pop hl ;10

exx ;4

pop iy ;14
pop de ;10
pop bc
pop hl

ld sp,ix ;10

push hl ;11
push bc ;11
push de ;11
push iy ;15

exx ;4

push hl ;11
push bc
push de
push af

ld hl,#7ff0 ;10
add hl,sp   ;11
ld sp,hl    ;6

ld de,#fff0 ;10
add ix,de ;15

mend

kopia
kopia

ost_4:
kopia
kopia
kopia
kopia

EX AF, AF' ;4
dec a ;4

jp nz,petla ;10    170*6*16 byte=16320

inc a

ex af,Af'

jp nz,ost_4 ;10  4*16 byte=64

ld sp,(#8002) ;20

jp linia_3

org #377

linia_3:
pop de
pop bc
pop hl
pop af

ex af,af'
exx

pop ix
pop iy
pop de
pop bc
pop hl
pop af

ei
koniec:
ret

McArti0

  • *
  • Wiadomości: 4
Odp: Tricki na Amstradzie
« Odpowiedź #83 dnia: 2021.02.19, 23:22:53 »
Ja pisywałem tylko w Basicu a

LD HL
LD DE
LD BC
LDIR
RET

to najbardziej zaawansowany kawałek kodu jaki zdarzało mi się używać świadomym znaczenia każdego bajta. :)
Czy potraficie tak zmodyfikować powyższą metodę bym mógł ją wywoływać w Basicu podając jednocześnie parametry?
czyli CALL adrprocedury,adrźródła,adrdocelowy,ileprzesłać 
a nie jak teraz, że muszę POKE-ami ją modyfikować i wywołać prostym CALL adrprocedury

I skoro trafiłem na takich speców to zapytam, ile by zajął kod do przeniesienia 16KB tą metodą LDI?

ostatni parametr jest od razu w DE jeżeli, skorzystać z tego to nie mógł by to być "ile przesłać", tylko adres docelowy.
można też skopiować DE do BC.

generalnie rejestr IX zawiera adres w pamięci gdzie znajduje się słowo (integer) z ostatnim (u nas trzecim) parametrem.

(IX+2) to adres przedostatniego parametru
(IX+4) to adres przed-przedostatniego parametru czyli pierwszego.

w rejestrze A jest ilość parametrów.

można by karmić rejestry długą sekwencją

LD C,(IX+0)
LD B,(IX+1)
LD E,(IX+2)
LD D,(IX+3)
LD L,(IX+4)
LD H,(IX+5)

;19*6=114 taktów

LDIR

RET

to przy założeniu, że na pewno są 3 parametry, bo nie sprawdzamy akumulatora.


Wersja przez stos

DI               ;4
LD IY, 00     ;14
ADD IY,SP   ;15

LD SP,IX     ;10

POP BC      ;10
POP DE      ;10
POP HL      ;10

LD SP,IY    ;10

EI             ;4

;  ^  87 taktów

LDIR

RET

ps. nie da się umieścić w rem niestety ;-), bo są zera w jednym i drugim.