logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

jaki jezyk programowania jest uzywany w DSP - assembler vs C

Freddie Chopin 18 Lut 2008 20:21 5578 8
  • #1 4819721
    Freddie Chopin
    Specjalista - Mikrokontrolery
    staralem sie znalezc temat, ktory odpowiedzialby na moje pytanie. liczylem, ze taki bedzie, jednak nie bylo [;

    czy do DSP stosuje sie assemblera, czy juz tylko C, a ludzi piszacych w assemblerze nie potrzeba w ogole, bo nikt powazny tego nie uzywa? w mikrokontrolerach assembler juz praktycznie nie istnieje, bo kontrolery sa szybkie i maja kupe pamieci, a do tego sa tanie, wiec kozysci z uzycia asm (mniejszy kod wynikowy i szybsze dzialanie) praktycznie nie maja znaczenia. czy w DSP jest podobnie?

    pytam, poniewaz osobiscie planuje zostac programista takowych procesorow i bardzo lubie sobie pisac w assemblerze, tylko nie wiem, czy umiejetnosc ta jest w ogole cos warta dzis, kiedy wszystkie procki maja kupe pamieci i sa bardzo szybkie. wydaje mi sie, ze jest to jeszcze jednak cecha pozadana - moze nie dla kazdego projektu, jednak dla tych mniejszych, nie wymagajacych ogromnego kodu (szybkie aplikacje sterujace/pomiarowe/audio), assembler jest jak znalazl i wtedy kozysci z jego stosowania maja znaczenie...

    chetnie poznalbym jednak opinie innych. (;

    0x41 0x56 0x45!!
  • #2 4823435
    Zaquadnik
    Poziom 27  
    I właśnie z takich opinii, że po co pisać w asm, skoro procek szybki, to napiszę w C i będzie śmigać mamy niedouczonych informatyków, dla których słowo optymalizacja jest nieznane :P

    Ale do rzeczy, drogi kolego, nie wszystko da się zrobić w C dostatecznie szybko, zwłaszcza istotne jest to w DSP. Zatem asembler tutaj nie jest taki bezcelowy :]
  • #3 4825036
    Freddie Chopin
    Specjalista - Mikrokontrolery
    sa tacy, ktorzy twierdza, ze jesli nie da sie czegos zrobic w C, to taniej wychodzi wziasc szybszy procesor, niz bawic sie w assemblerze. procesor jest tanszy niz czas programisty

    osobiscie sie z tym nie zgadzam, jednakze to nie moje zdanie ksztaltuje rynek, jego wymagania i sposob realizacji wielu rzeczy...

    z tego co sam sie dowiedzialem od paru osob assembler jest ogolnie w DSP wciaz stosowany, tyle ze slyszalem tez pare opinii, jakoby bylo to malo przyszlosciowe, a opinie te byly od powaznych ludzi... stad moje watpliwosci.

    0x41 0x56 0x45!!
  • #4 4825101
    shg
    Poziom 35  
    Szybszy procesor jest tańszy niz czas programisty, jeżeli wykonuje się małą ilość urządzeń.
    Jeżeli natomiast urządzeń ma być milion, to lepiej na każdym procesorze zaoszczędzić po dolarze, a na programistów wydać nawet pół miliona. Zostaje jeszcze time to market, ale to można skompensować chociażby odpowiednio dużą ilością programistów w dobrze zorganizowanym zespole.

    Często wygląda to natomiast tak, że większa część programu pisana jest w języku wysokiego poziomu (najczęściej C), natomiast kilka najbardziej krytycznych procedur pisze się w asemblerze.
  • #5 4826433
    Freddie Chopin
    Specjalista - Mikrokontrolery
    tylko jaka firma robi miliony urzadzen [; przeciez raczej zdecydowana wiekszosc programistow dsp pracuje w firmach ktore najwyzej robia czegos na setki/tysiace w porywach.

    0x41 0x56 0x45!!
  • #6 4828625
    shg
    Poziom 35  
    Freddie Chopin napisał:
    tylko jaka firma robi miliony urzadzen [;

    Apple. 141 milionów iPodów. Wprawdzie to nie zupełnie procesor DSP, tylko zwykły ARM, ale zasada pozostaje, zresztą zestaw instrukcji ARM7 do DSP całkiem dobrze się nadaje.
    Chińczycy i ich tanie odtwarzacze mp3. Tam siedzą kości Sigmatel, a w nich klasyczny już DSP56xxx. Produkcja też idzie w miliony.

    Odtwarzacze DVD, Zestawy kina domowego, "wieże" ze średniej półki, komputery samochodowe (ale rzadko, najczęściej jest zwykły mikrokontroler), modemy DSL.
    Telefony komórkowe, najczęściej ARM, podejrzewam jednak, że tu soft pisany jest w C, ze względu na paskudnie krótki time to market, stanowczo za krótki, bo wiele telefonów ma błędy w oprogramowaniu.

    W każdym z tych urządzeń znajduje się przynajmniej jakiś jeden krytyczny fragment kodu napisany w asemblerze.
  • #7 4828714
    Freddie Chopin
    Specjalista - Mikrokontrolery
    czyli ogolnie assembler jeszcze nie umarl i umierac nie zamierza ? <: szkoda by bylo teraz czas tracic na cos, co sie w sumie nie przyda w przyszlym zawodzie...

    0x41 0x56 0x45!!
  • #8 4828742
    shg
    Poziom 35  
    Nie umarł i nie umrze, aczkolwiek może zostać "zdegradowany" do pozycji języka, który jest potrzebny tylko do napisania kompilatora. Stanie się tak, jeżeli pojawi się jezyk wysokiego poziomu, a właściwie to kompilator takiego języka, za pomocą którego będzie można uzyskać kod równie wydajny. Chociaż i tak zawsze pozostanie grupa entuzjastów asm.
    Znajomość asemblera przydaje się nawet jeżeli programuje się w C. Dobrze jest czasem podejrzeć, co wygenerował kompilator i czy nie dało by się tego zrobić lepiej. Kompilatory które mają optymalizer peep-hole (np. gcc) cierpią na taką wredną przypadłość, która objawia się tym, że jeżeli jakaś reguła nie została dla optymalizera ściśle zapisana, to taka optymalizacja nie zostanie wykonana. W takich okolicznościach pomaga na przykład zmiana kolejności wykonywanych operacji, tak żeby optymalizer mógł sobie tą sekwencję dopasować do wzorca.

    Zresztą asembler jest językiem bardzo prostym, wręcz banalnym. Za to programowanie w nim w większości przypadków proste już nie jest, chociaż są rzeczy, które łatwiej jest napisać w asemblerze niż w C. Tyczy się to głównie procedur przetwarzających duże ilości danych w powtarzalny sposób. Na przykład filtry FIR, ale w implementacji bezpośredniej, której używa się dla krótkich jąder przekształcenia. Dla długich używa się FFT, bo wtedy jest wydajniej, a to już w zasadzie łatwiej było by napisać w C.
    Ogólnie rzecz ujmując, pisanie w asemblerze szkieletu programu (pętle, instrukcje warunkowe, zmienne) jest zadaniem niewdzięcznym i tu o wiele lepiej sprawdza się C. Za to tam, gdzie trzeba "przemielić" porcję danych o wiele lepiej sprawdzi się asembler.

    Język C nie nadaje się niestety do wszystkiego. Ot, chociażby z pozoru banalna operacja pomnożenia dwóch liczb 32-bitowych, tak żeby otrzymać wynik 64-bitowy. Nie da rady bez zrzutowania czynników przed mnożeniem na 64 bity. Na 32-bitowej architekturze z jednej operacji mnożenia robią się trzy i do tego dwa dodawania. Na 8-bitowej jest to już wręcz tragedia.
    Rozwiązaniem jest tu funkcja napisana w asemblerze.
    Podobny przykład - instrukcja MAC.

    Inny przykład, operacja ROL / ROR użyta do "przekręcenia" jednej zmiennej, wyciągnięcia z niej bitu (MSb, albo LSb) i "wkręcenia" tego bitu do innej zmiennej. W asemblerze dwie instrukcje. W C musimy ręcznie bobrać wartosć bitu, przesunąć pierwszą zmienną, przesunać drugą zmienną i "wkleić" do niej bit, ale że C nie potrafi operawać pojedynczymi bitami, to po drodze ten "wyciagnięty" bit doprowadzić należy do postaci, którą będzie dało się "wkleić" do drugiej zmiennej (chyba, że na jednej zmiennej wykonujemy ROL, a na drugiej ROR, lub odwrotnie). Taką operację wykorzystuje się na przykład przy liczeniu sum kontrolnych, czy szyfrowaniu, czyli tam gdzie duza szybkosć działania jest jak najbardziej wskazana.

    Istnieją oczywiście biblioteki, które oferują tego typu funkcje, są też one czasem częścią API systemów operacyjnych. Jeżeli natomiast takiej biblioteki nie ma, to zamiast rozkładać ręce, po prostu sięga sie po asembler.
  • #9 4839999
    Xitami
    Poziom 29  
    http://www.dspguide.com/ch28/5.htm
    warto przeczytać, ale w sumie to nie wiem czy Szchaqu nie wyczerpał już tematu.
    Są i inne przykłady tego co potrafi specjalizowany procesor DSP.
    "Normalne" procesory też bywają nie normalne, np. SIMD czy inne MMiksy.
    Puki na rynku jest jakiś tysiąc różnych procesorów puty będzie się je jeszcze programowało asemblerem.
    Może kwantowość coś zmieni? Może, ale pożyjemy zobaczymy. Ale nawet wtedy pozostaje sprawa połączenia procesora ze światem, a to można zrobić na różne sposoby, zależnie od zastosowań, potrzeb itp.
    Wydaje mi się że jakiś kompromis zawsze będzie w tym zaklęty i tak zostanie na wieki wieków, amen.
    Myśląc assemler trzeba chyba brać też pod uwagę HDL, o coraz większej roli na rynku.
    Z jednej strony algorytmika, dzięki matematyce wiemy coraz więcej, a z drugiej materia, coraz więcej potrafimy zakląć w żelazie (a może nawet w czymś mniejszym), te dwa światy chyba na zawsze pozostaną rozdzielone,...
REKLAMA