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

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthormrk
   • CommentTime1 Oct 2021 13:10 zmieniony

    
   @0xF
   
   wersja rust: ->link<-
   
   wcześniejsza wersja w clang (nieaktualna): ->link<-
   
   Emulator to GoodEnough Atari Emulator :) Oddzielny wątek na forum jest tutaj: ->link<- - i tam proponuję przenieść ewentualną dalszą dyskusję o samym emulatorze :)
2. • 2: CommentAuthor0xF
   • CommentTime1 Oct 2021 15:10

    
   Wow!
3. • 3: CommentAuthorspencer
   • CommentTime24 Oct 2021 21:10

    
   mind blow!,przełom w 8bit, śledzę wątek na AA, aż trudno uwierzyć
4. • 4: CommentAuthorilmenit
   • CommentTime25 Oct 2021 08:10

    
   @spencer - podeślij link do wątku na AA, jakoś nie mogę zlokalizować.
5. • 5: CommentAuthorspencer
   • CommentTime25 Oct 2021 14:10

    
   @ilmenit (pomyłka, chodziło o ten wątek)
   
   ->link<-
6. • 6: CommentAuthormrk
   • CommentTime19 Nov 2021 23:11 zmieniony

    
   Jak ktoś chce pobawić się llvm-mos, to właśnie zrobiłem obraz docker'a który można użyć jako devcontainer w Visual Studio Code (zawiera świeże binarki llvm-mos + llvm-mos-sdk) Opis jak skonfigurować Visual Studio Code do pracy z devcontainers jest tutaj: ->link<- (pod linuksem i MacOS wystarczy docker, pod windowsem dodatkowo trzeba zainstalować i skonfigurować WSL2). W vscode trzeba zainstalować rozszerzenie "Remote - Containers"
   
   Potem wystarczy sklonować z github'a to repozytorium: ->link<- i otworzyć w vscode jako Dev Container. Następnie `make` w terminalu vscode i powinien zbudować się hello.xex
   
   Spróbuję też zrobić analogiczne środowisko dla rust'a
7. • 7:
      
     CommentAuthorjhusak
   • CommentTime19 Nov 2021 23:11

    
   Czad!
8. • 8: CommentAuthormrk
   • CommentTime5 Dec 2021 00:12 zmieniony

    
   Od jakiegoś czasu dostępne są automatycznie aktualizowane wyniki zestawu benchmarków llvm-mos w postaci ładnych wykresów ->link<- - i wygląda to nieźle, a autor nie powiedział jeszcze ostatniego słowa :) Niedawno odpaliłem tutorial / benchmark @ilmenit'a ->link<- i wygląda na to że clang przegania już cc65 na każdym etapie:
   
   

   01-start
    cc65: 9495416
    llvm-mos: 6012211
    
    03-smallest-unsigned-data-types
    cc65: 9204740
    llvm-mos: 3622166
    
    04-get-rid-of-C-stack
    cc65: 7848252
    llvm-mos: 3556882
    
    05-replace-array-of-structs
    cc65: 7388015
    llvm-mos: 3470131
    
    06-get-rid-of-enums
    cc65: 7170008
    llvm-mos: 3321251
    
    08-get-rid-of-parameter-passing
    cc65: 7194231
    llvm-mos: 3326267
    
    09-replace-calculations-and-switches-with-lookup-tables
    cc65: 1622941
    llvm-mos: 513274
    
    11-improve-array-access
    cc65: 775136
    llvm-mos: 513274
    
    12-inline-functions
    cc65: 702467
    llvm-mos: 690483
    
    14-llvm-mos-opts
    cc65: 1913617
    llvm-mos: 514688
   
9. • 9:
      
     CommentAuthorjhusak
   • CommentTime5 Dec 2021 01:12

    
   To czas go zacząć używać :) Następny na liście.
