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.
    • 20: CommentAuthormrk
    • CommentTime30 Jan 2022
     
    Ź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: CommentAuthormrk
    • CommentTime20 Feb 2022 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' :]
    • 22: CommentAuthormrk
    • CommentTime26 Feb 2022 zmieniony
     
    Pierwsze oficjalne wydanie llvm-mos: ->link<-

    Polecam zapoznanie się z listą 'What you get' w linku wyżej
    • 23: CommentAuthorilmenit
    • CommentTime26 Feb 2022
     
    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:
       
      CommentAuthorcrrn
    • CommentTime26 Feb 2022 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: CommentAuthorilmenit
    • CommentTime26 Feb 2022
     
    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: CommentAuthormrk
    • CommentTime26 Feb 2022
     
    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: CommentAuthormrk
    • CommentTime26 Feb 2022
     
    @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: CommentAuthor0xF
    • CommentTime28 Feb 2022
     
    1. Jak wygląda współpraca z Altirrą w kwestii debugowania?
    2. Czy jest jakieś wsparcie dla profilowania?
    • 29: CommentAuthormrk
    • CommentTime28 Feb 2022 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: CommentAuthormrk
    • CommentTime1 Mar 2022
     
    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: CommentAuthorilmenit
    • CommentTime1 Mar 2022
     
    @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:
       
      CommentAuthorjhusak
    • CommentTime1 Mar 2022 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: CommentAuthormrk
    • CommentTime1 Mar 2022 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: CommentAuthormrk
    • CommentTime6 Jun 2022 zmieniony
     
    Ciekawosta: prezentacja o llvm-mos na tegorocznej konferencji EuroLLVM:
    - polecam!
    • 35: CommentAuthorlaoo
    • CommentTime7 Jun 2022 zmieniony
     
    No no. mrk, jesteś sławny!

    • 36: CommentAuthortebe
    • CommentTime7 Jun 2022
     
    poproszę zdjęcie widowni, kto tam siedział?