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:
      
     CommentAuthorpirx
   • CommentTime7 Oct 2020

    
2. • 2:
      
     CommentAuthorlaoo
   • CommentTime7 Oct 2020

    
   Oglądałem to. Facet jest łebski, ale to co tu zrobił jest bardzo słabe.
   
   Więcej nadziei pokładam w tym projekcie: ->link<-
3. • 3: CommentAuthorastrofor
   • CommentTime7 Oct 2020

    
   Patrząc jak obiektowość działa w mad pascalu, a z tego co widziałem to wymagało to bardzo dużo czasu i wysiłku aby podstawowe obiektowe rzeczy były stosunkowo stabilne i wydajne, to ten projekt wydaje mi się nierealny. Bardziej sensowna wydaje się dyskusja czy używać pure assemblera, czy jakieś nakładki nieco wyższego poziomu, jak mad pascal, action! itd.
4. • 4: CommentAuthorilmenit
   • CommentTime7 Oct 2020 zmieniony

    
   Wszystko zależy od kompilatora. Współczesne GCC czy LLVM potrafią bardzo dobrze optymalizować kod - na tyle, że narzut np. na funkcje wirtualne jest bliski zeru. Ale niezależnie od tego jak dobry będzie optymalizator, niektórych rzeczy na 6502 się nie przeskoczy - np. wskaźniki gdy mają adresować przestrzeń 16bit będą wolne, dostęp do pamięci alokowanej dynamicznie będzie wolny). Nawet w silnie optymalizowanym C++ trzeba by pisać w stylu Action!, aby kod był szybki. Dla mnie istotne, aby pisany tak "niskopoziomowo" kod był szybki - tu Mad Pascal ostatnio mocno się poprawił i przeskoczył CC65. Ale na horyzoncie jest też sporo nowych języków, które testuje teraz na AtariAge Zbyti.
5. • 5: CommentAuthorastrofor
   • CommentTime7 Oct 2020

    
   Szkoda że jest tak mało przykładów, obiektów z otwartym kodem pokazujących obiektowe możliwości c albo mad pascala, ja osobiście znam tylko gitlaba Bociana gdzie pare projektów faktycznie ma obiekty.
   
   Inna sprawa, dla kogo jest to ułatwienie, bo mi się wydaję że to nie działą tak że słabo znam architekture atari, więc jezyk wysokopoziomowy mi w tym pomoże, ale bardziej tak że świetnie znam architekture atari, świetnie znam kompilator języka w którym piszę i wtedy ten wysokopoziomowyjęzyk jest bardzo pomocny. Oczywiście to nie jestżaden zarzut, tylko smutne wyznanie trudnej prawdy.
6. • 6: CommentAuthor0xF
   • CommentTime7 Oct 2020

    

   C:\0\src>cat hello.cpp
   #include <iostream>
   
   int main()
   {
           std::cout << "Hello, world!" << std::endl;
   }
   
   C:\0\src>clang++ -s -O2 -Wall -static hello.cpp -o hello.exe
   
   C:\0\src>ls -l hello.exe
   -rwxr-xr-x 1 fox None 933888 Oct  7 17:06 hello.exe
   

   
   
   Program wypisujący "Hello, world!" ma prawie megabajt na Intelu. Na 6502 to będzie dużo więcej. Na pewno tego chcecie?
   
   

   ilmenit:

   Wszystko zależy od kompilatora. Współczesne GCC czy LLVM potrafią bardzo dobrze optymalizować kod - na tyle, że narzut np. na funkcje wirtualne jest bliski zeru.

   
   Ciekawe. Jakieś szczegóły lub link?
7. • 7:
      
     CommentAuthormgr_inz_rafal
   • CommentTime7 Oct 2020

    
   Tydzień temu robiłem podobną prezentację dot. Rusta i Atari :D
   
   Nagrania jeszcze nie widzę, ale to dobrze, bo daleko mi do takiego szołmena jak Jason. Ciężko mi się gada jak nie ma ludzi tylko kamerka :P
   
   Zgadzam się z laoo, że jedyna prawilna droga to dobry backend do LLVM, ale do tego to niestety trzeba:
   * poświęcić za dużo cennych heartbeatów
   * znać się :D
