atarionline.pl Action!, MAD Pascal, C - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthorastrofor
    • CommentTime14 Apr 2020 zmieniony
     
    Celowo jak tytuł wątku nie napisałem Action! vs mad pascal vs c , bo nie chodzi mi tu o to który z języków jest lepszy. Chciałbym się bardziej dowiedzieć o historię , różnicę, ewentualnie słabości tych trzech języków. Moim zdaniem wszystkie 3 są językami podobnego poziomu, o dość podobnej filozofii.
    -- Mad Pascal jest mocno rozwijany, posiada elementy obiektowe, sporo programistów zainteresowanych pisaniem i rozwijaniem języka, poza tym społeczność mocno nastawiona na open source.
    -- c Szczerze coś tam słyszałem, ale niewiele, ostatnio na Kwasie online autor His Dark Majesty powiedział że właśnie hdm powstał w c niejako jako port tego produktu na pcta, bez szczególnego grzebania w assemblerze. Zabrzmiało to naprawdę super, szczególnie że c jest żywym językiem, nawet bardzo żywym.
    -- Action! to prawdziwie język z epoki (choć c też chyba był na atari za jego świetności). Także pewnie super materiał do szukania ciekawostek, anegdotek itd. Czy wróci do życia, trudno powiedzieć. W książce TDCa można się doczytać że w kompilatorze był jakiś spory bug. Pewnie masę rzeczy pominąłem, o 90% pewnie nie wiem. Jak by się ktoś odniósł byłoby super.
    • 2: CommentAuthorzbyti
    • CommentTime14 Apr 2020 zmieniony
     
    Było na ten temat trochę w wątkach w kórych testowałem różne języki programowania na A8, ale wtedy chyba miałeś jeszcze status zaginionego ;P

    ->link<- & ->link<-
    • 3:
       
      CommentAuthorKaz
    • CommentTime14 Apr 2020 zmieniony
     
    Tak, Ilmenit przy pisaniu HDM posługiwał się Cc65, nota bene też ciągle rozwijanym. Z tego co mówił, obecnie kompilowany HDM jest o kilka kilkobajtów krótszy i nieco szybciej działa niż ten z 2010 roku...

    Tak, w czasach zamierzchłych na Atari były zarówno różne implementacje C i Pascala, ale były takie jakieś mało użytkowe, jakoś nie pamiętam, żeby były w wygodnej formie czy miały zawsze taki komplet z kompilatorem jak Action!. I chyba tak to było odbierane na całym świecie, bo w Action! powstawało najwięcej softu, oczywiście po Basicu i asemblerze. Więc nie był taką ciekawostką, jak się wydaje współcześnie.
    • 4: CommentAuthorilmenit
    • CommentTime14 Apr 2020
     
    Z mojego punktu widzenia:

    Aktualnie CC65 i Mad Pascal to najlepsze narzędzia do pisania w językach wyższych niż asembler na Atari jak chodzi o cross-compilację. Szybkość generowanego kodu mają porównywalną.
    Mad Pascal ma większą bazę funkcji bibliotecznych dla Atari, ale składnię Pascala, co dla niektórych może być nieprzyjemne. Z większych gier napisanych w nim na Atari jest "Pac Mad" ->link<- . Zaleta - aktywnie rozwijany przez Tebe, potencjalna wada - o ile się nie mylę, tworzy go tylko Tebe.
    CC65 ma składnię C, co powoduje, że prościej na niego przejść z innych języków współcześniej używanych jak C++, C#, Java czy nowego C (ponad standard C89 wykorzystywany w CC65). Z większych gier napisanych w nim na Atari to "His Dark Majesty", "The Hunt", lub tworzone aktualnie "Adam Is Me" lub ->link<- . W CC65 powstało też sporo gier na NESa czy C64. Zaleta - rozwijany na GitHubie przez kilka osób. Wada - niektóre optymalizacje trzeba robić ręcznie.
    Action! jest dla lubiących "natywne narzędzia", ale Gury ożywił Effectus, czyli cross-compiler ->link<- ... który generuje kod pośredni Mad Pascala w nowej wersji.
    • 5: CommentAuthorastrofor
    • CommentTime14 Apr 2020 zmieniony
     
    @zbyti: z tym benchmarkiem to wykonałeś mega robotę!

    Z mojej perspektywy mad pascal, przynajmniej w PL ma większy background. Prężnie działający techniczny wątek na aolu, sporo otwarego kodu i przykładów, że wymienię wszystkie pracę Bociana, był też ktoś konwerjący wszystko co się da ze spectrum(pełen szacun !). W c znalazłem źródła The Hunt... i nie powiem było spore wooow! Ale z tego co widzę(oczywiście mogę się mylić) to Polska ekipa c , to jednoosobowa armia, Pascalowców jest znacznie więcej.No i pascal trochę mi się kojarzy z liceum, pod koniec studiów ktoś proponował prace w delphi, to spotykał się ze zdziwionymi spojrzeniami, a to było prawie 20 lat temu, ale jako hobby czemu nie! Kurs Action! myślę podobnie jak Zbyti, że to będzie dobra okazja do ogarnięcia mapy pamięci atari, no i pewnie będzie wesoła atmosfera ;)
    • 6:
       
      CommentAuthorsun
    • CommentTime15 Apr 2020
     
    @ilmienit: kod madpascala jest również na githubie i można sobie pogrzebać jak ktoś lubi ;)
    • 7: CommentAuthorilmenit
    • CommentTime15 Apr 2020
     
    @sun:
    to dla porównania:
    Mad Pascal - contributors: 1 ->link<-
    CC65 - contributors: 64 ->link<-
    • 8: CommentAuthorastrofor
    • CommentTime15 Apr 2020
     
    64 contributors brzmi jak c64 ;) Myśle że kompilator jest elegancki i zoptymalizowany, ale z bibliotekami na atari może być troche posucha. Zresztą czytałem już taką opinię na tym forum (Zbyti). Z tego co widziałem w The Hunt. to całość jest przygotowana do śmigania na windowsie (wyższość plików bat nad sh)
    • 9: CommentAuthorzbyti
    • CommentTime15 Apr 2020 zmieniony
     
    @astrofor a mógłbyś przytoczyć moją opinię? Bo nie do końca kojarzę...

    Z tego co pamiętam, to CC65 złapałem tylko na gorszej optymalizacji mnożenia niż to jest w Mad Pascalu.

    Co do macoszego traktowania A8 to przypominam sobie dyskusję o millfork.

    Chyba, że chodzi o wypowiedź kogoś innego w wątku co założyłem.

    @illmenit kwestię bibliotek MP vs. CC65 poruszył także i tutaj.

    A co do one-man-army to oprócz @illmenit okazało się, że w CC65 także wymiata @antrykot ale faktycznie na źródła jego programów nie natrafiłem.
    • 10:
       
      CommentAuthorbocianu
    • CommentTime15 Apr 2020
     
    CC65 - contributors: 64


    64 kontrybutorów z czego 20 zrobiło mniej niż 3 commity :D
    to są tylko liczby. Poza tym cc65 jest bardzo fajne, ale nie jest focusowane na Atari w przeciwieństwie do MadPascala.
    Ja wolę jednego dobrego, skutecznego i reagującego na prośby i sugestie Tebego :)

    I nie mówię że Mad-Pascal jest lepszy, tylko mówię, że jest lepszy dla mnie. A także wygodniejszy i intuicyjny. O gustach można tak dyskutować godzinami i fajnie, że możemy, bo mamy kilka narzędzi i każdy może poszukać czegoś dla siebie. I fajnie że mamy wybór!
    • 11: CommentAuthorilmenit
    • CommentTime15 Apr 2020 zmieniony
     
    64 kontrybutorów z czego 20 zrobiło mniej niż 3 commity :D

    drugi punkt widzenia to taki, że 44 kontrybutorów zrobiło 3 commity lub więcej ;)
    • 12: CommentAuthorastrofor
    • CommentTime15 Apr 2020
     
    to trochę offtopic ale ciekawy artykuł o jednoosobowych projektach na repozytorium :

    ->link<-

    Tebe - życzymy wiele zdrowia, i nie jeździj na motorze ;)
    • 13:
       
      CommentAuthorcrrn
    • CommentTime15 Apr 2020
     
    Panowie wiem że nie w temacie Atari, ale się wypowiem - wybaczcie, ale Kaz mówił że mogę ;)
    Po kilku dyskusjach tutaj i np na KWASie ja odkrywam ostatnio coś co się nazywa KickC i jest w zasadzie luźną (na razie) implementacją C i jednocześnie nakładką na Kick Assembler. Narzędzia w zasadzie komodorowskie, ale od biedy pewnie by się dało do Atari zastosować.

    Po dwóch dniach prób stwierdziłem że przetestuje w boju. Wybrałem sobie jako pomysł taką samą gierkę jak pisze Jelcynek na kanale Jaskinia Prawiczka. Zamierzam zrobić to samo co on na Atari i nagram o tym film(y) i pewnie artykuł. Odezwę się jeszcze bo narzędzie wygląda na prawdę zacnie i warto podzielić się w świecie retro wiedzą
    • 14: CommentAuthorastrofor
    • CommentTime15 Apr 2020
     
    @crrn: rewelacja - masz już pierwszego subskrybenta
    • 15: CommentAuthorilmenit
    • CommentTime15 Apr 2020
     
    sam jestem ciekawy jak się rozwinie konkurencja pomiędzy Millforkiem i KickC. KickC zaczął jako wariant języka C, ale autor na Facebooku napisał, że teraz głównie inwestuje czas w kompatybilność ze standardem języka. O ile może to przyciągnąć więcej użytkowników, niektóre cechy tego języka mogą wykluczyć wiele potencjalnych optymalizacji dla 6502.
    Ivop jakiś czas temu zaczął porta GCC dla 6502 - ->link<- mogłoby się też ciekawie rozwinąć więc szkoda, że projekt w zawieszaniu. Nowe kompilatory o ile robią dobre niskopoziomowe optymalizacje generowanego kodu maszynowego, to zdecydowanie kuleją przy optymalizacji kodu na poziomie języka i tu by mogła być duża przewaga GCC.
    • 16:
       
      CommentAuthorsun
    • CommentTime15 Apr 2020
     
    @ilmienit: ja podzielam raczej głos bocianu, tj. nie ilość komitów jest istotna a jakość :) Napisałem to tylko dlatego, że - na razie - madpascala rozwija 1 osoba, co nie znaczy, że się nie można do projektu dołączyć. Nie umniejszajmy też roli bocianu z jego libami oraz innych, którzy choćby zasilili całość źródłami swoich produkcji - czyli niby 1 osoba a nie jedna, jeśli patrzymy na całość a nie tylko na core kompilatora.
    • 17: CommentAuthorzbyti
    • CommentTime15 Apr 2020 zmieniony
     
    Liby do Mad Pascala można pisać, ale z tym dołączaniem do rozwijania kompilatora to już zupełnie inna historia...

    Jak już pisał bodajże Rudla - kompilator to specyficzny kawałek kodu, a ten z optymalizacjami to już przypadek szczególny.

    Jeżeli ktoś powątpiewa w moje słowa nich sobie poczyta trochę źródła kompilatora Mad Pascala... W tym co tam widać to tylko na ten moment autor kodu ma szansę się odnaleźć, albo jakiś mega-mózg, ale i tak wątpię by ktoś potrafił to zrobić z marszu.

    EDIT: pomijam już wymagania związane z wiedzę z obszaru kompilatorów oraz znakomitą znajomość 6502, ASM i Pascala.
    • 18: CommentAuthorastrofor
    • CommentTime15 Apr 2020
     
    Mimo mam wrażenie to ilość kompilatorów, niekoniecznie atari, ale 8 bit , przewyższa ilość kompilatorów z pełnymi i rozbudowanymi bibliotekami.
    • 19: CommentAuthortebe
    • CommentTime15 Apr 2020
     
    był już kiedyś ten link

    ->link<-

    problem popularności danego kompilatora dotyczy każdej platformy, zmienia się skala tego zjawiska, zależnie od popytu i podaży na dane rozwiązanie
    • 20: CommentAuthorilmenit
    • CommentTime16 Apr 2020 zmieniony
     
    Wiele języków dla 6502 jak Atalan, Effectus, Plasma, PyMite czy teraz KickC lub Millfork to "one man show" i gdy autor traci zainteresowanie, to narzędzie kończy swoje życie. Pisanie kompilatorów jest niestety trudne i tym bardziej np. Millfork pisany w Scali pewnie nie przyciągnie wielu kontrybutorów. Podobnie może być z KickC, gdzie językiem kompilatora jest Java. Mad Pascal i CC65 mają tę zaletę, że pisane są w tym samym języku co kompilator (Pascal i C), więc użytkownicy kompilatora mogą prościej do niego kontrybuować.
    Gdyby to nie był Tebe, to bym do Mad Pascala podchodził ostrożnie, ale Tebe pewnie był, jest i pewnie będzie długo po tym, jak my stracimy zainteresowanie Atari ;)
    Kontrybutorami do CC65 na Atari (nie do core) są np. aktywni na AtariAge Irgendwer, dmsc, Shawn Jefferson czy Bill Kendrick.
    Do cc65 też powstają biblioteki np. ostatnio player RMT
    ->link<-
    Z bibliotekami dla 6502 jest według mnie tak, że to głównie dobre przykłady jak coś zrobić, ale w praktyce każdy program dla 6502 jest na tyle inny, że "generyczne biblioteki" często tracą przydatność. Dla przykładu biblioteka pisania na ekran. Super, ale moje DLIST ma 3 różne tryby graficzne, a biblioteka zakłada, że sama otworzy ekran pod konkretnym adresem. Do ostatniego projekty chciałem wykorzystać dostępną na AtariAge bibliotekę szybkiego rysowania pikseli w ASM. Bardzo dobry kod, ale jako baza, bo po dostosowaniu do mojego projektu kod jest ok. 30% szybszy.

    Odnośnie popularności - ja będę CC65 propagował, podobnie jak Wy będziecie propagować MAD Pascala. I dobrze! Każdy ma swoje gusta i gdy propagowanie rozszerzy liczbę użytkowników, powstanie więcej fajnego softu na naszą platformę :)
    • 21: CommentAuthorzbyti
    • CommentTime16 Apr 2020 zmieniony
     
    @ilmenit to będziesz zadowolony z ostatniego KWAS-a bo KK pokusił się oswoją ocenę pisania w C dla 8-bit :]

    Nawet nieudolnie wciągnąłem go w ocenę poziomu trudności wykonania PoP na A8. Jak widać jak ktoś jest takim macherem to zrobienie PoP nie postrzega jako jakiegoś przełomu na małe Atari.

    Propaguj CC65! Na pewno będę korzystał z każdego materiału jaki wypuścisz, chcę to narzędzie opanować obok Mad Pascala, jak wkońcu ogarnę podstawy A8 za pomocą warsztatów @TDC ;)

    Jak będę w miarę posługiwał się 4 językami na A8 to wtedy świadomie wybiorę i wymasteruję najbardziej mi pasujący.

    Chociaż według KK pisanie na 8-bit i 64KB to tylko ASM, a jemu pasuje najbardziej jego własne narzędzie które nie czyni pisania w ASM tak rozwlekłym ;)

    Dyskusja się zaczęła od ~2h nagrania.

    Jak odsłuchasz to ciekaw jestem Twojej opinii na temat tego co powiedział KK :]
    • 22:
       
      CommentAuthorKaz
    • CommentTime16 Apr 2020 zmieniony
     

    Ilmenit:

    Wiele języków dla 6502 jak Atalan (...) to "one man show" i gdy autor traci zainteresowanie, to narzędzie kończy swoje życie


    O właśnie. Kiedyś Atalan wyglądał obiecująco i jakoś przygasł. A przecież powstało kilka gierek w tym języku, np.:

    • 23:
       
      CommentAuthorlaoo
    • CommentTime16 Apr 2020 zmieniony
     
    Siedzę teraz trochę na Atari Lynx i tam ludzie głównie piszą w cc65 (w asemblerze garstka) i te ich produkcje są zwyczajnie tragiczne. Na maszynie, która ma naprawdę dużą moc robią albo crapy, albo coś tragicznie wolnego.
    Ja zawodzę się na cc65 za każdym razem jak tylko do niego siadam. Jeszcze nie widziałem, żeby kod dłuższy niż kilka rozkazów był w nim wygenerowany optymalnie. A jeżeli mam pisać w nim specjalnie kod, żeby on nie robił głupot sprawdzając co rusz wynik i optymalizując aż będzie jako-tako, to już swobodniej czuję się pisząc w czystym asm.
    • 24: CommentAuthorzbyti
    • CommentTime16 Apr 2020 zmieniony
     
    @laoo no to szkoda, że Cię nie było na ostatnim KWAS-ie, ja bym z tego KWAS chętnie zrobił panel programistów, niestety niektórzy ludzie mają inne zainteresowania ;) :D

    KK też mówił o Lynx i CC65, generalnie macie zbieżną opinię w tej sprawie ale chętnie posłuchał bym także Ciebie na live :]

    EDIT:
    @xxl też mógłby się pojawić na KWASie, dla zabawy każdy o nieznanej ksywce i bez mikrofonu jest o to przeze mnie podejrzewany :]

    @tebe też mógłbyś wpaść, tak dla potomności! :D
    • 25:
       
      CommentAuthorlaoo
    • CommentTime16 Apr 2020
     
    @zbyti małe dziecko w domu planuje mi niestety wieczory inaczej niż siedzenie do nocy na kwasach :(

    Ale mi też dobry język wysokiego poziomu spędza sen z powiek, bo z Solem czujemy, że np pisanie logiki do gry w asm jest uciążliwe. Tylko nie znaleźliśmy niczego dostatecznie dobrego. Ja widzę potencjał w milforku, musiałbym się tylko dowiedzieć/nauczyć czy da się pisać w nim kod poszczególnych procedur, a nie cały program.

    Port gcc byłby świetną sprawą, ale to bardzo trudne. Mi chodzi po głowie, żeby kompilować gcc do np risc-v i tłumaczyć risc-v na 6502 z pewnymi specyficznymi optymalizacjami. Pomysłów można mieć wiele, tylko nietrafiony pomysł jest dość bolesny, bo w tym wieku czas to jedyna waluta jaką tak naprawdę się płaci.
    • 26: CommentAuthorzbyti
    • CommentTime16 Apr 2020 zmieniony
     

    laoo:

    Ale mi też dobry język wysokiego poziomu spędza sen z powiek, bo z Solem czujemy, że np pisanie logiki do gry w asm jest uciążliwe.

    Jak patrzę na algorytmy szachowe etc. to napisanie tego w językach wysokiego poziomu nie przekracza raczej moich możliwości, zrobienie z tego ASM już by mogło, więc dlatego tak interesuję się Mad Pascalem.

    Także jak odkryjecie coś w tej materii to dajcie znać! :]

    laoo:

    (...) bo w tym wieku czas to jedyna waluta jaką tak naprawdę się płaci.

    Prawda, ale wypowiedziana bardziej boli ;(
    • 27:
       
      CommentAuthorlaoo
    • CommentTime16 Apr 2020
     
    Pisanie w asemblerze wcale nie jest trudne. Trudne jest tylko czytanie czegoś, co napisało się kilka dni temu :)
    • 28: CommentAuthorilmenit
    • CommentTime16 Apr 2020
     
    @laoo - "kodu optymalnego" to raczej kompilatory dla 6502 szybko nie wygenerują. To nie mainstream jak kompilatory MS, Intela czy GCC. Ale nie znaczy to, że nie warto ich używać właśnie do logiki gry :-) Pisanie w języku wyższego poziomu to oprócz czytelności też olbrzymia szybkość pisania w porównaniu z asmem.
    Zasad pisania w CC65 aby generował dobry kod nie jest dużo. Przede wszystkim trzeba inaczej używać structs (zamiast "tablicy struktur" robić "strukturę tablic"), zwykle nie używać wskaźników, ale indeksów tablic i pamiętać, że kompilator nie robi wysokopoziomych optimalizacji kodu. Jak dokończę aktualny projekt to napisze artka jak pisać w CC65, aby było "prawie optymalnie".
    Osobiście też marzę o super-szybkim kompilatorze - Millfork lub KickC idą w tę stronę i trzymam kciuki za wytrwałość ich autorów, aby nie skończyły jak Atalan czy GCC-6502.
    • 29:
       
      CommentAuthorKaz
    • CommentTime16 Apr 2020
     

    Ilmenit:

    Jak dokończę aktualny projekt to napisze artka jak pisać w CC65, aby było "prawie optymalnie".


    Super! Dawaj premierę na główną, to więcej osób się zapozna.
    • 30: CommentAuthorzbyti
    • CommentTime16 Apr 2020 zmieniony
     
    @Kaz wolałbym info na głównej o artykule bo sam artykuł było by fajnie mieć w jakieś bardziej czytelnej formie/formatowaniu oraz formacie (PDF) by łatwo było to sobie trzymać pod ręka.
    • 31:
       
      CommentAuthorKaz
    • CommentTime16 Apr 2020
     
    Jedno drugiemu nie przeszkadza. Można online i PDF jednocześnie - to ułatwia wyszukiwanie i dotarcie.
    • 32:
       
      CommentAuthorlaoo
    • CommentTime16 Apr 2020 zmieniony
     
    @ilmenit Trochę zagalopowałem się z tym "optymalnym", bo doskonale wiem na czym polegają problemy w translacji kodu C na 6502.
    Raczej chodziło mi o cokolwiek co nie powoduje zgrzytania zębami i wyrywania włosów.
    godbolt (https://godbolt.org/) ma w swoim arsenale cc65 i łatwo można się przekonać jakie potworki on wypluwa. Ja wiem, że to nie jest łatwe i to najlepsze co mamy, bo nikomu nie opłaca się inwestować milionów w dobry kompilator dla 6502... ale jednak niesmak pozostaje.
    • 33: CommentAuthorilmenit
    • CommentTime16 Apr 2020
     
    Hm... na Godbolt CC65 nie widzę. Coś trzeba przestawić? Wrzuć jak możesz przykład kodu, dla którego CC65 generuje potworka a chętnie poradzę co z tym zrobić.
    • 34: CommentAuthorzbyti
    • CommentTime16 Apr 2020 zmieniony
     
    @ilmenit zmień źródło na C (domyślnie ładuje się C++) to dostaniesz możliwość wybrania CC65.

    Przykład kompilacji kawałka Twojego kodu (rom-sum) na stronie ->link<- CC65 2.17:

    // Type your code here, or load an example.
    unsigned int sum(void) {
    register unsigned int s;
    register const unsigned char* p;
    s = 0;
    for (p = 0; p != 0; ++p)
    {
    s += *p;
    };
    return s;
    }

    .proc   _sum: near

    jsr decsp4
    ldx #$00
    lda #$00
    ldy #$02
    jsr staxysp
    ldx #$00
    lda #$00
    ldy #$00
    jsr staxysp
    L0004: ldy #$01
    jsr ldaxysp
    cpx #$00
    bne L000B
    cmp #$00
    L000B: jsr boolne
    jne L0007
    jmp L0005
    L0007: ldy #$01
    jsr ldaxysp
    ldy #$00
    jsr ldauidx
    ldx #$00
    ldy #$02
    jsr addeqysp
    ldy #$00
    ldx #$00
    lda #$01
    jsr addeqysp
    jmp L0004
    L0005: ldy #$03
    jsr ldaxysp
    jmp L0001
    L0001: jsr incsp4
    rts
    • 35: CommentAuthorilmenit
    • CommentTime16 Apr 2020
     
    @zbyti - to bez optymalizacji włączonych?
    • 36: CommentAuthorzbyti
    • CommentTime16 Apr 2020 zmieniony
     
    @ilmenit wszystko puszczone domyślnie, pobaw się sam, ja nie mam wiedzy, jest tam okienko na flagi kompilatora.

    Mogę ustawić takie flagi jakie dałeś w paczce z kodem, ale możesz zrobić to sam i pokazać różnice, masz większe kompetencje w tym względzie.
    • 37: CommentAuthorilmenit
    • CommentTime16 Apr 2020 zmieniony
     
    do dodania flagi do włączenia optymalizacji: -Osir -Cl

    Dla czytelności kodu wygenerowanego można przenieść "ręcznie" na ZeroPage, zamiast używając słowo "register" i dla kodu:
    #pragma bss-name (push,"ZP")
    #pragma data-name (push,"ZP")
    unsigned int s;
    const unsigned char* p;
    #pragma bss-name (pop)
    #pragma data-name (pop)
    #pragma zpsym ("s");
    #pragma zpsym ("p");

    // Type your code here, or load an example.
    unsigned int sum(void) {
    s = 0;
    for (p = 0; p != 0; ++p)
    {
    s += *p;
    };
    return s;
    }


    mamy:
    _s:
    _p:

    .proc _sum: near

    lda #$00
    sta _s
    sta _s+1
    sta _p
    sta _p+1
    L000A: lda _p
    ora _p+1
    beq L000B
    lda _p+1
    sta ptr1+1
    lda _p
    sta ptr1
    ldy #$00
    lda (ptr1),y
    clc
    adc _s
    sta _s
    tya
    adc _s+1
    sta _s+1
    inc _p
    bne L000A
    inc _p+1
    jmp L000A
    L000B: lda _s
    ldx _s+1
    rts
    • 38: CommentAuthorxxl
    • CommentTime16 Apr 2020
     
    to jest po optmalizacji?
    • 39:
       
      CommentAuthorlaoo
    • CommentTime16 Apr 2020 zmieniony
     
    Jestem pod wrażeniem tego wyniku. Z tego co podłubałem, to widzę, że kluczem jest przełącznik

    -Cl Make local variables static


    Bez niego wychodzi jakiś szajs, ale z nim to faktycznie nie ma się czego specjalnie czepiać. Nie wiem tylko jak to się skaluje. Plus jeszcze otwartą kwestia jest zarządzanie pamięcią na te zmienne.
    Ale i tak jestem pozytywnie zaskoczony!
    • 40: CommentAuthorilmenit
    • CommentTime16 Apr 2020
     
    Tak, teraz po optymalizacji.

    "-Cl Make local variables static" powoduje, że kompilator nie używa software stacku, więc odpada rekurencja (co zwykle nie jest potrzebne, choć np. dla programu szachowego z jakimś algorytmem min-max czy alpha-beta by znaczyło zrobienie własnego stosu).
    • 41:
       
      CommentAuthorlaoo
    • CommentTime16 Apr 2020
     
    Co jak co, ale stos na 6502 to jednak nieporozumienie :)
    • 42: CommentAuthorilmenit
    • CommentTime16 Apr 2020 zmieniony
     
    A o co chodzi ze "strukturą tablic" zamiast "tablicą struktur".

    Tablica struktur:
    #define NO_MONSTERS 32

    struct monster {
    unsigned char x;
    unsigned char y;
    };

    struct monster monsters[NO_MONSTERS];

    #pragma bss-name (push,"ZP")
    #pragma data-name (push,"ZP")
    unsigned char index;
    #pragma bss-name (pop)
    #pragma data-name (pop)
    #pragma zpsym ("index");

    void set_monsters(void) {
    for (index=0;index<NO_MONSTERS;++index)
    {
    monsters[index].x = index;
    monsters[index].y = index * 2;
    };
    };

    generuje paskudny:
    _monsters:
    _index:

    .proc _set_monsters: near

    lda #$00
    sta _index
    L001A: lda _index
    cmp #$20
    bcs L0009
    ldx #$00
    lda _index
    asl a
    bcc L0018
    inx
    clc
    L0018: adc #<(_monsters)
    sta ptr1
    txa
    adc #>(_monsters)
    sta ptr1+1
    lda _index
    ldy #$00
    sta (ptr1),y
    ldx #$00
    lda _index
    asl a
    bcc L0019
    inx
    clc
    L0019: adc #<(_monsters)
    sta ptr1
    txa
    adc #>(_monsters)
    sta ptr1+1
    lda _index
    asl a
    iny
    sta (ptr1),y
    inc _index
    jmp L001A
    L0009: rts


    zaś po zmianie na "strukturę tablic" (może być dowolnie zagnieżdżona) mamy:
    #define NO_MONSTERS 32

    struct monster {
    unsigned char x[NO_MONSTERS];
    unsigned char y[NO_MONSTERS];
    };

    struct monster monsters;

    #pragma bss-name (push,"ZP")
    #pragma data-name (push,"ZP")
    unsigned char index;
    unsigned char calc_result;
    #pragma bss-name (pop)
    #pragma data-name (pop)
    #pragma zpsym ("index");
    #pragma zpsym ("calc_result");

    void set_monsters(void) {
    for (index=0;index<NO_MONSTERS;++index)
    {
    monsters.x[index] = index;
    calc_result = index * 2;
    monsters.y[index] = calc_result;
    };
    };

    generuje (prawie optymalny):
    _monsters:
    _index:
    _calc_result:

    .proc _set_monsters: near

    lda #$00
    sta _index
    L001C: lda _index
    cmp #$20
    bcs L000B
    ldy _index
    lda _index
    sta _monsters,y
    lda _index
    asl a
    sta _calc_result
    ldy _index
    lda _calc_result
    sta _monsters+32,y
    inc _index
    jmp L001C
    L000B: rts
    • 43: CommentAuthorilmenit
    • CommentTime16 Apr 2020
     
    w tym przykładzie dodałem jeszcze pośrednie "calc_result", ponieważ operacje arytmetyczne w języku C są wg. definicji języka rzutowane do int, a przeniesienie ich przed zapisem do tablicy do zmiennej typu unsigned char powoduje, ze optymalizator generuje jeszcze lepszy kod.
    • 44: CommentAuthorzbyti
    • CommentTime16 Apr 2020 zmieniony
     
    No dobrze... :] Ale czy w tym wątku to naprawdę ja mam pokazać wyniki kompilacji analogicznego kodu w Mad Pascalu?!

    @tebe, @bocianu do dzieła! :D

    EDIT: @ilmenit ten drugi przykład imponujący! :]
    • 45: CommentAuthorxxl
    • CommentTime16 Apr 2020 zmieniony
     
    _s:
    _p:

    .proc _sum: near

    lda #$00
    sta _s
    sta _s+1
    sta _p
    sta _p+1
    L000A: lda _p
    ora _p+1
    beq L000B
    lda _p+1
    sta ptr1+1
    lda _p
    sta ptr1
    ldy #$00
    lda (ptr1),y
    clc
    adc _s
    sta _s
    tya
    adc _s+1
    sta _s+1
    inc _p
    bne L000A
    inc _p+1
    jmp L000A
    L000B: lda _s
    ldx _s+1
    rts



    po optymalizacji:
    lda     #$00
    sta L000B+1
    sta L000A+2
    sta L000A+3
    L000A clc
    adc $FFFF
    bcc L000C
    inc L000B+1
    L000C inc L000A+2
    bne L000A
    inc L000A+3
    bne L000A
    L000B: ldx #$ff
    rts



    o polowe krotszy ?
    • 46: CommentAuthorilmenit
    • CommentTime16 Apr 2020
     
    jestem szczerze ciekawy jak Mad Pascal sobie radzi z "tablicą struktur" (tak się pisze zwykle w językach wysokiego poziomu) vs "strukturą tablic". "Tablica struktur" jest zwykle dla kompilatorów 6502 powolna, ponieważ jest dostosowana do adresowania poszczególnych "obiektów" wskaźnikiem, co na 6502 jest powolne.
    • 47: CommentAuthorantrykot
    • CommentTime16 Apr 2020
     
    Ilmenit, rzutowanie to coś innego niż sądzisz.
    • 48: CommentAuthorilmenit
    • CommentTime16 Apr 2020 zmieniony
     
    @antrykot, masz rację, przejęzyczenie, chodziło o "promotion"

    "char or short values (signed or unsigned) are promoted to int (or unsigned) before anything else happens. This is done because int is assumed to be the most efficient integral datatype" - co niestety nie jest prawdą dla 6502. Standard języka C89 używany przez CC65 był definiowany, kiedy już istaniały 16bitowe procesory.

    @xxl, chyba nawet współczesne komercyjne kompilatory nie generują samomodyfikującego się kodu. Jest to super do dostępu "wskaźnikowego" w ASM, dopóki nie trzeba tego wskaźnika użyć w kilku miejscach.
    • 49: CommentAuthorxxl
    • CommentTime16 Apr 2020
     
    no dobrze ale ten kod na 100% nie byl optymalny w rozumieniu kompilatora c: przklad:

    tya
    adc _s+1
    sta _s+1

    widzialem sporo optmalizowaneo kodu z c i to powinno wyladac tak:

    bcc @+
    inc _s+1

    wydaje mi sie tez ze sledzi wartosci zmiennych i to tez powinno wyladac inaczej:

    jmp L000A

    powinno byc

    bne L000A

    poza tym sprawdza warunek na poczatku...


    jestm prawie pewny ze cos jest nie tak z tym kodem.
    • 50: CommentAuthortebe
    • CommentTime16 Apr 2020 zmieniony
     
    romsum w wydaniu MP (bez specjalnych ustawień kompilatora, czy jego konfiguracji)
    mva #$00 RESULT
    sta RESULT+1

    sta P
    mva #$E0 P+1

    jmp l_009B
    l_009C

    ldy #$00
    lda RESULT
    add (P),y
    sta RESULT
    scc
    inc RESULT+1

    inc P
    sne
    inc P+1
    l_009B

    lda P+1
    jne l_009C
    lda P
    jne l_009C


    źródło
    function sum: word;
    var p: PByte absolute $e0;
    begin

    Result := 0;

    p := pointer(rom);

    while p > pointer(0) do begin
    inc(Result, p[0]);

    inc(p);
    end;

    end;