10. • 10: CommentAuthormrk
    • CommentTime5 Dec 2021 01:12

     
    Polecam vscode + devcontainer z posta wyżej. Co prawda jeszcze nie uaktualniam go na bieżąco, ale jak będzie taka potrzeba zacznę (można zrobić automat na github actions pewnie).
11. • 11: CommentAuthorilmenit
    • CommentTime5 Dec 2021 12:12

     
    Niezłe wyniki! Używam Visual Studio (nie Code), więc pozostanie skompilować SDK samemu.
    
    Jak jest z konfiguracją kompilatora jak chodzi o rozmieszczenie pamięci? Czy można:
    1. ustalić najniższy/najwyższy adres programu?
    2. rozbić sekcje code/data/bss na różne obszary (aby np. było okno dla banków pamięci rozszerzonej lub carta)?
    3. ustalać wyrównania pamięci (dla fontów, dlisty czy duszków)?
12. • 12:
       
      CommentAuthorlaoo
    • CommentTime5 Dec 2021 13:12

     
    Jak zajmowałem się projektem w zeszłym roku, to nie miałem jakichś bardzo dużych problemów, żeby skompilować llvm pod Visualem. Muszę się za to znowu zabrać i sobie przypomnieć jak to się robiło, można byłoby wystawić jakąś kompilację pod Windowsa.
    Co do konfigracji pamięci, to llvm to dość standardowe środowisko, więc linker da się dość precyzyjnie konfigurować tymi dziwacznymi linkerowymi plikami konfiguracyjnymu. Ja chcę pójść krok dalej i zasychać wynikowe ELFy i linkować je sobie samemu (jestem trochę freakiem kontroli nad projektem ;p)
13. • 13: CommentAuthormrk
    • CommentTime5 Dec 2021 17:12 zmieniony

     
    @ilmenit tak jak napisał @laoo wyżej początek pamięci jest ustawiany w konfigu dla linkera. Domyślny jest dostarczany przez sdk: ->link<- ale można użyć swojego.
    Koniec pamięci (i początek software'owego stosu) ustawiany jest w crt0: ->link<- - pewnie można zlinkować ze swoją wersją lub po prostu nadpisywać to w main.
    
    Wyrównywanie pamięci działa, ja robiłem to tak:
    

    char data[DATA_SIZE] __attribute__((aligned(4096))) = {...}
    

    
    
    Samodzielna kompilacja całości pewnie nie jest nawet konieczna, bo automatycznie generowane są releases pod windows, mac i linux'a: ->link<-
    Niestety nie zawierają one na razie sdk (natomiast samo sdk powinno się pewnie dać zbudować za pomocą kompilatora pobranego z releases). W każdym razie pod linuksem nie miałem większych problemów jeśli chodzi o zbudowanie całości, pod Windowsem zgaduję że może być trudniej (ostatnio na slacku toczyła się jakaś większa dyskusja na ten temat).
    
    edit: jest issue by robić releases sdk też automatycznie: ->link<- więc może niedługo zacznie to działać.
14. • 14: CommentAuthorilmenit
    • CommentTime6 Dec 2021 11:12

     
    Czy jest jakiś guide jak rozwijać bibliotekę standardową o kolejne funkcje? ten "STA mos8(__rc0)" mnie trochę zaskoczył ;)
    ->link<-
15. • 15: CommentAuthormrk
    • CommentTime6 Dec 2021 13:12 zmieniony

     
    Nie kojarzę. Ale polecam przejrzeć wiki, tu na przykład znalazłem opis tych modyfikatorów (w tym mos8): ->link<- I pewnie warto też popatrzeć na to co jest w sdk/common/lib: ->link<-
