Tak, ja wiem, ile zajmuje rep/sep, i oczywiście, przy całkowicie ośmiobitowym kodzie, nie zawsze się opłaca przełączenie (dla pojedynczej operacji - prawie nigdy). Ale tam są takie oto na przykład ciągi rozkazów 8-bitowych:

Nie patrzę całościowo, więc nie wiem, czy ten kawałek ma jakikolwiek wpływ na renderowanie klatek, ale wygląda, jakby danie rep #$20 na początku, a sep #$20 gdzieś na końcu pozwoliło go skrócić o połowę.

Widziałem podobny kawałek kopiujący w podobny sposób z miejsca na miejsce bodaj 12 bajtów przy użyciu 24 rozkazów - 72 bajty, 96 cykli, przy przełączeniu na 16-bitowy akumulator zeszłoby to do 40 bajtów i 14 rozkazów na sumę 66 cykli.

Jakieś ciągi lsr/ror/lsr/ror na dwóch kolejnych bajtach, w pętlach i bez - to wszystko jest do optymalizacji.

Dzięki za troskę, ale o niczym nie zapomniałem - w1k może to wkleić Claudowi tak samo, jak wkleja tu jego odpowiedzi.

Nie ma pośpiechu, dzięki.

Popatrzyłem sobie jeszcze tu i tam i nadal mi się wydaje, że coś można osiągnąć mikrooptymalizacjami niekoniecznie nawet polegającymi na zastosowaniu 16-bitowego akumulatora, bo i kod czysto ośmiobitowy można ulepszyć, np.

Zakładając, że nie ma odwołań z zewnątrz pod $4d60 (a nie widzę, żeby były), reforma da 8 cykli zysku (a ten kawałek kodu jest wywoływany bardzo często).

Co więcej, zawartość akumulatora jest potem (po odgałęzieniu bcc pod $4d66 do rts w $4d76) tracona, więc można zastąpić cmp $1353 przez sec/sbc $1353, a sec i sbc stojące poniżej odgałęzienia zlikwidować całkowicie. To da razem 10 cykli zysku - a cały kawałek od adresu $4d5a do $4d6d ma ich, o ile dobrze liczę, 28.

No, i tak dalej, i tym podobnie, usque ad mortem.

benche.. + SPEEDUP_LOG.md (jest napisane po słowacku)

drac030, tak, pozwoliłem AI na to spojrzeć i przyznać, że niektóre rzeczy są tam zbędne. w rzeczywistości takie zmiany w kodzie dają około −302 µs/f = +0,18% fps. jutro wydam nową wersję, a potem będę miał 10-dniową przerwę.

Zdecydowanie nie o to chodzi. Próbuję oszukać AI, żeby pomyślała, co piszesz, a konkretnie skopiowała i wkleiła Twoją reakcję. Pracuję nad tym, tak :)

fps 2.94 - 3.12

http://turiecfoto.sk/atari/doom-test/doom.zip

tak, robię to dokładnie tak samo. zwracam też szczególną uwagę na same pliki, używam też gemini pro i przesyłam wyniki do rozpatrzenia w opus 5, fable 5.

a nie możesz tych wytycznych które podał ci drac030 wprowadzić jako skill? Bo to przecież normalne żeby go uczyć tego jak ma pisać. i dokładnie opus czy fable radzi sobie z tym idealnie.

Jeszcze się przyczepię, bo to trochę pokazuje, jak u tego całego Claude'a jest z myśleniem, a tym samym, z jakością kodu. Mamy takie coś:

00:E9EA:    REP #$20
            LDA $D1
            AND #$7FFF
            ASL
            ASL
            CLC
            ADC #$2C74
            STA $84
            SEP #$20
            LDY #$00
            LDA [$84],Y
            STA $E7
            INY
            LDA [$84],Y
            STA $E8

Jak widać, wersja testowa w końcu używa 16-bitowego akumulatora (i robi to dużo częściej niż poprzednia, naliczyłem 47 wystąpień rozkazu rep #$20). I bardzo dobrze. Ale byłoby lepiej, gdyby to było robione z głową:

1) rozkaz AND #$7FFF jest w ogóle niepotrzebny, a zajmuje 3 bajty i 3 cykle
2) dalej mamy przełączenie na 8-bitowy akumulator (SEP #$20), po czym kod radośnie pobiera z pamięci 16-bitowe słowo bajt po bajcie i takoż bajt po bajcie odkłada je do dwóch kolejnych komórek pamięci.

Powinno być tedy:

00:E9EA:    REP #$20
            LDA $D1
            ASL
            ASL
            CLC
            ADC #$2C74
            STA $84
            LDA [$84]
            STA $E7
            SEP #$20

Oszczędza się 10 bajtów i 15 cykli, głównie dzięki przestawieniu jednego rozkazu w inne miejsce.

Dalej idzie wywołanie podprogramu, który: a) kopiuje owo $E7-$E8 do $EF-$F0, oczywiście znowu bajt po bajcie, robiąc jednocześnie mnożenie przez 8 przez trzykrotne przesunięcie w lewo, oczywiście też bajt po bajcie (tym razem przynajmniej pierwsze przesunięcie robi razem z kopiowaniem, brawo; ale resztę już na pamięci, niebrawo). Chociaż można to zrobić tak:

00:E9EA:    REP #$20
            LDA $D1
            ASL
            ASL
            CLC
            ADC #$2C74
            STA $84
            LDA [$84]
            STA $E7
            ASL
            ASL
            ASL
            STA $EF           
            SEP #$20

W następnym kroku do obliczonej wartości trzeba dodać 256 i zapisać ją pod $BF-$C0. Kod:

            CLC
            LDA $EF
            ADC #$00
            STA $BF
            LDA $F0
            ADC #$01
            STA $C0

Chociaż wystarczyłoby tak:

00:E9EA:    REP #$20
            LDA $D1
            ASL
            ASL
            CLC
            ADC #$2C74
            STA $84
            LDA [$84]
            STA $E7
            ASL
            ASL
            ASL
            STA $EF
            CLC
            ADC #$0100
            STA $BF          
            SEP #$20

Oryginał: 36 rozkazów (w tym dwie pary JSR/RTS), 67 bajtów, 130 cykli CPU.

Modyfikacja: 17 rozkazów, 29 bajtów, 53 cykle CPU. Przy czym STA $E7 może być w ogóle niepotrzebne, jeśli tak, to 16 rozkazów, 27 bajtów, 49 cykli.

Ostatnia dzisiejsza wersja ma błąd. Krok po kroku:

1) ładujemy całość
2) przechodzimy do menu
3) wybieramy New game
4) wybieramy którykolwiek z epizodów, np. nr 3, wciskamy Return
5) robimy parę kroków
6) wciskamy Esc, żeby wrócić do menu
7) wybieramy New game - już w tym momencie panel na dole zamienia się w kaszkę
8) wybieramy inny epizod, np. nr 2, wciskamy Return (panel się odtwarza)
9) robimy parę kroków
10) wciskamy Esc, żeby wrócić do menu
11) wybieramy New game (panel = kaszka)
12) wybieramy epizod nr 1, wciskamy Return - w tym mniej więcej momencie następuje zwis, program przestaje reagować na klawiaturę i joystick