Tak apropo optymalizacji przeprowadzanej przez współczesne kompilatory - artykół na temat problemów z implementacją dość prostego algorytmu: https://www.researchgate.net/publicatio ... ed_Locking

Interesujące bo dopiero po przeczytaniu tego dowiedziałem się jak dużo swobody ma kompilator c++ przy decydowaniu o kolejności działań. Artykół jest z 2004 - ponoć dopiero w 2011 wprowadzono do standardu c++ pozwalające napisać ten kod w 100% bezpiecznie
W pewnym sensie zetknąłem się z podobnym problemem w praktyce - kompilator c firmy windriver na procesory arm - generował bardzo szybki i wydajny kod ale debugowanie było bardzo upierdliwe bo kolejność wykonywania linii była inna od oczekiwanej, nie dało się postawić pułapki w blokach typu
If (a)
B++

Bo potrafił je skrócić do pojedynczej instrukcji itd.
Co gorsza - nie dało się tych optymalizacji wyłączyć bo traktował je jako poziom podstawowy.
Trochę znam asembler arm - ale z całą pewnością nie potrafiłbym napisać czegoś równie wydajnego w asemblerze Tak więc jestem w obozie "wstawki asm tam gdzie to absolutnie konieczne"

Kod pisany "ręcznie" nie musi być lepszy - czasem po prostu trzeba napisać kilka linii w asm żeby użyć bardzo konkretnej funkcji procesora w bardzo konkretny sposób. Przykład z mojego podwórka, funkcja wymuszająca przeładowanie cache kodu w procesorze- dokumentacja wymaga żeby po zapisie w rejestrze następna instrukcją był NOP - albo piszesz dwie linie w asemblerze, albo kod w C i się modlisz żeby kompilator czegoś nie "zoptymalizował".

tuxcnc pisze: ↑

15 lis 2022, 19:27

Ogólnie to ten kod miał być tylko przykładem, że nie tylko warto znać budowę procesora na który się pisze kod, ale nawet czasem jest to konieczne.
Tutaj (STM32) jest na przykład taka heca, że procesor jest 32-bitowy, ale licznik tylko 16-bitowy. Skąd ktoś traktujący procesor jako "czarną skrzynkę" ma wiedzieć jakiego typu zmiennych użyć?
Oczywiście ktoś piszący program na peceta nie musi wiedzieć co to jest tablica deskryptorów, ale jakieś ogólne pojęcie o budowie procesora mieć trzeba, choćby żeby wiedzieć dlaczego bardzo podobny kod wykonuje się dziesięć razy wolniej...

