seban napisał/a:nie wiem jak jest dokładnie w CC65 (trzeba by podpytać np. Fox-a) ale wydaje mi się że stos jest emulowany (przynajmniej gdy wybierzemy "większy model pamięci/adresowania"). Niestety narzut kodu przy realizacji w tego w ten sposób jest dość spory i mam wrażenie że wydajność kodu generowanego przez kompilator drastycznie spada.
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.
seban napisał/a:Wydaja mi się że w przypadku 65xx i C problemem stają się również operacje które wymagają użycia dużej ilości
wskaźników, przykładowo:
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
perinoid napisał/a:@Fox: Możesz wyspecyfikować, o co ci chodzi? Czego według ciebie nie zrobiłem lub co zrobiłem a nie powinienem? I przede wszystkim, czemu powinienem byl tak zrobić (lub nie)? Konkrety proszę. Przyglądałem się fragmentom, np. jak robiona jest pętla dla tablicy dłuższej niż jedną strona albo jak jest robione memcpy. Ale całego kodu nie przeglądałem bo nie było to dla mnie interesujące.
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?