atarionline.pl llvm-mos - 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: CommentAuthormrk
    • CommentTime1 Oct 2021 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: CommentAuthor0xF
    • CommentTime1 Oct 2021
     
    Wow!
    • 3: CommentAuthorspencer
    • CommentTime24 Oct 2021
     
    mind blow!,przełom w 8bit, śledzę wątek na AA, aż trudno uwierzyć
    • 4: CommentAuthorilmenit
    • CommentTime25 Oct 2021
     
    @spencer - podeślij link do wątku na AA, jakoś nie mogę zlokalizować.
    • 5: CommentAuthorspencer
    • CommentTime25 Oct 2021
     
    @ilmenit (pomyłka, chodziło o ten wątek)

    ->link<-
    • 6: CommentAuthormrk
    • CommentTime19 Nov 2021 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:
       
      CommentAuthorjhusak
    • CommentTime19 Nov 2021
     
    Czad!
    • 8: CommentAuthormrk
    • CommentTime5 Dec 2021 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:
       
      CommentAuthorjhusak
    • CommentTime5 Dec 2021
     
    To czas go zacząć używać :) Następny na liście.
    • 10: CommentAuthormrk
    • CommentTime5 Dec 2021
     
    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: CommentAuthorilmenit
    • CommentTime5 Dec 2021
     
    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: CommentAuthorlaoo
    • CommentTime5 Dec 2021
     
    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: CommentAuthormrk
    • CommentTime5 Dec 2021 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: CommentAuthorilmenit
    • CommentTime6 Dec 2021
     
    Czy jest jakiś guide jak rozwijać bibliotekę standardową o kolejne funkcje? ten "STA mos8(__rc0)" mnie trochę zaskoczył ;)
    ->link<-
    • 15: CommentAuthormrk
    • CommentTime6 Dec 2021 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: CommentAuthorlaoo
    • CommentTime6 Dec 2021
     
    Ś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: CommentAuthorlaoo
    • CommentTime6 Dec 2021 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: CommentAuthormrk
    • CommentTime6 Dec 2021 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: CommentAuthorilmenit
    • CommentTime6 Dec 2021
     
    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.