16. • 16:
       
      CommentAuthorlaoo
    • CommentTime6 Dec 2021 16:12

     
    Ściągnąłem binarki i rzeczywiście działają. Nie udało mi się skompilować SDK, ale też za mocno nie próbowałem. Co mogę jednak powiedzieć po napisaniu kilku prostych funkcji i skompilowaniu do pliku *.s, to że samo kompilowanie bez linkowania produkuje póki co dużo niepotrzebnej żonglerki na stronie zerowej i stosie (nawet przy -Oz). Może to wszystko jest wycinane jak się włączy link-time-optimization, ale nie udało mi się jeszcze tego sprawdzić.
17. • 17:
       
      CommentAuthorlaoo
    • CommentTime6 Dec 2021 16:12 zmieniony

     
    @ilmenit zerkałeś na issues w repozytorium Twojego tutoriala? Jeden z gości od llvm-mos prosi o dodanie licencji, żeby mogli użyć tych testów u siebie.
18. • 18: CommentAuthormrk
    • CommentTime6 Dec 2021 19:12 zmieniony

     

    laoo:

    Jeden z gości od llvm-mos prosi o dodanie licencji, żeby mogli użyć tych testów u siebie.
    

    
    
    Ha, super. Wrzucałem kilka razy na ich slacku wyniki, fajnie było by faktycznie to mieć w standardowo odpalanych benchmarkach, wtedy wyniki pojawiały by się pewnie też tu: ->link<-
    
    @ilmenit - mam fork'a który pozwala na skompilowanie dodatkowo pod llvm-mos (zarówno na a800 jak i na 'sim' z sdk), mogę wystawić jakieś PR'y
    
    BTW ostatnio dzięki tutorialowi Ilmenit'a został poprawiony ten błąd: ->link<- - co ciekawe okazało się że jest to błąd w samym llvm i fix pójdzie prawdopodobnie upstream :)
19. • 19: CommentAuthorilmenit
    • CommentTime6 Dec 2021 20:12

     
    Dzięki za info, nie zwróciłem uwagi na ten dodany Issue. Dałem licencję MIT. Fajnie, że ten artykuł jest wykorzystywany w wielu miejscach i bardzo się ciesze, że może pomóc w tak ambitnym projekcie jak LLVM-MOS.