8. • 8:
      
     CommentAuthorCOR/ira4
   • CommentTime7 Oct 2020

    
   @ mgr_inz_rafal
   Wytnij z kartonu publikę,żarówę skieruj na twarz i poczuj się jak na przesłuchaniu-kamerki nie będzie widać,cień publiki owszem(jak ją lekko od tyłu podświetlisz i klimat będziesz miał ;)
9. • 9:
      
     CommentAuthormgr_inz_rafal
   • CommentTime7 Oct 2020

    
   Mądrego to aż miło posłuchać ;-)
10. • 10: CommentAuthorilmenit
    • CommentTime7 Oct 2020 zmieniony

     
    @0xF - Zakładam, że w Twoim przykładzie dołączana jest gigantyczna biblioteka standardowa. W przypadku kompilatorów dla 6502 każda platforma zwykle ma ręcznie napisaną w asmie bibliotekę standardową, która w przypadku Atari by musiała być mała. Ale i tak strumienie z C++ to byłaby przesada, bo użyte <iostreams> jest napisane na szablonach oraz zawiera masę symboli. Jeżeli się użyje innej części biblioteki standardowej <cstdio> to wynik jest zdecydowanie lepszy ->link<- czy ->link<-
    O tym właśnie pisałem "Nawet w silnie optymalizowanym C++ trzeba by pisać w stylu Action!" - przykłady dla CC65 wrzuciłem jakiś czas temu tu ->link<- . Nawet w przypadku biblioteki napisanej w asm trzeba wybierać sensownie czego użyć np. w CC65 użycie printf powoduje dołączenie kilku kilobajtów kodu do pliku wykonywalnego, bo funkcja jest gigantyczna (jedna funkcja robi masę rzeczy ->link<- ) i w generowanym kodzie nie może się równać pisaniu po pamięci ekranu.
    O ile można mówić, że biblioteka standardowa to część języka, "branżowym standardem" (np. w AAA lub mobile gaming, databases, interpreters, drivers, security, real-time systems) jest to, że nie używa się biblioteki standardowej C++, ale własnych implementacji. Takie implementacje np. nie używają dynamicznych alokatorów w kontenerach (object pools, przeciw fragmentacji pamięci) lub wyjątków (narzut, nie działanie w ramach jądra systemu). Standard języka sobie, praktyka sobie ;-)
    A odnośnie optymalizacji wirtualizacji ->link<- lub ->link<-
    Ogólnie, współczesne kompilatory robią cuda przy optymalizacjach np. bardzo polecam zobaczyć ten fragment ->link<- albo ->link<-
11. • 11:
       
      CommentAuthorlaoo
    • CommentTime8 Oct 2020

     
    @ilmenit Można rozróżniać bibliotekę standardową od runtime'u. Bardzo duży kawałek biblioteki standardowej C++ to szablony w nagłówkach i one się bardzo ładnie potrafią skompilować. Wszystkie kontenery z STL przyjmują opcjonalne alokatory. Więc nie używanie tego dla jakiejś zasady jest po prostu głupie. Co najwyżej sensowne jest mieć własną implementację niskopoziomowych odwołań do systemu.
12. • 12: CommentAuthorilmenit
    • CommentTime8 Oct 2020

     
    @laoo - tak, runtime i biblioteka standardowa to nie to samo, szczególnie jak się idzie do współczesnego C++. Odnośnie STL - są alokatory dla trzymanych w kontenerach obiektów, ale oprócz danych są jeszcze wewnętrzne struktury danych dla konkretnych algorytmów, które nie są pod kontrolą piszącego. Ale w pełni się zgadzam - współcześnie STL się na tyle poprawił ze względu na szybkość (i jest wiele różnych alternatyw) że pisanie własnego ma coraz mniejszy sens. Może hedynie, gdy są ograniczenia platformy np. w obsłudze wyjątków. Cały STL bazuje na wyjątkach i choć można w kompilatorach wyłączyć rzucanie wyjątków, to przy problemach np. z alokacją funkcja wywala program, zamiast zwrócić NULLa.
