Wyobraźmy sobie taką sytuację, że jest jakiś procesorek, który nam idealnie pasuje sprzętowo (peryferia, obudowa). I na wyczucie przewidujemy, że da się w nieo upchnąć program jeśli bedzie zgrabnie napisany. A w C nie wchodzi w żaden sposób. Co wtedy? Zmieniać koncepcję całkowicie, tylko dlatego że jedno narzędzie jest niedorobione?
No zgoda, nie do końca taki sam :))))
To jest to do czego ja osobiście przywiązuję wielką wagę, ale nie każdemu musi przeszkadzać. Lubię panowac nad tym, co gdzie i kiedy zostanie w pamięci użyte. Wiedząc jak działa program w czasie rzeczywistym (jaki proces kiedy się uruchomi a kiedy nie), czego kompilator C wiedzieć nie może, mogę swododniej zarządzać mniejszą pamięcią uzyskując jej większą wydajność.
Jest to prawdą, że poradzenie sobie z problemem banków flash jest upierdliwe, ale tylko w przypadku gdu program napisany jest "na żywioł". I problem banków wynika w trakcie i program nie był do niego od razu przystosowany. Czy C potrafi tak rozmieścić kod w pamięci programu, że skoków między bankami jest optymalnie mało w czasie i przestrzeni? Wątpię. A jeśli nie potrafi, to duża ilość programu i czasu pracy procesora (w być może krytycznych momentach) pójdzie na bezsensowne trzaskanie bankami.
Chesz powiedzieć, że jeśli w 18f8720 są błędy w sprzęcie, to procedury C potrafią je obejść? ;)
W jakim sensie nie wchodzi? Do pamięci, czy nie spełnia wymagań czasowych?
Należy się zastanowić, _dlaczego_ nie chodzi i rozwiązać problem. Jeśli nie jest dostatecznie wydajny, to należy zlokalizować miejsca odpowiedzialne za powstawiane wąskich gardeł, a następnie spróbować je poprawić, w pierwszej kolejności na poziomie algorytmicznym, a dopiero po wyczerpaniu się pola manewru na poziomie implementacyjnym. Jeżeli rozwiązanie wymaga użycia asemblera, to bezwzględnie należy go użyć. Tylko należy skupić się na rozwiązywaniu rzeczywistych problemów, przepisując w asemblerze krytyczne czasowo lub layoutowo fragmenty, a nie cały program. Istnieje pewna nieformalna, oparta na obserwacjach heurystyka o nazwie 90-10, która mówi, że typowo za 90% czasu wykonania programu jest odpowiedzialne 10% kodu. Popraw więc te 10%, a nie przepisuj całego programu, bo to nie ma najmniejszego sensu.
Czasami istotnie jest niedorobione, ale obawiam się, że w większości przypadków problemy są spowodowane niedostatecznymi kompetencjami twórcy programu i zwalane na narzędzie, bo przecież ono w mordę nie da. :-)
To panuj. Jaki to ma związek z C?
Asembler też tego nie wie. Tylko Ty to wiesz. I możesz to równie dobrze powiedzieć asemblerowi, jak i kompilatorowi C, jeśli tylko potrafisz.
A co Ci przeszkadza samemu napisać własny podsystem zarządania pamięcią w C? W C++ to już w ogóle jest prosto, placement new, przeciążanie operatorów new i delete itp.
Ale ja dalej nie wiem, po co Ci ona, skoro mieścisz się w marginesie akceptowalnego czasu działania programu.
Tylko należy skupić się na rozwiązywaniu rzeczywistych problemów,
A dlaczego przepisywać a nie napisać od razu wydajniej? ;) Czy to nie jest 2 razy więcej pracy?
Istnieje pewna nieformalna, oparta na obserwacjach
Rozumiem, że jest to zaimportowana na potrzeby informatyki zasada 20-80, znana w okresie przedelektronicznym w teorii marketingu ;)
Asemblerowi wcale nie muszę mówić.
Skoro jest aż tak łatwo i wszystko pod kontrolą...
Programy które piszę, z reguły wymagają gimnastykowania się co do rozmieszczenia instrukcji nawet w asemblerze, bo jeden cykl rozkazowy za dużo potrafi mi rozwalić potok pracy urządzenia a w najlepszym wypadku pogarsza parametry. Więc C tu nie widzę nijak.
Jeśli mowa o procesorach z mikroskopijną pamięcią, to istotnie asembler może pomóc. Jednak w przypadku średnich mikrokontrolerów z 64+ KiB pamięci nie wydaje mi się to wiarygodne. Sam takie programowałem w C i jakoś wszystko się mieściło.
Ale po co? Słowo-klucz: prawo Amdahla. Jeśli dokonując cudów optymalizacji również te 90% kodu zajmującego 10% czasu wykonania przyspieszysz pięciokrotnie (a tu mi kaktus...), to w porównaniu do programu ze zoptymalizowanymi kluczowymi
10% uzyskasz poprawę o 1/((1-0.1) + (0.1/5)) * 100% = 8,7%. Normalnie rewelacja, warta lat wyrzeczeń i poświęcenia! Mamusię oszukasz, tatusia oszukasz, ale matematyki nie oszukasz... :-)))
Zanim zaczniesz "optymalizować" -- policz to i owo...
Nie sądzę, by informatyka rościła sobie prawo pierwszeństwa do tej zasady. Jedynie intensywnie z niej korzysta, bo dość dokładnie oddaje ona rozkład czasu wykonania w typowym programie.
No to to musi być jakiś asembler z Hogwartu, bo te niemagiczne tego nie potrafią.
A jeśli przyjdzie przerwanie, to stracisz więcej niż cykl i dopiero będzie targedia...
"Kiedy rum zaszumi w głowie Cały świat nabiera treści Wtedy chętnie słucha człowiek Morskich opowieści"
Może to zabrzmi zabawnie ale czasami warto prototypować algorytm w innym języku niż docelowy. Np. pisząc w asm/C dla ARMa w moim ostatnim programie najpierw sprawdziłem działanie pomysłu algorytmu w Pythonie. Python ma operatory bitowe więc było to jak najbardziej możliwe. Później po przetestowaniu słuszności zastosowanego algorytmu mogłem się tylko skupić się na jego implementacji.
(czyli zabawa w alokację rejestrów dla zmiennych/stałych, układanie kodu aby load/store było raczej przez ldm/stm kiedy to możliwe, wykorzystywanie egzekucji warunkowej dla maksymalnej korzyści, etc.)
Imho warto rozdzielić te dwie rzeczy - programowanie algorytmu i jego implementację. Mniej męczenia się z bugami po drodze i nawet jeśli zajmuje to więcej czasu to zyskuje na tym jakość kodu wynikowego. :)
Czemu dziwne? Ja przed zapisaniem algorytmu w VHDL dokładnie go modeluję i dostrajam w C++.
No i o to chodzi.
"projektowanie". ;-)
No co Ty, przecież po zastosowaniu sztuczek rodem z Harrego Pottera można przyspieszyć program wynikowy prawie o całe 9%! Kto by się w obliczu takiego zysku przejmował jakością kodu źródłowego...
Używając trików z maskowaniem można zwykłe skalarne ALU zmusić to wektorowyc obliczeń w niektórych sytuacjach... Mój mikser RGB 16BPP właśnie tak pracuje i na Arm9 wydajność ogranicza dostęp do pamięci a nie ilość cykli dla cpu. (a ręczne używanie flag dla conditional executing jest bardzo dobre dla np. maskowania pikseli)
Ponad to kompilator C nigdy nie będzie aż tak agresywny z wykorzystaniem rejestrów a czasami nawet jeden Rxx więcej potrafi zrobić wielką różnicę.
Nawet dla zwykłych prymitywnych pętli zwykle daje się pokonać kompilator ale oczywiście wszystko w granicy rozsądu. Te 10 procent kodu, które zarzynało cpu w 95 procent to był asembler - reszta w C bez specjalnego zachodu bo po profilowaniu wychodziło, że zyski byłyby poniżej 0,5 procenta.
Ale rozmawialiśmy o czymś takim jak PIC z powiedzmy 1K dla instrukcji. Tutaj tylko asembler ma sens bo to będzie raptem tylko 1K linijek kodu. PIC jest fajny bo prosty ale jak się rozumie jego prostotę i potrafi to wykorzystać. Przecież nie mówimy tu o jakiś wielkich programach - mój projekt robił cały globalny loop w 41 cykli a ile by robił napisany w C dla 14-bitowego PICa? Napewno o wiele więcej jak sądzę o chodziło o zwykły 4bit->16 dekoder (mógłbym zejść bliżej 30 cykli likwidując subprocedury call/return). (a to ma znaczenie ponieważ większy zegar = więcej prądu więc tutaj uzysk nawet 10 cykli to byłoby nie byle co)
Nie zmienia to faktu, że tylko czekam aż wreszcie dostanę te moje CPLD, które zamówiłem już jakiś czas temu (...) to zastanawianie się nad PICem pójdzie w odstawkę. :)
Choć z drugiej strony... tyle zmiennych jest kiedy rozpatrując możliwą implementację - rodzaj opakowania, napięcia zasilające, potrzebne narzędzia (zarówno soft i hard i ich koszt), ile scalak żre prądu, czy są jakieś dodatkowe wymagania (np. zewnętrzne taktowanie czy też rezystory na wejściach aby one nie pływały), potencjalne sytuację awaryjne (np. bez wyłączenia programowania niskonapięciowe w PICach można bardzo ładnie sknocić projekt), jakieś erraty, akceptowane czasy opóźnień reakcji na sygnały...
Muszę przyznać, że mam od tego straszny kociokwik nawet przy tym moim (prostackim?!) pierwszym sprzętowym projekcie jaki robię...
No dobrze, ale wlasciwie o czym mowimy? O seriach urzadzen 1milion sztuk, gdzie roznica w cenie w wysokosci 10 centow przeklada sie na sensowny zysk czy o produkcji jednostkowej / hobbustycznej i maloseryjnej (rzedu kilkuset - kilku tysiecy sztuk)? Jesli to drugie, to uzywanie PICa kompletnie nie ma sensu. Porzadny procesor, w rodzaju ATMEGA88, kosztuje 5 zyka. I na tym procku C smiga bardzo dobrze.
Ależ oczywiście, tylko w większości przypadków wystarczy sobie poowijać instrukcje wektorowe wstawkami asemblerowymi ukrytymi w funkcjach inline i następnie używać tych funkcji w C. Niektóre kompilatory mają te funkcje wbudowane, na przykład kompilator Intela ma cały zestaw funkcji intrinsic do operacji MMX oraz SSE. Jeśli kompilatorem jest GCC (a na sporą liczbę mikrokontrolerów jest on dostępny), to sobie takie funkcje potrafię napisać sam w oparciu o bogate rozszerzenia tego kompilatora. A jeśli chcę mieć pełną kontrolę nad postacią kodu wynikowego, to sobie mogę napisać odpowiednią wstawkę blokową, z czego dość często korzystam. Dzięki temu w asemblerze mam tylko to, co musi być w asemblerze, a nie dodatkowo jakieś kody inicjalizacyjne, pętle obsługi komunikatów itd. -- przecież to byłoby bez sensu.
Owszem, i właśnie na te "czasami" zostały przewidziane wstawki. Zazwyczaj jednak jest wszystko jedno, jak kompilator przetłumaczy dany fragment kodu, o ile jakość przekładu będzie w granicach rozsądku.
Kompilator daje się pokonać zawsze, to tylko kwestia wysiłku. Tylko rzadko kiedy jego pokonywanie ma sens. A jeśli z pomiarów wychodzi, że ma -- to na tespecjalne okazje są specjalne narzędzia w postaci m.in. wstawek asemblerowych.
I dokładnie o tym mówię. Tylko tutaj człowiek z jakichś dziwnych przyczyn jednak chce walczyć o te 0,5 procenta pisząc wszystko w asemblerze. Sądzę, że powodem było niewykonanie odpowiednich obliczeń, których wyniki są często sprzeczne z intuicją.
I w jego przypadku asembler może być jedynym rozwiązaniem. Ale takie małe procki już powoli wymierają, pojawiając się w sklepach w cenie złomu. Ja sobie do drobnych zadań kupiłem
10 AVRków z 2KiB pamięci po 2,90 zł./szt., do większych mam ARMy.
Właśnie tak też wyglądał mój kod - C + inline asembler dla niskopoziomych/szybkich funkcji - czyste C dla logiki ogólnej.
Myślę, że bardziej to, że dla niewielkich programów to można napisać kod w prostym asemblerze takim jakim ma np. PIC od ręki... Dla np. funkcji w rodzaju sterowania pinanmi korzystając ze wcześniej zapisanych wzorów w tablicy to nie jest wielkie wyzwanie do zrobienia w asemblerze. :)
Pakowanie się w C dla programu liczącego z 100-150 linijek asemblera może się tu rzeczywiście wydawać dziwne.
Przy milionie sztuk to się zamawia gotowy specjalizowany scalak, a nie chrzani w programowanie...
Jesli to drugie,
Osobiście nie znam firmy, która produkuje urządzenia w ilosciach pięciocyfrowych. Moja najbardziej dojna krowa w ciągu 10 lat została wytworzona w ilości zaledwie kilku małych tysięcy. Na początku napędzana była 87c51, potem 89c51 potem PIC-em a druga część zestawu najpierw motorolą, teraz pic-em. I jakoś nie zauważyłem, żeby przechodzenie z procesora na procesor ksztowało tyle, że się to nie opłacało. Zawsze się opłacało. Mimo rzeźbienia w asemblerze ;)
Największy program jaki napisałem na pojedynczego jednoukładowca ma jakieś 35Ksłów i wkrótce (po dodaniu nowych opcji) osiągnie 45Ksłów. Przed zmianą procesora na najnowszy, z dużą ilością flash, gdyby został napisany z C, wtedy wraz z danymi użytkownika nie zmieściłby się w
65Ksłowach. SPRAWDZONE! Zaraz ktoś powie, że trzeba (było) zmienić procesor na inny, innej firmy... ;)
Zaznaczam, że nadal poruszam się w tym wrażym programie asemblerowym swobodnie. Bo, jak ktoś już wspomnieł, nie jest to kwestią języka. Natomiast programy w C czytają mi się źle. Pewnie rzecz przyzwyczajenia...
Prawda jest taka, że pochopne sięganie po relatywnie duże (do potrzeb projektu) układy scalone odbija się często czkawką w postaci problemów z urządzeniem. Bo duży układ to układ z większą iloscią błędów i większą awaryjnoscią. Tak samo bez potrzeby nie wali sie zegara 40MHz, jeśli
4MHz wystarcza. Na tym kończę swój udział w tej dyskusji ;)
Użytkownik "A.Grodecki" <ag.usun snipped-for-privacy@modeltronik.com napisał w wiadomości news:e0lpsj$aae$ snipped-for-privacy@nemesis.news.tpi.pl...
To zależy od błędu :) Jeśli producent niedostatecznie przetestował hardware (bo używał tylko jednej procedury), a kompilator tej procedury używa, i gwarantuje to poprawny wynik - wtedy jest to jakieś "obejście" - bo błąd polega na tym, że nie każdy sposób obsługi jest prawidłowy. Jeśli hardware jest tak skopany, że nie istnieje żaden gwarantowany sposób na poprawne działanie, no to wtedy chyba wszystko jasne... W każdym razie nie miałem na myśli automatycznej emulacji programowej nieudanego hardware :)
Np takie, że czasami debuger sobie a procesor sobie... Czytaj erraty, errata jest tak samo ważna a nawet ważniejsza od dokumentacji podstawowej. Z tego co się orienuję, to dużo lepiej jest użyć czegoś z końcówką 22 lub 27, jeśli chodzi o najnowsze serie. Co nie znaczy, że nie ma tam błędów. Są, np port szeregowy im zdecydowanie nie wyszedł i czasami dzieją się rzeczy trudne do obejścia. SPI... na szczęście nie używam sprzętowego. Generalnie dochodzę do wniosku, że wszystko schodzi na psy - w ciągłej walce o dominację zapomina się, że przede wszysykim produkt musi być dopracowany. Czasy prostego przejścia z jednego procesor na drugi, powoli odchodzą w niebyt. NIe wystarczy przerobić procesor na nowy sprzęt, trzeba go jeszcze przerobić adekwatnie do błędów w nowym sprzęcie.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.