20. • 20: CommentAuthormrk
    • CommentTime30 Jan 2022 02:01

     
    Źródła konwertera obx2elf: ->link<-
    W katalogu example przykład wykorzystania (sprite multiplexer Shanti'ego konwertowany do elf i linkowany z programem w clang, o czym pisałem tu: ->link<-
21. • 21: CommentAuthormrk
    • CommentTime20 Feb 2022 14:02 zmieniony

     
    Ciekawostka: remote source-level debugging za pomocą lldb (na screen'ie plugin lldb do vscode). Na razie podłączony do prostego symulatora 6502, ale nic nie stoi na przeszkodzie by zaimplementować protokół remote gdb na przykład w atari800 (na pewno będzie w GoodEnough)
    
    Na screen'ie widać trochę magii - polecam na zerknięcie jak została skompilowana pętla 'for' i zastanowienie się co musi robić lldb by poprawnie wyświetlić wartość zmiennej 'i' :]

    • lldb2.png
      
      
      
      
22. • 22: CommentAuthormrk
    • CommentTime26 Feb 2022 07:02 zmieniony

     
    Pierwsze oficjalne wydanie llvm-mos: ->link<-
    
    Polecam zapoznanie się z listą 'What you get' w linku wyżej
23. • 23: CommentAuthorilmenit
    • CommentTime26 Feb 2022 09:02

     
    aż trudno uwierzyć, że udało się to doprowadzić do tego stanu. Kolejny projekt na Atari będę robił w llvm-mos (ale KickC też wygląda coraz ciekawiej, ciekawy jestem porównania ich szybkości i jakości generowanego kodu.)
24. • 24:
       
      CommentAuthorcrrn
    • CommentTime26 Feb 2022 13:02 zmieniony

     
    fajny news... aż dodałem u siebie na portalu. Będę testował tego llvm-mos'a - podzielę się wnioskami
    KickC jest faktycznie fajny i najnowasza wersja sprzed paru dni sporo dodaje i poprawia, ale ma jeden bardzo poważny problem, który uwidocznił się mi podczas pisania gry oraz wiem że kilku innym osobom też. problem nie jest błachy. Powolność kompilacji... i mam na myśli naprawdę powolność. moja gra dla C64 kompiluje się ponad minutę. Robienie poprawek w takim kodzie to masakra.
25. • 25: CommentAuthorilmenit
    • CommentTime26 Feb 2022 15:02

     
    Rzeczywiście, długo. KickC nie wspiera jednostek kompilacji ->link<- ?
    W przypadku profesjonalnych projektów często się oddziela kompilację Debug i Release (też ze wględu na czas pracy optymalizatora). Czy przy wyłączeniu optymalizacji kompilacja też trwa tak długo?
    Mrk, jak pod względem czasu kompilacji wygląda llvm-mos?
26. • 26: CommentAuthormrk
    • CommentTime26 Feb 2022 16:02

     
    Nie wyszedłem niestety jeszcze poza bardzo małe projekty, które kompilują się szybko, ale powinno być dobrze - na atari nie jesteśmy w stanie generować dużych binariów po prostu, a clang to jednak kompilator na duże maszyny, gdzie się generuje ogromne binarki w porównaniu do atari. Więc kompilator (czas kompilacji) powinien być też dużo bardziej zoptymalizowany
27. • 27: CommentAuthormrk
    • CommentTime26 Feb 2022 16:02

     
    @ilmenit to coś dla Ciebie (pewnie już widziałeś na slack'u):
    
    

    mysterymath:

    Alright, through various linker and SDK magicks I've gotten the trivial (main: rts) c64 binary size down to 32 bytes, including the BASIC header. Other targets are similar. If you take a look at the generated assembly, it's basically just a skeleton of _start/_init, main, and _fini .
    The region before the JSR to main and the contents of _fini are filled out based on what you actually use in the binary: if you touch the stack pointer, it's initialized, if you touch .bss, it's zeroed, if you use C++ constructors/destructors, they're run, and if you call exit, then the hard stack pointer is saved for the non-local jump. Each mechanism is pay-as-you-go.
    

    
    
    
    Właśnie sprawdziłem rozmiar xex wygenerowanego z:
    

    void main() {
    }
    

    
    
    Wynik: 30 bajtów (włączając nagłówki xex)
    
    więc jesteśmy o 2 bajty lepsi niż c64 ;)
28. • 28: CommentAuthor0xF
    • CommentTime28 Feb 2022 18:02

     
    1. Jak wygląda współpraca z Altirrą w kwestii debugowania?
    2. Czy jest jakieś wsparcie dla profilowania?
29. • 29: CommentAuthormrk
    • CommentTime28 Feb 2022 20:02 zmieniony

     

    0XF:

    1. Jak wygląda współpraca z Altirrą w kwestii debugowania?
    

    
    
    clang generuje debug info w formacie DWARF i Altirra na razie z tego nie umie skorzystać. Można natomiast próbować wyciągać potrzebne informacje z pliku w formacie ELF i generować pliki które Altirra zrozumie, tu na przykład prosty skrypt generujący plik .lab który bez problemu czytany jest przez emulator: ->link<-
    
    

    2. Czy jest jakieś wsparcie dla profilowania?
    

    
    
    W DWARF jest chyba wszystko co potrzebne (tablice symboli, mapowanie PC -> funkcja), wsparcia w emulatorach na razie oczywiście jeszcze brak.
    
    Generalnie potencjał jeśli chodzi o debugowanie jest - kilka postów wyżej wrzucałem informację o LLDB podłączonym do symulatora 6502 ->link<- z pełnym source-level debugging, przełączaniem pomiędzy kodem źródłowym / listingiem assemblera czy wyświetlaniem wartości zmiennych, testowałem z lldb oraz wtyczką do vscode i działało bardzo fajnie (są jakieś błędy w wygenerowanym DWARF i nie można było czasem zobaczyć wartości jakiejś zmiennej, ale to pewnie będzie do ogarnięcia)
    
    Idealnie by było gdyby atari800 / Altirra umożliwiły z czasem zdalne debugowanie za pomocą lldb / gdb (na pewno spróbuję to dodać w GoodEnough emulator).
30. • 30: CommentAuthormrk
    • CommentTime1 Mar 2022 11:03

     
    Niestety autor altirry właśnie zadeklarował że nie zamierza implementować protokołu 'gdb remote' - szkoda.
    
    A wsparcie dla DWARF może pojawi się jak projekt dojrzeje (i jeżeli zostanie napisane to od zera, bez użycia gotowych istniejących bibliotek).
    
    BTW nie rozumiem trochę niechęci do używania zewnętrznych bibliotek, a spotykam się z tym już nie pierwszy raz (i po raz kolejny w projekcie c++). Czyżby brak sensownych narzędzi do obsługi paczek / zależności? Pisząc swój emulator bardzo chętnie używałem gotowych klocków (używam gotowego emulatora 6502 / gotowych bibliotek do obsługi grafiki / dźwięku / logowania itd) i nie wyobrażam sobie pisania wszystkiego od zera (naprawdę szkoda czasu na wymyślanie za każdym razem koła na nowo)
31. • 31: CommentAuthorilmenit
    • CommentTime1 Mar 2022 11:03

     
    @mrk - Wykorzystanie gotowych bibliotek umożliwia szybkie składanie kodu, ale jednocześnie jest ograniczające gdy:
    - zewnętrzny kod jest często modyfikowany na poziomie API i wymaga ciągłych przeróbek u siebie
    - gdy ma niepoprawiane błędy
    - gdy rozwój idzie w innym kierunku niż oczekiwany
    - gdy kod jest porzucany
    - gdy wymaga dedykowanego systemu buildowania
    - gdy ma inne, nawarstwiające się zależności
    - gdy ma inną licencję
    - gdy wykorzystuje rozszerzenia kompilatorów zamiast "czystego" C++
    - gdy używa zbyt nowego standardu C++
    - gdy używa zbyt starego standardu C++
    - gdy ma problemy z wydajnością
    - gdy ma "specyficzne" API
    - gdy ma inne podejście do obsługi wielowątkowości
    itd.
32. • 32:
       
      CommentAuthorjhusak
    • CommentTime1 Mar 2022 11:03 zmieniony

     
    No i gdy chcesz napisać kod, który "raz napisany działa zawsze niezależnie od updejtów" maksymalnie długo.
    
    Testowanie kodu za każdym razem kosztuje.
    
    Są różne zastosowania i czasem podejście biblioteczne jest jedynym możliwym. Ale czasem kod musi być odporny na wszystko, a wtedy właśnie biblioteki są potencjalnym miejscem, gdzie jest niewykryty błąd, który ktoś może wykorzystać w niecnych celach.
    
    Dlatego ja piszę głównie w C, ten się nie zmienia tak często, a jeśli już, to minimalnie.
33. • 33: CommentAuthormrk
    • CommentTime1 Mar 2022 12:03 zmieniony

     
    @ilmenit - dzięki za szczegółową listę. Spora jej część jest faktycznie specyficzna dla C++ (różne standardy cpp, brak spójnego systemu budowania / dystrybucji paczek). Część to ogólnie znane problemy otwartego kodu, które często można rozwiązać przypięciem się do konkretnej wersji / wysłaniem PR'a / w ostateczności przepięciem się na własnego fork'a (dalej często dużo prostsze niż pisanie od zera). Problemy z licencją też można rozwiązać - niedawno na przykład bevy zmieniał licencję z MIT na MIT+Apache, co nie było proste bo wymagało poproszenia o zgodę każdego z kilkuset developerów - ale udało się.
    
    

    jhusak:

    Ale czasem kod musi być odporny na wszystko, a wtedy właśnie biblioteki są potencjalnym miejscem, gdzie jest niewykryty błąd, który ktoś może wykorzystać w niecnych celach.
    

    
    Niestety nie możesz zakładać że Twoja własna implementacja skomplikowanego formatu / protokołu jest wolna od błędów. Zewnętrzna biblioteka to też więcej par oczu które patrzy na kod / poprawia błędy (także bezpieczeństwa).
    
    W każdym razie ja zawsze zaczynam od sprawdzenia czy nie mam już gotowca na 'crates.io' :)
34. • 34: CommentAuthormrk
    • CommentTime6 Jun 2022 23:06 zmieniony

     
    Ciekawosta: prezentacja o llvm-mos na tegorocznej konferencji EuroLLVM:

    - polecam!
35. • 35:
       
      CommentAuthorlaoo
    • CommentTime7 Jun 2022 09:06 zmieniony

     
    No no. mrk, jesteś sławny!
    
    
36. • 36: CommentAuthortebe
    • CommentTime7 Jun 2022 10:06

     
    poproszę zdjęcie widowni, kto tam siedział?
37. • 37: CommentAuthorspencer
    • CommentTime25 Jan 2023 02:01

     
    pojawiło się w Altirra 4.10 / 01.01.23 wsparcie dla DWARF jakie generuje LLVM(o którym było powyżej w wątku), wersja initial póki co
38. • 38: CommentAuthoradi
    • CommentTime25 Jan 2023 10:01

     
    Powiedzcie mi proszę dlaczego na Atari nie można pisać programów w C, np. posługując się zewnętrznym kompilatorem na PC.
    Jhusak pisał wcześniej, że jest to pozbawione sensu w systemie z kilkudziesięcioma kilobajtami pamięci RAM.
    Ale np. w ATTiny12 jest np. 1KB pamięci flash (czyli ROM), 0 bajtów pamięci RAM i 32 rejestry ogólnego przeznaczenia, a kod pisze się praktycznie tylko w C.
    Oczywiście masochiści mogą używać assemblera, ale mi robi się na myśl o nim "gęsia skórka".
39. • 39: CommentAuthorilmenit
    • CommentTime25 Jan 2023 10:01

     
    Czemu nie można? Można, w tym większe projekty/gry jak "Adam Is Me", "His Dark Majesty", "The Hunt", tak dla przykładu ;)
    Problemem jest często jakość generowanego kodu i tu w przyszłości LLVM-MOS może pomóc. Poza nim najlepszy dla C jest CC65, w którym trzeba pisać kod w specyficzny sposób, aby był wydajny na poziomie asemblera.
    ->link<-