13. • 13: CommentAuthor0xF
    • CommentTime8 Oct 2020

     

    ilmenit:

    <iostreams> jest napisane na szablonach oraz zawiera masę symboli.

    
    
    Zauważ, że symbole wyciąłem. Z symbolami ten exe ma prawie 3 MB. :)
    
    

    ilmenit:

    A odnośnie optymalizacji wirtualizacji ->link<- lub ->link<-
    Ogólnie, współczesne kompilatory robią cuda przy optymalizacjach np. bardzo polecam zobaczyć ten fragment ->link<- albo ->link<-

    
    
    To mój chleb powszedni. :)
    
    Wcześniej pisałeś "narzut np. na funkcje wirtualne jest bliski zeru", a chodzi o dewirtualizację. cito też ją robi przy generowaniu kodu C.
    
    

    ilmenit:

    to przy problemach np. z alokacją funkcja wywala program, zamiast zwrócić NULLa.

    
    
    Gdy skończyła się pamięć, zakończenie procesu jest dobrym pomysłem. Jest bardzo prawdopodobne, że nie starczy już pamięci na np. otwarcie pliku logu i zapisanie tam informacji o błędzie.
14. • 14: CommentAuthorilmenit
    • CommentTime8 Oct 2020 zmieniony

     
    "Gdy skończyła się pamięć, zakończenie procesu jest dobrym pomysłem."
    to racja, ale to mało przyjazne gdy aplikacja jest krytyczna z punktu widzenia continuity np. silnie zintegrowana z systemem operacyjnym czy na gwarancji jej działania bazują jakieś urządzenia. Można oczywiście pytać przed alokacją o ilość dostępnej pamięci, ale takie funkcje zwykle nie zwracają max. ilości dostępnej do alokacji przy fragmentacji pamięci (rozmiaru maksymalnego przydzielanego obszaru na stercie).
    O ile może nie wystarczyć pamięci na otwarcie pliku i zapisanie tam, to dobrą praktyką jest mieć plik logowania otwarty od początku działania programu :-)
15. • 15: CommentAuthortebe
    • CommentTime8 Oct 2020 zmieniony

     
    Szkoda że jest tak mało przykładów, obiektów z otwartym kodem pokazujących obiektowe możliwości c albo mad pascala, ja osobiście znam tylko gitlaba Bociana gdzie pare projektów faktycznie ma obiekty.
    

    
    lib\graphics.pas
    lib\objects.pas
    lib\cmc.pas
    lib\mpt.pas
    lib\rmt.pas
    lib\highmem.pas
    
    przykłady użycia
    txtout.pas ->link<-
    cmc, mpt, rmt ->link<-
    TMemoryStream ->link<-
16. • 16:
       
      CommentAuthorpirx
    • CommentTime8 Oct 2020

     
    rozpocząłem najciekawszy wątek na aol od lat :] brawo ja
17. • 17: CommentAuthor0xF
    • CommentTime8 Oct 2020

     
    Brawo Pirx!
18. • 18: CommentAuthornome
    • CommentTime9 Oct 2020 zmieniony

     
    @0XF
    Gdzieś Ty testował ten program, to chyba z DEBUG INFO?
    
    nome@asx-comp:~/cpp$ cat hello.cpp
    #include <iostream>
    
    int main()
    {
    std::cout << "Hello, world!" << std::endl;
    }
    nome@asx-comp:~/cpp$ g++ -o hello hello.cpp
    nome@asx-comp:~/cpp$ ls -l hello
    -rwxr-xr-x 1 nome nome 17256 paź 9 21:28 hello
    nome@asx-comp:~/cpp$
    
    Poza tym plik wykonywalny zawiera różne sekcje i jego rozmiar nie świadczy o wielkości wygenerowanego kodu
    
    W tym przypadku rozmiar sekcji .text to 0x01e1 a sekcji .rodata to 0x0013
    
    Oczywiście pozostają jeszcze biblioteki dynamiczne - ale to jako ROM w ATARI
    
    A przy statycznym linkowaniu tak jak u Ciebie cały niepotrzbny bagaż się wlecze. Ale mogę tak opisać bibliotekę, że zlinkują się tylko potrzebne funkcje. i kdo będzie dużo mniejszy.
    Tak na marginesie pierwsze implementacje C++ to był preprocesor języka C.