Nie widzę żadnego odniesienia do 6502. To na pewno ten link co trzeba?

Pod zdjęciem adaptera: "It has a full-fledged computer inside it, usually a simple embedded processor with a 6502 core".

Te narzędzia jeszcze do nie tak dawna nie były darmowe... rzuciłem na nie okiem w momencie kiedy WDC udostępniło je, ale nie byłem zachwycony tym co wypluwał ten kompilator. Do tego instrukcja i sam kompilator i linker wydawały mi się strasznie toporne i chwilę mi zajęło zanim poprawnie udało się skompilować cokolwiek :)

Zresztą nie oszukujmy się... 6502 nie jest przyjaznym procesorem jeżeli chodzi o kompilatory, w większości przypadków tam gdzie ktoś wkłada 65xx pisanie w C mija się z celem, bo kod wygenerowany przez kompilator przy małym projekcie jest tak duży że tracimy połowę zasobów tylko dlatego że "kompilator".

Widziałem kiedyś też to co generuje komercyjny kompilator IAR-a, mimo że firma ma długą tradycję w pisaniu kompilatorów i ich kompilator robił co mógł, to kod nie był również zachwycający, niestety jak pisałem już wcześniej same ograniczenia architektury powodują że nie da się wygenerować sensownego kodu przy bardziej złożonych "konstrukcjach językowych". Może w przypadku 65816 jest lepiej, ale tutaj nie mogę się wypowiedzieć bo nie zajmowałem się analizą kodu wygenerowanego dla 65816 przez jakikolwiek kompilator.

...co chyba obserwujemy w MadPASCAL TeBe-go ;) Nie używam, ale tak mi się wydaje.

Kiedyś liczyłem na to że KickC ma szansę stać się całkiem fajnym kompilatorem, ale prawdę mówiąc przestałem śledzić zmiany i postępy w projekcie, bo miał on fazę kompletnego zastoju.

Z MadPascalem mam ten problem że to Pascal, to był co prawda jeden z pierwszych języków (po BASIC, ASM, etc.) których się uczyłem, ale gdy tylko przesiadłem się na C, to pisanie w Pascalu jakoś przestało być, hmmm... no nazwijmy to "atrakcyjne". Doceniam oczywiście starania TeBe i ogrom pracy który włożył w MadPascala, ogromny szacun za to! Ale sam Pascal jakoś mnie odrzuca, być może mam jakieś bezsensowne uprzedzenia i pewnie gdybym posiedział i przystosował się ponownie to by to jakoś poszło, ale ja po prostu robię za małe rzeczy aby wytaczać taką armatę jak MadPascal to moich prostych/prymitywnych projekcików... jestem jeszcze z tego pokolenia dla którego pisanie w pure ASM to czysta radocha :)

Ponieważ się "nie znam" to się wypowiem ;) 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:

ctx->iocb.len = 256;

będą również kłopotliwe do prostej/optymalnej realizacji za pomocą "zasobów" które są dostępne w 65xx.

Do kompletu jakieś nie ma mowy o ramkach stosu, etc. Trzeba tak naprawdę emulować "duży" stos, jeżeli chcemy mieć możliwość operowania na większych strukturach danych, czy lokalnych zmiennych znajdujących się na stosie.

@seban: no, ja asm to prawie nie znam, ale jakoś też mi się lepiej pisze drobnostki w C niż w Pascalu. Ale wiem, że to tylko przyzwyczajenia, ale im jestem starszy, tym jakoś mam mniej czasu na własne sprawy... A może to wina sytuacji i zmęczenia zdalną pracą, czego nie wykluczam...

Wow! No to tak jak myślałem... "zawsze można liczyć na braci z Azji" :D Prawdę mówiąc jestem zdziwiony że użyli właśnie rdzenia 65xx... zdziwiony to nawet mało powiedziane. O ile słyszałem o stosowaniu rdzeni podobnych do 65xx w układach skalerów do monitorów, to nie sądziłem że ktoś będzie integrował ten rdzeń z jakimś kawałkiem "Serial Engine" obsługującego USB, szczególnie w chwili kiedy dostępnych jest bazylion rozwiązań opartych np. 8051 czy inne 8-bitowce z o wiele większym wsparciem i bardziej rozbudowanymi bibliotekami do obsługi wszystkiego.

EDIT:

idąc tropem który pokazał Krótki, można znaleźć tego więcej: http://www.weltrend.com.tw/en-global/pr … /66/83/252

i dla zainteresowanych nota katalogowa: WT65F1, i jeszcze jedna trochę bardziej "rozbudowana": WT65F1 JTech.

Patrząc na zasoby tego typu wynalazków, wątpię aby dało się sensownie użyć jakiegoś języka wyższego poziomu. Zapewne cały soft zawarty w tego typu przejściówce powstawał w ASM.

btw. mam te przejściówki, w środku jest wersja "scalaka" bez obudowy i wyprowadzeń, czyli krzem położony na płytkę drukowaną, drutowany do PCB i zalany plasticzanym blobem :)

Da się oczywiście i w ten sposób, ale stos jest po prostu za mały aby dało się nieco bardziej skomplikowane rzeczy w ten sposób zrealizować, 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.

Ten WT65F1 to nawet fajna zabawka... 3 porty I/O w tym jeden z High Current. Aż kusi by się pobawić.. ale niestety.. jest słabo dostępny... na Ali sztuka kosztuje 140 zł. Więc odpada.

Ciekawe podejście do problemu.

Panowie... wątek jest SPRZĘTowy... :-)

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?