40. • 40:
       
      CommentAuthorjhusak
    • CommentTime25 Jan 2023 10:01 zmieniony

     
    @adi, pisałem o mniejszym sensie używania C++ na Atari, nie C.
41. • 41: CommentAuthorświęty
    • CommentTime25 Jan 2023 10:01

     
    Po pierwsze 6502 nie został zaprojektowany do pisania w C (choćby ze względu na brak kilkunastu rejestrów czy drugiego stosu) , to co generuje np CC65 to jakaś porażka - używa programowego stosu oraz procedur pomocniczych do kompilacji kodu i każdy parametr poza rejestrami przewala przez adresowania lda (sp),y oraz aktualizacja licznika stosu co jest mega wolne. Dekompilowałem w ten sposób skompilowanego Vicdooma i to co wyszło z kompilatora to był potworek ... Ani przejrzyste ani szybkie , do tego brak optymalizacji itp nie wspomnę że dostęp do niektórych np Array był też przez lda (zp),y ...
    Co innego w przypadku np Atmegi - mając 32 rejestry większość argumentów w funkcjach jest przenoszone rejestrami więc jest to szybkie , kompilator C używa 16 dolnych jako rejestry ogólnego przeznaczenia, górne 16 jako rejestry do argumentów funkcji - przez to nie musi używać programowego stosu aż tak bardzo. Chyba że jest duże zagnieżdżenie funkcji.
    Ogólnie kompilator C można używać do rzeczy nie wymagających szybkości ani specjalnie zwartego kodu np menu początkowe w vicdoomie ;) Tyle z mojej strony i moich spostrzeżeń
