ABI cc65 stosuje do argumentów i zmiennych lokalnych stos programowy. Na stronie zerowej jest wskaźnik o identyfikatorze "sp". Stos sprzętowy jest używany tylko do adresów powrotu i na dane tymczasowe. Odczyt z wierzchołka stosu programowego wygląda tak:

    ldy #1
    lda (sp),y
    tax
    dey
    lda (sp),y

Na tej zasadzie mamy dostęp do wierzchnich 256 bajtów stosu.

Tu widzę tylko jeden wskaźnik: ctx. Zagnieżdżone struktury mają offsety będące stałymi czasu kompilacji.

; AX=ctx
    sta ptr
    stx ptr+1
    ldy #offsetof(ctx_iocb.len)
    lda #<256
    sta (ptr),y
    iny
    lda #>256
    sta (ptr),y

Twierdzę, że wydajność kodu zależy od tego, czy ISA jest dostosowana do semantyki języka programowania.
Twierdzisz, że "można spokojnie napisać kompilator", "Bez żadnego problemu", "zadanie dla studenta 3-go roku informatyki", ale nawet nie zajrzałeś do wyników cc65, nie wspominając o jego algorytmach optymalizacji.
Jeśli nie było to dla Ciebie interesujące, to skąd tak śmiałe tezy?

Dzięki za odpowiedzi! Autor posta chyba popłynął. W komentarzu ktoś mu wytknął, że nie wszystkie myszki działają z pasywną przejściówką.

Hmmm, nie szukają w tym WDC inżyniera kompilatora? ;)

Z C na 6502 są dwa podstawowe problemy:

• większość kodu operuje na intach, które są co najmniej 16-bitowe

• mocno używany jest stos, a 6502 oferuje tylko dostęp do elementu na wierzchu i ma mały stos

65816 rozwiązuje oba te problemy. Nie widziałem kodu wygenerowanego dla 65816, ale mogę się założyć, że jest znacznie bardziej wydajny, niż dla 6502.

Nie znałem tego programu, a Control+H pokazuje imponującą listę operacji! Dodałem obsługę do RECOIL.

A wiesz, że dekompresor ZX0 na 6502 już był? Jest link na https://github.com/einar-saukas/ZX0

Szybkie mnożenie w Shrinklerze:

Dekompresja obrazka trwa teraz 5,6 sekundy zamiast 9,5 sekundy.

Koszty:

• dodatkowe 1,5 KB na tablice kwadratów

• kod dłuższy o około 150 bajtów - co nie jest złym wynikiem, bo wciąż jest krótszy od inflate

• dodatkowe 8 bajtów na stronie zerowej

VBLK nie, bo "X nie jest stałe". DLI by się nadało.

Inne podejście to jeśli procka jest jednorodna, wstawić do niej jakiś licznik, żeby sama umiała się przerwać.

zopfli --deflate --i4000: 1598 bajtów

Edit:
Dopisałem info o --i do instrukcji inflate. Pewnie nie byłem jedyną osobą, która nie wiedziała o tej opcji.

Na czym polega różnica?

Przydałby się jakiś wzorcowy dla Atari 8-bit zestaw danych do kompresji, żeby porównywać kompresory:

• riverraid.rom jest spoko, przydałby się jeszcze jakiś wiekszy nieskompresowany program

• grafika (conan.gfx jest git)

• plik tekstowy (gpl-3.0.txt?)

• cmc, mpt lub rmt bez nazw instrumentów

Może kogoś zainteresuje mój warsztat. Mam teraz monitor 4K i świetny edytor, ale przy bardziej zaawansowanych optymalizacjach kartka jest niezastąpiona.

To ma sens, bo kod jest mocno 16-bitowy i nawet kulawe przełączanie się między trybami 8/16 bitów nie powinno boleć. Plus MVN się przyda. Ale dopał nie będzie taki, jak przy szybkim mnożeniu na 6502.

Dobre pytanie.
Na PC zwykle kompresuje się tylko bardzo duże zbiory i przykłada wielką wagę do wydajności dekompresji, a mniejszą do stopnia kompresji. Shrinkler wykonuje jedno mnożenie i kilka operacji warunkowych na każdy bit skompresowanego strumienia. Nawet na wypasionym pececie dekompresja tak skompresowanych gigabajtów trochę potrwa i nie ma jak jej zrównoleglić. Na Amidze i Atari każdy poczeka te kilka sekund na rozkompresowanie pojedynczych kilobajtów. Na pececie przydałaby się akceleracja sprzętowa. Być może dałyby radę akceleratory AI, które są świetne w mnożeniach.

Syzygy 7 - "Obsługa podkatalogów".

Dlaczego masz inne wyniki od moich? Skąd wziąłeś Shrinklera i Deflater? Ja skompilowałem Shrinklera z GitHuba, a zopfli z MSYS2.

Tebe mądrze pisze we wszystkich trzech powyższych postach. Gdzie tu się klika lajki?