W niektórych sytuacjach jest to konieczne - ale taki kod warto schować w odzielnym pliku albo przynajmniej wydzielonych funkcjach opisanych jako dedykowane do konkretnego sprzętu.
Ale czasami poleganie na konkretnej architekturze może się bardzo zemścić. Parę lat temu miałem "przyjemność" pracować przy portowaniu na ARM kodu napisanego pod Motorolę 68k. Autorzy orginalnego kodu (ze wstydem przyznam że jestem jednym z nich) uprościli sobie życie wykorzystując fakt że Motorola 68k jest "big endian" i podczas interpretacji danych z portu szeregowego albo eeproma może odczytać wartości 32bit wprost z binarnego bufora, bez żadnych dodatkowych deklaracji. ARM (tak jak x86) jest "little endian" i czytał głownie brednie...
Z drugiej strony - libpng (http://www.libpng.org/pub/png/libpng.html ). Można ją bez problemu skompilować pod windows i linuxem x86. Można ją skompilować pod Motorolę 68k. W razie potrzeby można zdefiniować własny alokator pamięci (przydaje się przy systemach "bare metal", nie posiadających malloc/free) - po prostu coś pięknego
Albo FatFs (http://elm-chan.org/fsw/ff/00index_e.html) - implementacja FAT16,FAT32 i extFAT - chodzi praktycznie na wszystkiem. W konfiguracji można wyłączyć wszystko co niepotrzebne (np. zostawiać sobie "read only" FAT16, albo ReadWrite ze stałą datą modyfikacji pliku jeśli nie mamy RTC) i zredukować wilkość kodu do minimum. Jest nawet wersja działająca na mikorkontrolerach z ilością ramu mniejszą niż wielkość sektora na karcie SD... po prostu coś pięknego

tuxcnc pisze: ↑

15 lis 2022, 19:27

Z czego następnym razem każecie mi się tłumaczyć?
KOD JEST DOBRY I NAPISANY ZGODNIE Z ZASADAMI !

nigdy nie pracowałem na stm32 ale kolega z biura tak i parę rzeczy obiło mi się o uszy...
https://micromouseonline.com/2013/01/13 ... -approach/

tuxcnc pisze: ↑

15 lis 2022, 15:25

Kod: Zaznacz cały

if (TIM2->CR1 & 0x10)
  {
          timer2_ovf-=0xFFFF;
  }
  else
  {
          timer2_ovf+=0xFFFF;
  }

Pozwolę sobie skrytykować:
1. Kod jest kompletnie nieprzenośny.
2. Nie zawiera komentarza wyjaśniającego co dokładnie robi i dlaczego - jeśli dasz go komuś kto nie zna tego konkretnego procesora tak dokładnie jak ty albo dostanie go bez informacji na jaki proc jest przeznaczony to... będzie wesoło
3. Jest prawdopobne że nowoczesny kompilator zoptymalizowałby kod bez twojej "pomocy"

tuxcnc pisze: ↑

15 lis 2022, 13:53

Jak dla mnie, to kolejny język dla debili, dla których procesor to czarna skrzynka, do której nie wolno zaglądać, bo i tak się nie zrozumie...
Cóż, "programiści" którzy niczego nie rozumieją, ale pamiętają co trzeba napisać żeby zadziałało, to prawdziwa plaga.

Nie da się oceniać języka na podstawie "hello World" (może poza brainfuckiem i podobnymi żartrami) - gdyby było inaczej wszyscy byśmy pisali w perlu albo pythonie. Rust powstał jako narzędzie do rozwiązywania konkretnych problemów np. pisania bezpiecznych, wielowątkowych programów. W przeciwieństwie do C potrzebne do tego elementy są dostępne na poziomie składni języka a nie biblioteki dzięki czemu kompilator może wychwycić więcej błędów.
Oczywiście - możesz powiedzieć że dobry programista uzyska ten sam poziom bezpieczeństwa używając c i pthread a reszta świata powinna się dokształcić zamiast tracić czas na tworzenie nowych narzędzi ale to niezbyt realistyczne podejście...

Avalyah pisze: ↑

15 lis 2022, 11:32

Ale autor chce C, nie C++. A pełna kompatybilność idzie C->C++ a nie odwrotnie

C nie ma "pełnej kompatybilności" z c++ - chyba że w nowych wersjach standardu c coś dodano.
Na przykład w c (przynajmniej według starego kompilatora) legalne jest użycie funkcji przed jej deklaracją - kompilator wprawdzie ostrzeże ale skompiluje taki kod używając domyślnych typów argumentów. Kompilator c++ uzna ten kod za niekmpilowalny.
Teoretycznie są to tylko drobne szczegóły i programista które takie śmiecie zostawia w swoim kodzie jest niekompetentny - ale właśnie takie drobiazgi powodują że C jest uznawany za przestarzały i niebezpieczny

tuxcnc pisze: ↑

14 lis 2022, 19:26

Szczerze mówiąc o Rust nigdy nie słyszałem,

linuxa kernel 6.1 najprawdopodbniej będzie supportował rust (z tego co zrozumiałem - jako język do pisania nowych modułów) więc pewnie niedługo usłyszysz
https://thenewstack.io/rust-in-the-linux-kernel/

Ja tylko dodam że jeśli planujesz programować w c++ to NIE musisz zaczynać od c
Co do literatury - 20 lat temu uczyłem się z "symfonia c++" Jerzego Grębosza i imho była to dobra książka - z tego co widzę ostatnia wersja to "Opus magnum C++11 Programowanie w języku C++" - też trochę przestarzała, ale podstawy aż tak się nie zmieniły...