42. • 42:
       
      CommentAuthorlaoo
    • CommentTime25 Jan 2023 10:01

     
    Nawet llvm nie jest tu jakimś świętym graalem. C i pochodne został zaprojektowany z pewnymi założeniami co do architektury procesora, na który będzie kompilowany. Np taki procesor powinien mieć funkcjonalny stos. 6502 nie spełnia tego założenia, bo stos w nim jest tylko pro-forma. W rezultacie "duży" kompilator nigdy nie wygeneruje dla niego wydajnego kodu. Dla 6502 potrzebny jest osobny język. Coś jak shadery dla GPU - maszyna bez stosu, za to z dużą liczbą rejestrów (strona zerowa). Wg mnie tylko coś takiego ma szansę być wydajnym.
43. • 43:
       
      CommentAuthorcrrn
    • CommentTime25 Jan 2023 11:01 zmieniony

     
    Kiedyś porównywaliśmy kompilatory C na 6502 i polecałem wtedy KickC, który w połączeniu z KickAsm generuje dość dobry kod. Kompilator jest jednak wolny. Dlatego przesiadłem się na Oscar64. Jest Super! szybki i także robi bardzo dobry (wg mnie) kod. Ma kilka innych zalet nad KickC ale o tym przy okazji...
    Od biedy dało by się go zmusić do generowania kodu dla Atari.
    I da się pisać gry w C. Ilmenit kilka wymienił to ja dodam tylko (co prawda na C64 ale zawsze) moją grę Robot Jet Action. w 90% napisaną w C.
    
    Kluczowe dla mnie było pisanie małych fragmentów kodu i sprwdzanie co wygenerował kompilator. Jak robił jakiegoś potworka to starałem się zrozumieć dla czego tak skompilował i pisałem moją procedurę inaczej aby wygenerowany kod był szybszy i/lub krótszy.
