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
    • CommentTime25 May 2021
     
    ->link<- - wygląda na to że pojawił się działający backend LLVM dla 65xx!
    Bawię się tym od wczoraj - oryginalnie była dostępna konfiguracja pod c64, ale po drobnych zmianach udało się utworzyć konfigurację dla małego atari (produkującą pliki xex), PR w drodze.
    Co to oznacza w praktyce - na początek nowoczesny toolchain z kompilatorem C/C++ i assemblerem, docelowo zapewne także inne języki bazujące na LLVM (mam nadzieję na Rust'a :] )
    • 2: CommentAuthorpirx
    • CommentTime25 May 2021
     
    najs! Ile ma .xex?
    • 3: CommentAuthorlaoo
    • CommentTime25 May 2021 zmieniony
     
    O, fajnie, że facetowi udało się to pchnąć do przodu.
    Coś tam nawet dopisałem ( np. SHF_MOS_ZEROPAGE to mój pomysł i implementacja ), ale wnętrzności LLVM są strasznie skomplikowane, a gość wymagał, żeby pisać testy do wszystkiego, no i przez engine testów LLVM już nie przebrnąłem i odpadłem :)
    • 4: CommentAuthormrk
    • CommentTime25 May 2021 zmieniony
     
    @pirx za dużo - jakieś 11kB :) Zerkałem do wygenerowanego pliku asm i widzę dużo nieużywanego kodu, więc powinno się dać ładnie z tego zejść.

    @laoo - nieźle. Teraz pewnie przyda się pewnie parę rąk do pracy nad SDK dla atari - z wywołań systemowych zaimplementowany jest na razie tylko `putchar` (EOUTCH).
    • 5: CommentAuthorlaoo
    • CommentTime25 May 2021
     
    Co do tych 12kB - w ogóle cudem jest, że facetowi udało się zmusić Clanga do generowania jakiegokolwiek kodu 6502. Z tego co ja liznąłem wnętrzności, to mogę sobie wyobrazić, ile wysiłku i "brainpower" to wymaga. Więc mamy pierwszą wersję i dowód że się da. Clang/llvm potrafi być dość agresywny z optymalizacją, tylko trzeba go nastroić. Więc trzymamy kciuki, żeby autor nie zeszedł ze stanem baterii za nisko i żeby ktoś znalazł się do pomocy. Ja trochę pomagałem, bo widziałem zastosowanie dla GASa w swoim projekcie (podobała mi się idea ELFa dla 6502), ale ostatecznie odkryłem, że ELF nie jest taki elastyczny jak potrzebuję i oczywiście poszło w pisanie kolejnego własnego asemblera :)
    • 6:
       
      CommentAuthorYosh
    • CommentTime25 May 2021 zmieniony
     
    Ło, niezłe osiągniecie. Wiem ile to pracy bo sam robiłem podejście i aż głupio zbyć to:

    "jak przeskoczy jakość kodu c65 (ktora jest tez dosc toporna) to pogadamy"
    "... potem mad pascala podejrzewam"
    "... a ręczny kod asm?"

    No ale marzenia mam duże, trzeba zasypać gościa feature requestami np.

    const uint16_t var[2] __attribute__((lohi)) = {0x1234, 0xabcd};

    mialo by zamienic tablice na
    var_lo
    dta $12,$ab
    var_hi
    dta $34,$cd

    dla szybszego adresowania, a to najprostszy 'trik' 6502 ...

    A jak ogarnąć, że flaga procesora Decimal może być użyta jako szybki bool - o ile w danym obszarze nikt nie wykonuje dodawań i odejmowań ;)

    Gorąco trzymam kciuki, ktoś w końcu realizuje moje marzenia na które nie mam czasu :)
    • 7: CommentAuthorlaoo
    • CommentTime25 May 2021 zmieniony
     
    Jest topic na 6502.org i widzę, że jest ich dwóch, stąd liczba mnoga na wiki (a nie figura stylistyczna dodająca powagi). W ostatnim wpisie piszą, że odpalają testy llvm, żeby jak najwięcej przeszło, potem dopiero zajmą się optymalizacją, więc na razie tym '12kb' bym się nie przejmował, a llvm ma strasznie duży potencjał optymalizacyjny.

    ->link<-
    • 8: CommentAuthormrk
    • CommentTime25 May 2021
     
    Pytanie do praktyków.

    Wrzuciłem PR dodający konfigurację dla atari800xl: ->link<-

    Trzeba zadecydować jak ma wyglądać domyślny 'layout' pamięci - od jakiego adresu generować kod oraz gdzie umieścić software'owy stos (stos rośnie w dół, trzeba określić jego koniec).

    Przykładowo dla c64 kod jest umieszczany od adresu 2061 (dec) , koniec stosu to 0x9fff

    Do testów na emulatorze ustawiałem sobie segment kodu na 0x1000 i stos poniżej na 0x0fff

    W review dostałem sugestię by stos ustawić podobnie jak w c64, czyli na koniec dostępnej pamięci.

    Mogę ustawić go runtime na MEMTOP - ale co wtedy z ewentualną zmianą trybu graficznego (via S:) - olać?

    Jakie są dobre praktyki jeśli chodzi o umieszczanie kodu za DOS'em, jakie MEMLO można bezpiecznie przyjąć?
    • 9:
       
      CommentAuthorKaz
    • CommentTime25 May 2021
     

    mrk:

    po drobnych zmianach udało się utworzyć konfigurację dla małego atari (produkującą pliki xex), PR w drodze. Co to oznacza w praktyce - na początek nowoczesny toolchain z kompilatorem C/C++ i assemblerem, docelowo zapewne także inne języki bazujące na LLVM (mam nadzieję na Rust'a :]


    Nieźle, kurde felek! Brawo panie kolego. A Javę też będziemy odpalać na małym Atari?

    Yosh:

    No ale marzenia mam duże, trzeba zasypać gościa feature requestami np.


    Słusznie, zasypuj! :D
    • 10: CommentAuthorilmenit
    • CommentTime25 May 2021 zmieniony
     
    Tutaj jaki ma layout pamięci CC65:
    ->link<-
    CC65 zaczyna domyślnie program od $2E00, ale można przyjąć $2000 i będzie działać z większością DOSów.

    Jak będę miał więcej czasu to chętnie zerknę na wygenerowany kod.
    Zbyti jakiś czas temu przygotował zestaw dla KickC ->link<- , a ponieważ jest analogiczny do tego z MadPascala, można porównywać kilka nowo tworzonych języków.
    • 11: CommentAuthormrk
    • CommentTime25 May 2021
     
    @ilmenit dzięki! w takim razie ustawiam program na $2000, stos na MEMTOP
    • 12: CommentAuthorlaoo
    • CommentTime25 May 2021 zmieniony
     
    Zakładam, że zerkanie do wygenerowanego kodu może być zwodnicze, bo dostaniemy tylko kod przemielony przez wysokopoziomową optymalizację (czyli że kompilator "wykonuje sobie" program i sprawdza czy nie wyszło coś statycznego), ale nic niskopoziomowego, bo LLVM ma bardzo dużo opcji strojenia optymalizatora pod konkretną platformę, ale to dużo pracy, którą na pewno będą chcieli zrobić później.
    • 13: CommentAuthormrk
    • CommentTime26 May 2021 zmieniony
     
    Polecam przeczytanie całego wątku na 6502.org który podlinkował wyżej @laoo ->link<- - masa ciekawych informacji jak to działa pod spodem, sporo przykładów wygenerowanego kodu (piszą też na przykład dlaczego spora ilość optymalizacji które już były zaimplementowane została na razie usunięta (why WorseIsBetter).

    A PR dodający atari/800xl.cfg został już wmergowany :) ->link<- - co ciekawe mysterymath zdążył już zrobić tam mały refaktor
    • 14: CommentAuthormrk
    • CommentTime27 May 2021
     
    Jeszcze jeden update. Wyżej pisałem że dzięki llvm-mos mam nadzieję na Rust'a dla Atari (Rust używa LLVM do generowania kodu) - i okazuje się że to już praktycznie działa :)
    Więcej szczegółów: ->link<-
    • 15:
       
      CommentAuthorYosh
    • CommentTime27 May 2021
     
    Kciuki mi naszły krwią! no ale trzymam. Może jak dopłyną do mikro optymalizacji to się w to zerknie i coś pogrzebie:)
    • 16: CommentAuthorilmenit
    • CommentTime27 May 2021
     
    Świetne, trzymam kciuki. mrk, projekt potrzebuje atarowego wsparcia i super, że jesteś tym zainteresowany.
    • 17: CommentAuthormrk
    • CommentTime27 May 2021
     
    @ilmenit dzięki, będę obserwował na pewno i pewnie co jakiś czas wrzucał coś do SDK dla Atari. BTW _ilm_ na reddicie to Ty? Jak ktoś ma konto na Reddit to prośba o podbicie: ->link<- :)
    • 18: CommentAuthorilmenit
    • CommentTime27 May 2021
     
    tak, ja
    • 19: CommentAuthormrk
    • CommentTime17 Jun 2021 zmieniony
     
    Update:

    Prace nad llvm-mos nie zwalniają - autor ostro ciśnie i cały llvm-test-suite już się kompiluje (z wyłączeniem testów operacji zmiennoprzecinkowych których obsługi jeszcze nie ma oraz części testów które na przykład zakładają 32-bitowy int), na ponad 1300 testów nie działa tylko kilkanaście. Podsumowanie od autora sprzed kilku dni tutaj: ->link<- - mocno już nieaktualne, bo wtedy failowała jeszcze połowa :)

    Ze swojej strony cisnę wsparcie dla 6502 w Rust - jakiś czas temu dodałem obsługę target triple dla mos-6502: 'mos-unknown-none' i od kilku dni jestem już w stanie budować binarki bezpośrednio za pomocą cargo :) więcej szczegółów tutaj: ->link<-
    • 20: CommentAuthorpirx
    • CommentTime17 Jun 2021
     
    oh boy
    • 21:
       
      CommentAuthorEnjo
    • CommentTime18 Jun 2021 zmieniony
     
    Teraz dodajcie to, że kolega napisał zestaw zasad ulepszających optymalizację kodu (nie pamiętam gdzie to było. Na Atariki?). Można by dodać te zasady do clang-tidy jako kolejny moduł.

    (clang-tidy to narzędzie LLVM do statycznej analizy kodu)
    • 22: CommentAuthormrk
    • CommentTime20 Jun 2021
     
    Aktualny status: ->link<-
    • 23: CommentAuthorPeri Noid
    • CommentTime20 Jun 2021
     
    Że tak zapytam: jak to się ma do cc65? Pomijając fakt, że cc65 chyba stanęło w rozwoju. Chodzi mi o możliwości i kompatybilność źródeł.
    • 24:
       
      CommentAuthorjhusak
    • CommentTime20 Jun 2021
     
    CC65 się powolutku dowija, czyli: błędy i optymalizacje, oraz pewnie nowe architektury, jak już.
    Natomiast C++ czy Rust na Atari to już petarda (pomijając sensowność C++ na kilkudziesięciu kilobajtach pamięci).
    • 25: CommentAuthormrk
    • CommentTime21 Jun 2021 zmieniony
     
    Z kompatyblilnością powinno być dobrze: cc65 to ANSI C (prawie), clang to C99, czyli powinien być kompatybilny w dół z cc65. Oczywiście gorzej trochę będzie na początku z bilbliotekami - llvm-mos zawiera na razie szczątkową bibliotekę libc, brak oczywiście na razie bibliotek dla poszczególbych platform) - ale mam nadzieję że zostanie to szybko nadrobione (i nie liczę tu na obecnych autorów llvm-mos ale raczej na społeczność).

    Mi na przykład udało się bez problemu skompilować wszystkie kroki z "CC65-Advanced-Optimizations" @ilmenit'a bez zmian w kodzie samego programu (game.c), musiałem jedynie dodać kilkulinijkowy "atari.h" i poprawić nieco benchmark.h
    • 26: CommentAuthorilmenit
    • CommentTime21 Jun 2021
     
    CC65 jest wciąż rozwijany, ale bardzo rzadko kwestie optymalizacji. Większość rozwoju idzie w lepsze wsparcie różnych platform.
    CC65 robi bardzo mało high-level optymalizacji i tutaj już teraz LLVM jest bez porównania lepszy. Optymalizacje takie można robić "ręcznie", ale dobry kompilator wiele z tego, co zrobiłem w tym artku na githubie, powinien zrobić automatycznie. Wątpię jednak, że będzie niektóre rzeczy (jak zastępowanie wskaźników indeksami tablic) robił, ponieważ nie ma takiej potrzeby w "większych procesorach". Ale kto wie, współczesne optymalizatory robią czasem cuda.
    CC65 ma całkiem dobry (choć daleki od ideału) peephole optimizer i tutaj będzie sporo pracy nad LLVM. Jak dobrze może zrobić niskopoziomowe optymalizacje zależy od założeń odnośnie stosu, sterty czy strony zerowej, które przyjął autor tego backendu LLVM.
    • 27: CommentAuthortebe
    • CommentTime21 Jun 2021
     
    ->link<-

    taki uniwersalny, konfigurowalny kompilator do wszystkiego ;)

    FPC (Free Pascal Compiler) dla LLVM

    ->link<-