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 15:04 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 15:04 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 16:04 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 17:04
       
      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 18:04 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 13:04
       
      @ilmienit: kod madpascala jest również na githubie i można sobie pogrzebać jak ktoś lubi ;)
      • 7: CommentAuthorilmenit
      • CommentTime15 Apr 2020 13:04
       
      @sun:
      to dla porównania:
      Mad Pascal - contributors: 1 ->link<-
      CC65 - contributors: 64 ->link<-
      • 8: CommentAuthorastrofor
      • CommentTime15 Apr 2020 13:04
       
      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 13:04 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 13:04
       
      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 14:04 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 14:04
       
      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 14:04
       
      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 14:04
       
      @crrn: rewelacja - masz już pierwszego subskrybenta
      • 15: CommentAuthorilmenit
      • CommentTime15 Apr 2020 14:04
       
      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 18:04
       
      @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 19:04 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 19:04
       
      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 20:04
       
      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 08:04 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 10:04 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 10:04 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 10:04 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 10:04 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 10:04
       
      @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 11:04 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 11:04
       
      Pisanie w asemblerze wcale nie jest trudne. Trudne jest tylko czytanie czegoś, co napisało się kilka dni temu :)
      • 28: CommentAuthorilmenit
      • CommentTime16 Apr 2020 12:04
       
      @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 12:04
       

      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 12:04 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 12:04
       
      Jedno drugiemu nie przeszkadza. Można online i PDF jednocześnie - to ułatwia wyszukiwanie i dotarcie.
      • 32:
         
        CommentAuthorlaoo
      • CommentTime16 Apr 2020 13:04 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 13:04
       
      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 13:04 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 13:04
       
      @zbyti - to bez optymalizacji włączonych?
      • 36: CommentAuthorzbyti
      • CommentTime16 Apr 2020 13:04 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 13:04 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 14:04
       
      to jest po optmalizacji?
      • 39:
         
        CommentAuthorlaoo
      • CommentTime16 Apr 2020 14:04 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 14:04
       
      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 14:04
       
      Co jak co, ale stos na 6502 to jednak nieporozumienie :)
      • 42: CommentAuthorilmenit
      • CommentTime16 Apr 2020 14:04 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 14:04
       
      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 14:04 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 14:04 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 14:04
       
      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 14:04
       
      Ilmenit, rzutowanie to coś innego niż sądzisz.
      • 48: CommentAuthorilmenit
      • CommentTime16 Apr 2020 14:04 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 15:04
       
      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 15:04 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;