44. • 44: CommentAuthorilmenit
    • CommentTime25 Jan 2023 11:01

     
    dokładnie jak pisze crrn - można używać kompilatorów C (czy Mad-Pascala), ale gdy chcemy uzyskać sensowny kod to trzeba znać architekturę 6502 i asma, zerknąć do wygenerowanego kodu i zrozumieć jakich konstrukcji przy pisaniu programów unikać. To, że język umożliwia np, korzystanie ze wskaźników czy przekazywania przez stos, nie znaczy, że programy trzeba z ich używaniem pisać. Potem jest pytanie "a skoro tak się ograniczać, to czemu nie od razu asembler?". Moja odpowiedź to: oszczędność czasu (x3-x5) i kwestia łatwości utrzymania kodu (szczególnie powrót do niego po dłuższym czasie). Dla asm pozostają wtedy tylko time-critical kawałki.
45. • 45:
       
      CommentAuthorcrrn
    • CommentTime25 Jan 2023 11:01

     
    no to jak sobie tak słodzimy :) to i ja napiszę że w 100% zgadzam się z ilmenitem.
    moją grę napisał bym w całości w assemblerze - bez problemu, ale zajęło by mi to 10 razy dłużej. w moim RJA w assemblerze jest w zasadzie tylko player muzyki i depacker do exomizera i bb2 :)
46. • 46: CommentAuthoradi
    • CommentTime25 Jan 2023 11:01

     
    Dzięki Wszystkim za wyczerpujące odpowiedzi :).
    Rzeczywiście nie ma co upierać się na C czy C++. Wystarczy jakikolwiek język wyższego poziomu, oby tylko generował wydajny kod maszynowy na 6502.
    Nie wiem kto pisał moduły cross-kompilatora C dla procesorów Atmela, ale pewnie zadbał aby były one dopasowane do specyfiki procesora.
    Super jakby coś takiego było również dla Atari.
    Język może być dowolny, byle nie assembler i koniecznie na PC.
    Zwróćcie uwagę ile wyrafinowanych trików stosowali w latach 80-tych (w Polsce nawet 90-tych) twórcy gier, nie mając PC-tów i cross assemblera, o emulatorach Atari nie wspomnę.
47. • 47:
       
      CommentAuthorjhusak
    • CommentTime25 Jan 2023 12:01 zmieniony

     
    Zarówno C(C65), jak i np. Action! mają triki pozwalające pisać kod o kilkunastokrotnej różnicy w wydajności(na plus). Żeby pisać szybki kod trzeba wiedzieć, co wygeneruje kompilator. Bez tego jest "średnio".
    
    Action przekazuje do funkcji pierwsze 3 bajty parametrów przez AXY, a CC65 pierwszy bajt przez A. Mając to na uwadze i używając starannie zmiennych globalnych umieszczonych na stronie zerowej można pisać naprawdę sprawny i zwięzły kod (na 90% z tym przekazywaniem, piszę z pamięci)
    
    Jest świetna strona Davida A. Wheelera o 6502 opisująca m. in. filozofię tworzenia kompilatorów na tenże procek.
    
    Realizacje: ->link<-
    
    Fiozofia: ->link<-
48. • 48: CommentAuthorsolo/ng
    • CommentTime25 Jan 2023 15:01 zmieniony

     
    "oszczędność czasu (x3-x5)"
    
    Jak ktos ma doswiadczenie w pisaniu enginow/wiekszych projektow w asmie to nie bedzie oszczednosci czasu. Enginy Timepilota, LynxQuesta, MK, FQ napisalem relatywnie szybko (od zera/bez ogladania oryginalego kodu), majac w miare czysty kod, listy objektow, triggery, rozbudowana logike, namespaces itd. Kazdy kolejny engine re-uzywal sobie kilka rzeczy z poprzedniej produkcji (bo sporo elementow bylo pisanych od razu w miare ogolnie, do wielokrotnego uzycia).
    
    Mam wrazenie, ze jakbym to pisal w CC65 to zajeloby mi wiecej czasu, ciagle ogladajac sie za siebie "co mi kompilator wypluje". Zapewne po jakims czasie mozna byloby tutaj dojsc do jakiejs wprawy. Nie mowiac, ze prawie na pewno nie daloby sie zrobic takiego np. FQ/TP (zostaly 3 bajty wolne via czysty asm).
    
    Kwestia perspektywy i - prawdopodobnie najwazniejsze tutaj - kto sie plynniej w czym porusza.
49. • 49:
       
      CommentAuthorpirx
    • CommentTime25 Jan 2023 16:01

     
    dodam swoją rabiniczną myśl, że wszyscy Panowie macie rację. moje ostatnie doświadczenie to skorcz, program technicznie prosty, ale zawierający ogromną jak na tą małą maszynkę ilość logiki "biznesowej". pisanie tego w asemblerze to była męka, dlatego zajęło to ponad 20 lat. dlatego też jak sądzę nie ma innego pełnego klona scorchered earth na ośmbity, bo po zrobieniu proto twórcy orientowali się, że teraz jeszcze 8 razy tyle robótki przed nimi.
    
    z drugiej strony dzięki asemblerowi cała gra mieści się na karcie 32KiB.
50. • 50: CommentAuthor0xF
    • CommentTime25 Jan 2023 18:01

     
    poproszę zdjęcie widowni, kto tam siedział?

    
    Moi koledzy z korpo.